ISO 20000 Control processes documentation

Where should we keep our ISO 20k documents? Do we need a sophisticated document system, database or a printed library? Is a shared folders system enough? We asked ourself these and many more questions before we started implementing our service management system.

Living with our ISO/IEC 20000 Service Management System for years, we gathered some experience and knowledge about it that I will be happy to share here. I would like to spend a few posts on the key parts of the system, with document and record management in focus.

I have touched the theme in my previous post Service Management Document System, now let's elaborate it through specific process groups.

Mind you, I am not aiming to describe specific ISO20k requirements, for this you have the standard(http://www.iso.org/iso/catalogue_detail?csnumber=51986). I am discussing the specific required and nice to have documents and their whereabouts.

I will go through each process group and share my experience and opinions.

Let's start with Control processes. It's in the heart of the ISO 20000 schematic and I really feel these processes deal with the vital documents and records for the service management. So it's a good place to start.


Configuration management
Policy: this document will define the main game rules focusing on general non-sequential process rules. After the initial creation, it will not change frequently. Policy can sometimes be a part of the

Procedure document, but I prefer to put it in a separate document since I find it easier to maintain it.

Procedure: a document which describes how Cis are tracked. It will also be rarely changed . Policy and procedure can be stored in shared folders or in a document management system. Configuration Item Type Definitions: we have to have these, and it helps if we have the ITSM tool to keep it in.

CMDB records: if you have CMDB automated in a separate CMDB application or a piece of a ITSM tool, then you are all set, it's a way to go. Otherwise, you have to keep and maintain the knowledge about the customer's infrastructure in one ore (usually) more databases/document repositories. Basic CI info will probably be kept and maintained in your ticketing application. Less structured data can be kept in a separate database and documents. It is very important to keep these data up to date. This can be done by appointing ServiceDesk and/or account managers to be responsible for CI info accuracy. Bad CMDB data are the source of all evil in ITSM. Things to take special care of:

Catalogue of services - services are Cis, and are usually composed of technical services, dependent of many Cis. Think carefully how will you maintain this data, and especially how deep will you go in granular description of Cis.

Access data - passwords and accounts for accessing customer infrastructure are very sensitive and it has to conform to 6.6. Information security management.



Control processes group in ISO/IEC 20000

Change management
Policy: again, a separate document or a part of a procedure document. A good practice would be to keep all important non-sequential data in a policy, like definitions, acronyms, interfaces. There are processes which don't specifically require a policy, but we like to create one for every process anyway. See if it works for you.

Procedure: Only emergency procedure is required, but again it would be nice to have a separate document here defining all types of changes that we perform.

Emergency change definition: it would be very useful if you can get this definition in a contract with the customer. In case of external customer, most of them insist on their own templates created by their legal, so this Emergency change definition agreement has to be done in a separate contract. Most of the auditors will accept a simple confirmation reply from a customer to your e-mail.

Records: change schedules, RFCs, plans, analysis, reports are results of CAB meetings and other CM activities, and they can be kept either in your Service Desk tool or on any other tool you use for document management, in accordance with 4.3.2 Control of documents.

Release and deployment management
Release policy: same as the other policies. You have to keep a record about your agreement with the customer regarding this policy. It would be best if it is in your SLA but it can also be separate mail exchange or a document signed by the customer.

Emergency release definition also has to be agreed with the customer.

Records: plans, control documents, reports/analysis can be kept either in your Service Desk tool or on any other tool you use for document management, in accordance with 4.3.2 Control of documents.

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?

CMDB - What You Need To Know

"Take care of the luxuries, and the necessities will take care of themselves." -- Dorothy Parker, an American writer and poet

Much is said about Configuration Management Database in IT information circles and literature. More or less, everyone agrees that CMDB is some kind of hub of all ITSM processes, but opinions differ on the scale of it's importance. From "nice to have because ITIL says so" to "first thing you have to do, without it nothing makes sense". Well, I am with this second extreme bunch.

ITIL is full of details and descriptions, but without a direct prescription how things should be done. Data model, relations, APIs? I don't blame them, technology is moving fast and things that will be possible tomorrow are imaginable by fewer and fewer people, so this vagueness in ITIL is given with a good measure of direct guidelines and freedom of interpolation. After all, CMDB became a kind of religion, even better, a Loch Ness monster parallel story: everyone is talking about it, and a very few people witnessed it. To some extent, one can agree with IT Skeptic that it can't be done by definition of Configuration Management goal:

"account for all the IT assets and configurations within the organization and its services"

ALL IT assets? What have you been smoking lately? There is a sniff of inconsistency here, since ITIL also talks about setting the level of CI control. So, what is it, ALL or SOME assets? Mouse, keyboard and web camera, or my precious USB mug heater, are they assets? Of course, we can give a better eye to this def, and read it backwards. ITIL is business oriented, and makes an (however large, still feeble) attempt to put a CUSTOMER in focus of poor over-worked sex depraved IT people. Not an easy task.

ITIL focuses on introducing order in IT, as a function of serving BUSINESS. ITIL mentions ALL assets, but in this context ALL means "as much as you irresponsible people can manage, and focus to those that are important for the business services to the ladies in the Accounting dept, or whatever dept. you signed your SLA with, without real understanding what SLA really means."

Every IT organization starting to deal with services quickly learns that it is not about Service Desk, Incident or Problem Management. It is WHAT you have, WHERE is it, WHO is responsible, HOW it works, WHEN is it going to die, and in WHICH way it supports our business. And approximately in that order. To every sensible IT guy it is obvious that CMDB can't be done, but that's something we HAVE to try to do. 30% is infinitely better then nothing, you can live with 70% and prosper for a long time. Take care of the luxuries first, cover the assets most important for your services, other CIs will fall into place with time and effort. A large US pharmaceutical company that implemented a new NW discovery tool found out that they have some 10.000 network assets more then they knew about. Have they survived somehow before that discovery? Of course. Have they found valuable resources and knowledge about their infrastructure that will help them be more agile and produce better decisions in the future? You bet.

Another thing. ITIL is IT oriented, and it covers basic best practices of IT organizations. Implementing ITIL is a first step in introducing organized structure to IT from bottom end, base of the pyramid. Above it, on the road to better understanding of business, stand methodologies which are not exclusively IT oriented, and they serve to connect IT to business even more, like BSC, SOX, COBIT, various project, work and performance management technologies. ITIL's task is to introduce first enablers of customer satisfaction. ITIL asks from IT to first form knowledge of their own business (CMDB) and then agree with Business on the best way to support it (SLM).

Views on CMDB and CI relations

I will discuss SLM and SLA later, and importance of Service Catalogs. For now, let me point out the evolution of structured thought: CMDB enables all 10 ITSM processes. It contains crucial information on CIs. Out of that info we start when we define basic components and IT services. Only then we are able to introduce the IT to Business and really listen to it's requests. That's why the Service Catalog resides in CMDB, or ON the CMDB, because it comes from the opposite direction. CMDB thinks bottom-up, and Service is defined top-to-bottom. So it is a crucial link from CEO to your network switch, from IT to Business. That's why in implementing ITIL, a common sense is to start with Service Desk, Configuration and Incident Management, and Service Level Management in parallel.

A number of possible problems can occur in CMDB life, aside from the obvious and mentioned in ITIL Blue Book. Integration with other ITSM tools is a very important one. I have seen some IT companies implement a stand-alone CMDB. Not sure what is the purpose of that. Also, CMDB deals with the data that naturally or historically reside in other applications, like ERP, HRM, Document Management, Asset Management... There is always a grey area or overlapping as some data wants to live in more then one place.

Main rule is: if there is a legal, financial, technical or strong cultural reason for a type of data to be referent in other systems, then periodical mirroring of data is performed (hourly or daily) to CMDB. Some data will be synchronized inbound to CMDB, (ERP people are particularly sensitive to their data) and some will be synchronized both ways, like contact data (mail, phone etc.) to and from Human Resources Management application. Some data will eventually be synched outbound, to Asset Management application for example.

A lot of it can go wrong in CMDB implementation. But, based on all the above and some more, having a CMDB conforming to ITIL recommendations, common sense and your business needs is a one of the hardest and most rewarded projects that an IT can perform.

Configuration Management Basics

Mission
To identify, record and report on configuration items and their relationships that underpin IT services.

Goals

• To account for all IT assets, configurations and services within organization
• To provide accurate information and documentation on configurations and assets to other SM processes
• To provide a sound basis for Incident, Problem, Change and Release management
• To verify configuration record and correct exceptions

Configuration Management Mind Map

Definitions
Configuration Management: The process of identifying and defining Configuration Items in a system, recording and reporting the status of Configuration Items and Requests for Change, and verifying the completeness and correctness of Configuration Items.
CMDB - Configuration Management Database: database which contains details about the attributes and the history of each CI and details of the important relationships between CIs.
CI - Configuration Item: basic CMDB element. Component of an infrastructure that is under the control of Configuration Management. CIs may vary widely in complexity, size and type, from an entire system (including all hardware, software and documentation) to a single module or a minor hardware component.
DSL - Definitive Software Library: a physical library or storage repository which contains authorized master copies of software versions. May consist of one or more physical software libraries or filestores, and can include physical store to hold master copies of purchased software, disaster safe.
DHS - Definitive Hardware Store: secure storage of definitive hardware spare components and assemblies. Details of these components and their builds and contents should reside in CMDB. DHS items can be used on demand for additional systems or in the recovery from major Incidents.

Objectives

• To provide accurate configuration information
• To define and document processes and procedures
• To identify, label and record CI
• To control and store authorized specifications documentation and software
• To report on status and history of CIs
• To record changes to CI in a timely way
• To audit physical items and reconcile any differences between them and the CMDB
• To educate and train in control processes
• To produce metrics on CI, changes and releases
• To audit and report and exceptions to standards and procedures

Process

• Planning
• Identification
• Control
• Status accounting
• Verification and auditing

Benefits

• Accurate information on CIs and their documentation
• Controlling valuable CIs
• Adherence to legal obligations
• Financial and expenditure planning
• Making software Changes visible
• Contributing to contingency planning
• Supporting and improving Release Management
• Improving security by controlling the versions of CIs in use
• Enabling the organisation to reduce the use of unauthorised software
• Allowing the organisation to perform impact analysis and schedule Changes safely, efficiently and effectively
• Providing Problem Management with data on trends
  

Possible Problems

• Wrong CI detail level
• Adequate initial analysis and design
• Configuration Management implemented in isolation
• Lack of commitment to maintaining accuracy

Critical Success Factors

• Managing Configuration Item information
• Providing capability to perform risk analysis of changes and releases

Key Performance Indicators
Managing CI Information

• Number of CIs logged and tracked
• Number of CIs with attribute failures
• Number of changes to CI attributes
• Number of additional CIs
• Number of deletions of CIs
• Number and frequency of exceptions in configuration audits

Providing Capability To Perform Risk Analysis Of Changes and Releases

• Number of incidents caused by inaccurate configuration data
• Percentage of Services tracked with CIs versus known products and services

Incident Management Mind Map

I have process mind maps, and I am looking for a free tool to display them on the web. Until then, here is a JPG of Incident Management mind map.

Service Management

Have been thinking about service management a lot lately. Since the core bussines of my company is SM, we are educated in most of the known methodologies and implementing most of the best practices from ITIL, MOF, COBIT, ISO...
Blogging about it could be a good way of setting some basic knowledge points for the new people in the business. I will take the liberty of reshaping and adding to previous posts according to comments and sugestions of the People.