Iso 20000 Processes
Alysa Guillama
In this blog post, I will speak about the first group of processes of the ISO/IEC 20000: Service Delivery Group, because if you want to learn ISO 20000 we have to analyze its structure in detail. To understand all processes, you need to have in mind that a process performs activities to produce a result for the company, and this result helps us to manage the service.
1. Capacity Management: The company requires the resources necessary to provide the service: people, equipment, and communications. Thus, an organization with ISO 20000 has to foresee a possible peak workload or an increase in performance of IT services offered to its customers. In the event that it is necessary to increase the capacity (people, equipment, etc.) is important to update the agreements of service and is also necessary to identify the costs.
2. Service Continuity & Availability Management: The disaster scenarios need to be identified and contingency strategies defined, so that in this way the service will be uninterrupted or a possible shutdown does not affect much the service. Therefore, the organization can ensure that the service is still running with acceptable quality levels. It is also very important to define a test plan to verify periodically that the established procedures are working properly.
3. Service Level Management: Agreements need to be defined so that it is clearly established what type of service is provided, and under what conditions. There are three types of agreements: Service Level Agreement (agreement with a client), Operational Level Agreement (according to an internal supplier) and Support Agreement (agreement with an external provider). In this case it is very important to establish regular meetings to check compliance with the agreements.
4. Service Reporting: Periodic reports need to be defined with detailed information about the service. It is important to establish a delivery plan and present the results to customers, which will have detailed information about the status of the service (possible failures, updates, changes in internal operations, maintenance, improvements, breakdowns, etc.). In this manner, the client will have a global vision of the status of the service, and this information will come periodically, so the customer can make decisions supported by actual information.
5. Information Security Management: Security measures need to be defined to protect information against threats. All information systems have risks; 100% security is not possible, and we need to guarantee the information of our customer. In this case it is very important to define a risk management methodology to identify assets, analyze threats / vulnerabilities, calculate risk and develop a treatment plan to reduce it to an acceptable level.
6. Budgeting & Accounting for Services: As expected, the money also is important. You need to control costs and profits of service delivery, because you need to know if your service is profitable or if you need to make a new investment. In addition, you need to know costs of resources, assets and equipment and to analyze actual cost versus planned cost.
Well, this is all that I can tell you for now about the service delivery group. This group of processes is basic for managing IT services because all companies need to manage the delivery of their services. Otherwise, how will a company manage its workload? What if the service goes down and there are no contingency strategies defined? If service conditions are not reflected in an agreement, can our customer claim whatever he wants? If we do not send our customers periodic reports of the service, how can they know the status of the service? If we do not establish security measures, can we protect the information? And, if we offer service without controlling the budget, will we always have money to pay expenses?
Frequently, an ISO 20000 certification is sought after introducing ITIL, because it allows an IT organization to actually prove that it is a customer-oriented, efficient and effective supplier of IT services. A certification can thus be used for marketing purposes, or to gain access to customers and markets which require their service suppliers to be ISO 20000 certified.
ITIL was explicitly written to be aligned with ISO 20000, as the following table exemplifies: for every section in ISO/IEC 20000:2011, Part 1 (Mandatory Requirements) there are one or several related ITIL processes.
ITIL focuses on the life cycle of services, but offers less guidance on establishing and operating the Service Management System (SMS) itself. As a consequence, it is at times not straightforward to map the ITIL guidance and (especially) Section 4 and Section 5 of ISO 20000, but various ITIL processes together can typically be used to fulfill the requirements.
If we want to improve our service, we have to control it; otherwise, we will come dangerously close to chaos. The question here is: How can we control it? With processes! The ISO/IEC 20000 has a set of three processes for controlling our service: Configuration Management, Change Management and Release & Deployment Management.
With these processes we can control the configuration of the elements that make up our service (servers, software, etc.); we can control changes occurring in the service (change server, change of an agreement, etc.); and we can control deliveries that we send to our customer (What do we deliver? When? And under what conditions?).
It is important to identify the elements that are used to manage the service (these elements, in ISO 20000, are called Configuration Items). For each Configuration Item we need to save information about it, such as name, version, responsibility, owner, dependencies (for example, an Operative System is related to a computer.), etc. The ISO 20000 does not define these parameters; they must be defined by us. For these Configuration Items, we will make a snapshot of its setup and this will be stored in a database called CMDB (Configuration Management Database). From there we can retrieve the configuration of a Configuration Item, if necessary. Therefore, it is very important to establish a procedure to periodically check the integrity of the CMDB, because the information that it contains is critical to the business.
Another important concept is the baseline, which can help us to control the configuration of the Configuration Items before passing them to a production environment. If we do not establish a baseline before moving into production, we risk losing the stable initial configuration, which may involve malfunction. Now lets see an example: A server could be a Configuration Item, and the settings of its parameters (OS version, hardware model, HD capacity, memory, etc.), would be stored in the CMDB. Furthermore, this Configuration Item is related to software. Finally, if we want to transfer them to a production environment, we must first establish a baseline with both.
This process is closely related to other processes (for example: Configuration Management, Release and Deploy Management, Capacity Management, Service Level Management), because it can be used to manage any change. For management, we need a workflow, which includes a Request For Change (RFC), which goes through an approval process. The RFC can be a form with fields to complete the information about the request (at a minimum: name of the person who requested the change, date of the request, priority, Configuration Items affected and the description of the request).
After the RFC is reviewed by a responsible party that will assess risks, impact and benefits for the business, the RFC can be approved. In this case, we can make changes, but there must also be defined guidelines to go back to the state before the change, in case the change has not been made correctly. Without this approval process, anybody can make any change, which can be a problem because we have no control in our documentation and in our management system.
All RFC must be registered and saved in our system. For example: We must change the server configuration, because it needs more memory. We need to generate a RFC, which is verified by a responsible party, and if approved, changes are made. (We also will need to change the information about the Configuration Item in the CMDB.) If the change fails at some point, it can be restored to the initial state.
All conditions for release and deployment of products must be established, and we must define a plan where all deliveries and deployments are planned at the time. Therefore, we need to define a plan for deliveries, which will contain dates, frequency and types of delivery. Furthermore, we need to define a plan for how to deploy the product in the customers system (installation of software, plugins, DLLs, etc.), and it is possible that we need to perform changes during the delivery, in which case we have to use the process of Change Management.
Also, we need to define a procedure for emergency deliveries, because it is possible that our customer needs the product quickly. You must have in mind that in any delivery or deployment, errors can occur; then, we must have defined a reverse procedure to recover the previous configuration. To avoid errors in a product environment, we must define a test environment, where we can try the product before performing the delivery. For example, we provide to our customer an updated version of our software, but we need to try it in our test environment beforehand. If all is good, afterward, we can install it in the production environment of the customer; if it fails, we must return to the initial configuration of the system (before installing the latest version of our software).
As you have seen in these three processes, the ISO 20000 provides useful tools to control our services. Can we manage a service without controlling the configuration of its elements? And without control of the changes? Or without control of the deliveries? Without ISO 20000, the answer to all these questions will likely be no, so we have a new reason to work with it!
c80f0f1006