The ITIL concept emerged in the 1980s, when the British government determined that the level of IT service quality provided to them was not sufficient. The Central Computer and Telecommunications Agency (CCTA), now called the Office of Government Commerce (OGC), was tasked with developing a framework for efficient and financially responsible use of IT resources within the British government and the private sector. The earliest version of ITIL was actually originally called GITIM, Government Information Technology Infrastructure Management . Obviously this was very different to the current ITIL, but conceptually very similar, focusing around service support and delivery. Large companies and government agencies in Europe adopted the framework very quickly in the early 1990s. ITIL was spreading far and, and was used in both government and non-government organizations. As it grew in popularity, both in the UK and across the world, IT itself changed and evolved, and so did ITIL. In year 2000, The CCTA merged into the OGC, Office for Government Commerce and in the same year, Microsoft used ITIL as the basis to develop their proprietary Microsoft Operations Framework (MOF). In 2001, version 2 of ITIL was released. The Service Support and Service Delivery books were redeveloped into more concise usable volumes. Over the following few years it became, by far, the most widely used IT service management best practice approach in the world. In 2007 version 3 if ITIL was published. This adopted more of a lifecycle approach to service management, with greater emphasis on IT business integration.
Where does your organization stand today
Deming’s Quality Circle provides a simple an effective model for quality control. The model assumes that to provide quality the following sets should be taken: Plan Do Check Act
Service Strategy: Defines the polices and strategies to implement Service Management in line with overall business strategy. Service Design: Describes how to use the strategy to create designs and specification for service. Service Transition: Details how to get specification into the Live Environment. Service Operation: Now in Live environment, this stage defines how to best support the day to day running of service throughout its life. Continual Service Improvement: Service Performance is measured at each stage ensuring that IT Align and continually realign to the business needs.
Service Support Service Desk Incident Management Problem Management Configuration Management Change Management Release Management Service Desk The formal ITIL goals of the Service Desk function are: "To act as the single point of contact between the user and IT service management. To handle incidents and requests, and provide an interface for other activities such as change, problem, configuration, release, service level, and it service continuity management." The key phrase for this process is single point of contact (SPOC). Service desk is the only function within the ITIL framework; all other entities are processes. The difference is that a function is an organizational department within IT whereas a process is a series of consistently repeated steps that may go across organizational boundaries with the intent of a common goal. The service desk is often described as the face of IT; when managed properly it tends to personalize and humanize what many perceive to be an impersonal, highly technical organization. Incident Management The formal ITIL goals of Incident Management are: "To restore normal service operation as quickly as possible with minimum disruption to the business, thus ensuring that the best achievable levels of availability and service are maintained." The key phrase for this process is restore service as quickly as possible. This process is less concerned with the root cause of an incident, and more concerned with restoring normal service to users as quickly it can. The emphasis here is on first level resolution; incidents that cannot be resolved at first level are then passed on the second level support as part of problem management. In either case, incident management owns the incident from "cradle to grave," even when it is passed over to other support groups. Problem Management The formal ITIL goals of Problem Management are: "To minimize the adverse effect on the business of incidents and problems caused by errors in the infrastructure, and to proactively prevent the occurrence of incidents, problems, and errors." There are several key phrases for this process. One is minimize the adverse effects of problems ; another is proactively prevent problems ; a final key phrase associated with this process, which is not part of its formal goal, is to identify the root cause of problems. In ITIL terminology, any incident that cannot be resolved at the first level of support is designated as a problem. Problem management has five areas of responsibility: identify the root cause of a problem; develop a permanent fix for the problem; provide a temporary workaround solution for the problem until the permanent fix is implemented; submit a change request to implement the permanent fix; prevent proactively the occurrence of problems. Configuration Management The formal ITIL goals of Configuration Management are: "To provide a logical model of the IT infrastructure by identifying, controlling, maintaining and verifying the versions of all configuration items in existence." The key phrase for this process is logical model of the infrastructure. There are several responsibilities of configuration management but four of the most important of them are: determining the scope and detail of configuration items; identifying the attributes of and the relationships among the various configuration items; updating of the configuration items records in the configuration management database (CMDB); conducting of audits of the physical configuration items in the infrastructure and comparing them to the logical records in the CMDB. Change Management The formal ITIL goals of Change Management are: "To ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, in order to minimize the impact of any related incidents upon service." The key phrase for this process is standardized methods for handling large numbers of changes. Change management is responsible for assessing, approving, scheduling, coordinating, overseeing and reviewing authorized changes to configuration items. Once the changes are implemented, change management is responsible for conducting post implementation reviews. Release Management The formal ITIL goals of Release Management are: "To take a holistic view of a change to an IT service and ensure that all aspects of a release, both technical and non-technical, are considered together." The key phrases for this process is ensuring all aspects of a release (i.e., change) are considered and physically implementing changes. In contrast to change management which authorizes changes, release management plans, tests and physically implements the changes. This process also develops the backout plans for changes and executes the backouts when required. Summary This article offers common, everyday translations of the formal goals of the processes associated with the ITIL Service Support book. The intention is to enable those of you interested in obtaining a quick overview of the processes to do so with minimum effort and maximum effectiveness. A companion article translating the processes of the ITIL Service Delivery book precedes this section of the Management Guide.
ITIL V3 has brought guidance to current IT best practices and has emphasized the need for IT to work and communicate with business efficiently ITIL V3 is an evolution of ITIL V2, rather than a replacement
Quality of IT Service Largely depends on how IT Manages relationship with business
![ITIL Introduction ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)