ISO/IEC 20000 SMS general requirements documents

Which documents are required in SMS general requirements of ISO/IEC 20000? This chapter is about management involvment and adding quality control flavour to service management

Management responsibility

It is absolutely impossible to establish an elaborate service management system (SMS) without the active and unconditional support from the top management. The plan and the policy are just dead letters on paper (or screen) if they are not supported with the visible and constant vision-based commitment from the CEO and CIO. Therefore you have to ensure that the service management policy and plan are at least reviewed, approved and backed up by the top management.

Other parties

Most of service providers need to include other parties in order to complete some of the service management processes. It is very important that the provider can demonstrate the accountability and authority to manage these processes with an end-to-end visibility.



SMS General requirements documents

Documentation management

Two simple procedures have to be established here:

• Control of documents
• Control of records

It is a fact that service providers implementing ISO20k usually have a quality management system (QMS) based on ISO9001, and this makes it easier. If the QMS and the SMS are of the similar scope, then just delegate control of these procedures to the QMS. If it is not the case, just write and implement these two simple procedures. Not a rocket science.

Resource management
Parts of resource management requirements can also be delegated to other quality systems. It is very difficult to run a service management system without some essential Human resources practices, so if you already have some, integrate them into your SMS.

Establish and improve the SMS
This part of the norm is aligned with Deming's wheel: Plan-Do-Check-Act. Therefore the documents covering this part are:

• Service management plan
• Continual improvement policy and procedure
• Internal audit procedure and plans
• Audit records
• Nonconformities
• Corrective/preventive actions
• Management review
• Improvement proposals

 

ISO/IEC 20000 Design and transition of new or changed services documents

Change is hard. Service management people love the Status quo. Introducing new services in your system takes a lot of time, resources, knowledge. Even the slightest changes on an existing service can have adverse impact on the business process.

Large changes are often done by the technology specialists from architecture or infrastructure departments. They usually don't care much about your service management methodologies and best practices, since they operate by their project management methodologies and frameworks. Some of the common infrastructure project management methodologies are "Nexting" (clicking the Next button until the server is installed), Run'n'gun and Quick'n'dirty. And voila - new service is ready for support.

This mentality can create barriers between departments and impact the business in a very bad way.
In order to overcome this, all stakeholders have to agree on set of rules for introducing new/changed service.

So this is what chapter 5 is all about. Policy, procedural documents and records that cover activities during the service design and transition.



Design and transition documents

Policy will describe the general rules of the game. I personally like to add a New/Changed service procedure which will describe the workflow and responsibilities. This ensures that everyone knows what to expect, minimizing the blame management playground.

ISO/IEC 20000 Service delivery processes documents

Service delivery process group means business. Back in the old days, it was half of ITIL V2 Service Management. This is a large and complex process group oriented towards the customer. Service delivery processes create a lot of documents and records. Where will you keep them?

For additional info, please have a look at our previous posts:

• Service management document system
• Control process group documents
• Resolution process group documents
• Relationship process group documents

For all of these processes and their documents my general remarks are the same as before. Try to have a separate procedure document for each process, even if it is not required. Also, each process should have a policy, at least as a part of the procedure. These should give a quick general knowledge about the process to new employees and provide some structure to the SMS (Service Management System).

Service delivery process group documents

6.1 Service level management
SLM is a key process in Service delivery, most of the other processes depend on it. There is a lot of communication with the customer during the process, and records should be retrievable either from the file system, specialized applications or document management system. All the changes on key documents should be done through the Change management process.

6.2 Service reporting
Reports are an important way of communication with the customer. Service provider has to keep records of all agreements about reporting with the customer. Optimal place to put report definitions would be the SLA, or a separate contract. For newly developed reports it would be enough to archive a customer's reply to your mail with the new report proposal.
All the reports have to be defined according to the requirements, so they can be delivered even if the main assignees are unavailable. Thing vacations, flu seasons… Keep the report definitions in a neat report catalog, and insist on standardized reports as much as possible. If the customer requires something specific, evaluate the requirement, and if it is found valuable, include it in your standard report.

6.3 Service continuity and availability management
This process requires a lot of activity and resulting records. The auditor will probably like to see most of them. C&A management is a difficult and tedious process since it doesn't provide immediate business results, but it provides proof that you are serious about your business.

6.4 Budgeting and accounting
Here is one process that most of the IT people tend to neglect. If it's true your case too, turn to your finance department and go through the requirements with them. They will most probably be able to help you pull it off.

6.5 Capacity management
Capacity management has some very simple requirements and it is rather straightforward. If you are a managed services provider, or if you provide IT services to external customers, try to document and archive your communication with the customer about the capacity, since you have to take into account their resources too. The auditor might want you to prove that you take care of things over the fence.

6.6 Information security
If you are implementing ISO/IEC 20000, there is a chance you alredy certified for ISO/IEC 27001. Good for you, since you can redirect most or all of this process requirement to your ISMS (Information security management system). If not, follow the requirements and take care of the produced documents and records similar to the other recommendations from this series of posts.

So, a bunch of complex processes. Don't be intimidated by them. Plan your implementation, one process at a time. In the beginning, it looks like a Mission impossible. After some time, you'll get used to it :)

ISO/IEC 20000 Relationship processes documentation

Relationship processes add a human flavor to IT service management. There is a bit more freedom in defining documentation for Business relationship and Supplier management then in ITIL-descended Service Support and Delivery processes.

In the next few posts I will focus on process specifics. For a more general info  about the SMS document system you can have a look at my previous posts:

• Service Management Document System
• ISO 20000 Control processes documentation and
• ISO 20000 Resolution processes documentation.

 



Relationship processes documentation in ISO/IEC 20000

Business relationship management
Business relationship management refocuses IT to the customer and his needs. Documents and records can be created in a variety of ways and saved according to your organization document management preference.

A policy would be nice to have.

 

Records serve as the proof that you are performing this process as required. We keep both the documents and records in our document management system, alternatively they can be placed on a shared folder system.


Supplier management
Supplier management forces the provider to consider the supplier's ability to stay within agreed SLA parameters.

Same as the above, documents and records can be in the document management system or in shared folders.

ISO 20000 Resolution processes documentation

Incident and Problem management, being the most matured processes in service management should be easy to define in ISO20k. But where do we put documents and records? What do we have to pay attention to?

And here comes the infamous resolution process group. How to deal with these documents and records?

Incident and service request management
Procedure: As we know, in Incident management there are three separate procedures. If you are a small service support organization, all three of them can be in one document, as separate chapters.

Policy is not required, but, as I said, we like to keep the standard form for all processes. Policy, again, can be a separate document or a part of above mentioned procedure document, preferably in the beginning. Your documents will sit in a Resolution process group folder on your file share, document management system or a service management wiki.

Records: You probably have some kind of a ticketing app, or a full Service Desk application. Your Incident and Service request records will reside there.
Same as before, you have to agree with the customers about some details, AND don't forget to keep these agreements in electronic or paper form. Your auditor will probably want to see them.



Resolution process group in ISO/IEC 20000

Problem management
Procedure: As we know, the Problem management process can be fairly simple until you start to write it down. Please, try to have fun with this one as we did :)
Policy: same as above.

Records: Problem records, known errors, fixes and even reviews can be kept in your Service Desk application, or at least they can be linked to a document repository where they are saved in MS Word, PDF or other form.
Reports about process effectiveness will be kept in your document repository or maybe somewhere where you maintain your meeting minutes documents.

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: What Methods To Use?

How to gather customer satisfaction data? What methods are there? What ITIL says? What methods will work for you?

USA Today has come out with a new survey - apparently, three out of every four people make up 75% of the population.
David Letterman
 
In my last post I spoke about Customer Satisfaction. OK, but how to gather data? How to interview customers? How to get the best results in surveys and help educate the customer about the proces?
Here I give you a list of basic ITIL methods for gathering customer satisfaction data and my coments of its worth in my company. Mind you, we are in Managed Service business, so my grades are biased.

If you are a small IT in  government agency or an IT in Airline company, you may look for different values. Still, this will give you an idea.

Customer Satisfaction

After-Call Survey

Callers are asked to remain on the phone after the call and then asked to rate the service they were provided.

This method requires that you have some kind of telephony automation like Interactive Voice Response (IVR). The thing with this method is, however you set the system it will often be despised by the customer. Most of the people don’t like to hear recorded messages and even more people hate moving down the menu tree with phone keyboard. Outcome? Only extremes: customer which are very satisfied and wish to reward an agent by giving him good grades or, more often, a very pissed off customer who will go out of his way to express his low level of satisfaction.

Call Center organizations are doomed to use this technology since phonecalls are the only way of communicating with the customer. In ITSM there are usually more ways to talk to customer.

My worth: 1/5

Mail Surveys
We never considered sending mail interviews to customers as an option. Not in this century at least. What kind od IT-related person would fill the received paper form and send it back to us? Do we need a feedback from this kind of person? No, thanks.

With e-mail it's maybe slightly better. We used to have a ServiceDesk application which would send an automated notification on incident resolve event, asking the customer contact to reply in an email grading their satisfaction with speed and quality of resolution by grades 1 to 5. So lame. Response percentage of 0,05% was enough to pacify our ISO9001 auditor but it was next to worthless to us otherwise. One good thing was that receiving a small number of answers in an unstructured text email made the result processing much easier :-)

My worth: 1.5/5

Group Interviews

In this method, customers should be gathered in small groups and interviewed together. This can maybe be somewhat useful in a group of people working together, even then their answers will be biased and dependent. Possible value I see in this one is that they will help to develop communication between customers of different knowledge levels and enhance collective process knowledge.

In my organization we try to keep different SLA customers as far from each other as possible. We do not conduct group interviews but we do organize ITSM workshops here and there for our customers, feedback is usually very good.

My worth: 2/5

Phone Surveys
Some time after the interaction with Service Desk, an independent agent calls the customer.

You are in the middle of your monthly report, juggling a database and three spreadsheets, and some guy calls you to grade your experience with Service Desk from ten days ago? You will brush him off. OK, maybe not the first time, but the next, for sure.

So, if you want to get the results with this method, you need trained people with strong communication skills and good opening lines. Also, a good idea is not to have surveys for all calls, to let the customer rest from you periodically. If they anticipate your call, they start thinking up good excuses to brush you off. Surprise them periodically.

My worth: 2/5

Personal interviews

Surveying person is usually Incident Manager or Service Desk manager, while the Customer representative is a person responsible for SLA on their side. These can be contact persons on Major incidents after the post mortem reporting, but that’s another story and this should be defined in Major incident procedure.

These interviews are usually periodic and should be conducted at least annually (usually they are, during a contract renewal), but more preferably on quarterly basis. During these, the two parties communicate customer needs and help focusing Service Support towards things important to customer. So the questions in a survey should be aligned with Service Desk and Incident Management KPIs.

These are of great value to us.

My worth: 4/5

Online Surveys

We worked with several Service Desk automation tools, different vendors. In the end, we developed a Web application which enables us to send different surveys to our customers. They can be Ticket related, periodical or Ad Hoc surveys with predefine templates of multiple choice and freeform answers. We like it so much that we host it to other departments of our company. And we do not sell it, it’s that good :-)

Customers fill it in their own convenience (ok, we sometimes call and beg them to fill surveys), and after they submit the form they are automatically in the report.

Web-based surveys are a life-saver to us.
My worth: 5/5


Other Methods
Blogs, tweets, wikis, forum discussions and chats are all nice to have and, if maintained well, they will influence customer experience positively.

However, it is next to impossible to mine a structured measurement of customer satisfaction out of them, and they shouldn’t be used for that purpose.


Additional About Surveys

Scoring
It will be best to define simple questions with multiple choice number ratings. How many different grades? For fine gradation in longer interviews we use grades 1-10. For faster, ticket-focused surveys we opted for a coarser gradation. We used 1-5 for a long time, but a lot of the grades were distributed to 1, 5 and 3. Eliminating the middle value and shifting to 1-4 made our customers think more. We still use (1-4) system for most surveys and we are satisfied with it.

In addition, it is often nice to put an optional comment field under every question. Doesn’t cost much, and sometimes customers leave very useful info there.

How many questions?
You certainly don’t want to scare of the customer with a bunch of questions. OK, annual interviews can be longer, and internal ITIL/ISO20000 audits and assessments can gave a gazillion questions, but survey on incident performance can have only one (how satisfied are you?), ideally three, or maximum five multiple choice questions. You fish for quantity here.

Anonymous or named?
Some customers will answer an anonymous survey rather then named. Well, their problem. This is one case where customer is not always right. You want to know who is satisfied, who is not, so you can decide on your further actions.


Related posts:

Customer Satisfaction in ITIL Service Management: Do You Get It?
Elementary facts about ITSM 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?

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.