Service Management Document System

A few words about the service management document system. Whether you implement ITIL processes or a complete ISO/IEC 20000 service management system, your documents and records have to live somewhere. What is the best practice here?


Let's keep the main thing the main thing. What document system is already at place in your organization? Use it. If your organization has reached the level of maturity to implement the Service Management System, odds are that you already have some kind of a sensible document management software.

Introducing a new feature, no matter how seductive it may seem, will just prolong the learning curve and increase the resistance to the change. You don't want that. Try to stick with what you have. Implement the system with what you've got and let it live for some time. At the end of the first year, you will know what's missing, and you can take it from there.



Service Management Document System

So, the only thing you have is a file share system? No sweat. It can work very well for you. You have implemented a Wiki in your company? Even better. Even with the hype of wiki fading away and reducing it below its measure, it can be utilized ideally for specific purposes. You have a real document management system, open source or from a renowned vendor? Cool, we will put it to work.

Documents
Internal documents - when we talk about basic service management documents like policies, processes and procedures, these are the documents which won't change frequently. The ideal place for them is where you already keep this kind of documents. File share, document management system, collaboration applications, even paper versions might work. Of course, I'm not very serious about this last one :)

What you have to have in mind with these documents is that:

• they must be easily accessed by the authorized personnel,
• they have to be found and identified quickly
• approved by authorized people
• only the last approved version should be accessible to the audience
• versioning might come in handy.

If you are kind of halfhearted here, my recommendation for document management here is the Wiki. Any kind of a decent open source or Wiki as a part of some document management system you have deployed. Documents open quickly in any browser, everything is indexable and searchable, and versioning is easily traceable. A bunch of advantages compensate well for the minor difficulties in text formatting.

External documents - unstructured documents like customer and vendor agreements and contracts, legal documents, laws, norms, company and employee certificates etc. can be in paper or electronic form. For some of them the organization has to conform to legal requirements of keeping and archiving.
For efficient service provider operation most of the paper documents shall be converted to electronic form and accessible to employees according to their user rights. This is where it gets a bit tricky. Not everyone should be able to see every bit of information.
Financial parts of contracts should be accessible on a need to know basis. But other operational parts like contact lists, SLA parameters and operation rules should be availyble to everyone involved. How to deal with that?

Records
In the course of your service manageemnt thrench-line battle, you tend to produce a lot of records. These can be records in your application database or nonstructured records like periodic or on-demand reports. Records, as well as documents, should be legible, readily identifiable and retrievable. Also, they have to conform to requirements for retention and disposal.

Application records- various service management applications will create records, probably in some kind of relational database.  By their nature, they are not too demanding for space, so they should be retained in operational state as long as needed, sometimes even longer.

If your Service desk application has trouble indenxing and operating a large number of records, you will move all your older data into an archive (warehouse) database in order to improve the application speed. This way you can easily access your history data for reporting purposes, and keep a swift application operation. Incidents, problems and changes historycal data can come in very handy when you get a request for a report of all the incidents on Apache server since 2007, and their relation to problem records.

Other, more practical use of long record retention would be very practical: disregarding the implemented Knowledge Management system, Service Desk analysts tend to search for existing incidents and problems in order to find a previous solution to an existing issue. 

Non-structured records are created every day, these are mostly electronic form documents acompanying the operative or reactive actions in service management. E-mail messages, written documents, spreadsheets and screenshots tend to take a bit more space. Nevertheless, they should be kept according to regulatory and statutory requirements, or longer.

The best location for them would be an indexed, full text searchable document management system, or at least a shared folder with an indexing option.

In the end, a piece of advice: anything you can do to avoid the overhead is a good effort. Auditors are reasonable people most of the time. If you have any kind of basic document management system with versioning and approval workflows, you should defend the existing functionality without additional work.

No use of keeping additional records, versioning tables, approval sheets and stuff if minimal requirements can be satisfied with what you got. Even if something is missing, the auditor will respect your willing not to fake the unnecessary records in order to keep your processes more efficient. Yeah, you'll get a nonconformity or two, a few improvement recommendations, but it will help you to move in the right direction. Have faith.

 

AXELOS - new name of the joint venture managing ITIL and PRINCE2 certifications

As we mentioned in a previous post, Capita plc and Government Office created a new joint venture to promote and manage ITIL® and PRINCE2® certifications.

On 1st July 2013 the joint venture has been launched under the new name - AXELOS.

 

CEO of AXELOS is Peter Hepworth who came from Activision Blizzard (Call of Duty, anyone?).

 

AXELOS will be the owner of the intellectual property of the Best Management Practice portfolio. It will manage licensing schemes, accreditation and support of examination institutes, training organisations, and consulting organisations.

 

Have a look at the official press release.

 

A few less known curiosities:

• On average one ITIL exam is taken every 1.5 minutes.
• ITIL exams are available in 21 languages in over 150 countries worldwide.

Let us all hope these latest development will turn out for the best of international IT Service Management community.

UPDATE: Axelos shows first signs of life. Have a look at http://axelos.gtml2.com/axeloslz/lz.aspx?p1=054481S1&CC=&p=1&cID=0&cValue=1, first strategy hints and some nice market research figures there.

Cabinet Office let the 51% of ITIL/PRINCE2 to Capita plc

Her Majesty decided to let the 51% of ITIL/PRINCE2 ownership to Capita plc, a company selected after an extensive procurement process to create a new Joint Venture organization. 

Cabinet Office will get 10 million pounds advance and three additional annual payments of 9,4 million pounds. In return, Capita will own 51% of a new Joint Venture (JV) organization. Government Office keeps 49%.

That's a lot of money. And this transaction opens a lot of questions, for all involved subjects. What will change for ATOs, authors of central and complementary publications, certified companies and individuals? Who will write new versions?

How is the new JV going to triple the revenue in next ten years? Who is going to receive the short end of the stick? Furthermore, why is Cabinet Office selling a piece of a golden goose?

We on ITIL side of the fence recognized the V3 and 2011 pumped up the pyramid of revenue-generation. Owner of ITIL will earn much more in this new frame. Is the government really that bad in managing money generators as ITIL and PRINCE2 after thirty-something years of experience?

Time will probably tell. But I have a huge problem with patience...

Customer Satisfaction Survey Grading

What grades do you use in customer satisfaction surveys? How are grades influenced by the culture of the country? What to do if you perform surveys in different countries with different background?

I have been discussing customer satisfaction here a few times. Related to that, let me share a brief anecdote with you:

We implemented a new Service Desk SW on a customer's site. They are a managed services company providing support all over the world, 24x7. After the resolution of every ticket, contact person on a ticket receives a mail notification with a link to a short web-based survey.

There were just a few questions regarding speed of resolution, communication, competence of support people and overall satisfaction with the ticket resolution.

Grades were 1-5, with the above explanation that 1=poor and 5=excellent.

We received quite a bunch of survey results at the beginning, which was the intention. Here and there, a low score was received, but we were not alarmed, you can't please everyone. Service Manager was in charge to treat all grades below 3 as a customer complaint and to follow up with customers to raise their satisfaction.

Then one day we received two very bad results, averaging below 2. Both from the same market. Alert! We are doing something wrong.

So Service Manager sent apologetic mail with a inquiry what went wrong and how can we improve, blah...
The answer came quickly, from both customers, saying they are sorry, but they thought 1 is better and 5 is poor.

Was something wrong with the survey code? Customers sent us their screenshots, everything is fine, the explanation at the form header clearly stated "1=poor and 5=excellent". Both customers were from Germany. On a request to explain how they misunderstood this clear instruction, they said: "German school grading system is 1 to 5, a one being the best grade (Sehr gut), and five the worst - insufficient (Nicht genügend)". So they didn't bother looking at explanations, they automatically presumed that this survey from another country complies to their long-term grading experience in German scholar system. Can't blame them.

Therefore we looked arround, what are grading standards in school systems around the world?

USA and influenced states use ABCDEF grades. Europe differs very much depending on history, somewhere 1 is bad, under the German skirt it is excellent (Chezh republic and Slovakia also).
Eastern European countries, Asia and Oceania use either Russian 1-5 system or percentage system 0-100%.

Interesting details:

• Venezuela uses rather exotic 0-20 grading system
• Ecuador and Serbia (opposite hemispheres) use similar 5-10 grading systems where 5=fail and 10=excellent.
• A lot of countries use different grading systems for primary, high school and university grades.

So what approach to take in grading customer satisfaction in order to make it intuitive regardless of their local education background?

 

We had only two solutions:

• Go to using 1, 2, 3, 4 grades, where customers won't be able to relate to their finer graded school system. 1-4 is also good because it eliminates the indifferent middle grade, and it forces a customer to decide for better or worse 2 or 3.
• Take the -2, -1, 0, 1, 2 grading approach. Good: it is self-explanatory, negative numbers can't be good. Bad: it leads the customer to a mediocre "0" grade, suggesting that it is OK.

For now, we are using the second proposed grading system, accepting the downside that some customers see nothing bad in selecting a "0", which is a neutral grade.

An additional tweak would be to change grades to -1, 0, 1, 2, which would "push" a customer towards positive grades some more.

What metod do you think is most apropriate for you?


Related articles:

Customer Satisfaction 
How bad do we need it in IT Service Management? Where is it mentioned and where is it dealt with in ITIL V3? How do we manage it in real life?

Customer Satisfaction Survey: What Methods To Use?
How to gather customer satisfaction data? What methods are there? What ITIL says? What methods will work for you?

ITIL 2011: Free Mind Map

Surprisingly lot of you people asked for my refreshed ITIL 2011 edition mind map.
Since you have seen pictures of it in my previous posts, you know I have it ;)   I've put it here for free download.


ITIL 2011 Mind Map

Mind you, this is still my working version, so please let me know if you find any typos or errors.




Of course, if you decide to dig deeper, I recommend buying a full set of books from TSO or Amazon.

Download my ITIL 2011 Mind Map here.

If you don't have a MindJet MindManager, you can have a look in flash here (it will ask you for a viewer installation). Hope you enjoy it!

ISO 9000 - ISO/IEC 27001 - ISO/IEC 20000: How do They Fit Together?

 -
With newly refreshed ISO/IEC 20000 alignment to ISO 9001 and ISO/IEC 27001, I thought it would be nice to have a set of more detailed information about relations between these three, all in one place.

Think, there is a great chance that a Service Provider aiming for 27001 or 20000 already implemented ISO 9001. And once we have two standards out of these three, how much more work is it to get the third one?

For new people here:

• ISO 9001 is a Quality Management standard
• ISO/IEC 27001 is an Information Security norm
• ISO/IEC 20000 is dealing with Service Management. It was developed on ITIL V2 basis and is now in a second edition. Have a look at posts:
• ISO/IEC 20000 Rediscovered
• ISO/IEC 20000 Brief History
• ISO/IEC 20000 Refreshed

If a company already adopted a Quality Management mindset from 9001, then going either for 27001 (Information Security Management) or 20000 (Service Management) is a natural thing. Usually the order of implementation is determined by local market demand and governmental regulation of the core business (Financial organizations, Service providers, military...).

Implementation of ISO/IEC 27001 brings a significant market advantage to a Service Provider, since it is often a requirement in tenders, especially in European countries. It will make you care about security, both yours and of your customer. In the beginning it will feel a bit restraining, but for a good reason. It will significantly reduce risks of losing contracts due to information security reasons.

ISO/IEC 20000 requires a broad specter of implemented processes, but if you are a service providing organization with some experience and knowledge of ITIL (could it be otherwise?), then it shouldn't be a problem. It will only make you define neglected or less cared for aspects and Service Management processes.

Here is a simple diagram I use in presentations to communicate a quick win-win feeling to the audience:

How ISO 9001, 27001 and 20000 overlap

And here is a table of more detailed relations.

ISO 9001 - ISO/IEC 27001 - ISO/IEC 20000 Mapping

This is still a working version of the table, but still pretty usable. Hope you enjoy it. If it displays too small for you when clicked on, you can copy it with rightclick and paste it to your favorite text or picture editor. Or, click here on my Google pages.

ITIL Continual Service Improvement

CSI is not strictly a lifecycle stage, since it spans through all four other stages. It is mainly a set of Quality Management skills put together to make better Strategy, Design, Transition and Operation. Therefore the main tool is Deming's circle (Plan-Do-Check-Act) together with Seven-step Improvement process.

Continual Service Improvement relies also on change management and capability improvement methodologies. Everything is oriented to align processes from Strategy to Operation, and thus comply to changing business requirements.

Purpose

Purpose of ITIL Continual Service Improvement is to ensure IT Services alignment with business needs. This is  done via improvements to IT services through Strategy, Design, Transition and Operation stages. We want to improve effectiveness of service, process and cost.

Objectives

I will quote these in a best effort to provide quality info under 'fair use' terms

• Review, analyze, prioritize and make recommendations on improvement opportunities in each lifecycle stage
• Review and analyze service level achievement
• Identify and implement specific activities to improve IT service quality and improve the efficiency and effectiveness of the enabling processes
• Improve cost effectiveness of delivering IT services without sacrificing customer satisfaction
• Ensure applicable quality management methods are used to support continual improvement activities
• Ensure that processes have clearly defined objectives and measurements that lead to actionable improvements
• Understand what to measure, why it is being measured and what the successful outcome should be

Scope

• Overall ITSM health
• Alignment of Service Portfolio with changing business needs
• Organization maturity and capability
• Continual improvement of all aspects IT services and supporting assets

Value

• Continual service quality improvement
• IT Services alignment to business needs
• Cost effectiveness
• Identification of improvement opportunities in all processes via monitoring and reporting
• Identification of improvement opportunities org. Structures, resources, partners, technology, training and communications

Principles

Here are some Key principles:

CSI approach
It is a somewhat changed improvement approach from V2. here are steps and deliverables:

• What is the vision? - Align with business vision, mission, goals and objectives
• Where are we now? - Baseline assessments
• Where do we want to be? - Measurable targets
• How do we get there? - Service and process improvement
• Did we get there? - Measurement and metrics
• Feedback branch to beginning is How do we keep the momentum going? - Manage the implementation of improvement changes

ITIL Continual Service Improvement Mind Map

Service Measurement

Why do we Measure?

• To validate
• To direct
• To justify
• To intervene

Baseline - current state of CI used as reference value for future comparisons

Vision to measurements:

1. Vision
2. Mission
3. Goals
4. Objectives
5. CSF
6. KPI
7. Metrics
8. Measurements

The seven-step improvement process

This is the only process in CSI, as title says it consists of seven steps, nicely mapped to a Deming's PDCA cycle and Knowledge management DIKW cycle. Picture is worth 1000 words. Enjoy:

 CSI Seven-Step Improvement Process diagram

ITIL Service Transition

Service Transition is a stage which gives most pain to the IT Service Provider. Transition (add new, change existing, retire old service) is a source of many service disruptions. So we want our transition of service to be planned, built, tested, evaluated and deployed in an organized and controlled manner.

  

Purpose

To ensure that new or modified services are in conformance with business requirements, as defined in previous Strategy and Design stages, and that services which are no longer needed are properly retired.

Objectives

• Efficiently and effectively plan and manage service changes
• Manage change risks
• Release planned changes
• Manage expectations on new or changed services
• Manage accurate knowledge and info on changed services and assets

Value

• Better estimation of cost, timing, resource requirement and risks
• Higher volumes of successful change
• Reduce delays from unexpected clashes and dependencies
• Reduced effort spent on managing test and pilot environments
• Improved expectation setting for all stakeholders
• Increased confidence that new or changed services can be delivered to specification without unexpectedly affecting other services or stakeholders
• Ensure that new or changed services will be maintainable and cost- effective
• Improved control of service assets and configurations.

Scope

Creating new and changing existing services, implementing new and changed services, service retirement. Plan-build-test-evaluate-deploy.

Key principles

• Align service transition plans with the business needs
• Implement all changes through transition
• Adopt a common framework and standards
• Maximize re-use of established processes and systems
• Manage relationships with stakeholders
• Manage systems for transfer of knowledge and decision support
• Plan release packages
• Proactively manage resources across transitions

ITIL V2011 Service Transition Mind Map

Service Transition Processes:

  

Transition Planning and Support

Since Transition is so important, ITIL  defines the separate Transition Planning and Support process in order to manage and control changes and releases, from overall planning to specific transition resources management. The accent here is on standardization and best practices, managing of overall resources and helping with major changes and releases but not detailed planning of individual changes.

  

Change Management

Change Management is the key Transition process, and one of the key ITIL processes altogether. Since changes are the main cause of service disruptions, we want as much control of change as possible. In Change Management we ensure that all changes are recorded and evaluated. Authorized changes are prioritized, planned, tested, implemented, documented and reviewed. This way number of failed and unauthorized changes is significantly reduced, as well as number of resulting incidents and problems.

  

Service Asset & Configuration Management

This process was previously named Configuration Management and dealt with Configuration Management Database (CMDB). It looked and sounded too technical which scared off some new business-minded people in ITIL. In fact, Conf. Management was in charge of our knowledge of infrastructure: what do we have, where it is and how it works. To be more in spirit of the business aspect of this process, Asset management flavor was added, so now we follow lifecycle of IT assets from cradle to grave and actual info on this assets is available from all processes, any time.

  

Release and Deployment Management

Previous Release Management was the most difficult to explain in an "Elevator presentation", so deployment was added in order to enable Americans to get it quicker. It would be less confusing if it was called only Deployment management from the beginning. In a nutshell (or elevator :)) RDM deals with consequences of Change Management process: build, test and deployment of releases.

  

Service Validation and Testing

This one is a separate process since it is a discipline used throughout the lifecycle, mainly from Change and Release management. Service Validation and Testing will ensure that the service will deliver expected outcomes, and that it is 'fit for purpose' and 'fit for use' (Utility and Warranty, remember them from Strategy?).

  

Change Evaluation

This was 'Evaluation' in V3, and probably since no one knew what it relates to, they added 'Change' in 2011. So now we know it is a process which deals with evaluation of change. It is implemented to identify all predicted and unpredicted change effects. Smaller changes can be evaluated within Change Management, and for more significant changes (up to company to decide).  It is triggered before every approval point.

  

Knowledge Management

Knowledge Management was such a hype in 90's! Here in ITIL Service Transition, it is added as a nice to have process which is even in the foundations syllabus. General idea is to capture and manage knowledge as Service Provider's intellectual property. Methods are classic KM, I even recommend the reading since it is digest version of all I once knew about Knowledge Management.

ITIL Service Design

Service Design connects the Strategy with Transition and Operation, providing tools to create and redesign services aligned with strategic objectives. It takes care that service management is fully aligned with business needs and uses its capabilities in an efficient and resilient manner.

Purpose
To design IT Services in a cost-effective, secure manner and in accordance to Service Strategy, and to take care of designed service delivery having in mind customer satisfaction.
A set of design governance documents is defined: methods, best practices, procedures and policies.

Objective
Effective IT Service design using continual improvement methods, ensuring service alignment with existing and new business requirements.

Five Aspects of Service Design
deal with designing:
 • service solutions for new or changed services
 • management information systems and tools
 • technology architectures and management architectures
 • processes
 • measurement methods and metrics

Four Ps:
(we remember them as People, Processes, Technology from last version)
 • People
 • Processes
 • Products (services, technologies, tools)
 • Partners (manufacturers, supplier,  vendors)

Service Design Package (SDP)
Definition: "Service Design Documents defining all aspects of an IT Service and its Requirements through each stage of its Lifecycle. A Service Design Package is produced for each new IT Service, major Change, or IT Service Retirement"

ITIL V2011 Service Design Mind Map

Service Design processes:

Service Catalogue Management
Deals with management of information about all live services. Info has to be accurate and current.

Availability Management
One of the oldest ITIL processes, connected to SLM. Ensures that delivered services availability is in accordance with the agreed levels. Of course, in a timely and cost-effective manner.

Capacity Management
Another V2 veteran: Capacity Management wants to ensure that IT capacity (infrastructure and services) meets the agreed requirements in a cost effective (and timely, of course) manner. Capacity management spans through all ITIL lifecycles, since cost-effectiveness and efficiency are among the basic reasons for ITIL existence.

IT Service Continuity Management
IT Service Continuity Management (ITSCM) process is responsible for the alignment of IT services to Business Continuity Management.

Service Level Management
This is a matured key process, SLM ensures that all services are delivered as agreed. It is tightly coupled with other processes emerged from Service Delivery group. Main purpose of SLM is to improve communication and understanding of Business and Service Provider.

Design Coordination
New in ITIL 2011, this process became the central point of communication and control for all processes in Service Design stage.
Design Coordination process is in charge of all design activities, whether they are done through projects or Change Management. It ensures consistent design of services which are aligned with Service Strategy and will be properly prepared for Transition.

Information Security Management
ISM is a governance process which ensures that information security policy  is aligned with business security. ISM maintains and enforces the security policy.

Supplier Management
A fresh process which was probably introduced for better compliance with ISO/IEC 20000, same as Business Relationship Management in Service Strategy. Supplier Management ensures getting value for money from suppliers. All activities are included: negotiation, agreements, supplier performance management, seamless integration of underpinning contracts and delivered services.

ITIL Service Strategy

Service Strategy has the central position in the circular ITIL lifecycle model.
By a broader definition, strategy is a plan devised to achieve a long-term aim. Service strategy is therefore a systematic long-term plan designed by the IT service organization to achieve defined objectives.

A good service strategy should define a way to create and deliver a better value to the customer.
Main objective of service strategy is to recognize competitors and have them in mind when considering services which will in some way be better than the competition's.

Service management is regarded as a strategic asset in the service strategy stage.

Service Strategy deals with

• developing service markets
• service provider types
• development of a service portfolio
• financial aspects of service management
• business relationships and others.

Strategy provides the tools and guidance to an organization to step back from daily operation and view existing services in terms of

• costs
• risks involved
• their performance

Strategy is about the pure cause of services, not about effects and how-to’s.

Service Strategy deals with some key principles:

• Utility and warranty
• Utility is "what is the service"/fit dor purpose.
• Warranty is "how it works"/fit for use.
• Value Creation - what does the service do for the customer and how he/she sees it.
• Assets -anything that can help us to deliver the service. Assets are either resources or capabilities.
• Resource - a kind of physical assets: infrastructure elements, people, financial capital, applications.
• Capabilities - intangible assets: usualy the ability to create value.
• Patterns of Business Activity (PBA) every cutomer has activities which generate demand for services.
• Governance - defines how we implement and follow strategy, policies and processes.

ITIL V2011 Service Strategy Mind Map

Service Strategy Processes:

Service Portfolio Management
A service organization manages investments in services across the lifecycle by exercising Service Portfolio Management.
Service Portfolio Management enables customers to understand what services are available, why they should use them (and why from this provider) and what will be the costs. Also to govern the services in such a way to support Service Strategy.
It enables a service organization to determine weaknesses and strengths of their portfolio, what the priorities and weaknesses of their investment are and how to allocate resources according to these priorities and risks.
Service Portfolio Management deals with

• services which will be delivered (pipeline)
• services which are being delivered (catalogue)
• withdrawn services (retired)

Financial management for IT services

Financial management enables the service organization to measure the value of IT services and underpinning assets. It manages cost-effectiveness of IT Service Management.

Service organizations use Financial management  to achieve Better decision making, Change Speed, Better Service Portfolio Management, Financial and Operational control, Sense of service value.

In ITIL 2011 returned to key activities from earlier versions:

• Accounting
• Budgeting
• Charging

Demand modeling is focused on TCO of service provision to the customer.

Return of Investment (ROI) is the main value of an investment.

Business Relationship Management
This is a newly defined process in Service Strategy. Here is the culprit for the fact that Measurement and Reporting are not in CSI any more. Anyway, this is a welcome change. BRM existed for some time in ISO/IEC20000 and is widely recognized as a crucial process in IT Service Management. Its main purpose is to support most of other processes in all lifecycle stages - by helping Service organization and Business to better understand each other. Which is, as we know, the basic means/goal to all ITSM organized voyages. If Business and IT don't make an effort to speak the same language, to understand each other's pains, then all the other endeavors are meaningless.

Demand Management
Another new  process! Previously, Demand Management was dealt with inside of Capacity Management. On primary ITSM levels, it is the right place for Demand Management. But since we started dealing with Strategy and Design lifecycle stages, we saw Demand as the crucial driver for them. So here it is.

Service Strategy is the most boring ITIL book. It was most thoroughly rewritten in 2011., and it still helps me to fall asleep when all other methods fail :)
On the other hand, it contains some very important concepts and aspects of Service Management which tend to be more and more interesting as you gather experience working in IT industry.

ITIL 2011 Processes

Here is a clear and organized table of ITIL 2011 processes for you. What is where, what is important, what is old and new:

ITIL 2011 Processes Table

There are some changes from 2007 edition.

What is not so obvious from this table, most of the changes happened in Service Strategy. Strategy Generation is not treated as a process any more, rest of the processes are more uniformly described. New processes are Strategy management for IT Services and Business Relationship Management.

Some interesting changes in Service Design also: processes are better described and aligned, I like to see clarified Pipeline to Catalogue transition. New process is Design Coordination.

Less radical changes in Service Transition. Understandable, since these were mature processes. Except for Evaluation, which is now called Change Evaluation process.

Least changes in Service Operation. Of course, new Service Fulfillment and Event Management additionally clarified. Interesting , but not unexpected, Problem Management was polished some more. Looks like Problem Management was problematic from the beginning :)

Continual Service Improvement: of course, more changes. CSI model is now CSI approach. 7-step process has seven steps :)  What bothers  me a little is that Service Measurement and Reporting are not processes any more. Where I work, these are most important processes and the right place for them is in CSI.

Functions

All four functions are still Defined in Service Operation:

• Service Desk
• Technical Management
• IT Operations Management
• Application Management

Generally, I like the way things are developing. This is probably not the last of changes we will see in ITIL. TSO and Cabinet Office people are taking care of their baby.

ITIL 2011 - What Happened?

ITIL Lifecycle Suite 2011 Edition

As you can see in an excellent ITIL History article on this blog, ITIL has come a long way from first publications in late 80's. In July 2011 ITIL V3 was updated to 2011 edition.
Now folks, let's get down to basics. I will slowly go through changes and events and talk a little bit about every ITIL Lifecycle stage and what happened where. I am talking about my following posts here, of course. Those who know me understand the emphasis on SLOWLY here :)

So, we received a package of books which are 57% heavier (2,5kg increase) and have 46% more pages (+600) comparing to "old" 2007 V3 edition. Apparently, this increase was mostly due to thorough Service Strategy book rewrite, and of course a larger font used.

Service Strategy was the most vague and least accepted in larger ITSM community, so it really needed some serious rewriting. Other books were also improved to some point, a few new processes introduced, obvious ambiguities and errors removed (some new created), so the whole package looks more polished and admissible by the critical members of the community.

Complete list of Frequently Asked Questions can be found on APMG's ITIL Official Site on this page http://www.itil-officialsite.com/Publications/ITILPublicationUpdates.aspx  .

Also, a very fine summary of 2011 updates can be found on the same page. Look for ITIL 2011 Summary of Updates .

People at ILX Group were so kind to update their popular ITIL Process Model available free for download here: http://www.ilxgroup.com/downloads/itil-2011-process-model.pdf

Con
Critics among us will keep the mantra that the whole thing is a bit out of date and clinging to it's 80's roots, not referring enough to modern concepts of Clouds, Agile and Virtualization.
Also, they say that the vastness of material is repelling, supporting the complex Qualification scheme http://www.itil-officialsite.com/Qualifications/ITILQualificationScheme.aspx in a self-serving purpose to make more money.

Pro
On the other side, attaching tighter to modern technologies brings the danger of quicker obsolescence. Polishing general concepts made ITIL go this far, so "descriptive not prescriptive" motto lives on.
2000 pages is a lot, but it is fair to give the authors credit of the intention to cover adequately all topics in an integral baseline set of books.
For executives, beginners and innocent passers-by, Compact/Digest editions will probably follow soon, like this fine pocket book: http://itservicemngmt.blogspot.com/2012/02/new-itil-foundation-handbook-released.html

Anyway, most reviewers are happy with the overall 2011 update. Are you?

As I said, I intend to go through all five lifecycles in the following articles. Stay tuned.

ISO/IEC 20000 - A Brief History

From DISC PD 005 over BSI 15000 to ISO/IEC 20000. Specifications, requirements, Code of practice.

History is a myth that men agree to believe.
Napoleon

ISO/IEC 20000 Timeline

I have been looking around for some brief document with ISO/IEC 20000 history, and I could not find anything useful.

Here are a few major points I have collected from various sources in ISO/IEC 20000 history.

1995: British Standard Institution (BSI) published the first version of DISC PD 0005:1995 - Code of Practice for IT Service Management. It described only four basic ITSM processes.

1998: BSI publishes a revised version of DISC PD 0005:1998 and it already described all five process areas and 13 processes as we know it today.

2000: Published BS 15000:2000 - Specification for IT Service Management which was used together with the code of practice DISC PD 0005.
Also in 2000, the third supplementary document entitled DISC PD 0015:2000 IT Service Management Self-Assessment Workbook was published.  It was a questionnaire that enabled anyone to make an assessment of its compliance degree with BS 15000.
Some serious revisions and rewriting followed, resulting in standard documents very similar to today's norm:

2002: BS 15000-1:2002 IT service management - Specification for Service Management;
PD 0015:2002 - Self-Assessment Workbook

2003: BS 15000-2:2003 IT service management - Code of Practice for Service Management
The same year a new PD 0005:2003 Guide to Management of IT Service Management was published with explanations of the purpose of BS 15000, and also the framework guidance on how to use the standard processes and implement them.
BSI 15000 was adopted by many service companies in UK, and countries worldwide accepted it.

2005: BS-15000 was placed on the “fast track” by the ISO. By the end of the year, with some moderate changes, it was published as ISO/IEC 20000 standard:

• ISO/IEC 20000-1:2005 Specification  is very formal, it defines processes and provides assessment/ audit criteria.
• ISO/IEC 20000-2:2005 Code of Practice that gives HOW-TOs and describes best practices for implementation of Part 1.

Standard was unchanged for four years. Adoption was a bit slower due to somewhat lower ISO maturity level of the standard. The norm requirements were very demanding, and supplemental documentation was scarce and sometimes ambiguous. There was a need for some additional documentation:

2009: ISO/IEC TR 20000-3:2009 Guidance on scope definition and applicability  was published. It provided guidance on scope , applicability and of conformance for service providers

2010:

• ISO/IEC TR 20000-4:2010 Process reference model - describes  the service management system processes implied by ISO/IEC 20000-1 at an abstract level.
• ISO/IEC TR 20000-5:2010 Exemplar implementation plan for ISO/IEC 20000 -1 - provided guidance  to implementation of ISO/IEC 20000 by example and advice.

2011. April:  ISO/IEC 20000-1:2011 - new version of specification is out.

2012. February: ISO/IEC 20000-2:2012 - new Guidance on the application of service management systems published.

If someone has an update or a correction to this, I will be very glad to update the post. Thank you.

Related posts:

ISO/IEC 20000 Essentials
A few more words on ISO/IEC 20000

ISO/IEC 20000 Rediscovered
Describing differencies and similarities of ITIL and ISO/IEC 20000

ITIL and ISO/IEC 20000 Compared
ITIL V2 - ITIL V3 - ISO20000 comparisson table

Hope this helps. Have a nice day!

Many Calls One Incident

Every time user calls in, we log it as the new incident. Or we update an existing incident.
What happens when one major business service goes down? Do we log every call from a different user as a new incident?
Are these just related incidents or there is only one incident? What are calls?

I have seen a few interesting discussions on the Net about the technology of Service Desk Incident logging.

Since I have some 18 years of IT Service Management experience in practice and in theory, and this is a matter I have a strong opinion about, I might say a few words about it.

INCIDENT MANAGEMENT PROCESS
Incident Management is the oldest and most chewed up process in all IT Service Management. Everyone does Incident Management. Maybe not Capacity Management or IT Financial Management, but Incident Management is in phase 1 of most ITSM/ITIL implementations. So it is the best defined and best known process. Everyone interested in ITSM knows everything about it. Right?

DEFINITIONS
What was the definition of an incident? Here are some:

• ITIL V2: any event which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or a reduction in, the quality of that service.
   
• ITIL V3: An unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a configuration item that has not yet impacted service is also an incident, for example failure of one disk from a mirror set.
   
• MOF: Failure of a service or component to provide a feature it was designed to deliver.

Very nice. All bases covered. Very defined. For decades.

SCENARIOS
So consider a few scenarios:

• User cannot log in, she forgot her password. Service Desk creates a incident ticket and resolves it in a first call. Splendid.
   
• User has a problem with his PC. Service Desk assigns a technician on that incident . Technician visits the customer, resolves the incident and SD closes it.
   
• Print server goes down. No one in the headquarters can print. Imagine the legal department people. Sales girls and their Tenders & Invoices... Hell must be a nicer place to be. Phones are off the hook, percentage of unanswered calls goes up fast.

Imagine a mail server crash in a large enterprise. That must be a show. This is a very common case, happens every day in IT all over the world.

So then, is every new call from a panicking user a new incident? Or it is just one incident, and many end user calls (inquiries?). Read ITIL books V2 and V3 all you want and you won't find the answer.

V2 books are in favor of rule that every new call is an incident. OK maybe if the same contact person calls a second time, then it can (maybe) be logged in the same Incident record. But, another person, another Incident.

V3 broke Incident management into new Incident Management and Request Fulfillment with an eye on Event Management. So everything is not an incident any more, it can be an user request. Which doesn't help us here much. Every call about the incident is still an incident by our good ITIL books. And that's best practice. Sort of.

ITIL Service Management sure has some place for improvement here. What I feel sorry for is that authors of V3 strived to cover as much new territory they could (Knowledge Management? Strategy Generation?), creating more ambiguity and material which will need improvement, and flaws of the basic processes remain uncovered. Best practice system should cover such basic scenarios as above mentioned.

What happens in example above, if every call is an incident? All incidents are logged and categorized. A lot of them.

If a mail server went down, is it a new incident every time user notices he can't send mail? No, of course not. It's ONE incident, i.e. one interruption of the mail service. In a good Service Desk environment this incident will often be recorded before any user notices it. The amount of users impacted will only influence Priority of the incident, (remember, Impact X Urgency), not the number of incidents.

This is a nice question I have asked every ITIL trainer/consultant I've met, and I've always had fun.

HOW SHOULD IT BE DONE? 

So, how do you do it at home?

In my company, Service Desk has an Incident Management tool which enables us to log an Incident. All later calls from the same contact person (department) are logged as updates of that incident.

All later calls from new persons regarding that incident (mail server down!) are creating new tickets which are connected to that first incident. These related tickets are not considered incidents, we call them simply "tickets".

When the original incident is resolved, an original contact person for that incident is asked to confirm. Incident is then closed, and all associated tickets too. All contact persons from these tickets get a notification about the closure and are asked to reopen the incident if they feel their service is not yet restored.

Some tools on the market even have special entities, "Calls", which are linked to an initial Incident in a similar manner. Some other tools are at least able to interlink incidents so that when the original one is resolved, SD people can at resolve related incidents one by one, "on foot".

This scenario can repeat quite often in enterprise Incident Management, even in mid-sized managed service companies. So it would be nice if someone explained it to good ITIL best practices author.

NOTE

There is one potential catch with "One incident/Many tickets" method: if you treat various departments or business units of your company as different customers, i.e. you have a different SLA with Finance, Legal or Marketing, then you would want incidents and outages to show on their respective SLA reports. If your IM and reporting tools are not perfectly linked to the service Configuration Items in your CMDB or your Service Catalog item, you will probably want to create one incident for every contracted SLA.

This will also be the case if your contact defines a business unit associated with the incident, and the reporting tool regards incidents as service disruptions on associated business units. Here the value of a good Service Catalog/Portfolio comes to the fore.

Sometimes this vagueness is justified by “descriptive, non prescriptive” nature of ITIL. Well in my humble opinion, if something is called best practice, then it should describe the best practice of common events.

It would be very nice if this issue gets to be addressed in the next ITIL release, don't you agree?

Related posts:

Incident Management Elements
Key elements of Incident management.
http://itservicemngmt.blogspot.com/2007/05/i-will-go-through-main-elements-of-itsm.html

Incident Management Mind Map
Download the incident management mind map.
http://itservicemngmt.blogspot.com/2007/05/incident-management-mind-map.html

All About Incident Classification

How to deal with incident categories.

http://itservicemngmt.blogspot.com/2007/05/all-about-incident-classification.html

 

What Everyone Should Know About Incident Priority

Incident prioritization in ITIL.

http://itservicemngmt.blogspot.com/2007/06/incident-priority-what-everyone-should.html

  

ISO 20000 Rediscovered

"It is easier to do a job right than to explain why you didn't. "
- Martin Van Buren -

If we browse thru brief ITIL history, we can see that ITIL (or its basic concepts) was present in IT since the wheel invention. There lies the key to its popularity in IT service business. What can an IT business do to improve it's functioning, but turn to ITIL, or some of its derivatives, like MOF or ISO/IEC 20000? You educate and certify people, define your functions and processes and introduce tools for their automation. And then you are ITIL compliant. Or not?

ITIL is best practice guidance. In the V3 it becomes a bit more prescriptive, but still it stays a framework that basically tells us WHAT we SHOULD DO. In ITIL V3 there are some more ideas on HOW, but that's not its forte. You can define everything by ITIL recommendations, and it can help you a lot in your Service Management work, but you are still not ITIL compliant. Because there is no such thing as ITIL compliancy. You can measure your processes and report on them all you want, but no one guarantees that you made it there.

An international standard for IT Service Management, ISO/IEC 20000, is heavily based on ITIL. It deals with most important ITIL processes, but also adds some new. It defines requirements and code of practice for ITSM, and also provides the tools for assessment and audit of the system.

By ISO 20000, use of ITIL is not mandatory, but since 20000 is by its nature above ITIL in the pyramid, implementation and certification is much easier (read: “only possible”) if it is ITIL supported. ISO 20000 requirements are very short, not much juice there. HOWs and SHOULDs are in ITIL, SHALLs are in ISO 20000. So know your ITIL.

Also, it doesn't hurt if a company is ISO 90000 certified. You know, mindset and experience...

So, a possible path of implementing ITSM is combination of ITIL and ISO 20k: You define the phases of implementation with processes according the pain you feel in your processes. Also you implement ISO 20000 Plan-Do-Check-Act methodology and metrics for every considered process. Educate people, define the scope, processes and roles. Implement automation tools. Check. Act…

A tiny catch: ISO 20000 requires full frontal coverage, all processes have to be implemented. Scope can be limited only to a specific customer or part of organization. But you can keep your ITIL phased implementation, process by process, or in groups of processes. Apply what ITIL tells you, and implement what ISO20000 requires in each phase. In the end, you have a Service Management organization functioning on best practice principles and ready for ISO20000 certification.

ITSM pyramid

Certification
ITIL Qualification Scheme is for the people. Companies are not certified. Example: my company certified a bunch of people in ITIL Foundations 5 years ago. 95% of them left the company since then. In the meantime, we recognized the cost of repetitious certification of new employees. So we developed internal informal ITIL training, to support our business needs and processes. Only higher positioned people get formal ITIL certificates. We created internal support policies, procedures and work instructions, some of them included in our ISO9000 QMS, some external.

Now, ISO/IEC 20000 provides certification on a company level. External auditor (Registered Certification Body) conducts the review, and if the company meets the certification criteria, it can be certified and display the logo.

So if a company wants to be competitive, and introduce order and best practices in their service business, it should definitely think about ISO/IEC 20000 certification.

ISO20k doesn’t introduce much overhead, it just tells you in advance what things shall be done eventually, and keeps you from wandering in the dark. If implemented right, certificate should be a bonus, not the target.

Related posts: ITIL ISO/IEC 20000 Compared : ISO/IEC 20000 Essentials : Implementing ITIL and Staying Alive

Implementing ITIL and Staying Alive

At first sight, ITIL implementation path depends on who you are and what you do. And of course, with what do you do it. So: People, Processes, Technology.

At the beginning, let's move one starting dilemma out of the way: full frontal or phased approach? Phased, period. Strategically, you will have in mind full set of processes. But when you start, you want to dig deep and narrow, not broad and shallow. Hit the major pain points, ensure quick wins, and fly on the wings of starting success. This will enable you to move forward easier.

Critical factor number one? Management support. A lot of it.

From What Angle?

• You can try to imagine a well-organized company whose major pain is to know what it has, where it is and how it works. They have a stabile infrastructure with a low incident rate, and their Service Desk copes with it fine. But they implement a lot of changes and they want to gain more control over the Change and Configuration management. Of course, this is a fairy tale company, since a lot of hanges automatically means a lot of incidents, but just for the sake of the argument, this imaginary company would start it's ITIL journey in Change and Configuration Management.
  
• Or, maybe you are in a bank. Security is probably one of your biggest concerns. Maybe you want to start with Information Security and Access management. Depending on your country regulations, maybe you will even start ISO27000 certification. In some parts of the world it is a very likely case.
  
• Some service organizations with a high-end infrastructure (ASPs?) will be focused on geting their services definition right: Catalog, Portfolio, Demand, Suppliers, SLM...
  
• But, in nine out of every 9.1 cases, you are firefighting. In incidents up to your ears. Your left doesn't remember what your right has just done. Your customers are pissed. And because of the chaos you're in, you turned to ITIL. So you start from Incident Management. What a cliché.

So you decided to implement ITIL. How?

Simple: first you get a few ITIL Foundations certificates. Then you realize that you need a magic wand. What? Something to do the job for you. So, you realize that it is the tool that will take you on a journey. Of course, the TOOL.

You read some Gartner reports, evaluate some tools, and choose the best salesmen of evaluated tools. His implementing team is ITIL certified, his Tool is all Pink and shiny. Sadly, but this is usually the most critical point on your way.

You probably chose a good application, since most of the tools on the market are adequate for first steps in ITIL. At the end of the day, and at the beginning of your project, it all depends how good is your vendor. Because at most cases, he will be your ITIL consultant, too. So look closely. References, team certification, staff fluctuations.

To add some odds to your side, at least at the first phase of your project, hire an independent consultant. If you can afford one. This will probably save you a lot of effort, and eventually your job.

P.S.: If your company has ISO9000 certificate, it will be relatively painless for you to start preparing for ISO/IEC20000. You can implement the tool and ITIL processes, you can certify your people, but ISO 20000 offers you the mechanism for process definitions and audits. More on ISO/IEC20000 later, for now I've put a few mindmaps for you to download:

• ISO/IEC20000 Specification Mind Map
  A set of requirements.
  
  
• ISO/IEC20000 Code of Practice Mind Map
  Guidance and recommendations on quality standards for ITSM.

ITIL V3 Mind Map Download

There is a lot of stuff in the new V3 core books. I have read most of it, and I was overwhelmed with new slang, archetypes, processes, acronyms.

After the second reading, you start noticing that there even exists a connection between the graphics and the text in these books. One just has to read carefully.

Memorizing and putting things in a perspective can be difficult when grasping such a broad scope. Mind mapping can help to some extent.

I have created a simple mind map for the purpose of my own data organization. I thought that sharing it with a community would be a good idea. So I have put it for download on this temporary space.

I took the measure of deleting the content that could be problematic as copyright goes. Still, a lot of public info and my own graphics are left inside. This is a working copy, and will be upgraded regularly. For now it is in Mindjet Mind Manager format, if you have trouble viewing it, let me know, I can maybe export it to xml.

ITIL Service Definition

"A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific cost and risks. "

"Service Management is a set of specialized organizational capabilities for providing value to customers in the form of services. "

I could be wrong, but this is the definition of a Service! And it is finally here, after almost 20 years of ITIL. So at last we know what are we talking about.