ISO/IEC 20000-1 Service Management Processes - PDF

5.5 CLAUSE 8 Clause 8 of ISO/IEC 20000-1 contains all the areas usually known as service management processes or practices. It is, therefore, obligatory that we start this section with a description of process design in general. This section is based on the principles of Lean, which go far beyond...

5.5 CLAUSE 8 Clause 8 of ISO/IEC 20000-1 contains all the areas usually known as service management processes or practices. It is, therefore, obligatory that we start this section with a description of process design in general. This section is based on the principles of Lean, which go far beyond the strict requirements of the standard but are generally useful as a framework for good process design. Keep in mind that any documentation of processes that suit your organization is sufficient to conform to the requirements of the standard. Processes that are documented only as drawings (for use by illiterate employees) have been used in some organization's SMS, for in- stance. 5.5.1 Process design The definition of a process in ISO/IEC 20000-1 is as follows (see Clause 3.1.18): Process is a set of interrelated or interacting activities that use inputs to deliver an intended result". When you design a process according to Lean practices, you should start by considering what the inputs to the process are and what the outputs of the process are. More specifically, consider the SIPOC model: inputs are provided by a supplier (this is not the same as what is meant in the context of supplier management, but refers to anyone who provides inputs to a process), outputs are consumed by a customer (not necessarily the same as the customer using the services). This results in the following model: Figure 2. SIPOC Model For each of your processes, you should start by creating a SIPOC and detailing the process that effectively transform the inputs into outputs. For instance, for a continual improvement process, the SIPOC as presented in Figure 3 was created. 34 Document Set Targets Prioritize Figure 3. SIPOC for a continual improvement process the output of one process can become the input of another: for instance, in Figure 3, the continual service improvement process uses the output from a quality assurance process as one of its inputs. In turn, one of the outputs of the continual service improvement process serves as an input to the risk management process. In this way, a complete system of interdependent processes can be mapped that show how each process relates to the other. An example of a system flow chart is illustrated in Figure 4. 35 The next level of detail for a process design is a detailed flow chart: the SIPOC show a handful of steps (seven, in case of the CSI process in Figure 3), but the detailed flow chart is able to show more details regarding the workings of the process, owners of steps and decisions made during the process. This may result in something similar to Figure 5. Figure 5. Detailed process flow for a CSI process To complete the process design, a RACI Matrix should be created that shows the roles that are Accountable for, Responsible for, consulted on, and Informed about the process. A RACI for the abovementioned CSI process is shown in Table 2. Table 2. RACI Matrix for a ticket review process All the above-mentioned elements come back in the Process template in the Documentation Toolkit, which can be used for the documentation of all processes in the SMS, including the following from Clause 8 of the standard. 5.5.2 Operational planning and control Mandatory documented information Template Clause 36 8.1 Document Documented 'information to the extent necessary to have confidence that processes have been carried out as planned This requirement means that you should be able to measure the processes to see if they have been performed well. You can think of setting process performance indicators that are measurable and producing monthly reports on these. This also serves as input to top management, giving them an indication that the SMS is running well. Plan the services 5.5.3 Mandatory documented information 5.5.4 Mandatory documented information Template Service requirements are usually documented at the beginning of developing a service. These requirements can be in any form - a simple document is sufficient, as long as it is available to the staff needing to refer to these requirements. This also needs to be done for existing services and any changes to services. 37 Control of parties involved in the service lifecycle Mandatory documented information A service catalogue can provide a fairly simple list of the services, including their outcomes and possible dependencies on others. The template also contains fields for a unique identifier, a Service Owner and the status of the service (namely Active, Planned or Decommissioned). Note that the status may not always be relevant for customers, so you can omit this if you would like to keep the information internal. 5.5.5 Configuration management Mandatory documented information Template Document Services and service components that are provided or operated by other parties Processes, or parts of processes, in the organization's SMS that are operated by other parties Definition of relevant controls for other parties involved in the service lifecycle Clause Document Definition of types of Cls Configuration Information Configuration items (CIS) are to be listed including a unique identifier, the type (e.g. software, hardware, tool, etc.), a description, a possible relation- ship with other Cls (e.g. when a CI is part of a larger CI, for instance an IP address on a server) and the status (active, decommissioned, planned). 38 The spreadsheet in the toolkit can be utilized, but often, a Configuration Management Database (CMDB) is used, which forms a central repository for CI and configuration information. Where other parties, such as internal or external suppliers or customers acting as suppliers, are used in order to provide services, service components or (parts of) processes, this should be registered in the Other Parties spreadsheet. This is a simple list containing the name of the service/process, identifying what component is provided by a third party, the name of the third party and an identification of a control (e.g. contract, internal agreement, performance indicator) for the performance of the third party. Other configuration information relating to all Cls needs to be made available to other processes, such as change management. The format of this information can vary greatly depending on the type of CI, so no further template can be provided for this. 5.5.6 Business relationship management Mandatory documented information For each service, a set of service level agreements (SIAs) should be developed. These should contain aspects such as service level targets, provider workload limits and any other exceptions. The template adds other possible information, such as penalties in cases where service levels are not met. Performance against the service level targets and workload changes should be reported on, which can be completed with the default reporting tem- plate. Supplier management 39 A list of customers, users and other interested parties in the services needs to be created and maintained. This is a simple list, on which business relationship management activities can be recorded. Complaints received about the services from customers or other stake- holders should be listed and acted on. The template provided has the following fields: Clause 2. Reference number. 3. Name of the service involved. 4. Description of the service complaint. 5. Source of the complaint — e.g. the name of the user or customer. 6. Name of the service owner. 7. Follow-up actions to handle the complaint. 8. Closure date. 9. Status (open/closed). suppliers or customers acting Suppliers or Customer acting Supplier management information consists of legal documents, which may have a very specific form in your organization. The document templates provided for contracts and agreements with suppliers are based on the 40 minimum requirements in ISO/IEC 20000-1, but may be superseded by 5.5.7 Service level management Mandatory documented information what is already being used in your organization. Note that the contract with external suppliers requires more formal clauses than the agreement with internal suppliers or customers acting as suppliers. Apart from these contracts and agreements, a list of possible disputes with suppliers needs to be maintained and acted on. The template contains the following fields: Demand and consumption 8 Report Template.pptx of services The demand for services and their usage should be determined and fore casted. This can be done depending on your services, and is based on actual monitoring of the services and the customer requests for them. 5.5.12 Capacity management Mandatory documented information 1. Reference number. 2. Name of the service involved. 3. Supplier name. 4. Description of the dispute between the organization and the supplier. 5. Name of the service owner. 6. Any actions taken to resolve the dispute. 7. Closure date. 8. Status (open/closed). Document Capacity requirements The requirements for service capacity can be documented in a table, which includes the following fields: 5.5.10 Budgeting and accounting for services Mandatory documented information Template Service name. 41 Capacity type - human, technical, information or financial. Current capacity. Required capacity. Date on which required capacity is to be implemented. Possible impact of the capacity change on service level targets. Clause 8.4. I Document Costs against budget The only mandatory documented information in this section is a report on the costs incurred to provide the service and run the SMS versus the budget allocated. This report can come from your organization's default financial management system, outlining the financial forecasts that can be reviewed as well as any costs that can be managed, such as when the budget is at risk of being exceeded before the end of the budgeting period. 5.5.11 Demand management Mandatory documented information Capacity in ISO/IEC 20000-1 includes human, technical, information and financial resources. These are very different from each other and therefore each needs to be handled in its own way. 5.5.13 Change management 42 Mandatory documented information Clause Based on the list of change requests that are compiled, reports can be put together that analyze trends in changes, e.g. increases in specific change types. If required, any opportunities for improvement may be derived from such a report. 5.5.14 Service design and transition Mandatory documented information Change management is an important area in service management, however the amount of information required to be documented is quite limited. The Change Management Policy documents all services, components and other items that are governed by change management. It also defines the different types of change (e.g. Normal, Standard and Emergency) and how these should be managed in the organization. Finally, the policy highlights the criteria that determine what types of change may have a major impact on customers or the services. It is these major changes that will have to be run via the service design and transition process, which uses a more project-oriented approach than that needed for regular changes. All change requests need to be documented. The template provided has the following fields: 1. Date on which request has been received. 2. Reference number. 3. Type of request - e.g. minor, major, removal, new service, etc. 4. Description of the change. 5. Date of last update. 6. Priority of the request. 7. Owner of the request, e.g. a change administrator. 43  8. An impact assessment of the change — this is to list the possible impact the change may have on services, customers, the business and finances. 9. Marker if this change needs to use the service design and transition process. 10. Due date for implementation. 11. Completion date. 12. Status (open/closed). The service design and transition process are used as a project approach to manage changes that may have a major impact on the services or customers, as determined by the criteria set out in the Change Management Policy. Various other types of change however, also need to be run via this process, including new services, removal of services and transfers of services to a third party. This process requires the production of a service design, which documents the service requirements, the approach to implementing it and any potential impacts on SLAs, contracts and the service catalogue. 5.5.15 Release and deployment management Mandatory documented information Results and conclusions drawn from the analysis of the success or failure of releases Acceptance criteria Types of release Incidents are likely to be managed using some form of (cloud-based) platform. For small organizations, however, a template has been provided with the minimum information needed to manage an incident. The fields are straightforward, as follows: 1. Date on which the incident was opened. 2. Type of incident — this can be by environment, by service, by CI type or other categories. Make sure information security incidents are indicated as such. 44  3. Incident description. 4. Reference number. 5. Date of last update. 6. Owner of the incident. 7. Impact of the incident on the services and/or the business on a scale of 1-5. 8. Urgency to resolve the incident on a scale of 1-5. 9. Priority of the incident — the multiplication of Impact and Urgency, 10. on a scale of 1-25. 11. Actions taken to deal with the incident. 12. Major incident indicator. 13. Due date for resolution of the incident. 14. Actual completion date. 15. Possible problem record opened in relation to this incident. 16. Status. If a major incident occurs, a Major Incident Procedure should be in place that states how it should be handled. This procedure can indicate who Reporting on the success or failure of releases should be regularly carried, for instance, every month. Any relevant statistics and root cause analysis can be documented in the default Report Template. Acceptance criteria for releases are to be documented before the release is deployed into the live environment. It should then be verified against these acceptance criteria to see if they will be met so that the release can be approved and scheduled for deployment. If the acceptance criteria are not met, action needs to be taken to modify the release so that it can be approved, or the acceptance criteria may be modified if the customer or users agree with it. After deployment, tests should be performed to verify that the release does indeed meet the acceptance criteria when present in the live environment. The types of release are defined in a simple list, where for each service the type of release is identified, e.g. normal, emergency, and others. Coupled with this, the way of managing the release types is determined, be it along the lines of standard change management and release or deployment processes for normal releases. 45 5.5.16 Incident management Mandatory documented information needs to be involved, who takes the lead in managing the incident, how frequently certain levels of management need to be informed about progress, etc. 5.5.17 Service request management Mandatory documented information 5.5.18 Problem management Mandatory documented information Template 8.6.2 Service Requests.xlsx 8.6.2 Service Request Work Instructions Clause Document As with incidents, problems are likely to be managed using some form of (cloud-based) platform. For small organizations, a template has been provided with the minimum information needed to manage an incident, as follows: 1. Date on which the problem was opened. 46  2. Type of problem - this can be by environment, by service, by CI type or other categories. 3. Problem description. 4. Reference number. 5. Date of last update. 6. Priority of the problem — this can be a High-Medium-Low scale or a 7. numeric scale. 8. Owner of the problem. 9. Impact of the problem on the services and/or the business. 10. Actions taken to deal with the problem. 11. Possible related incident records. 12. Possible related known errors. 13. Due date for resolution of the problem. 14. Actual completion date. 15. Status. Known errors are issues with the services that have been raised, but for which no root cause has been determined. A workaround should have Service requests are to be recorded, prioritized, fulfilled and closed. The spreadsheet provided has a number of fields that can be used to record service requests and track their progress, as follows: 1. Date on which the request was opened. 2. Request description. 3. Reference number. 4. Date of last update. 5. Priority of the request — this can be a High-Medium-Low scale or a numeric scale. 6. Owner of the request. 7. Actions taken to deal with the incident. 8. Due date for resolution of the incident. 9. Actual completion date. 10. Status (open/closed). 47 Each service request should have a documented procedure describing how to fulfil this. A framework for these procedures can be found in the Service Request Fulfilment Procedure Template. The exact procedure is dependent on the type of each request. Information security risks should be documented in the risk register and treated accordingly. Controls implemented to mitigate information security risks should be decided on and noted in the risk register. Information security incidents can be documented in the same register and treated according to the incident management process. This register can be used to report on information security controls as required. The information security policy is a generic document, with the template provided using generic wording, which can be adapted as needed depending on what your organization needs. 48 5.6 CLAUSE 9 Mandatory documented information 49