torsdag 27 juni 2013

Who is the customer of IT?

I know, business first. The following scenario is not a contradiction to service management and customer-centric focus in any way or an attempt to say its wrong, i am a strong believer so do not get me wrong. I like to challenge anything comprehensive and try to simplify it a bit too far. Lets just skip the traditional thinking and look at IT equipment as means to do something. The person that is trying to do something with the help of IT equipment is an IT consumer. The consumer has goals and needs just like anybody else independent if they work within IT or not. Hopefully everybody's goals are aligned so that they all work for the same cause, business and IT. Lets take a look at a normal situation where IT has staff that handles tickets in an ticket handling tool. There is also a Business application where business staff performs their work.

In both cases there is an application and a users of that application. One significant difference though is that the IT staff is using their application when there is an incident/change/request on the business application. I know it is very simplified but anyway. Who is the customer in this case? Where can we do improvements that could have significant positive impact on the final cause that all are working to achieve. Should not we treat IT staff the same way as business staff? IT staff has goals and ways to achieve them with help of IT equipment (the ticket handling application for one). Now this is getting a bit complicated if we say that IT itself is delivering services within IT. But is not that the case?

When talking about IT Service Management we always talk about the business customer and the importance of understanding their needs and to empower them in achieving their outcomes. IT should measure it's contribution to that and so on. I do not disagree but i play with the idea of performing IT Service Management within IT. There are probably tons of stuff we could do better by behaving more as service providers within IT itself. Lets continue on the scenario mentioned earlier. 

Lets treat the IT support organization as the customer. That includes anybody within IT (could also be external providers) that is involved in handling an incident/change/request (lets call them interactions). Of course the handling of any "interaction" inherits it's circumstances from business needs but nevertheless, it just boils down to different targets that the IT staff will try to achieve. That is their outcome. To handle the interaction and achieve the outcome based on specific targets. The needs/targets vary from interaction to interaction but they are still there. What would happen if we treated the support organization as the customer and started to define the services that they are consuming with IT service management. Lets empower the support organization to reach their goals (what ever they might be) and measure our ability to enable/empower that, just as if it would be the business. What would happen if we did and succeed? 

One thing is for sure. Any business that would rely on that support organization would probably experience it big time. And now we have not even talked to the business about IT services or involved them in anything that they might not even be focused on or not understand. I know that this would not enable IT to drive and evolve the business which pretty much is the end game but anyway. What it would do, is that if IT could succeed internally, we would learn the IT organization the practice of IT service Management, establish new behavior and culture, and be good at it before we try to practice it on somebody else. We would experience all the good and the bad and learn from our misstakes, first hand.

I am thinking if we can not do it small, why on earth do we think we could do it big. When we nail the small we could proudly and confidently embark on the big. Just a tought :)

tisdag 25 juni 2013

Why an SLA does NOT give you IT Service Management

IT Service Management .... what does it stand for? If we take a quick look at Wikipedia it says that it "refers to the implementation and management of quality IT services that meet the needs of the business". What does that actually mean? That IT should implement something AND manage it in a way that meet the needs of a business. So what are the business needs then? Well, how long is a rope?

That a business has goals i guess is a no brainer. But what are the business needs? What is IT's contribution in this? if we take a closer look at business goals, where do we end up concerning IT? If the business is using IT to try to achieve their goals, IT should measure the business ability to do so. Is it not the only thing that matters? If business is achieving their goals to a certain level, IT's responsibility should be to provide better ways of doing just that or more. Try to wright that in an SLA. 

If the business has a target and that target is reached, is everything OK? it should right? Even if IT did a terrible job it is still good, or? Is it only OK if the business targets was reached but if they where not it is ITs fault?

IT need to stop acting like we are a grocery store and as long as people buy the groceries everything is OK. If our store customers comes home, tries to cook a dinner and it tastes awful would they blame the grocery store? Of course not. Why? Because we did not promise it would, and why would we? We are in the grocery business, not cooking business, right? But what would happen if we, as a grocery store, suddenly said that if you purchase your groceries from our stores your dinner will taste grate. Do you think we would get any complaints? I think we would drown in complaints. So lets apply some SLA to this grocery scenario. In the SLA we wright about store availability (open hours to do purchases) and bags for carrying, variety of available recipes with instructions, warranty of certain groceries etc. Would the dinners taste any better? I guess not. Even if we actually deliver every part included in our service the food would probably not taste better that the chefs ability to cook. The goal here is to have good tasting food but what are the needs? One customer is a decent chef but cant read so every time he cooks he mixes in the wrong ingredients and the result is a dinner that tastes bad. Another customer gets everything right except the heat on the stove so everything gets burnt and tastes awful. Same goal but totally different needs.

So how do we solve this? With an SLA? An SLA that is IT centric (availability, response times etc.) will never ever be in the interest or main focus of a business. So how about an SLA that is business centric? Well now we are getting somewhere, or? Lets do as in our grocery store and promise good tasting food. That should do it, right. I guess not. The question is how do we measure the chefs ability to cook. If we can quantify that in any format or way we are getting someware. That would help us to see if IT's improvments actually improves what really is in the business focus and interest, their ability to cook. Service management is about caring, behavior and culture, not about availability and response times.

One thing that we can decide on, and count on to happen is that the goals and needs of a business will always change. As soon as we have helped somebody with one thing another thing will appear as a new week point that needs to be managed/handled/improved. Today almost everything, in one way or the other, involves IT. Does that mean that we will have to deal with everything eventually? I do not know but i know one thing, an SLA will not give you IT Service Management so if you are pursuing that, start by going to your business and ask them if there is something that they think you could do to make their life easier when trying to acomplish their goals and then really try hard to do it. Then you are actually doing Service Management even without and SLA.

måndag 17 juni 2013

Design a process, communicate and implement value

As a process designer we need to think ahead. We need to think ahead and see the future value as clear as possible to be able to do a good process design. The better we can see the future, the better our process will probably become. It is a matter of time traveling and make the necessary changes in real life and it is right here i see something that we could improve tremendously.

What do i mean with that? A basic way of designing a process could be to develop a ASIS process design that clearly shows how the process is implemented. A TOBE process design to identify the gap that has to be covered. A implementation plan that removes the gap and takes us from ASIS to TOBE in an effective manner. Sounds easy don't it? Usually there is no trouble in developing the ASIS or the TOBE process. The implementation plan should be no big deal either. So why is there a general understanding in the business that implementing process is hard? I frequently hear and read that communicating during implementation of the process is what is the hardest thing with processes implementations. As soon as you show a process to a stakeholder or an process operator for verification during design you either get rolling eyes and a general lack of interest or the opposite, an theoretical acceptance but not the corresponding action in reality when implementing. How come we during the process design so often get acceptance from both performers and stakeholders but in reality we struggle so hard with the implementation and realization of it? 

Many years ago when i was a process youngster i had such firm belief that i could, and would, change the word by designing better processes. That was it. It was a revelation for me and i could see the "code" in front of me, just like in the movie The Matrix when you see the rain of letters and numbers falling down on their computer screens, i could read it. I did a lot of good during those years but boy what a fight it was. The effort of establishing a TOBE and get it reviewed, accepted and even communicated was a walk in the park compared with actually establish the changes and implementing the new way of working. The constant discussion of metrics, tools, activities, input, output, people depend on you, this is required not optional etc. Anybody could have been discouraged by this but i had seen the light so I just kept trying even harder. The more i talked about the process the more alienated i got. I was a process fool with a tool! That was a long time ago and a lot of water has passed under the bridge since then and my conclusion are that the more we talk and communicate about the processes itself, the further from reality we are perceived. 

What we need to come to terms with is that the process is just a visual representation of a series of activities that can be sequential, parallel, conditional, mandatory etc. and is usually a combination of them all. The way we design and visualize a process has absolutely nothing to do with a operator actually performing a part of the process. It has nothing to do with why something has to be performed in a certain order or not. What we, as process designers, are experts in is to see and understand the purpose of a process and how to, by a series of activities and flows, achieve that purpose. We use our technique to represent the information required in the process and all conditions that needs to be fulfilled. We can even measure the process to see progress and outcome and propose adjustments based on that. But as i said earlier it is not a question of designing the TOBE or ASIS or even the implementation plan that is the challenge. It is in communicating and establishing the process to achieve the purpose and value designated with it. 

So the dilemma here seems to be, how do we design and implement a process without talking, showing or ever mentioning the process itself to the outside world? We need to communicate based on outcome and use a language that establish trust and ambition. The process itself absolutely needs to be designed and constructed but we maybe need to look at it as if it was confidential. Yes, it is a big secret of the trade and is never to be communicated or shown outside the design room. The only thing that is to be revealed is the purpose of the process and the value that it will bring. This would mean that we will have to change the way we speak and communicate when it comes to processes. There are some ground rules for process design so lets take a look at what should be present in a process and see where we end up. 

- A process have a defined trigger.
- A process have a defined end result.
- A process have a purpose.
- A process brings value.
- Each activity have an initial condition that needs to be met before it should be performed.
Each activity has an end result condition that needs to be met before considered finished. 
Each activity have a responsible performer (even if automated).
Each activity is supported by a tool (even if performed with pen and paper).
Each activity is dependent on information that is required to be performed.
Each activity generates information before considered finished.

If we could se the above in a process design we could consider it to accomplish the basics in process design. But if we apply the dilemma on this situation and agree on that never mention or to show the process itself, how do we communicate about it? Well the first question is who are we communicating with? If we are communicating with a stakeholder we certainly should talk about the purpose and value the process brings. Even every activity can be described in value. So what of the ground rule list should be considered when talking to a stakeholder?

Interests of a stakeholder:
- A process have a defined end result.
- A process have a purpose.
- A process brings value.
Each activity has an end result condition that needs to be met before considered finished. 
Each activity generates information before considered finished.

Every point in the list above can be described as purpose and value. As you can see everything is result based. It is what we get from the activities and process itself. Each process activity can even be described in value and purpose if needed to go to that level of detail. Still, never to have mentioned or shown the activities or the process design itself.

How would the list look if we would talk to an operator (performer). This time i divide it in two parts. The first part is what i consider operator requirements. Basically what the design suggest should be achieved and available for the operator before performing her work (process activity). The second part is what is expected of the operator and must be achieved by her to consider the activity as performed. 

Requirements by the operator:
- Each activity have an initial condition that needs to be met before it should be performed.
- Each activity is supported by a tool (even if performed with pen and paper).
Each activity is dependent on information that is required to be performed.

 Required of the operator:
- Each activity has an end result condition that needs to be met before considered finished. 
Each activity generates information before considered finished.

As you can see it is much easier to isolate the purpose and value in each process activity if we break it down to this level and simply answer the question WHY for each process step and each statement for process design. This way we can communicate with any person about the process or even a small part of the process but disguise it in terms of purpose and value FOR her, or the purpose and value contributed BY her to achieve the overall purpose and goal with the process.

It is more about the words we use than in the format we do it in. If you are used to present and communicating using slides continue with that. Just make sure you never reveal the process design in the material. Always express yourself in beneficiary terms FOR the attendee or requirements OF the attendee. This is applicable for stakeholders, operators, managers, end users etc. The process is just a tool of the trade and a way to describe the information flow, the activities where it is used and modified/created for a specific situation. It can be used for many things and should mainly be used where both the author and receiver base their assumptions/analysis/design on processes.

In other circumstances you are better of hiding it!

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.

måndag 10 juni 2013

The content and structure of services

I find the term service here and there when reading about catalogs, delivery, frameworks etc. and i find it difficult to find good descriptions of what the content of a service is and how to structure it. Here are my thoughts.

To describe services seem almost intangible and very hard in practice considering so many is struggling with it. Although, i think it is still possible to apply som structure to the concept without making too hard on yourself. When applying a bit of structure it can be easier to move forward afterwards. I often hear examples of what an IT service might be and there is always references to a description that should clearly state what is included and not included in a service. What it should be and examples of it is harder to find.

If we want to define a service I would assume that it has more than one part. Among those parts there might be some that would be considered as mandatory versus some which could be optional. If we just for the fun of it called these parts service functions. Then we could start from this service function and ask ourself, one by one, what is it for? How is it used? what does it provide? If we have the ability too answer the question, i think that we have a pretty good idea of who the consumer is and how the consumers process looks like when the consumer is actually using our service function. An important point is that we need to understand what parts of the consumer process is our IT service enabling?

I could go even further and say that the service is nothing/empty until one or more service functions are defined. This would mean that we actually define the service through service functions in this case. If a corresponding service function does not exist the service does not cover it. This gives us our first structure.
In the picture we have one service and four service functions. Lets imagine that each of these service functions cover a specific part of a consumers process and all together they enable the consumer to achieve its process outcome. Of course the consumer is probably using other services as well to achieve the process outcome but lets stick to our service to make it easier. The naming of these service functions should correspond with what the consumer is doing. The service should be named corresponding to the outcome the consumer process is achieving. This way communication is easier.

Next we want to group the services. I would guess that there are more customers and consumers that can benefit from a service the more standard the service is. So we should try to group our service in service groups. Lets continue this example with an IT department and a business department/unit trying to define the services for this business unit. One way of grouping the services could be that the business unit is one service group and all services that are specific for and used by this business unit are grouped into one service group. If there are more units working with similar areas and consuming same services it could be beneficiary to add them all to the same group and choose a good name for the group that corresponds to the business the units are performing. This way it is easy to have a discussion about cost, delivery, availability etc. because everything or a majority is applicable for the business unit you are communicating with. The business unit is also consuming more standard services like messaging, communication and service desk. These can be grouped into a service group called shared services or corporate service. The result of this is that a customer will probably consume services from multiple service groups where one will be very close to their core business and the other tend to be more standard services.

That would give us the following picture:

Here you se two service groups with services and service functions. This way it is possible to structure the content of a service with service functions and to group the services in customer segments or service groups even if all consumers are internally in one enterprise or externally.

Create an IT-service in 90 minutes

The task of creating IT-services could be daunting and it seems as many companies and IT departments are struggling with it. I like to simplify things to the point it gets ridiculous and start from there. If this mindset is applied to service and service modeling a couple of questions come in my mind. I think they are fundamental when defineing a Service in its simplest form. One important thing with these questions is that the answers can not be IT guessing. The answers must come from the IT consumer. No interpretation is allowed and I will get back to why I think so.

- WHAT is the consumer doing (in its context and with what applications)?
- WHY is the consumer doing it (what is the end result of the task)?
- What would happen if the consumer COULDN'T do the task at that moment (is it critical or could it be done later or in batch)?

So the header said "in 90 minutes" and that would imply that there is a recipe for achieving an IT-service in 90 minutes. Could it be done? well as I said, I like to simplify things so if you only allow 90 minutes to achieve this that is what you will get. On the other hand if you allow 4 weeks for it I am not so convinced that your result will be a hundred times better so keep it ridiculously short. 

What you will get is a clear understanding of what Infrastructure components are in direct relation to what the business actually do and what the effect is when they are not available. As I see it, an IT-service in its simplest form enabling IT to communicate with the business about services they can identify with and the ability to understand how it is delivered and what IT is contributing to.

Plan the 90 minutes in 2 steps. The first step is to schedule a meeting with a IT consumer that works in the area where you want to start your service modeling. The second step is to schedule a meeting with the technical responsible, probably more than one, of the applications that the consumer is mentioning during the first meeting.

Step one, meeting 30 minutes with the business. The person or persons that are invited should be very familiar with the business process and it is important that they are executing a part of their process. Try to identify a critical step in their process and ask them the three questions. you could end it right here with the answers or continue to ask them the three questions for each step of the business process that they can cover. Keep it simple and scoped instead of trying to cover too much.

Answers from first question: The answers of the first question is what I like to call service functions. Each consumer step is a potential service function. Sometimes multiple answers might be good to add to the same service function depending on the answer related to the depth in the business process. The key here is that the consumer can fully identify herself with the name and description of all the service functions. This still has nothing to do with IT so do not change it in any way to correspond more or less to IT terms, even if the consumer uses a "system" name in it, do not change it. Additionally, every time the consumer mentions a system or application, take a note of it. This will be the base for your second meeting. From a IT perspective the naming of the service functions are completely irrelevant. It could be called anything as long as the business and consumer understands what It is when using it during a follow-up or saying that it is not available for any reason.

Answers from second question: The answer of the second question is used to name the service. The logic here is that all answers from question one that is related to the same answer from question two is same as multiple service functions related to a service. If you merge two services to one then you have to relate all service functions to the new service as well. Important here to keep the business language and the correlation to the business result.

Answers from third question: The answer from the third question is the criticality of each service function. Yes that is correct, the criticality in this case is specified on service function and not the Service. This way they can easily be aggregated to the service when needed. Make it easy and classify the service requests as critical or not. The point here is that critical is a process stop for the business. A service function or business step that can be performed at another point in time is not critical.

Summary of step one, first meeting. Visually now we should have something like this.
We have one (or multiple if you had the time for it) service and at least one service function, hopefully more, related to each service. The service should have a name that completely corresponds to a result that the business is dependent on and should be identifiable by anybody relevant in the businnes. The description of the service must cover all the service functions that are related to the service but no more. The service functions are the content of the service so the service does not enable more than specified through the service requests.

Step two, meeting 60 minutes with the technical responsible (systems and applications mentioned during meeting one). The persons that are invited should be technically responsible or technically involved to the degree that they are able to answer on the technical impact of a service function in their respectively systems. The questions for each service function to the system representatives are:

- Specify any infrastructural equipment related to perform a specific service function. If you need to keep this easy, concentrate on applications installed on servers and the server itself.
- Is the infrastructure equipment critical to perform the service function or not. Can the consumer carry out the service function when the infrastructural component is not available (it might have redundancy or a queuing functionality that does not require full availability) or not.

Summary of step two, second meeting. Now we should have something like this.

Each service function has critical or non critical infrastructure components related. The infrastructure criticality only shows if the equipment is critical for the service function to work. It does not say if the service function is critical to the business. The relationship from the service function to the service tells if the service function is critical to the business. 

If you would use this visual structure when ever planing a change or managing an incident it is really powerful in impact analysis. It tells us clearly what service function a infrastructure component will affect and the meaning of it for the business/consumer. The same goes when a new demand of functionality is requested. It is easy to define if it is an add to an existing service function or a additional service function that needs to be defined and if the existing infrastructures is reusable or need additions as well.

After this first simplified step it is just the rest left :)

To drive or analyze a process with measurements

There is a lot that can be measured when it comes to processes. The terms KPI and metric is frequently used when talking about measurements. I like to look at measurement from two different angles. I call them Drive or Analyze. There is probably more accurate industry terms for them but i call them that to keep it simple. They are what they are called. I like simple. If you have read what i have written earlier you have seen that it is an important part in my interpretations.

The meaning of Drive. Well, what do you do when you are driving a car? You are constantly adjusting the steering wheel to keep the car within the lane. Sometimes you change lanes but always according to route. There are some short time goals which forces you to adjust while driving a car. If there is a car in front of you, you will avoid driving into it. There are speed limits that indicate the maximum allowed speed etc. Simply put. Tons of adjustments that you do to reach you final goal, arrive at the expected destination. The key here is usually that a measurement indicates if an action needs to be performed or  to be changed. This is a very short perspective and the information must be real-time. Basically it should be defined in the way that it tells you specifically what to do. Steer right or you will end up in the ditch. break or you hit that car. turn on headlights to make the surrounding aware. Put gas in the car or it will stop. No one of these are in any way described in the context of the final goal. But if you follow them you will significantly increase your probability to reach it. No one of these measurements are done to improve the process design either. They are instruments to execute the process correctly. To drive the process. They should be essential and ALWAYS AVAILABLE for any process operator driving the process. Would you step into a car knowing that the driver has a driver license but is currently become blind?

The meaning of Analyze. This is all retrospective. This can be from outcome (effectiveness), compliance, efficiency or improvement etc perspectives. A process is a living thing and it needs to be analyzed on a regular basis. It is here you will find your process weaknesses and as soon as you find an antidote for it you will find a new one to focus on. Usually it is not good to have too many at any current time. If you give a patient 5 different medicines at once, how do you know which one worked the best. Pick the one or ones that will give you the biggest positive impact and make them visible for everyone. How to make them visible? Create a driving measurement that prevents the unwanted handling with a defined counter action. 

But wait a minute here. Am I saying that analytics are to identify weaknesses and driving measurements are to mitigate/prevent them from happening? Sure! It is often during analysis the driving measurements are born. The driving measurements are the countermeasures for weaknesses found during analysis. If you create a driving measurement and it is used by the process operators things will happen in the process. Other parts of the process will be affected and new analysis is needed. This is a never ending story. If you do not plan to perform this continuously your process will slowly deteriorate and that is something karma would not like.

As an afterword i would like to add that when talking about effectiveness aka outcome it is the guiding star of them all. It has to be nailed and maintained like a new born baby. The purpose of it is to quantify the consumers ability to achieve their goals and to illustrate how IT has contributed to it. Nothing more and nothing less. 

fredag 7 juni 2013

ITSM, why the distance between theory and practice

During all the years of practicing ITSM i have always wondered why there is such a gap between the written word in books and online compared to challenges that you actually face while trying to implement and practice service management. You would think that you are in for a frantic roller coster when reading of organizational challenges, CMDB's, services, metrics, attitude, operations, customer-centric, processes and outside-in approaches. When gathering all challenges and hurdles you would need to cope with, on the road to ITSM, its easy to pick one or a few topics that are the least vague from you perspective and start with that. 

A few years down the road you ask yourself why you have not got any further with the initiative than you have. Feels similar? I have met countless companies that gladly have showed their initial approaches and plans, their implementation strategies etc. They range from small pragmatic to full scale projects but they all have something in common. That is that if they had the chance of doing it again they all would do it differently. It does not necessarily mean that they have failed the mission but on the question "what would you have done differently today" they all get that spark in their eyes and off we go. The easy solutions and corner cutting strategies burst out and the quick wins are lined up. I ask my self, why is it like this? Does all experience come to the conclusion that we did it wrong and there is a easy way out but that holy grail is always out of reach?

I do not have the answer on that but let us continue on the same path. Could it be that when initiating and pursuing service management, any organization, and i mean "any", like in all, learn things from them self, and their organization, that they actually did not know earlier? Could it be that even with the best knowledge within the topic of service management their is always a big portion of self awareness that is always overlooked? When looking back on all the companies i have meet i can see professionals with great knowledge and there is a well spread mix of internal as well as external resources or both in the initiatives with management commitment. If self awareness is an important part of the success of service management then i guess that goes hand in hand with unique challenges as well. After all it is attitude and people it is all about. We try to define it with processes and support it with tools and follow-up with metrics but what is the point if the attitude and people are not onboard. 

So how do we practice and perform changing attitude of people? could it be that simple that instead of embarking on a big service management program we need to practice what we learn to actually learn? What would happen if we did a lot of service management practice but in a very limited space? I mean if we could define one or a very few services in a limited space and go all-in on those. Limit the number of people involved and make it all happen within that limitation. I do not mean go short cuts or corner cutting but all the way with everything. A few people feeling all the benefits of service management. It seems that if we actually had a service which really meant something to the customer and really enabled the provider to do the "right" things instead of "good" things I reckon it would sell itself? if everybody could see, smell and touch all the benefits with working this way it would adopt itself, would it not? The service management initiative could support people change their attitude and ways of working instead of fighting or trying to convince them. 

I like the idea of inspiring people's curiosity and their inner confidence of "the right way". It is very hard to discharge a working solution that can be demonstrated hands-on. On the opposite hand it is very easy to discharge something which cannot be proven more than in theory. Could that be a way we successfully can change attitude? Well you be the judge.