Information Technology Infrastructure Library or ITIL is a framework of practices approaches intended to facilitate the delivery of high quality information technology (IT) services. ITIL outlines an extensive set of management procedures that are intended to support businesses in achieving both quality and value for money in IT operations. These procedures have been developed to provide guidance across the breadth of IT infrastructure, development, and operations.
The IT Infrastructure Library is so named as it originated as a collection of books each covering a specific ‘best practice’[1] within IT management. The names ITIL and IT Infrastructure Library are Registered Trade Marks of the Office of Government Commerce (OGC)[2], which is an Office of the United Kingdom’s Treasury. The content of the books is protected by Crown Copyright.
The eight ITIL books and their disciplines are: The IT Service Management sets (1) Service Delivery; (2) Service Support; other operational guidance (3) ICT Infrastructure Management; (4) Security Management; (5) The Business Perspective; (6) Application Management; (7) Software Asset Management; and (8) Planning to Implement Service Management. Another has more recently been supplemented with guidelines for smaller IT units, not included in the original eight publications: ITIL Small-Scale Implementation.
ITSM Set
IT Service Management (ITSM) is a discipline for managing large-scale IT systems, philosophically centered on the customer’s perspective of IT’s contribution to the business. This book if made up of eleven different disciplines, split into two sections, Service Support and Service Delivery.
Figure 1: ITIL Service Management Process
Service Delivery – primarily concerned with the pro-active and forward looking services that the business requires of its ICT provider in order to provide adequate support to the business users, it is focused on the business as the Customer of the ICT services. The discipline consists of the following processes:
Service Level Management – provides for continual identification, monitoring and review of the levels of IT services specified in the Service Level Agreements (SLAs)[3]. Service Level Management ensures that arrangements are in place with internal IT support providers and external suppliers in the form of Operational Level Agreements (OLAs) and Underpinning Contracts (UpCs). The process involves assessing the impact of change upon service quality and SLAs. The service level management process is in close relation with the operational processes to control their activities. The central role of Service Level Management leads to it being the natural place for metrics[4] to be established and monitored against a benchmark[5]. Service Level Management is the primary interface with the Customer (as opposed to the User who is serviced by the Service Desk). The Service Level Manager is reliant upon all the other areas of the Service Delivery process to provide the necessary support which ensures the agreed services are provided in a cost effective, secure and efficient manner.
Capacity Management – supports the optimum and cost effective provision of IT services by helping organizations match their IT resources to the business demands. The high level activities are: Application Sizing, Workload Management, Demand Management, Modeling, Capacity Planning, Resource Management, and Performance Management.
IT Service Continuity Management – helps to ensure the availability and rapid restoration of IT services in the event of a disaster. The high level activities are: Risk Analysis, Manage Contingency Plan Management, Contingency Plan Testing, and Risk Management.
Availability Management – allows organizations to sustain the IT service availability in order to support the business at a justifiable cost. The high level activities are: Realize Availability Requirements, Compile Availability Plan, Monitor Availability, and Monitor Maintenance Obligations.
Financial Management – the aim of Financial Management for IT Services is to give accurate and cost effective stewardship of IT assets and resources used in providing IT Services. It is used to plan, control and recover costs expended in providing the IT Service negotiated and agreed to in the SLA.
Service Support – this discipline of ITIL is focused on the User of the ICT services and is primarily concerned with ensuring that they have access to the appropriate services to support the business functions.
To a business, customers and users are the entry point to the process model. They get involved in service support by: asking for changes; needing communications and updates; and having difficulties and queries.
Service Desk – It is intended to provide a Single Point of Contact (SPOC) to meet the communications needs of both users and IT and to satisfy both Customer and IT Provider objectives, many organisations have implemented a central point of contact for handling Customer, User and related issues. This function is known under several titles often interpreted as having increasing levels of business relevance, including: call centre[6], contact centre[7], help desk [8]and service desk.
Service Desk acts as the central point of contact between service providers and users/customers, on a day-to-day basis. It is also a focal point for reporting Incidents[9] and for users making service requests. It handles incidents and service requests, as well as providing an interface, with users, for other Service Management activities such as Change, Problem, Configuration, Release, Service Level and IT Service Continuity Management.
The Service Desk pro-actively keeps users informed of all relevant service events, actions and service changes that are likely to affect them. The Service Desk is in the direct line of any impact on the SLA and as such should be kept rapidly informed of any planned or unexpected changes or service unavailability.
The Service Desk differs from a Call centre, Contact centre or a Help desk by offering a more broad and user centric approach, which seeks to provide a user with an informed single point of contact for all of their ICT requirements. A Service Desk seeks to facilitate the integration of business processes into the Service Management infrastructure. In addition to actively monitoring and owning Incidents, and user questions and providing the communications channel for other Service Management disciplines with the user community, a Service Desk also provides an interface for other activities such as customer Change requests, third parties (e.g. maintenance contracts), and software licencing.
Incident Management – The first goal of the incident management process is to restore a normal service operation as quickly as possible and to minimize the impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained. ‘Normal service operation’ is defined here as service operation within SLA.
Incidents may match with existing ‘Known Problems’ (without a known root cause) or ‘Known Errors’ (with a root cause) under the control of Problem Management and registered in the Known Error Database (KeDB). Where existing work-arounds have been developed, it is suggested that accessing these will allow the Service Desk to provide a quick first-line fix. Where an incident is not the result of a Known Problem or Known Error, it may either be an isolated or individual occurrences or may (once the initial issue has been addressed) require that Problem Management become involved, possibly resulting in a new problem record being raised.
The main incident management processes are the following: incident detection and recording; classification and initial support; investigation and diagnosis; resolution and recovery; incident closure; and incident ownership, monitoring, tracking and communication.
The incidents that cannot be resolved quickly by the Help desk will be assigned to specialist Technical Support[10] groups. A resolution or work-around should be established as quickly as possible in order to restore the service.
Incidents are the result of failures or errors in the IT infrastructure . The cause of Incidents may be apparent and the cause may be addressed without the need for further investigation, resulting in a repair, a Work-around or a request for change (RFC)[11] to remove the error.
Where an incident is considered to be serious in nature, or multiple occurrences of similar incidents are observed, a problem record might be created as a result (it’s possible that the Problem will not be recorded until several incidents have occurred). The management of a problem varies from the process of managing an incident and is typically performed by different staff and therefore is controlled by the problem management process. When a problem has been properly identified and a work-around is known, the problem becomes a ‘known problem’, when it’s ‘root cause’ has been identified, it becomes a ‘known error’. Finally a RFC may be raised to modify the system by resolving the known error, this process is covered by the Change Management process.
A request for new additional service is not regarded as an incident but as a RFC.
Problem Management – the goal of Problem Management is resolve the root cause of incidents and thus to minimize the adverse impact of incidents and problems on business that are caused by errors within the IT infrastructure, and to prevent recurrence of incidents related to these errors. A `problem’ is an unknown underlying cause of one or more incidents, and a `known error’ is a problem that is successfully diagnosed and for which a work-around has been identified. The CCTA defines problems and known errors as follows:
A problem is a condition often identified as a result of multiple Incidents that exhibit common symptoms. Problems can also be identified from a single significant Incident, indicative of a single error, for which the cause is unknown, but for which the impact is significant.
A known error is a condition identified by successful diagnosis of the root cause of a problem, and the subsequent development of a Work-around.
Problem management is different from incident management. The principal purpose of problem management is find and resolve the root cause of a problem and prevention of incidents; the purpose of incident management is to return the service to normal level as soon as possible, with smallest possible business impact.
The problem management process is intended to reduce the number and severity of incidents and problems on the business, and report it in documentation to be available for the first-line and second line of the help desk. The proactive process identifies and resolves problems before incidents occur. These activities are: trend analysis; targeting support action; and providing information to the organization.
The Error Control Process is an iterative to process known errors until they are eliminated by the successful implementation of a change under the control of the Change Management process.
The Problem Control Process aims to handle problems in an efficient way. Problem control identifies the root cause of incidents and reports it to the service desk. Other activities are: problem identification and recording; problem classification; and problem investigation and diagnosis.
The standard technique for identifying the root cause of a problem is to use an Ishikawa diagram[12], also referred to as a cause-and-effect diagram, tree diagram, or fishbone diagram. An Ishikawa diagram is typically the result of a brainstorming session in which members of a group offer ideas to improve a product. For problem-solving, the goal will be to find the cause and effect of the problem. Ishikawa diagrams can be defined in a meta-model.
First there is the main subject, it’s the backbone of the diagram what we try to solve or improve, the main subject is derived from a cause. The relationship between a cause and an effect is a double relation: an effect is a result of a cause, and the cause is the root of an effect. But there is just one effect for several causes and one cause for several effects.
Figure 2: Ishikawa Diagram or The Fishbone
Change Management – would typically comprise the raising and recording of changes, assessing the impact, cost, benefit and risk of proposed changes, developing business justification and obtaining approval, managing and co-ordinating change implementation, monitoring and reporting on implementation, reviewing and closing RFCs.
ITIL defines the change management process this way: The goal of the Change Management process is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, in order to minimize the impact of change-related incidents upon service quality, and consequently improve the day-to-day operations of the organization.
Change management is responsible for managing change process involving: hardware; communications equipment and software; system software; and all documentation and procedures associated with the running, support and maintenance of live systems.
Any proposed change must be approved in the change management process. While change management makes the process happen, the decision authority is the Change Advisory Board (CAB), which is made up for the most part of people from other functions within the organisation. The main activities of the change management are: Filtering changes; Managing changes and the change process; Chairing the CAB and the CAB/Emergency committee; Reviewing and closing of RFCs; and Management reporting and providing management information.
Release Management – used for platform-independent and automated distribution of software and hardware, including license controls across the entire IT infrastructure. Proper Software and Hardware Control ensure the availability of licensed, tested, and version certified software and hardware, which will function correctly and respectively with the available hardware. Quality control during the development and implementation of new hardware and software is also the responsibility of Release Management. This guarantees that all software can be conceptually optimized to meet the demands of the business processes. The goals of release management are: plan to rollout of software; design and implement procedures for the distribution and installation of changes to IT systems; communicate and manage expectations of the customer during the planning and rollout of new releases; and control the distribution and installation of changes to IT systems.
The focus of release management is the protection of the live environment and its services through the use of formal procedures and checks.
Configuration Management – is a process that tracks all of the individual Configuration Items (CI)[13] in a system. A system may be as simple as a single server, or as complex as the entire IT department. Configuration Management includes: creating a parts list of every CI (hardware or software) in the system; defining the relationship of CIs in the system; tracking of the status of each CI, both its current status and its history; tracking all RFCs to the system; and verifying and ensuring that the CI parts list is complete and correct.
There are five basic activities of Configuration Management: Planning – the Configuration Management plan covers the next three to six months in detail, and the following twelve months in outline. It is reviewed at least twice a year and will include a strategy, policy, scope, objectives, roles and responsibilities, the Configuration Management processes, activities and procedures, the CMDB[14], relationships with other processes and third parties, as well as tools and other resource requirements; Identification – the selection, identification and labelling of all CIs. This covers the recording of information about CI’s, including ownership, relationships, versions and unique identifiers. CIs should be recorded at a level of detail justified by the business need, typically to the level of “independent change”.; Control – this gives the assurance that only authorised and identifiable CIs are accepted and recorded from receipt to disposal. It ensures that no CI is added, modified, replaced or removed without the appropriate controlling documentation e.g. approved RFC, updated specification. All CIs will be under Change Management Control; Status Accounting – the reporting of all current and historical data concerned with each CI throughout its life-cycle. It enables changes to CIs and tracking of their records through various statuses, e.g. ordered, received, under test, live, under repair, withdrawn or for disposal; Verification and Audit – this is a series of reviews and audits that verifies the physical existence of CIs, and checks that they are correctly recorded in the CMDB. It includes the process of verifying Release and Configuration documentation before changes are made to the live environment.
ICT Infrastructure Management – processes recommend best practice for requirements analysis, planning, design, deployment and ongoing operations management and technical support of an ICT Infrastructure.
The Infrastructure Management processes describe those processes within ITIL that directly relate to the ICT equipment and software that is involved in providing ICT services to customers. These processes are: ICT Design and Planning; ICT Deployment; ICT Operations; and ICT Technical Support.
These disciplines are less well understood than those of Service Management and therefore often some of their content is believed to be covered ‘by implication’ in Service Management disciplines.
ICT Design and Planning – provides a framework and approach for the Strategic and Technical Design and Planning of ICT infrastructures. It includes the necessary combination of Business (and overall IS) strategy, with technical design and architecture. ICT Design and Planning drives both the Procurement of new ICT solutions through the production of Statements of Requirement (SOR) and Invitations to Tender (ITT) and is responsible for the initiation and management of ICT Programmes for strategic business change. Key Outputs from Design and Planning are: ICT Strategies, Policies and Plans; The ICT Overall Architecture & Management Architecture; Business Cases, Feasibility Studies, ITTs and SORs.
ICT Deployment and Management – ICT Deployment provides a framework for the successful management of design, build, test and roll-out (deploy) projects within an overall ICT programme. It includes many project management disciplines in common with Prince2[15], but has a broader focus to include the necessary integration of Release Management and both functional and non functional testing.
ICT Operations Management – ICT Operations Management provides the day-to-day technical supervision of the ICT infrastructure. Often confused with the role of Incident Management from Service Support, Operations is more technical and is concerned not solely with Incidents reported by users, but with Events generated by or recorded by the Infrastructure. ICT Operations may often work closely alongside Incident Management and the Service Desk, which are not-necessarily technical in order to provide an ‘Operations Bridge’. Operations, however should primarily work from documented processes and procedures and should be concerned with a number of specific sub-processes, such as: Output Management, Job Scheduling, Backup and Restore, Network Monitoring/Management, System Monitoring/Management, Database Monitoring/Management Storage Monitoring/Management. Operations are responsible for: a stable, secure ICT infrastructure; a current, up to date Operational Documentation Library (ODL); a log of all operational Events; maintenance of operational monitoring and management tools; and Operational Scripts.
ICT Technical Support – is the specialist technical function for infrastructure within ICT. Primarily as a support to other processes, both in Infrastructure Management and Service Management, Technical Support provides a number of specialist functions: Research and Evaluation, Market Intelligence (particularly for Design and Planning and Capacity Management), Proof of Concept and Pilot engineering, specialist technical expertise (particularly to Operations and Problem Management), creation of documentation (perhaps for the Operational Documentation Library or Known Error DataBase).
Security Management – describes the structured fitting of information security in the management organization. ITIL Security Management is based on the code of practice for information security management also known as ISO/IEC 17799.
A basic concept of the Security Management is the information security. The primary goal of information security is to guarantee safety of the information. Safety is to be protected against risks. Security is the means to be safe against risks. When protecting information it is the value of the information that has to be protected. These values are stipulated by the confidentiality, integrity and availability. Inferred aspects are privacy, anonymity and verifiability.
The current move towards ISO/IEC 27001 may require some revision to the ITIL Security Management best practices which are often claimed to be rich in content for physical security but weak in areas such as software/application security and logical security in the ICT infrastructure.
The Business Perspective – the name given to the collection of best practices that is suggested to address some of the issues often encountered in understanding and improving IT service provision, as a part of the entire business requirement for high IS quality management. These issues are: Business Continuity Management describes the responsibilities and opportunities available to the business manager to improve what is, in most organizations one of the key contributing services to business efficiency and effectiveness; Surviving Change. IT infrastructure changes can impact the manner in which business is conducted or the continuity of business operations. It is important that business managers take notice of these changes and ensure that steps are taken to safeguard the business from adverse side effects; Transformation of business practice through radical change helps to control IT and to integrate it with the business; and Partnerships and outsourcing
Application Management – encompasses a set of best practices proposed to improve the overall quality of IT software development and support through the life-cycle of software development projects, with particular attention to gathering and defining requirements that meet business objectives.
Software Asset Management – the process responsible for management, control and protection of software Assets throughout their Lifecycle.
Figure 23: Software Asset Management
Conclusion
There is sufficient evidence of the potential of ICTs that all governments and other stakeholders need to build new capabilities for producing, accessing, and/or using these technologies. In order to build these capabilities each country should establish and implement a national ICT strategy that is responsive to sustainable development goals.
As developing countries join the global information infrastructure, each country will need to find effective ways of maximizing the benefits and controlling the risks from ICTs. This will involve coordinated action through national ICT strategies encompassing the technologies and services as well as many aspects of the institutional environment. Strategies are needed which help to build the necessary scientific, technical, and engineering knowledge as well as the management techniques and social and economic institutions that are consistent with creatively using ICTs to reap the potential social and economic benefits.
Priority needs to be given to policies, regulation, education and training, and technology assessment programmes to enhance the capacity for creatively producing or using ICTs. The balance between producing and using the new applications will differ from country to country. Distinctions need to be drawn between producing ICTs for domestic consumption, especially where there is a requirement for divergence from standard commodity-type ICTs, and producing the technologies and services for export as a sector of the export economy. The ICT-using sectors in developing countries are highly differentiated and the relative benefits of use in the public and private sectors also need careful consideration. New coalitions of resources encouraging and partnerships among stakeholders, including the business sector, need to be encouraged in line with each country’s development priorities.
The coming decades will not see the eradication of the gap between the rich and the poor. However, if governments and other stakeholders design and implement effective national ICT strategies, the new technologies and services may help to reduce the gap for some of those who are disadvantaged or marginalized. Such strategies need to focus on the difficulties of using ICTs to transform data and information into useful knowledge that is consistent with development priorities.
– The United Nations Commission on Science and Technology for Development (UNCSTD) Working Group on IT and Development.
References:
Mansell, R & When, U 1998, Knowledge Societies: Information Technology for Sustainable Development, Oxford, Oxford University Press.
Office of Government Commerce available at [www.ogc.gov.uk]. Accessed on [09/14/06]
Wikimedia Foundation, Inc. available at [www.wikipedia.org]. Accessed on [09/14/06]
BC Associates Dx available at [www.itil-itsm-world.com]. Accessed on [09/14/06].
Drogseth, D 2005, ‘Business Alignment Starts with Quality of Experience; Business Alignment Won’t Emerge from Technical Silos, So Start at the Top: With the Customer’s Experience’, Business Communications Review, vol. 35 no. 3, p. 1.
[1] Best Practice is a management idea which asserts that there is a technique, method, process, activity, incentive or reward that is more effective at delivering a particular outcome than any other technique, method, process, etc. The idea is that with proper processes, checks, and testing, a project can be rolled out and completed with fewer problems and unforeseen complications.
[2] The Office of Government Commerce (OGC) is an organisation in the government of the United Kingdom. It is charged with tasks that improve the efficiency and effectiveness of business procedures for the government. The OGC reports to the Chief Secretary to the Treasury, a junior position in the British Cabinet. The OGC was formed on 1 April 2001, and provides services previously undertaken by The Buying Agency (TBA), the Central Computer and Telecommunications Agency (CCTA), and Property Advisers to the Civil Estate (PACE).
[3] Service Level Agreement (SLA) is a formal written agreement made between two parties: the service provider and the service recipient. It is a core concept of IT Service Management. The SLA itself defines the basis of understanding between the two parties for delivery of the service itself. The document can be quite complex, and sometimes underpins a formal contract. The contents will vary according to the nature of the service itself, but usually includes a number of core elements, or clauses. SLAs are most common for provision of IT services, particularly Internet services.
[4] Metrics are a system of parameters or ways of quantitative and periodic assessment of a process that is to be measured, along with the procedures to carry out such measurement and the procedures for the interpretation of the assessment in the light of previous or comparable assessments. Metrics are usually specialized by the subject area, in which case they are valid only within a certain domain and cannot be directly benchmarked or interpreted outside it.
[5] Benchmarking (also “best practice benchmarking” or “process benchmarking”) is a process used in management and particularly strategic management, in which organizations evaluate various aspects of their processes in relation to best practice, usually within their own sector. This then allows organizations to develop plans on how to adopt such best practice, usually with the aim of increasing some aspect of performance. Benchmarking may be a one-off event, but is often treated as a continuous process in which organizations continually seek to challenge their practices.
[6] A call centre or call center is a centralized office used for the purpose of receiving and transmitting a large volume of requests by telephone.
[7] A contact centre or contact center is a centralized office used for the purpose of receiving and transmitting a large volume of requests through letters, faxes and e-mails.
[8] A help desk is an information and assistance resource that troubleshoots problems with computers and similar products.
[9] An incident is any event which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or a reduction in, the quality of that service.
[10] Technical support (also tech support) is a range of services providing assistance with computer hardware, software, or other electronic or mechanical goods. In general, technical support services attempt to help the user solve specific problems with a product—rather than providing training, customization, or other support services.
[11] Request for Change (RFC) is a document containing a call for an adjustment of a system; it is of great importance in the change management process.
[12] The Ishikawa Diagram is a graphical method for finding the most likely causes for an undesired effect. The method was first used by Kaoru Ishikawa in the 1960s. Because of its shape, it is also known as the fishbone diagram. Another name for this technique is: the cause-and-effect diagram. The fishbone diagram is a method/tool used in a root cause analysis.
[13] Configuration items form the basis of configuration management. A configuration item, or CI, is a unit of configuration that can be individually managed and versioned. Typically, a configuration management system will control files, requirements, or another definable unit. These units are managed with a combination of process and tools to avoid the introduction of errors and to maintain high quality results. The units themselves can be considered configuration items, or they may be combined into an overall collection that is managed under the same set of processes and tools.
[14] A configuration management database (CMDB) is a unified or federated repository of information related to all the components of an information system. It helps an organization to understand the relationships between these components and track their configuration. The CMDB is a fundamental component of an ITIL framework. CMDB records configuration items (CI) and details about the important relationships between CIs. A configuration item is an instance of an entity that has configurable attributes. A key success factor in implementing a CMDB is the ability to automatically discover information about the CIs (auto-discovery), and track changes as they happen.
[15] PRINCE2, or PRojects IN Controlled Environments, is a project management method. It covers the management, control and organisation of a project.
Credit:ivythesis.typepad.com
0 comments:
Post a Comment