Why ITIL?

Mission, vision, goals and objectives. Most of the organizations have some or all of these. From a business point of view, that's fine and as it should be. But, what does it have to do with IT and its services? Service is a key issue here. Service, in general, should bring value, be customer oriented and rely on business case. It also brings business sense into IT. For IT, this could come as a surprise, especially for technology-oriented IT organizations. But, if you are running a customer-oriented IT organization it's common sense. I have not found any organization that is satisfied with technology-oriented IT inside the organization. No one understands what they are saying; no one knows what they are doing or how they are spending the budget, is a usual description in such a case. And, its not only typical for small organizations. I found it in large ones, as well. Customer- or service-oriented IT organizations are more interesting ones. They are struggling with costs, ROI (return on Investment), TCO (Total Cost of Ownership), controlling of changes, efficiency of Incident/Problem/Change Management processes, Service Desk They certainly need technology, but they see it through (business) service glasses. Therefore, they need a tool, i.e. methodology, which is not technology driven, but service driven. ITIL is a perfect match. ITIL does not have roots in theory, e.g. someones PhD. dissertation, but in practice. It encompasses experience from IT staff from all over the world; i.e. ITIL is the best practice for IT Service Management originated in IT organizations that deal with the same issues we found in daily activities, and therefore, everyone in IT Service Management can benefit from the fact that the wheel does not have to be reinvented. ITIL combines people, processes, products (technology) and partners (suppliers) and, if implemented, it changes organizations structure and processes, service management, productivity and customer satisfaction. There are many areas where an organization can benefit from implementing ITIL. I will mention the three most important here:

1. Business orientation of IT
The RACI (Responsible, Accountable, Consulted, Informed) model brings clarity to organizations functions and roles, and it constitutes the foundation for communication between IT and business. Have

you ever been a part of an organization where decision making, as well as execution, takes too long due to vaguely defined roles and respective responsibilities? Too often, isnt it? Professional and proven processes integrate customer value and outcomes in every process, role and function, while at the same time increasing customer satisfaction. The organization changes from being a reactive to a proactive one, IT is integrated with business and it can respond more quickly to changing business (or market) requirements.

2. Organization
Financial Management is integrated throughout the service lifecycle. That means that costs are planned and controlled, and cost justification can be easily made. The business can rely on the financial parameters provided and agreed upon with IT, and it can integrate them in business services provided within the market. The staff inside an ITIL-based organization gains competence and increases capability and productivity, which lead to higher staff satisfaction and retention. Operational processes, e.g. incident and problem management, are efficient, controlled and measured, which increases productivity and the satisfaction of both staff and customers. Efficient IT organizations have defined roles and responsibilities for operational processes, they use tools with implemented SLA parameters, and they have incident/problem catalogues in place. In such a way, processes and procedures are clear, resolution of incidents and problems is measured and compared to SLA requirements, and staff utilization is documented.

3. Quality of service
If an organization implements a framework that is proven to work, it is easier to agree on the service level and quality of the provided service to the customer. Constant measurements and improvements guarantee that quality assurance of the service does not end with the customer acceptance test, but it continues throughout the service lifecycle. Lessons learned and experienced on existing services will be integrated in every new service developed or improvement made on existing ones. The focus on customer needs and perception shifts away from a technological debate toward value received, customer satisfaction and customer relation. I found that many customers attach more importance to their perception of a provided

service than to the purely technical description of what a particular service does. And that directly influences future orders and relationships with that customer. There are many more areas where ITIL implementation means one step forward toward satisfied customers and the creation of a competitive advantage. The business world, as well as the IT world, is changing very quickly. IT needs to be a companys engine, business oriented, adaptive and efficient. For a long time ITIL mastered operational tasks, but Service Strategy, Service Design and Continual Service Improvement are powerful tools in IT Managements hands, when implemented and used correctly.

Taking care of relationships with ISO 20000

On occasion, you probably have thought about the complexity of personal relationships (with friends, with your family, with your spouse), but have you thought about the complexity that exists in business relationships? The elements involved in both are the same people, and although the objectives of each one are different, the means to achieve them must be the same: understanding, dialogue and good atmosphere! Fortunately, ISO 20000 has processes to manage these relationships; specifically, there are two: Business Relationship Management and Supplier Management. Both, as discussed below, offer the possibility to manage something as complex as the relationship with our customers and with our suppliers, which may involve, if not properly managed, loss of customers, prestige and money. Lets look at these processes:

Business Relationship Management

As you know, the customer relationship is always important, and obviously should always be good. To manage this relationship, we should establish periodic reviews to consider issues such as the status of agreements (for example SLAs), and the customer can then convey their concerns about the service. It is very important to have a claims process, and our customer must understand it. If our customer has a complaint, and it cannot be transmitted to us, without this information we can do nothing to process and resolve it, so our customer is likely to be angry. Therefore, we must offer several forms of contact: phone, email, mail (and our customer has to know this information). For example: What do we do when Internet

fails? We call our provider to ask what happened. After paying for the service for months, we need an explanation when it fails. What would happen if we had no way to contact the provider? Most likely, we will get angry and search for another supplier. Therefore, in this example we see how important it is to have a good relationship with our customers. On the other hand, in order to meet overall customer satisfaction, we should also establish satisfaction surveys to be conducted periodically. Such surveys are a useful tool to determine the degree of satisfaction of our customers, and will provide information about what we need to do in order to improve our service. The ISO 20000 does not provide a survey model, but it is very easy to develop. As an example, or as a base, you can use those calls you have received from your mobile telephone operator to know your level of satisfaction with the service.

Supplier Management
Here we need to review the agreements and relationships with suppliers. In this case, we will also establish regular meetings with the aim of checking the contractual situation for each supplier. The supplier must always offer everything that is contractually committed, and it should be reviewed. If we detect any non-compliance with the agreement, we must ask for explanation, and the supplier in question must provide details of what happened. Otherwise, we must study the situation and make a decision, which could be to change to another supplier (or penalize the current one). It is also important to establish a mechanism for approval of suppliers, to thereby select the best candidate (we need to establish a set of minimum requirements). Therefore, we will only work with suppliers who have gone through a selection process and have accomplished certain quality requirements. It also is important to define a mechanism for the resolution of contractual disputes and for normal or early termination of the service, because relations with suppliers in many cases are not ideal. For example, it may be possible that, for business needs, we are interested in ending a contractual relationship that we have with a supplier (for example, because the supplier does not offer the desired quality level). We can manage this break with a procedure, which establishes the global conditions that must be met (although particular conditions must be established in the agreement with each supplier), and the steps to be followed to end the relationship.

The Customer is Always Right

If we can manage these two processes properly, the relationship we have with our customers will be closer, and we will have constant feedback about what they want, or what they need. Also, we will work with the suppliers that best meet our needs, which also will help us to provide the best service to our customers. As they say: The customer is always right, so we have to listen to him and select the best tools (and suppliers) to please and satisfy him!

How to avoid unsatisfied customers by managing problems and incidents according to ISO 20000
As you can imagine, it is an absolute truth that there is no perfect service, and an anomaly always arises that prevents us from providing the service properly. At this point it is important to note that if we have committed contractually with our customer to offer a quality service (Service Level Agreements), we have to fulfill our obligations, because otherwise we will lose money. And of course, if there is any failure during the service, our mission is to manage and treat it to get everything back to normal. The ISO 20000 has a group of processes that helps us manage any anomalies that may arise. This group is called Resolution Processes, and consists of the two processes shown below:

Incident and Service Request Management

An incident occurs when an event takes place that can involve a failure in service. For this anomaly we must first register the incident, and then we have to keep track of its treatment and resolution. For the recording of incidents it is advisable to use a software tool to help us store and keep track of the incidents. This tool will save information about the incidents and the actions that have been carried out to correct them; therefore, we can also use it as a knowledge base, so that if in the future there is an incident that has already been solved in the past, we can consult our knowledge base and treat it more easily. At this point, it is very important to remember that we have to respond to the customer as soon as possible according to the agreements and procedures, and we must communicate to our customer any changes occurring in the state of the incident. Further, when we have resolved the incident, we need to confirm to our customer that everything is correct. To understand this process, lets look at an example: A customer calls because he cannot access our website. Then, we need to register the incident and tell the customer

that the problem has been due to a temporary error and it will be resolved shortly. When we solve the incident, all the information generated will be stored in our knowledge base, so if this incident happens again, we will have information about what happened and how it was resolved. After resolving the incident, we will close it and we will confirm to the client that everything is solved.

Problem Management
A problem also occurs when an event takes place that can involve an abnormality in the service. Here we also must register the problem, and afterward we have to keep track of its resolution and treatment; but, in this case we need to define preventive actions so that the event does not happen again in the future. The problems can also be stored and treated in the same tool we use for the incidents, but the tool must allow us to differentiate between incidents and problems. Therefore, in this case we also have a knowledge base, which we can use to find information about problems that have been resolved in the past. Resolving a problem usually involves making changes, so this process is closely related with the Change Management Process. Now lets see a brief example: The website is down; therefore, we need to study the origin of the problem and resolve it so that this does not happen again in the future. One cause could be that the web server has run out of space on the hard disk; then we would have to buy more disks and oversize the system to prevent this happening again. All information is saved in our knowledge base, and the change of hard disk will be managed through the Change Management Process.

Similarities and Differences

As we can see, both processes are very similar. The main difference is that the Incident Management mainly logs the event, and we need inform the client at all times regarding the state of treatment or resolution of the incident. However, the Problem Management Process corrects the problem and analyzes the causes of the event, to keep it from happening again. But, on the other hand, both processes can share the software tool to manage incidents/problems and store a knowledge base. I hope that after learning a little about these two processes, when you have a problem with your service, you know how to manage it! It is very important that you have in mind the difference between incidents and problems. Here is a basic understanding of both: An incident is when you need to give feedback

quickly to the customer about an event (respecting the times contractually agreed). A problem is when you need to analyze the event and solve it to prevent it happening again in the future!

Using ISO 20000 to control IT services

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?). Lets look at each of these processes in detail:

Configuration Management
It is important to identify the elements that are used to manage the service (these elements in ISO 20000are 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.

Change Management
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.

Release and Deployment Management

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!

ISO/IEC 20000 Service Delivery processes The basis for IT management

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. I will focus on the Service Delivery group, because their processes are easier to understand; so, in the next lines you can find more information about this first group of processes! The Service Delivery Group contains the following processes: 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? But, remember that there are more groups and more processes, so you need to read my next blog post If you want to know them all!

ISO 20000 The perfect way to improve IT services

In the Information Society in which we live there are many companies that provide IT services, but does every company care about customer satisfaction? In theory, everyone but the client knows that is not always true, and clients are becoming ever more demanding. What can we do to satisfy our clients? We can provide good service with acceptable levels of quality, but how can we prove it? One way currently adopted by thousands of companies worldwide is through an International Standard called ISO/IEC 20000 "Information Technology Service management." ISO 20000 was published in 2005 but, like other ISOs, originated in a British Standard: BS 15000. And, although they have many similarities, ISO 20000 at present has eight parts (ISO 20000-1 Service management system requirement, ISO 20000-2 Guidance on the application of service management systems, ISO 20000-3 Guidance on scope definition and applicability of ISO 20000-1, ISO 20000-4 Process reference model, ISO 20000-5 Exemplar implementation plan for ISO 20000-1, ISO 20000-7 Application of ISO 20000-1 to the cloud, ISO 20000-10 Concepts and terminology for ISO 20000-1, ISO 20000-11 Guidance on the relationship between ISO 20000-1 and related frameworks).

ISO 20000 and ITIL

ISO 20000 also has many similarities with ITIL. ITIL stands for Information Technology Infrastructure Library, and is a set of practices for IT service management. It was elaborated in the 1980s by the UK Governments Central Computer and Telecommunications Agency, and at present is a code of practices internationally recognized.

An important difference between ISO 20000 and ITIL is that ISO 20000 gives a certificate to a company, (as you know, ISO 20000 has eight parts, but only ISO 20000-1 is certifiable), while ITIL gives a certificate to an individual person. Both (ISO 20000 and ITIL) help us to manage IT services through a framework or code of practice, although in the case of ISO 20000 we also have a management system, which will be discussed in another blog post. Therefore, the most important parts of ISO are: ISO 20000-1 Service management system requirement, and ISO 20000-2 Guidance on the application of service management systems.

The structure of ISO 20000

There are many companies that implement and certify ISO 20000 because it is a way to assure customers that their services are managed under the umbrella of an internationally recognized code of good practice. And, although as discussed below implementing and maintaining ISO 20000 is often complex because there are many processes and procedures, any organization can start a project of this type regardless of size (although the organization will need the support of specialists). ISO 20000 consists of processes, but what is a process? Basically, a process is a repetitive sequence of activities that occur in an organization to provide an outcome to a recipient. Depending on the activities, we can have different processes, and for each process, we will require resources. At present ISO 20000 is made up of 13 discrete processes and are grouped into four sets: service delivery, control, resolution and relationship with suppliers. Now that you have an introduction to ISO 20000, you can think about how such a standard could improve your business. And yes, your business would undoubtedly improve, because you would have a management system to control all your business processes, and furthermore, you would have in mind an International code of practices to work with. At any rate, remember that ISO 20000 has more processes and we will talk about these in the next blog posts; do not miss them!