ITIL explained with coffee #ITILcoffee

After a short moment of inspiration i came up with the idea of creating a simple descriptions of ITIL processes based on a coffee scenario. After posting a few at Twitter (@howtoitil with hashtag #ITILcoffee) i got a number of requests asking if they are free to use. My reply, of course they are! So here they are, all of them.

How to scope your IT service initiative. Do you need a Portfolio,catalog or requests?

To be able to discuss IT service and potential scope, ambition and effect of IT services we need to establish a few terms. I will use three different terms that is very related to each other.

Service Portfolio: The content of a Service Portfolio describes what capabilities and business processes that a customer have, value and prioritize as of today and the future. This is the basis (customer requirements) that IT need to support and develop with matching IT services. The IT services is completely driven by customer needs. The Service Portfolio can be documented in any already existing or arbitrary format.

Service Catalog: The content of a Service Catalog describes all the IT services that is available for the customer at the moment. Any IT service description clearly states the service content, commitment, limitations etc. The content must reflect the available IT services for a customer and is favorable described as a sales brochure in either electronic- or paper- form.

Request Catalog: The content of a Request Catalog describes all the ways a user can interact with available IT services. It is how a user requests ability to consume an IT service. To add, change, move or delete ability to consume it. The content is completely an effect of IT's ability to bundle requests. The Request Catalog is usually available for users as a web based request portal.  

Now when we have three terms defined on a basic level we can continue with a few examples that is categorized on focus, based on these terms. A desirable effect is related to what part is in focus and the basic conditions to achieve them. This is just a few examples to show how one can categorize desirable effects to enable a strategy and plan that is not to fragmented.

Depending on ambition, and effects you pursue, you can use this way of sorting to scope and focus your initiative to increase probability of a good outcome. Do not try to do more than you can handle. There is a very important relation between the three different terms. A Request Catalog get higher quality if the content is a result of a working Service Catalog where the requests are defined based on how a user is supposed to interact with the available IT services. A Service Catalog in its turn get higher quality if the content is a result of a working Service Portfolio where the Service Catalog content is based on business outcomes prioritized by the customer as important and the IT services necessary to manage the business. The Service Portfolio verifies that the development of the IT services is based completely by the customers needs and future challenges. 

How categorization can help you decipher your IT services

The term IT service is commonly used in different IT contexts. It is frequently associated with IT delivery in an attempt to illustrate some form of packaging of benefit and value to the customer. What I often miss is the breakdown and categorization of the term IT service. To be able to apply it one need to be very clear with what it means due to the broad application of it. I simply call it navigation. The reason I think one needs to break it down is that the surrounding of an IT service is affected by what we mean when using term. Surrounding in this case is how we realize it, deliver it, measure it, describe it, what content to put in an SLA etc. All these things is affected by what we actually mean when using the term IT service. 

Category Transaction vs Subscription.

Lets start with the first categorization. Is the IT service used to illustrate something I actually use as part of my work or is it describing something I might need to order or request due to that I need it. Lets make an example. I need a printer available from my work computer due to high demand of printouts in my line of work. Lets assume that at the company I work, there is a request portal to place this kind of requests. I complete a request of a printer from the list of available printers I see fit for me and I receive a e-mail confirmation of what printer I have ordered. A few days later it gets delivered and installed, ready for my use. The IT departments commitment this far has a focus on delivering a working printer to me according to circumstances and prerequisites that the IT department have defined. Costs associated with this request is probably the purchase price of printer, paper and consumables like ink etc. for the printer.  

If we stop here I would categorize the above example as a Transaction IT service. The commitment from the IT department would basically be over and done. The request is measured in various ways, used in follow-up, is described, managed etc. as a IT service to achieve what described in the example above. From this point onward I have the possibility to make printouts from my work computer. If for some reason I need, I can call the IT department Helpdesk to get assistance if any problems might occur while using the printer. 

Now we get to the counterpart to transaction service. It is the Subscription service. If the IT service would have been described as a subscription IT service it would have to be structured differently. In a subscription I would probably not choose a printer from a list of available printers. I would probably choose what capacity of printout I need and how critical the printouts are at the time I print them (availability). We are potentially still talking about the same actual printer but there is a significant difference in the commitment from the IT department associated with the subscription IT service. Now the commitment is not only to deliver a printer, but the ability to print which includes the monitoring and planning of activities like change of ink cartridges, paper, plan service intervals, cleaning etc. The more printouts I do, the more the IT department need to act. Of course I still have the possibility to call helpdesk whenever I am in trouble with my printouts. Costs associated with this request should based on my printouts. e.g. I pay for each printout and this way I can change my behavior and that way influence my costs associated with my printouts.  

In the subscription example there is still a initial part that is corresponding to the transaction IT service. It is the actual delivery and installation of the printer. This needs to be measured and be managed as a transaction IT service but the significant part here is that the IT service is described as the ongoing commitment of printout ability from the IT department that is based on my printout needs. 

Category Generic vs. Specific

The reason to categorize if a IT service is generic or specific is due to that it often affects how the IT service is described and offered. Generic in this case is to offer the IT service to a broad base of customers with high level of flexibility. Preferably every available customer. If this is the case the IT service usually needs to be offered with different levels and scope. It can be levels based on volume, availability, response time, scalability etc. 

A specific IT service usually address a specific customers needs. The levels (options) that was characteristic for a generic IT service tends to define the actual service in much higher grade in a specific IT service. The specific service should cover a specific customer need and hence, there is less need of options and configurability. A specific service tend to need a high frequency of review and follow-up much closer to the customers goals and the value of the IT service. 

Category Process Oriented vs. Bundled

The third categorization is whether the IT service is process oriented or bundled. A process oriented IT service has a very strong connection to the customers business goals and output the customer is striving for. There is also a different foundation to show the IT service contribution to those business goals and outputs. The IT service content (service functions) is very closely related to the customers actual business flow and any activities and sequences that the business flow might consists of. The success of a process oriented IT service is completely dependent of the IT department ability to understand how the customers business process works, looks like and purpose. Any change in the customer business process might get a consequence in how the IT service is described or delivered and must be managed thereafter. 

A bundled IT service is more based on commonly occurring request behaviors, patterns or other practical reasons. An example could be a packaging of a mobile phone. If a user should have the possibility to request a mobile phone in the company request portal it would be rather inconvenient if the requestor received just a phone. It would probably lead to that every requestor would be forced to enter the portal again to request a working SIM card, and a phone cover, and cables, the changer and finally the correct rights for content synchronization. This would not be very efficient nor very practical for anybody. probably very frustrating. Here a bundled IT service would be very suitable. Put all parts in a bundle to be carried out in one request and let the requestor decide what is relevant in that particular case so that no further requests are necessary at a later stage. 

Category Customer Facing vs. Supporting

The last categorization is whether the IT service is used directly by a customer or is a supporting service to enable the former. Examples of customer facing IT services is all occasions when a user does not only order or change the delivery of a IT service but actually uses functionality provided by the IT service. It could be a "order management" IT service. The customer actually uses the functionality delivered by the IT service to perform the work concerning order management. 

A supporting IT service could be the operations of a database that the order management IT service is dependent on. It would be a hosting service that the IT department can purchase of a external hosting supplier or perform themselves internally. In the case of external hosting company there is parallel customer and supplier relationship. The hosting service have a supplier, a customer, is measured, managed etc. but the hosting service is still used as a supporting service to the order management IT service. 

Focus of transaction category

If your services are transaction services, focus on simplifying the request interface (portal) and standardize the fulfillment flow so it has high repeatability. Measure it to understand lead-times etc. and if you have a portal, be very clear with what the commitment covers e.g. the fulfillment of the request. 

Focus of subscription category

If the IT services are subscription services, focus on identify, define and describe the ongoing commitment that will be in place after that the request is completed. The commitment needs continually to be measured and verified by the customer.

Focus of generic category

If the services are generic services, focus on defining levels and scope that is actually used. There is no meaning of defining Gold, silver and bronze if nobody ever is going to by the Gold. Try to se it from the customers point of view instead of just copying something you seem fit. High flexibility and configurability is key, otherwise you will get a service with flavors that is to static to perfectly fit any customer

Focus of specific category

If the services are specific services, focus on the case the customer want supported. Understand the constraints the customer is dealing with and make sure your actually make life easier for the customer. 

Focus of process oriented category

If the services are process oriented services, focus on understanding the customer and their business process and the output the customer is trying to achieve. Make sure the service and the service content is named and described in business language according to the business process the service is supporting. There is major incentive to actively work with IT service Portfolio and IT service Catalog concepts. 

Focus of bundle category

If the services are bundled services, focus on making sure the bundle decreases the number of request the user needs to do to achieve their output. Bundled service commitments also needs to be described but tend more to be influenced by request patterns and other practical packaging. 

Focus of customer facing category

If the services are customer facing services, focus on defining relevance of services from customers point of view. When the customer enters the request portal the content shown should have high relevance for the customer. It should be obvious to the customer what the purpose of the content is and navigation should come naturally. The service should also be of high importance for operating the service with an accurate customer value defined to enable prioritization in the ongoing service delivery.  

Focus of supporting category

If the services are supporting services, focus on defining a delivery structure where the supporting services are put in relation to the services they are supporting. It is important to understand the impact and risks when planing changes or handling disturbances.  

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.