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 :)

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.

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. 

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.

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. 

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. 

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 :)