fredag 22 november 2013

How I create IT services

How I create IT services.... or is it value, hmmm service .... maybe value. arghhh  

What should I use? Service or Value? I offer services but I have to show the value. In my mind they are so closely related so its down to the semantics and on that level it does not actually matter. Either we can show and quantify our contribution or not. I guess we can call it whatever we want. 

Whether we call it one or the other, it seem hard to do when it comes to IT. Why? I will use an example of service I have encountered outside of IT which I would like to explore in this post. In sweden (where I live) there has been a strong trend last couple of years in the retail market that is starting to show very good success and revenue. I, as a grocery customer, am custom to cope with ever lasting chore of dinner planning for my family. But things are happening in this space that can contribute in a very good way for me as the customer. Before that, just a quick look at my reality. The process for my dinner planning is pretty strait forward (just to call it a process, talk about nerd). It is my own process and I guess it is probably common. I have designed it to achieve one of my weekly goals, put healthy and delicious food on the table every day of the week. I also try to achieve that at a specific time suitable for everyone in the family, and to a reasonable prize. The process looks like this.

-Come up with at least five dinners meals ideas
-Define all the ingredients
-Make inventory to cross out any ingredients that already exists at home
-Go to the store and purchase all ingredients once a week
-Stash all ingredients in appropriate storage
-Prepare dinner on a daily basis ready for a specific time
-If necessary, complement unforeseen groceries on a daily basis

Thats a pretty strait forward process and it serves me well. The performance is still very depending on that I can prepare the food I come up with. The more variation and exploration I bring to the table, the higher the risk is that the meal will not be delicious, which is my primary goal. But now back to the changes that has been happening in the retail space for the last couple of years. They are offering a home delivered, pre-decided, grocery bag including:

-Five dinner meals with high variety 
-Healthy ingredients
-Step-by-step instructions with a complete time estimate
-Fixed prize
-Home delivery once a week

This is the same grocery store that I have been doing my own purchases in. This could turn out to be valuable for me and support me in my process by decreasing my workload and even increase my ability to serve more healthy food, which was not one of my strongest capabilities but still a very big concern. If I were to buy this weekly grocery bag I could se the following.

pros:
-No more trying to come up with meals ideas
-Higher variety of meals
-Step-by-step instructions
-Meals probably ready on estimated time
-More healthier meals
-No more defining ingredients
-No more inventory
-No more going to the store
-Fixed prize or at least very predictable

cons:
-I can not influence what to eat
-Meals that might not be delicious and accepted by family

Unchanged:
-Prepare dinner on a daily basis
-If necessary, complement unforeseen groceries on a daily basis

This brings up the question of Value. What is the outcome in relation to risk and cost. At an initial look the purchase cost seems reasonably comparable. The difference from my own purchases seems neglectable. There are though a higher risk associated with the taste of the food. The variety could be acceptable as long as the taste stays high above average. More healthy food is a win from all angles. The total effort is decreasing and to sum it up, I gain more verity, higher health and less effort but I also gain in risk for my goal which is delicious food.

whether I choose to purchase it or not is not the main issue here. I only use this as an example to try to answer my initial question. What is Service and Value. From a supplier perspective they for sure call it a service because it is precisely that for them. For me as the customer it does not matter what the supplier call it. If I can not break it down to calculate the value for me, I will probably not become their grocery bag customer. If I do not think the outcome is worth the risk and cost associated with it I will probably not become their grocery bag customer. If I do not understand in what ways it is contributing I will probably not become their grocery bag customer. 

This means that for me to understand the value of this service I have some work to do. Here is a weakness. This forces me to do work to understand the value it brings to me. Now dinner planning is a pretty easy example and therefore the calculation is not that hard to make but when it comes to what IT contributes to, the calculation becomes more complicated. This is where IT needs to step up. We can not force the business to make this calculation. They will have to make the decision whether the outcome is worth the risk and cost, their value, yes. But IT needs to be become much better at putting the equation together.

IT is like that grocery bag supplier. We supply all the bits and pieces in one big bag but we forget the customer process and the recipes. We are not clear with what and how the ingredient are used in an understandable way and we are not clear with how this effects the process. If we could apply the recipes metaphor to how the information is consumed by our business they would tend to be much more interested in our IT services or whatever we choose to call it. Our ability to put together the equation for each recipe need to increase and then the conclusion of each meals value and the bag's value could be in reach. Each ingredient separately will never accomplish that.  

We need to start small. Each business department have their process and subprocesses just like mine handling family dinner planning. Pick one that matters for that business or department. That process or subprocess has an expected outcome. IT contributes to that outcome, figure out how! There are ingredients (information) that are put together to meals (outcomes) and there is an effort (process and preparation) that realizes a business goal (deliciousness). Break it down and put it together as the business consumes it. Not the way IT sees it. We see technology and solutions (bread, meat, vegetables, dairy etc.) and that is not how IT is consumed. The business compiles pieces of everything to create a meal. That is what we need to identify and most importantly, understand! As long as we do not understand the business goals we will have no chance to construct recipes (IT services) and eventually be able to calculate meaningful Value. 

So the reason I am using the term IT services instead of Value is because I work within IT so I am a supplier. When it comes to communicating and defining my services for a business, I concentrate on trying to understand the business goals and how my ingredients are put together to achieve that. I create recipes. I also contribute with any variations I might be able see, to increase the business value of my IT service. Im a chef on a mission :)

måndag 11 november 2013

I don't have IT services so what should i do with my Request Catalog?

First a short view back in time.
A few years back Gartner said that until 2013, 80% of IT organizations will have developed a IT Service Catalog prior to their IT Service Portfolio. Now it is 2013 and i don't know whether it is 80% that have actually developed an IT service Catalog. Regardless, I would still assume that out of the ones that have, a majority probably didn't do service catalog at all. What they did was a request catalog for their users to order things from IT. They probably did it without establishing a IT Service Portfolio or service catalog. Considering that the IT Service Portfolio should be the foundation for the IT Service Catalog, which in turn is the basis for a request catalog. what are all these Request Catalogs based on? In this article i use the term Request Catalog for the actual request interface that a consumer (requestor) uses to trigger/do a request.

So how do one develop a Request Catalog without the necessary foundation? My experience, when looking around, is that it has been common to confuse the Request Catalog with a normal Web Shop and therefore the concept of a Web Shop has been the template and guide. A lot of things are actually similar, even close to identical. This is one of the reasons that i think this confusion occurs in the first place. There are fundamental differences, but if you are not looking, they can be hard to identify. If my observations are true, it means that there are a lot of Request Catalogs out there which are designed to work as a Web shop.

Who cares? It is working fine.
Even if the Request Catalog is designed as a Web Shop, the IT organization would probably claim that it has helped them. That it might have improved request handling etc. I can not argue with that. I would even assume that they are right. Its not hard to figure out that everything that used to be ordered manually from a Service Desk in an unstructured way, now is easier to handle from a Request Catalog in a structured way. Win win, or? I'm sorry to say but the whole idea with a Request Catalog is to help the Customer. Did the Customer benefit from the Request Catalog? Well if it is designed as a Web shop, thats exactly what the Customer got. A web page where they can search and order the stuff the IT department think is important to order this way. And the stuff, is probably very similar to what was ordered manually by the Customer from the Service Desk before. All in all, the Customer didn't benefit that much at all. Quicker delivery maybe, better follow-up and some statistics. Nothing to brag about so you should care. This was not it's purpose and the customer benefits and experience should be much better.

Reality check!
So even if we admit that the Request Catalog should have been preceded by a IT service catalog and an IT Service Portfolio we can not change the fact that this, most likely, is not the case. So what do we do? If i would give the suggestion now to start a IT Service Portfolio initiative you would probably quit reading about here :) so i will not, but if you can, I suggest you do. But without it, how do we continue? Lets face it, no IT Service Portfolio is a weak start for a IT Service Catalog or a request catalog.

Can we turn this thing around?
Sure, of course, easy? maybe not. There are a couple of small things that can be done to gain short term benefits. And this time I'm talking about the benefits the Customer would experience. This will rub off on IT as well but that is a side affect, not the purpose. What we get from changing the focus a bit is a Request Catalog that is easier to manage and easier for the Customer to use.

What should we do then?
I will go deeper into each bullet but here are som principles.
1. Stop treating The Request Catalog as a Web Shop
2. Think Customer Scenario
3. Standardize and reuse everything

1. Stop treating The Request Catalog as a Web Shop.
So what are the fundamental differences between a Request Catalog and a Web Shop? As i mentioned earlier they can be hard to identify but that is not due to complexity, it is more due to that they are small and seems so obvious that we don't manage them properly. 

In a Web Shop you enter everything you got. If what you sell is not available in the Web Shop, you can not sell it. You try to create interesting and dynamic content that is frequently renewed/replaced and to top it off you offer a shopping cart and promise a good shopping experience. Everything a Web Shop should be. Throw in a couple of weekly offers and "right now" bargains you are on the right track for a good Web Shop. 

Is this applicable for a Request Catalog? Let break it down.
- Everything you got 
- Dynamic that is frequently renewed/replaced
- shopping cart

From the list above there is only one thing that I think is applicable for a Request Catalog. That is good shopping experience. Why? Well briefly explore each one. 

"Every thing you got" is a very poor strategy. The content in the Request Catalog should not be what IT "got"or want to offer, it should be what the Customer needs. That means that even if we have 5 different laptops models available, we should NOT put 5 different laptops models to choose from in the Request Catalog. 

"Dynamic that is frequently renewed/replaced" is lack of standardization. In a Request Catalog we want the opposite. The On-bonding service that the Customer finally learned to find and order should be consistent over time. It should be called the same thing, found the same way and in the same place. Actually, the more boring it is, the better experience for the Customer from recognition and repeatability perspective. 

The "Shopping Cart" is an old dinosaur. It is basically always there but the more it is used, the more it confirms that we do not help the Customer in the right way. We should offer more "single click" and "bundled service" that is fit for purpose. The cart is basic functionality in a Request Catalog and your design should consider it as a last resort option for the Customer, not the normal way.

2. Think Customer Scenario
To design content for an Request Catalog requires some thought. We had the example earlier of the 5 different laptop models. I know a laptop may not represent the best of "Services" but the example works anyway and the principles are the same in other context as well. The scenario is that a customer wants "a laptop", not "that laptop". So why would we offer 5 different laptops models and force the customer to chose one? We cannot assume that the Customer can chose the most appropriate one based on models. What we should offer is "a laptop" with relevant descriptions, maybe a few flavors like "light sales laptop" or "big screed laptop" or "powerful designer laptop" etc. Now you might say that -"Hey, then we will end up with 5 different laptops anyway! we did not earn anything with this design". And part of it is true. The number of options for the Customer might not decrease. But there is important differences. 

One difference is that the items reflect the Customer needs (scenario). If I'm ordering a laptop for a sales person it is much easier to understand and chose the correct one if it is called "light sales laptop" compared to a Supplier named Hardware model. 

Another reason is that the "light sales laptop" will be in the Request Catalog all the time even when the IT department changes the laptop model for another/newer one. The Customer will order the same thing year after year but the model and equipment that is delivered changes according IT cycles. Of course we can link information about the actual model that will be delivered when ordered, there is nothing wrong with that.

3. Standardize and reuse everything
To design the content this way means that we need to keep the focus on the customer and try to standardize based on customer scenario. It should be standardized with Customer focus. What does the Customer need included when requesting lets say staff On-boarding. We decide to include a laptop in the On-boarding service. Whenever someone orders the On-boarding service we will include the delivery of a laptop. Seems reasonable. When doing this we want to minimize the administration of this request. The laptop models we already have ("light sales laptop" or "big screed laptop" or "powerful designer laptop|) we want to reuse fully. If we standardize them correctly and want to "bundle" them into the On-boarding service we can reuse them exactly like they are. Once the On-boarding is triggered and the appropriate laptop is chosen by the Customer (could even be automatically selected if on-boarding is triggered on role) Every thing should be inherited and reused. Due to that the laptop does not change over time, there is no affect on the other services and recognition and repeatability from a Customer perspective is very high. The IT organization get a common way to deliver a laptop and can constantly improve the way this is actually performed even if it is requested separately or included in a bundle. 

What is the gain of all this.
If you apply the above, you will still not have a request catalog content based on a IT Service Catalog. But what you will get is a Request Catalog with a customer focus. The more you are able to standardize and reuse, the more "rub of" the IT organization will get. The more recognition and repeatability the Customer get, the better the shopping experience will be. If the Customer have requested a service before, they want it to be easy enough so they can do it again, with a blindfold. If the content is called something today it should be called the same tomorrow. We do not want changes made to content that forces the customer to search or read through the content again. Keep the changes of the "front" to an absolute minimum in a request catalog. Content that is added, phased out and replaced will of course occur. A few years ago there where no tablets, now there are. Now they are called iPad, Xoom, Tab, Nook, Nexus etc. Who knows what they will be called in the future? If we would design the content based on supplier models we would have a continuous need to change it as soon as we provide a newer or different brand or model. If we would design standardized content with customer focus we would probably have tablet names corresponding to the use it was targeted for. The need to change them would be very limited, even with linked information about the current model that is delivered.

Am i in the green zone now?
This does not in any way change the need for a IT Service Portfolio and a service catalog. What it does is that it gives you a working Request Catalog instead of a miss aimed Web Shop.

måndag 16 september 2013

The shortcut to successful ITSM. OPS, did i just say that?

Last couple of months i have read an increasing number of posts and articles addressing ITIL and the challenges with achieving good IT Service Management. All of them are good, some even exceptionally good. I read them and agree with them but they seem to have one thing in common. They are all pointing out the fact that the initiative must be Customer focused. The guiding star needs to be business value. I do not disagree with that. For sure not. Enable business and business value should be the guiding stars and a Customer focus should be main ingredient. 

Reality check.
I made a quick un-scientific search for articles and posts a few years back in time and guess what, we said the same thing back then. There might have been a few differences in the words used but the message was clear. Customer focus, Business value, IT as enabler seems to have been the receipt for ITSM success.

This gives us what?
If this is what we today promote as success factors for ITIL and ITSM i guess we will get the same result in a couple of years as we have today based on our recommendations a few years back. And what was that again. IT organizations still struggling and the community still promoting the same mantra, IT as enabler, business value bla bla bla. 

How can ITIL help?
Do I have an easy answers? No! There are no easy answers. There are no silver bullets. There is hard work and practice. What do I mean with that? If we take a closer look at ITIL there is something called ITIL Maturity levels which i really like. It actually states that every organization, in relation to ITL, has a maturity level that defines where they are positioned based on this maturity model. When taking a dive into this model we find that it is more than just the five main levels. It is multidimensional and a organization can carry out activities belonging to maturity levels both above and below their "actual" level of maturity. This makes things complicated even when simplified to 5 levels of maturity. 

What should we promote?
Is it easy enough to say Customer focus and Business value? I really do not think so. If we consider the ITIL maturity level model, there should be at least 5 different answers (and things are not even that simple). All of them shooting for Customer focus and Business value as their "End game" but there is usually a long way there. If we can not come up with better answers that are more inline with an IT organization needs we will just continue like this until all trust is spent. I know there are really good ITIL and ITSM practitioners and consultants out there but that is not enough. They might know what is needed but the general message is still not useful in the sense that it can be used by an IT organization in general.

ITIL and ITSM contains a lot of culture and you do not change culture. You can change behavior and behavior will eventually change culture. Culture is partly a result of behavior and not the opposite. That would mean that we have to start with a set of practical recommendations that is achievable on the lower levels. Considering that most IT organizations are at the lower maturity levels I guess that the first steps should not be to address IT as a Business, which is the highest level of maturity according to the ITIL maturity model, but that is still what we do.

Each level has its requirements, roles, activities and results. We can not cut corners or do shortcuts. There are effective ways to speed up progress but we can not jump ahead of time. I have the impression that many IT organizations tend to identify themselves higher in the maturity model than they really are. When this is the case there are important fundametal parts missing from lower maturity levels that will result in that the next level will be harder to accomplish, in some cases almost impossible. This is usually due to that some activities that are performed, and some results that an IT organization actually achieve, really are mapped higher in the maturity model but that does not count for everything that they do. We should try to identify ourself in the maturity model from the lowest level of activities and results we achieve, not the highest. This approach enable us to establish all the necessary requirements to evolve and establishes a solid ground to stand on to take the next step in the maturity model. Not to forget, the change of behavior that is established makes sure that the change of culture is also in the progress.

The shortcut to ITSM.
The shortcut to achieve good ITSM is not to think that one can go to the highest level of maturity at once. The shortcut is to establish, practice and verify that each maturity level is fulfilled before trying to address the next one, even if there are few parts of the next one that is already carried out. One step at a time with no leaps of faith. Does this mean that we need to do everything that is written in ITIL. For sure not. To achieve the "End game" there is a lot to do but the key is to identify the basic parts for each maturity level to enable the next step. Not to address the next step and later on realize what was missing. 

måndag 12 augusti 2013

I want information and a purpose

I love my work. I am officially a process nerd in everyone's eyes :) But long ago i started to asked myself why. Why do i like it so much? Is it something magical in the processes modeling that makes it so interesting? Is it the creation and visual blooming that occur on a whiteboard when you start drawing it? Is it the pleasure when verifying that the outcome was actually what it was supposed to be? is it the feeling when CSI work starts to show in metrics and KPI's?

There is a lot of joy in the work, thats for sure. But the last years i have seen a pattern. What really is the essence of my satisfaction is in the construction of it all. When you start, you know what triggers it and you know what the outcome should be. In the beginning, everything in between, is just a blur and it is here it starts. Finding all INFORMATION. It is everywhere and it is endless. There are people involved, everyone has their requirements and suggestions. Opinions flow and everything is discussed e.g. tools, user interfaces, routines, sequences etc. It like a wonderful bowl of spaghetti, all nestled in one and each other. 

Sorting out the structure, dependencies, sequence and foremost identify all relevant INFORMATION needed to get to the outcome, is what triggers me. The more information you can get hold on the better, if you are able to structure it, otherwise it can be a nightmare. What i have realized is that i do not want a process, I want an information flow. Information guides me, not a process. I do not care if we are working on the Incident, Change, Problem, Event or any other process. That is so irrelevant as long as the outcome is clear. What is the purpose of gathering the information, who needs it, where does it come from, when is it available, in what context, how should it be structured, when is it needed and the guiding star: what are you supposed to do with the information once you get it, and dont give me any "it is nice to have".

I conducted a brain teaser the other day. I challenged myself to define the major information flows required to replace all the operation processes defined in ITIL. One information flow replacing 5 ITIL processes. I know, it was doomed from the beginning but i did it anyway as an experiment, to challenge the paradigms i have and with a lot of simplifications. Some interesting thoughts arise from it though. Information defined in a process that is needed in the same process is usually structured the way the process needs to consume it. The logic used is based on the logic from the process. When initially designing a process you do it one by one and therefor it makes sence focusing on logic for a specific process. Some examples are -Incidents, they are categorized and structured the way we think is good when it comes to firefighting and analysis of that. -Changes, they are categorized and planned through time and with impact assessments due to the importance of that. And it goes on like that throughout the most of the processes. What if the Incident process had to structure, store and manage all Incident information base on requirements from Change and Knowledge Management, or the Change process had to store and manage all change information based on requirements from Event and Incident management and so on. 

So my mind was set. I would structure all information from one view but which would i take. I started to think of many different views and i asked myself the following question. What do i know about the environment I am trying to define? We are still talking about all the Operation processes in ITIL. What could be the common view? Hmmm the conclusion was that the only thing i know for sure is that whatever we do today, will not look the same in a couple of years. Could i use this somehow in my view for structure? And i could. I asked myself what i could use as a base for something unknown and it was so obvious. Continues Service Improvement (CSI)  is a perfect base for the processes. If we have a process today and we know it will change over time it is CSI that will make it happen. SCI does not only improve something to be quicker, bigger, taller. It changes it as well. SCI is not only vertical, it is also horizontal. If the customer is the focus for SCI and all the processes are based on the ability to perform SCI improvement i think we have very good conditions to actually amaze people.

So if my information structure should be based on SCI, meaning that everything should be initially structured and based on the ability of measuring, reporting and improvement, what would happen? The first thing i noticed was that it all had a big meltdown. Suddenly there were no processes any more. From an improvement perspective the analysis required data from every process every time. That means that already from the the first step in every process, which is registration, the information should be stored and structured from a CSI perspective. That is the only way to secure that it will transform over time, as will the requirements of it (and if CSI is focusing on the customer you can figure out the rest). All this lead me to a quite interesting information flow covering all the major steps in each operation process. 


Just imagine the change impact assessment and risk assessment quality when incorporating historical statistics for issues involving affected HW or SW, persons involvement , time of day, historic availability, incident ratio related to changes, early life support outcomes and the list goes on. Everything i mention here is fully possible already today. There is nothing odd about it. It is already out there. But when i take a closer look at the information itself, how it is structured, shown in UI, ad hoc availability etc. I see that there are limitations due to that the way information is consumed from the process itself often rules and other processes "use what they can", if they want. The information is not isolated but but it is not effort less to use either.

So what will happen in a couple of years? Do we have processes or do we have information flows and rules that guides us from a improvement perspective? I do not know. but i know why i like my job :) I feel like the character Sherlock Holmes, and every day is a new episode with a new mystery that has to be solved. A new unknown that has to be broken down to particles, logically assembled together to create magic. 

I will continue to design and create processes but the process is a byproduct of something larger. The information flow and the improvement requirements is ruling my world. I want information and a purpose.

onsdag 7 augusti 2013

I want to amaze someone every day.

I have a picture in my head of a circus clown walking around giving children animal balloons, looking into their big eyes filled with amazement while the balloon is slowly transforming into the animal of their choice. I want to amaze people as well. Hell, thats why i go to work every day. But do I amaze people every day. No i do not, but i would like to. There are so much things that "I would like to". I imagine going to work where people were amazed by the things we could do for each other. 

I would like to see the face of the Incident Manager when a new Major Incident has occurred and before she even picks up the phone, all information about the last 24 hours of "tickets of any sort" is nicely structured based on the service and infrastructure involved in the Major Incident.

I would like to see the face of a customer getting a phone call from the Service Desk informing that the issue she experienced earlier is now solved and the customer realizes that she had never reported the issue in the first place.  

I would like to see the face of a manager when her group or function presents their short term and long term improvement plan, without her asking for it. Plan based on quality measurements and KPI's when she understands that it will solve the stuff her boss been nagging about. 

I would like to see the face of service customer when IT, in a constructive way, explains the implications, alternatives, risks, options and costs associated with their latest demand in an understandable way without one single IT term.

I would like to see the face of a coworker when a colleague steps up and says that I think you are doing a great job and leaves without expecting and answer or gratitude. 

I would like to see the face of a customer when IT calls to offer a new service which solves the issues identified ahead.

I would like to see the face of a Service Desk agent when she answers a call and all information of the caller is automatically shown and interactive on her screen. The callers used services and applications, related events, related ongoing and resolved incidents, related earlier issues, related scheduled and performs changes etc.

I would like to see the face of a service responsible looking at a KPI dashboard realizing that it actually says something. No analysis is required and countermeasures and success factors are obvious and clear.

I would like to see the face of the service management tool responsible when a requestor specifies new demands by explaining their expected outcome, purpose and information required to get there instead of requesting new fields, forms and buttons.

I would like to see the face of a Operations Manager when realizing that the Problem Management Process he really did not want or understand actually solved the long running issues they have been struggling with and a happy customer just call him to tell him that.

I would like to see the face of a coworker using a whiteboard marker that actually work.

I would like to see the face of me when this list is fulfilled.

Well as you can se there is a lot of things "i would like to" and the list continues. Some day I will get there. That is my unswerving conviction and firm belief. call me a naive, thats ok. I think it is a compliment. 

onsdag 10 juli 2013

What does a 5 year old know about Service Management

More than a week has passed since we arrived here in Torrevieja, Spain. I have spent every hour with my family and foremost my 5 year old daughter. She has a wonderful way of looking at her surrounding which is not influenced by anything else than her own needs. What can she teach me about Service Management regarding that she only sees the world from her own needs and nobody else's. well, it turns out that it is a lot. One would think that everything she does is based on that the supplier, thats me, facilitates it for her. Nothing could be more wrong. It turns out that I am the customer and her needs are connected to mine. Let me clarify. If we are playing in the pool and it is lunchtime I would say that we need to go and eat. Her reply is, of course dad, then we can play some more afterwards. She projects our need to eat, to gain more energy to play. This way I get exactly what I want. Her getting out of the pool without any fuzz and kindly accompany me to the meal. She gets a dad that can't say no to some more pool time due to her excellent behavior. 

Later on that evening we all go to a big shopping mall in the area. She knows that there are carousels there and tags along, again by acting excellent. Once there, the wife wants to enter and browse every shop in the mall and here she amazes me again. My daughter pulls my hand and says. Mom can look in the stores while we have ice cream over there and points with her finger. My wife thinks it is a great idea and off we go to buy ice cream. Just next to the ice cream shop there is a carousel. In the line she looks at me and says. You can have an ice cream and you can sit right there on the bench while I take a ride on the carousel. How do you say no to that? She is the happiest kid in the world when her hair waves in the air while riding a big bunny. I feel like a king just looking at her and knowing that my wife is in shopping heaven. 

It turns out that my daughter is the supplier that fulfills my needs but she makes sure she gets paid. The days continue like this where she identifies my needs, justifies them with something she needs and, BOOM, she has a sale. You might say that c'mon, this is what kids do. They manipulate you this way and you as a parent think it is amazing and falls for it. All I can say is that you are so right. But I prefer it this way. We agree and get along. Well there are days where things do not ..... Lets just say that there are days :) 

If I could identify the needs of my customer, make sure they where fulfilled and made sure I got what I wanted for it I would say that I had a pretty good Service Management day. Wouldn't you? Kids can teach us to see things in a simpler way. In their world nothing is complex and anything is achievable. 

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. 

fredag 31 maj 2013

The tail of a server, asset and ci

Once upon a time there was a small server born. Along his interesting life he always took comfort in the "computer God" that he was was told lived in the Internet. From birth he always considered himself as curious, open for new ideas and thoughts, and this is his story.

Early on he lived in a big factory pretty much waiting for something to happen. One day there was a big fork-truck loading him and many other server on their journey towards new exiting adventures. After a couple days of traveling he could feel that the box he was inside had stopped. Somebody was scratching on the outside. The box was slowly opened and a face full of anticipation look down at him. - Oh look at that. What a beauty the person said. He was one of the company technicians and was known for his love for hardware new technology. The server had never felt this kind of care and warmth. He was really enjoying the mounting in the server room and installation of Software that the technician put him through. He was told plenty of times that he was the proud and joy and how fantastic everything was going to be.

During the unpacking he had seen that the technician had been talking notes and writing down numbers from the box on a piece of paper. He thought about it and asked the "Computer God". -What was that about? Why did the technician write down all that stuff? God replied -You are now an Asset. When you where received here you entered a new stage in your Asset lifecycle. You where registered as "received" instead of "ordered". You will soon be registered as "in use". You belong to the type of servers called "small server". You are the first of your kind and there are other ones, not of the same kind, already living here, also called "small server". They will slowly be faced out and replaced by more of your kind. -Wow, this really sounds fascinating thought the server and asked God. -Why am i a asset? God replied. -the company needs to keep track of you so that we know what contracts covers and supports you, what licenses are used on you, the cost of owning you and who the supplier is etc. You have a lifecycle that will manage and follow you as an Asset until you are disposed of. -What, said the server. Is my purpose to be disposed of? God replied -Well, not your purpose, but that will eventually happen to you. Just like it is now happening to the server that you are replacing. The server was very disheartened by this and did not feel good about the new things that he had learned.

The days passed and the server was really doing well and enjoying his job. Every time there was a need of process power he really put his hardware to it and performed his very best. Occasionally the technician came by and told him that he was doing such a good job and everyone was very impressed with his work. The server felt really good about this and continued to work very hard. One day he turned to God and asked. -I really like the job and its very clear to me that i do it good. But i am still wondering why i am doing it. Do not get me wrong, i really like it and the technicians are very kind and i like it here. -Well this is the life of a server. We keep track of you and take care of you. If something in you breaks down we order a new part and replace the broken one, everything is a part of you lifecycle. The server remembers the last time he was broken. It took 3 days before someone replaced the broken part and additional 2 days before he was fully operational again.

One day there was a buzz in the server room. All server where talking because one server had overheard a technician say the there is a new process guy starting at work. -Why is this so exiting? asked the server. The technician had said that the process guys was going to explain the purpose of all equipment including the servers. This sound really exiting thought the server but remembered what the God had told him about getting disposed of. He felt a bit depressed by it but was interrupted in his thought by a burst of processor capacity and did not think about it more. 

The months passed and the process guy had visited the server room a couple of times but there was no news about what was about to happen. After some additional weeks the buzz in the server room started again. -The process guy is done with the first stage, the server heard another server say. Everyone was exited about the news but time went by and nothing happened. One day, suddenly the server noticed that he was getting warm and after a wile a memory card broke down. Well, he though. I will just sit here and wait like the last time he broke down. But this time everything was different. People came running and remote control tools where used and he had never seen this much attention for any server before. He was up and operational in less that two hours. Less than two hours! This had never been seen before in the server room and all the servers where talking and discussing what had happened but without any answers. 

The little server felt proud. He did not really understand why he got all that attention but he did and the other server look at him with admiration. Everyone was happy for him and he felt very good. He asked God. -Do you know what happened and why i got all the attention? -Well, God said. You are now a Configuration Item as well as an asset. -I already knew that i was an Asset but what is a Configuration Item. -Well, you have actually always been an asset and then later a CI but the process guy has done some changes in the CMDB and now everyone can se what you are used for and who is using you. We also know if it is important that you work correctly and how long it can take before you need to be fixed. The server look confused and asked. -What is the difference between an Asset and a CI? God replied. -An asset is tracked from a financial perspective and the information is structured to fulfill those needs. An Assets being grouped into variants that is grouped into products that is grouped into types etc. This structure is used ,among a lot of other things, to maintain license compliance on the software that is running on you. -So what is a CI? -You se, said God, when you are used for something then the Asset status is set to "In use" and a new lifecycle starts and kicks in and that is the lifecycle of the CI. So in short you could say that within the status of "in use" for an Asset there is many more statuses that is irrelevant from an Asset perspective but i crucial in the delivery perspective where the CI exists. To keep them separate we call them Asset and CI. You are both Asset and CI but depending on what information is require we can look at it from different perspectives. 

-You still did not tell me why i got all the attention earlier on. -Well said God and thought about it for a while and continued. -I might as well show you because it is kind of hard to explain it. God showed him a picture with lots and lots of squares and lines and pointed to one of them at the bottom and said. -This is you. -Me? said the server and looked very confused. -Yes it is you and everything you are in relation with. -But said the server -Just follow me here, interrupted God. -This is a visual representation of everything in the server room and connected to it. We store the information in the CMDB and this square is you. This one over here is the server next to you. Here you have the network you are connected to and this is the softwares that is run on you. -We have always had this information said God. The server asked -Last time I broke down it took 5 days before i was in operational state and this time it took two hours. If we always had this information why was it such a difference. -As i said earlier the process guy had done some changes in the CMDB, which actually is what we are looking at right now but as a visual representation. The changes and additions he made are these squares here at the top. They are services. They shows us who is using the equipment for what and how important it is that it is working at a specific moment. The reason you got all the attention is because you are a very important part. The server look shocked and said -important, me, but, why? -You are a very critical part of a service delivery and when you break down there is a lot of people that can not do their job. We did not know that before but now when the process guy have shown us how to understand whats really important we can focus on the right things and make priorities based on that. 

As the story continues out little server experienced breakdowns and upgrades until he finally was replaced by a new server. The server felt that he had lived a fulfilling life and was looking forward for retirement. The Ci was decommissioned and the Asset was disposed of and the server ended up in a secondhand store. He was purchased by a newly graduated student who was exited to get her own server so she could learn how to write program code. She had a brand new new idea for a program like nothing else seen on the market but that is a completely other story.