tisdag 11 juni 2013

The color of service

Does service have a color? Of course, I think it does and i will tell you what i think it is, later on. For now you will have to set with that i think it is connected to a feeling. What? Both a color and a feeling? Come on now. Stop with the philosophy session and get down in the dirt. What is a service? I argue it has both a color and a feeling. I also argue that it is many other things as well. To keep it simple i will propose "one important thing I think it is, in one specific context".

I will just rack em up in no particular order and you can pick whichever you like the most. Do not forget though, you will need them all to create excellence and become a superstar. Oh, one more thing. If you think you are the superstar, think again. You are almost definitely not so. It is better to realize it now that someone else will get credit for your fantastic work and you will stand unrecognized. Why do I say that? Well, you should take pride in standing in the shadows. You should consider yourself as the sprinter coach that has been training sprinters for the 100 meter final in the Olympics. The winner or word record holder is always a superstar in this context but do you ever hear about their coaches? I can tell you I do not. The coach that has been working, probably for years or decades, to form and establish every small piece of technique and base for strength. Do not get me wrong now. A sprinter does the training themselves but there is a reason that there is a successful coach behind every successful athlete. There is a difference between knowing WHAT to do and TO DO it. Thats where you come in. You are the coach so get used to stand in the shadow of somebody else. Their success is a measure of your success. 

What I think a service consists of. You could probably argue that there should be more in here but if we can not keep it simple we have other problems. Here they come: "one important thing I think a service is, in one specific context".

From a Consumer (the one actually doing the stuff and using your service) perspective it is Usability. Thats is it. Nothing more. If a service does not provide usability the consumer will not consume it. The level of usability is always a discussion and basically higher the better from a consumer perspective. This is about adjusting expectations to reality. If you rent a car expecting a Ferrari and receive a Volvo you would be disappointed. If you expected a Fiat and received the same Volvo you would be happy. The usability was identical in both scenarios but your expectations and therefore your user experience will differ substantially. Do not forget this otherwise you will always have unsatisfied consumers while your doing a heck of a job. 

From a Customer (the one that is paying) perspective it is Value. Basically their return of investment. The customer do not want to hear about processes or tools, server or systems. They want to be able to se what they get in relation to the costs and the risk associated with it. I could even argue that availability is not relevant here. As long as the value is acceptable in relation to the cost and risk, availability could be awful but still quite sufficient for both the consumer and customer when it matters. Value can not be determined by the service provider. The service provider should measure service delivery in terms of the consumers ability to achieve their expected outcome and the contribution of the services in relation to that. Then the the value can be determined, but only then. 

From a Service provider (the one that will face the customer and get paid even if no actual money transferred is made) perspective it is SLM. Measure the service value in customer outcome context. Define the price for it, explain risk associated with it and HELP the customer to make the right choice on a frequent reoccurring basis. Write this down in a SLA for clarity. The service providers need to understand the expectations of the consumer and value for the customer and propose a reasonable cost/risk ratio which both consumer and costumer needs to understand and agree to. If it is not clear to the consumer what to expect. What do you think the experience would be during a disturbance? If the expectations are clear you could still have a happy consumer during a broken service delivery if it is handled according to expectation.

From a System (a IT solution where parts of or all is used in a service delivery) perspective it is Urgency. The classification of urgency can not be done on a system or technical level. It belongs to a service and is inherited to ANY PART of infrastructure that is a part of ANY SYSTEM that is contributing to a service delivery. This does not automatically mean that a service is using everything that belong to a system. A service can use parts of a system and therefore the urgency is only inherited to those parts. To know the urgency for all parts of a system you need to know the urgency for all services that the system is contributing to. This information is vital for the design and architecture of a system and is a MUST for defining the risk associated to a failure or disturbance. The urgency for a service is set by the customer and have to be agreed on by the consumer and sets the lowest level of service delivery.

From a Support (any part of IT that will be involved in a solving a problem through any process at any time based on a ongoing or potential consumer issue) perspective it is Satisfaction. The better the description of the consumers problem symptom is, the better possibilities support have to fix it and accomplish satisfaction. The goal here is to give the consumer a pleasant experience. If support has a visualization of the services the consumer can access/is using, and there is an event that has already triggered an incident on any IT infrastructure it should be shown here. If correlation of a symptom can be done with a service and finally be tracked to IT infrastructure at this stage you will have a match in heaven. The consumer can be told the estimated recovery time and recovery strategy with continues updates to the consumer of any changes in that estimate could be provided and if expectations are met we should achieve satisfaction, not guaranteed. If a correlation is not possible it gets more complicated and therefor needs more thorough analysis. Part of the analysis is to rule out the consumer client computer. If that is not the case you need Sherlock Holmes and you can still achieve satisfaction but it will demand more of you as the magic resolver.

From an Operation (any person performing operational activities on any IT infrastructure at any time) perspective it is Service Health. How does the service perform considering it's SLA. Is there any activities performed, happening or planned that could in any way lead to decreased or breach of a commitment. It is not the operations responsibility to evaluate if the service level is correct. It is their responsibility to maintain at least the level specified in the SLA. The service level shows the worst level of delivery acceptable and is NOT the target to reach. If levels are met but the consumer is still dissatisfied the SLM has not reached its purpose. If customer is happy but the consumer not it is time for a reality check and adjust expectations or level of service. 

From a Strategy perspective it is Forecast. If you can visualize all the services and have the ability to show passed, current, planned and the future, in terms of value, cost and risk for each service in customer outcome context, then you have a very cool service portfolio. Nice huh? One you have the ability to aggregate value, cost and risk in passed, current, planned and the future the portfolio can look any way. that format is not the important thing. To amaze people is the important thing, and with this information in any structured way, you probably would.

From a Finance perspective it is Service Structure. Got you there, didn't I. It should be money you say right? Well if you manage the money and the assets you still lack the ability to aggregate cost of service ownership without the service structure. If you can not tell what assets are used in a specific context you can not calculate cost of ownership. What actual cost you want to add to an asset and the structure is up to you. If you do not want to include facilities then do not. As long as you as the service provider and the customer is aware of what is included and not, it is fine. You can even allocate costs spread out on assets in terms of percentage or standardized manner and include or exclude anything of you liking. The structure makes sure that aggregation is consistent and comparable as long as it is clear what is included or not..  

From a Change perspective it is Impact Analysis. How will this change, replace or empower the outcome of the costumer? How will this be quantified? What service or services needs to be changed? How does this affect the solutions in place? What IT infrastructure parts will be affected by this change? What IT infrastructure parts could potentially be affected by this change. Are those potentially affected IT infrastructure parts involved in any other service delivery that needs to be considered? Well you get the point. Answering these questions with the maximum amount of automation would be very beneficiary. All might not be possible to answer automatically but a lot is achievable. A CMDB designed for these purposes can be very powerful. The questions are possible to answer anyway but it will take much more effort.

From a CMDB perspective it is Purpose. If the purpose of a CMDB is to calculate service impact based on IT infrastructure then design the CMDB structure to accomplish just that (Hint, take a good look at your service structure). Gather the right information based on the purpose and automate as much as possible but stick to the purpose. oh, one more thing, stick to the purpose ...... the purpose .... and the purpose. You get the point. CMDB is not a storage/dump area for stuff. If that is what you use it for you will end up with just a pile of stuff. Be very specific in what questions the CMDB should answer and base the answers on the service structure.

From a Service Structure perspective it is Translation. A business outcome must be translated to IT infrastructure. If you can not se your customers outcome and track it down through relevant layers to how it is realized in IT infrastructure the structure still needs work. This structure is then used throughout the organization in finance, operation, support, SLM, visualization, portfolio etc. as the core for aggregation, analysis and reporting. 

What the color and feeling was? Did you already forget about that? In my mind it is all clear. If the consumer is amazed and the customer pays me for doing it, the feeling is satisfaction and the color is green as in money.

3 kommentarer:

  1. Hello Mika

    thanks for your thoughts. As for me, I would argue that the Customer wouldn't be interested in the availability, capacity, security and continuity aspects - after all, these are all parameters to the associated risks and value for money. Talking about risks: the Customer should definitely see it as value for money if he/she can understand how the risks are (planned to be) managed. Then would the service package be complete, as complete as the green money (is it always green?) is also complete.
    Best regards

  2. I agree with you on customer value. Concerning risk i see it this way. The management of risk does not necessary need to be understood as long as it is managed and stated as such. When i go to a restaurant to eat i am not in any way aware of the risks involved in handling or cooking food and what mitigations are necessary to prevent them. All I know is that i do not want to be sick during or after the meal. I am expecting the restaurant to include that in the price. How and what, are not relevant for me at that point. It could be a differentiator if you had a restaurant in a neighborhood that was known for a lot of food poisoning. But that is not about risk management in my mind. Thank you for commenting, i really appreciate it!

  3. Mika, if you were in an obscure country and went to a restuarant, you may want to think about the risks you are taking.

    Also, you need to understand the capacity of the restaurant (can they serve food in a reasonable time if the place is full, do you need to make a reservation?) and if it is a self-service (availability) and of course the security may be important to you as well.