Tuesday, February 26, 2008
The Service Model
There is an important concept that ITIL V3 uses throughout the lifecycle; the model. There are many models suggested in the five core books. There are models for services, requests, incidents, problems, changes, releases and others. I will explore them one at a time, starting with the service model.
A service model helps define the service strategy for a particular market space. Think of a model as an architect’s blueprint. The blueprint will describe the process and functions supporting a service and the interactions between the service assets and the customer assets to create value. As it was previously discussed in this blog, value is created by a combination of utility and warranty. Interaction means demand connects with the capacity to serve. Service agreements specify the terms and conditions in which such interaction occurs with commitments and expectations on each side. The outcomes define the value to be created for the customer, which itself rests on the utility provided to customers and the warranty.
A service model describes and defines both the structure and the dynamics of the service; which are influenced by the customer’s requirement regarding utility and warranty. The service model will be used by all phases of the lifecycle.
Service Design would be drastically simplified if your organization only had one service and one customer for that service. However, reality is that we have many services offered to many customers which may or may not have similar requirements. It will be the job of the people involved with the processes found in the Service Delivery phase to evaluate the requirements, consolidate them and to suggest solutions to the customers then, once agreed to design the solution.
The Service Transition phase will then evaluate the details of the service model before proceeding with building, testing and deploying the solution. Service Operation will then take over, dealing with monitoring, incidents, problems and requests about the solution. Service Operation personnel will use the patterns of business activity to anticipate rises and falls in the demand for the service.
The Continual Service Improvement phase ensures the feedback to the strategy, design, transition and operation processes.
There is an interesting EXAMPLE of the dynamics of a service model in the Service Startegy book. It is figure 7.8 on page 164.
Here is an example on how to use the diagram. I am using an online shopping experience to illustrate this. This example is high level and does not reflect the actual sequence.
The diagram had 10 parts for a total of 14 activities. The diagram is a variation on the ISHIKAWA diagram. In order to make sense, you need to read the diagram from right to left
• Part 1 Shopping – three activities
1. Present a searchable and navigable catalog – the customer logs on to the website to shop
2. Search and sort – the website offers and has the ability to search a wide variety of products
3. Assist the shopper in selecting – The customer can simply browse or sign in as returning or new customer. There are various other sections such as help, recommendations, menus, etc.
• Part 2 Selection – two activities
4. Provide the shopping cart – The customer has the ability to select many items
5. Maintain cart contents – The shopping cart tracks the selected items and their attributes.
• Part 3 Recommendations – one activity
• Assist the shopper in selecting – provides the shopper with related items such as accessories, options, parts, etc. In the case of media such as books, CDs or DVDs the website will often provide other titles by same author, other books in same series if applicable, same genre, etc.
• Part 4 Ratings – one activity
• Assist the shopper in selecting – The website provides feedback from other customers, reviews from magazine articles, etc.
• Part 5 Assistance – two activities
6. Assign a sales specialist – can be electronic, web-based, phone, email, other. This is often done by asking the shopper if they have any inquiries or questions.
7. Answer questions – self explanatory
• Part 6 Special offers
• Provides links to other special offers to generate impulse buying. (Is this a gift? – offer gift wrapping, card, etc); the website often has a section “others also bought…”
8. Assist the shopper in closing – asks customer to proceed with check out
• Part 7 Shipping
9. Present the shipping options and their costs – from regular mail to express delivery as well as confirming stock availability. This is sometimes done by using third party vendors such as delivery companies.
• Part 8 Calculate shipping and tax information
10. Present with shipping and tax – adds shipping and handling costs if applicable as well as any applicable taxes. The tax is provided by an external party; the government. There may be many applicable taxes.
11. Obtain the final confirmation – in the case that the customer wants to add/change or remove items or cancel altogether. Websites often ask questions like “Are you sure?” or “Are you really, really sure?”
• Part 9 Submit details to shipper – one activity
12. Provide the confirmation details – the website will asks for the address, confirms it and provides delivery date. This activity may involve a third party.
• Part 10 Authorize shipment - one activity
13. Ship the items purchased – The warehouse receives order, picks it, packages it and ships it. This activity may involve a third party.
• Part 11 Payment processing
14. Complete the order – offers payment methods such as cash on delivery, cheque, credit card, gift cards or other. Payment through a website often involves a third party.
And finally
We come to the second activity 13 which is just under activity 14.
• After receiving confirmation such as proof of delivery or payment, a request for customer feedback is initiated. This can take many forms, such as an email, a phone call or a letter.
Personal take on the last activity
I would have labeled it differently such as “A” but let’s not worry about that. This activity indicates that a customer satisfaction survey may be initiated. We have learned in ITIL that we should close a record (such as an incident record) only after we have confirmed with the customer that everything is OK. However, in a shopping experience like the one depicted above, waiting for feedback before closing the order would be impractical. Not everyone will provide feedback.
Monday, February 11, 2008
About Resources and Capabilities
Is the concept of resources and capabilities really “new”?
Resources and capabilities are types of assets and used create value in the form of goods and services. Resources are usually consumed in some way, shape or form while capabilities are the abilities of an organization to transform the available resources into products and/or services.
Resources being items that are “consumed” are easier to explain and to understand. Resources include financial capital (money). Everything costs money and money does not grow on trees and every organization require money to function. It is the “fuel” of an organization. Other resources include the applications and the infrastructure. Application automate, enhance codify and mimic the functions and activities of the capabilities. The infrastructure is generally understood to be the hardware, software, network components, facilities components, etc. Application resources are part of the infrastructure and that the infrastructure can be viewed in layers with each layer building on the previous one. Information is the context given to data. More on this in a little while.
Capabilities include management, organization, processes, knowledge and people. Capabilities are used throughout the lifecycle of a products or service. To oversimplify things, resources are used to plan, do, check and act (Deming’s cycle) against products and services.
Before we get too ahead of ourselves, let’s explore the capabilities in more details. Management influences and is influenced by the hierarchical structure of the organization, its culture, history, and by the managers themselves. These influences can be both positive and negative. Please make sure you do not dwell only on the negative aspects but on the positive ones as well. Some questions to ask include:
• How long does it typically take for management to make a decision? Wait too long and you may miss the opportunity; respond too quickly and you may miss the mark. This is represented in one of the Service Operation conflicts of stability vs. responsiveness.
• Are decisions solely / mostly based on costs? Too much emphasis in cost cutting could result in sacrificing quality. This is represented in another of the Service Operation conflicts of cost vs. quality.
• Is management a victim of analysis paralysis? The organization might be stuck in a reactive mode instead of being proactive. However, the opposite might be true and the organization is too focused on being proactive.
There are obviously many other questions that might be asked but the management’s behavior needs to be understood in order to identify how resources are managed and how decisions affect the other capabilities as well.
Already we have touched on some aspect of the organization when we explored the management capability. The organization capability, like the management capability, influences and is influenced by the hierarchical structure of the organization, its culture, history, and by management and, again, these influences can be both positive and negative. Some of the issues raised by the organization capability might include:
• The culture of the organization
• The make up of the organization; centralized, localized, decentralized, etc.
• The customer’s perception of the organization
• Recent good or bad press
• etc
Processes are also very important capabilities. Think of it as an assembly line. Inputs go in; they get transformed through a set of activities and some outputs come out at the other end. Of course, this is an oversimplification. Processes are a lot more complex than that. They require process control capabilities such as ownership, policies, objectives, documentation and feedback mechanisms. It also requires process enablers such as process resources and process capabilities. There’s the link right there. You may have a great process but if it takes too long to accomplish anything or if it is not followed, what’s the use?
How can knowledge be a capability? The answer lies in its definition. Knowledge is putting information into context. Information (and by inference data) is a resource. This is concept is explained in the Service Transition phase in more details but basically the values stores in the fields of a database for example. The information is basically the field types. A series of numbers such as 1, 2 and 3 does not mean anything unless the fields are labeled. If 1, 2 and 3 represent temperatures or distances then we have a better but still incomplete understanding of their meaning. Knowing that distances 1, 2 and 3 relate to the distances (say in kilometers) between you and the three nearest coffees shops is knowledge. For example, management and the people through their experiences and skills placed in the context of the organization with have the capability to transform the information into knowledge. This is why information is the resource and knowledge the capability.
What about people?
People are both capabilities and resources. We employ people’s time, energy, skills and experience in various roles to help the organization produce and sell goods and services. This is the resource aspect. You do need the warm bodies through the use of their time, energy, skills and experience to execute the activities of a process, to make management decisions, to translate information into knowledge or to have an organization. In short, without people there are no capabilities and the resources certainly won’t spontaneously transform themselves into goods and services.
We can apply the concept of value creation to all the capabilities.
Utility
• Are the capabilities enhancing performance or inhibiting it?
• Are the capabilities removing or reducing constraints?
Warranty
• Are the capabilities available? Example: Management? People? Knowledge? Etc.
• Do we have enough capabilities? Example: People? Knowledge, organization? etc.
• Are the capabilities continuous enough to operate in times of crisis? Example: People? Processes? Management?
• Are the capabilities secure enough? Applies to all of course.
But can we apply the concept of utility and warranty to the resources? Of course we can. Think about it for a few seconds.
Utility
• Are the resources enhancing performance or inhibiting it? Old, obsolete infrastructure, information and untrained workforce?
• Are the resources removing or reducing constraints? are the resources constraints themselves?
Warranty
• Are the resources available? Do I have the raw materials?
• Do we have enough resources? Do I have enough for all my orders?
• Are the resources continuous enough to operate in times of crisis? Can I order more in time form same or difference source without compromising quality?
• Are the resources secure enough? Can my resources be easily stolen or spoiled?
In conclusion, capabilities and resources have been around for a long time. It is simply that the concept is new to many in IT and it is a new addition to the Service Management framework. If you think about it, you can apply the utility and warranty concepts throughout history of humankind; from the hunter-gatherers to the pyramid builders; from the Great Wall of China to the aerospace industry. What do they have in common? They all consumed resources and they all required capabilities.
It is all about integration…
Thursday, February 07, 2008
Service Portfolio vs. Service Catalog
I am often asked about the differences between service catalog and service portfolio. As I always do, let us start with the official definitions.
Service portfolio
The Service Portfolio is used to manage the entire Lifecycle of all Services, and includes three Categories: Service Pipeline (proposed or in Development); Service Catalog (live or available for Deployment); and Retired Services.
Service catalog
A database or structured document with information about all Live IT Services, including those available for Deployment. The Service Catalog is the only part of the Service Portfolio published to Customers, and is used to support the sale and delivery of IT Services.
As we can see, the service portfolio contains past, present and future services. The service catalog contains the present and the services “available for deployment”. End of discussion. That’s it, that’s all as my dad used to say. But of course it is not the end.
I would argue that currently all IT organizations offer services. They may not be exactly like the ones described in best practice documents or that they may not even be recognized as services. Regardless, it is important to recognize and accept this. So you read the best practice guidance and decide that you want to have best practice services in your IT organization. But where do you start?
Start with an inventory of what your IT department does. Ask IT folks what services they think they are offering. Ask customers and end-user. You now have a draft version of your service catalog. Now at this point your service portfolio only contains the “present” services. Let us assume that you have nothing “major” in the works so there are no services proposed or under development at this time therefore your service pipeline is empty. You have never retired a service so your “retired services” section is empty as well. It is understood that your “present” services are not aligned with best practices but that’s ok.
You could also start with an assessment of the current situation in your IT department. You may conduct a self assessment or hire a consulting organization to this for you so that you have an “unbiased” view of the situation. Just make sure the assessment does not take too long or cost too much.
ITIL V3 introduced to us IT folks the concept of service assets or service as assets. I am not going to get into a discussion on what constitutes an asset other than we are also told by best practice that assets can (and should) be Configuration Items (CIs). This means that the service will be recorded in the Configuration Management System (CMS) and will have various attributes. This supports the definition of the service catalog mentioned earlier.
Let us assume that you decide to create a service “à la best practice” to replace an exiting, very important, but deficient service. But wait, we just saw that a service is a Configuration Item, therefore it falls under the scope of Change Management. This means that you have to submit a request for change (RFC) when you want to propose your new service. This is good. Now you have an entry for the “proposed/under development” section of your service pipeline (future services).
Let us assume that everyone loves your idea and gives you the go-ahead to proceed with the development. The status attribute of the “new” service will change from “proposed” to “under development”. As you have embraced best practices, your service now goes through its service design phase. This may take a few iteration but we already knew that. So now you are ready for deployment. Wait a minute! The service transition phase tells us that the “new” service must be properly transitioned and this includes “testing”. Only when all tests are declared successful can the service be made available for deployment. Assuming all tests are successful, your service catalog has a new entry under the “available for deployment”.
Let me use an analogy here. My son likes to play a particular video game. This is the “existing” service. (Ok I am oversimplifying but indulge me). He learns through much hype and marketing that the next version will be available in stores in a couple of months. Now the service catalog has the existing version and the “to be available soon” version. People can either pre-order the new version of the game or wait in line outside the nearest store to buy it as soon as it hits the store shelves. Of course as soon as my son has acquired the new version, the “old” one is “retired” to some dark corner of his room. However retired does not necessarily means that it magically disappears. Retired is a stage in the Lifecycle of many Configuration Items (such as services). In this case my son may decide to play with the previous version or sell it to a second hand store. But the game manufacturer no longer sells or supports the “old version”. From their perspective it is retired.
So now you deploy your “new” service. It is a great success. Everyone loves it. Promotions and bonuses for all! (OOPPS, sorry this only happens in movies…). Of course along the way you have updated your service portfolio, catalog and various databases. You are now ready to submit a request for another new service and you are also ready to add your “retired” service to the “retired” section of your portfolio.
So now your portfolio has entries in the past, present and future sections. The service catalog has entries in the present and soon to be available sections. Congratulations! I know that I have oversimplified everything. I know first hand how difficult it can be to a) convince people (especially management), b) create the portfolio and the catalog c) create the processes, procedures and tools required d) get people’s buy-in and e) etc, etc, etc.
My personal take on the service portfolio
I have done of bit of research on products offered by some large organizations. I have found for example that car manufacturers not only have many car divisions but may also offer trucks, motorcycles, small engines, small planes and recreational vehicles to name a few. I have found that financial institutions may offer personal banking, business banking, credit cards, investments or even insurance. And the list goes on. This is their portfolio of products. The catalogs are based on their lines of business. Let us assume that I am in the market for a car. I understand that the manufacturer offers more than cars to offer me but at this time I don’t want to see their entire portfolio, just the “car catalog”. If I am in the market for personal banking, it is unlikely that the financial institution will show me the “business banking catalog”. Neither the bank nor the car manufacturer will let me see or even talk about the proposed new products or the ones still under development (pipeline).
Why can’t your IT organization use the same approach based on your lines of business? Remember that it is all about IT and Business integration.
In conclusion, start small. Don’t try to do everything at once. Use analogies to explain the concepts. It will be easier for people to accept them and to apply them to their situation.
Note:
By the way I will be away the next two weeks to our annual ITSM conference in Vegas. I am delivering a V2-V3 Manager Bridge course as a pre-conference event then presenting at our conference. I will keep updating this blog even while I am away. So if you are going to our conference, why don’t you look me up?