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.