Who are the Service Owners?

 Product Management, Service Management, SQM  Comments Off on Who are the Service Owners?
Dec 282011
 

As we enter the challenging environment of service management, one question arises naturally. We are managing the services but who owns them within the organization? The answer should be obvious but surprisingly it is not that simple for most operators.

In a typical SQM / Service Management project, we have to interface with the service owners. Service owners are the people who are accountable from the service and they know every details of the service. They are accountable from the technical performance of the service as well. Service owners, appear in IT CAB meetings, new product design processes etc. When compared to product managers, they are more technically involved in the service.

Readers who are familiar with the ITIL terminology will recognize the abbreviation, “RACI”. RACI stands for Responsible, Accountable, Consulted, Informed and it is used to describe the roles of the stakeholders within an IT organization. RACI is mostly applied to IT processes. However, it can be applied to products and services as well. According to ITIL;

– Responsible is the person who “does” the service. He/she is the person who executes the process/service.
– Accountable is the person who “owns” the service. This person is also called the service owner in different contexts.
– Consulted is the person who “knows” information about the service. The consulted person provides feedback about the service execution, also he is consulted in certain cases by the service responsible or accountable. The communication is bi-directional.
– Informed is the person who is “kept in the loop”. Informed people do not provide feedback to the other parties in the RACI.

Now, lets look at who could take the roles that are defined by the RACI.

Service Performance impacts Product Performance therefore the product managers should not be accountable for it, instead, they seem to be consulted. Product Management should be consulted about the changes that will be applied on the service as it directly impacts the product performance.

The responsible would be the operations, who runs the service. They are the people who fulfill, assure and bill it. As you can see, there are multiple groups that are responsible of the service.

But who is the accountable person for the service? It seems there should be a role which is missing in the chain. There needs to appear some “service managers” who are the real owner of the service in context. The service managers could be a separate functional group or they may carry additional responsibilities. This layer could be seen as a functional group that “overlays” on the top of the current functional organizational structure.

Each service component in the service tree can also be a sub service, either customer facing or resource facing. These services should also have owners and for the technical, resource facing ones, these would typically be individual departments within the operations. But for the customer facing services the “service manager” would again be required as the service authority.

It is important to differentiate the SOC (Service Operation Center) with the service owners. Service Operation Centers are a sub function of the monitoring function and they watch the service performance and orchestrate the necessary actions for service continuation. They watch OLAs and can notify the responsible departments about the violating conditions. (but they don’t push or force their manager’s anyway)

In today’s operator environment, it seems that the assurance departments (NOCs or SOCs) have owned the services naturally. This is not the right place as these departments do not have the authority for cross- organizational decisions. The “Service Manager” role will be more and more important in the process where the operators become more and more customer centric.

Customer Facing Services and the Granularity

 Product Management  Comments Off on Customer Facing Services and the Granularity
Jun 222010
 

According to TMForum, Customer Facing Service is a service that is represented as product offerings. This is quite explanatory. Another definition could be: Customer Facing Service (CFS) is any service that resides in the product/service catalog and interacts with the customer. A voice mail, site-to-site VPN, GSM voice, SMS etc. are all kinds of CFSs. The design of Customer Facing Services can be challenging. Inefficient designs may lead to other problems in business processes that manage these CFSs. Since our main goal is to reach to a more manageable, more automated and more flexible environment, our CFSs should be aligned with this strategy.

In this article, I will try to focus on the granularity (level of detail) of the CFSs. How granular our CFSs should be? This depends but if you want to implement “everything as a service” concept in your product/service design, you should have “very” granular services. When creating the most granular service, we should ask ourselves, “is this the least detailed sellable unit?” and “can I bind this, as standalone, to a product and bill separately?” Please note that, CFSs can be combined with other CFSs under one Product; there is no one-to-one relationship.

Ok. Let’s work on some examples now. Granular services concepts can be applied to datacenters. I have been in the design of such datacenter and two of the services we have worked were Bandwidth and Power. (Off course there were dozens of others but this two will be enough to explain the concept.)
Are these sellable and perceived by the customer? Do they, individually, represent the least detailed sellable unit? Yes. So, they are granular CFS candidates. What we can do next is to bundle these two CFSs under a Product Specification and offer it to the Market under different Product Offerings. Please note that, I still have the option to put one of these services under a different Product Specification and sell as standalone. The power of granularity comes into scene in here. Your Product Management and Marketing groups will have the option to create lots of combinations of these services to be offered which will increase our competitiveness.

The granular CFS should be sellable as standalone but this does not mean that you must sell them. For example, Power could be sold separately, but does it make sense for a datacenter? No. In theory, it could be sold but in real life you must bundle it with other granular services such as bandwidth, security, maintenance etc. and the best place to bundle related services could be the Product level. (You can also do this on the product offering level but that’s not the topic of today)

Suppose, our service provider does not have any intention to sell these services separately and launches one service named Co-Location Service. This co-location service has a monthly rate. Over bandwidth and power usages are rated and applied to the same service. Co-Location service is sold under the Co-Location Product. This is also a valid scenario but it increases complexity and decreases flexibility. Rather going this way, we could have 2 CFSs under the Co-Location Product.

Another example could be GSM Voice Call. Voice call is a granular CFS. I have seen some examples on the web saying that “receiving a voice call” is a CFS. I don’t think so. Voice call is a granular CFS which has attributes (is call receiving active, Suspended, Roaming Activated etc.) These attributes are not sellable as standalone. If they were, if you were subscribing for receiving calls, this would be a CFS but I have not seen any service like this. In the roaming scenarios for example, receiving calls are also billed. But, this is not a service that the customer buys! This is a separate rating scheme that is applied to the service under this specific condition. As I said before, the service attributes would be bind to one/more update flows (service activation flows). These flows (or operations you could say) could be exposed as different web services (but not different CFSs).

Choosing the granular services will also help you to decrease your troubleshooting time. We said that CFSs are the services that are “perceived” by the customer. But this perception is heavily impacted by your service design. Let me explain this. Suppose I am selling a product called Co-location, and in my product specification I am also saying that this product is composed of one service which is Co-Location. Whenever the customer perceives any problem, he/she will blame the co-location service, since this is the only service he/she is receiving. He/she will create a trouble ticket for this outage giving the detail “I am having a problem with my co-location service”. This is not very informative. Most of the times, it will be the service provider’s job to localize the problem. However, if the service was designed as two separate CFSs (bandwidth and power) rather than one, the customer “may” come and open a ticket on the bandwidth service with the detail “I am having packet loss problem on my line”. Your MTTRs will definitely fall.

Choosing the granular approach in your service design will bring flexibility. The service activation flows will be more manageable and troubleshooting will be easier. Choosing the CFS details is not the only task but it is a starting point before we move to the Product design area.