|
|
|
|
|
Information Technology Infrastructure LibraryThe Information Technology Infrastructure Library (ITIL) is a registered trademark and a community trade mark of the Office of Government Commerce (OGC). It was developed in the late 1980's by The United Kingdom's Central Computer and Telecommunications Agency (CCTA), which since became the OGC. By the mid 1990's it had become the world-wide de facto standard in IT Service Management. ITIL is an IT Service Management framework like ISPL, ASL, DSDM, and Cobit that can be used by managers in the Information Technology area. ITIL is a set of best practices standards for information technology (IT) service management. The CCTA created ITIL in response to the growing dependence on information technology to meet business needs and goals. ITIL provides businesses with a customizable framework of best practices to achieve quality service and overcome difficulties associated with the growth of IT systems. ITIL defines the organisational structure and skill requirements of an information technology organisation and a set of standard operational management procedures to allow the organisation to manage an IT operation and associated IT infrastructure. The operational procedures are supplier independent and apply to all aspects of the IT Infrastructure. The 'library' itself comprises several distinct sets: - IT Service Management is decompose into two main disciplines:
- The service delivery looks at what service the business requires of the provider in order to provide adequate support to the business;
- The service support is concerned with ensuring that the customer has access to the appropriate services to support the business functions.
- ICT Infrastructure Management is concerned with the processes, organisation and tools needed to provide a stable IT and communications infrastructure, and is the foundation for ITIL service management processes. This discipline includes the following processes:
- Network service management
- Operations Management
- Management of local processors
- Computer installation and acceptance
- Systems management
- Security Management
- Planning to Implement Service Management try to answer the question Where do I start with ITIL?. It explains the necessary steps to identify how an organisation might expect to benefit from ITIL and how to set about reaping those benefits.
- Applications Management embrace the software development lifecycle expanding the issues touched upon in Software development lifecycle and testing of IT services;
- Business perspective deals with issues that Managers can deals with.
The following diagram shows the framework of ITIL. This entry focus on the IT service Management, ICT Infrastructure Management and business perspective of ITIL. The IT service Management is the main discipline of ITIL and is divide into eleven processes, split into two sections, Service support and Service delivery. Fundamental notion Process theory This section gives an introduction to process theory, which is the basis for ITIL process models. A process is a connected series of actions, activities, and changes etc, performed by agents with the intent of satisfying a purpose or achieving a goal. A process model enables understanding and helps to articulate the distinctive features of a process. When a process has been defined it should be under control to be manageable, the process control is the process of planning and regulating, with the objective of performing the process in an effective and efficient way. The output produced by a process has to conform to operational norms that are derived from business objectives. If products conform to the set norm, the process can be considered effective (because it can be repeated, measured and managed).If the activities are carried out with a minimum effort, the process can also be considered efficient. Process results metrics should be incorporated in regular management reports. The model shown above is a generic process model. Data enters in the process, is processed and then the data comes out, the output has been measured and reviewed by the process control. This very basic description underpins any process description. A process is always organized around a goal. The main output of that process is the result of that goal. The approach underpins the plan-do-check-act cycle of any quality management system. Plan the purpose of your process in such a way that the process action can be audited for successful achievement and, if necessary, improved. Disciplines IT Service Management Service Delivery The service delivery discipline looks at what service the business requires of the provider in order to provide adequate support to the business users (See service support section). The discipline is compose of the following processes: - Capacity Management
- Financial Management
- Service Level Management
- IT Service Continuity Management
- Customer Relationship Management
The diagram above shows the relationships between all the processes. It is all explained during the next subsections. Service Level Management Service Level Management ensures continual identification, monitoring and reviewing of the optimally agreed levels of IT services as required by the business for ensuring the Service Level Agreement. The process involves assessing the impact on of change upon service quality and SLAs. The service level management process is on close relation with the operationals (see Service Delivery Process diagram) processes to control their activities. Capacity Management 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. Availability 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. IT Continuity Management IT 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, Risk Management. Financial Management Service Support The service support ensures that the Customer has access to the appropriate services to support the business functions. The business, customers or users are the entry point of the process model; they are involved in service support by asking: - Changes
- Communication, updates
- Difficulties, queries.
The service desk is the single contact point for the customers to record their problems. It will try to resolve it, if there is a direct solution or will translate their queries to incidents. When the incidents have been created, it is the input of a chain process: Incident management, Problem management, Change management, Release management and configuration management (see following sections for details), each process is integrated and connected via the Configuration Management Database (CMDB), which record the main data for the process, and in a same time the processes output documents for the tracability (Quality management). Service Desk The object of the Service Desk is to act 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 and making service requests. To handle Incidents and requests, and provide an interface for other Service Management activities such as Change, Problem, Configuration, Release, Service Level and IT service Continuity Management. The service desk has an obligation to keep the users informed of the service events, actions and opportunities that are likely to impact their ability to pursue their day-to-day activities. The Service Desk is in the direct line of any impact on the Service Level Agreement and as such needs rapid information flows. To meet both Customer and business objectives, many organisations have implemented a central point of contact for handling Custo;er, User and related issues. This function is known under several titles, including: The difference with the Service Desk and the Help desk and Call centre is the Service Desk extends the range of services and offers a more global-foccused approach, allowing business processes to be integrated into the Service Management infrastructure. It not only handles Incidents, Problems and questions, but also provides an interface for other activities such as custo;er Change requests, maintenance contracts, software licence... The objective of the Service Desk are: - Provide a single point of contact for customers
- Facilitate the restoration of normal operational service with minimal business impact on the custo;er within agreed levels (SLA) and business priorities.
The common Service Desk functions include: - Receiving calls, first-line customer liaison
- Recording and tracking incidents and compliants
- Keeping customers informed on reauest status and progress
- Making an initial assessment of requests, attempting to resolve them or refer them to someone who can
- Moniroting and escalation procedures relative to the appropriate SLAs
- Indentifying problems
- Contributing to problem identification
- Closing incidents and confirmation with the customers
- coordinating second-line and third line support.
Incident Management The first goal of the incident management process is to restore a normal service operation as quickly as possible and minimize the impact on business operations, thus ensuring that the best possible levels of service quality and availibility are maintained.'Normal servie operation' is defined here as service operation within Service Level Agreement (SLA). In ITIL terminology, an 'Incident' is defined as follow:new line 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 The definition means that an incident is a problem but without a root or cause. If the incident has a root, the incident become a problem or a known error(i.e next section). This is some examples of incidents: - application
- service not available
- application bug
- disk-usage threshold exceeded
- hardware
- system-down
- automatic alert
- printer not printing
- service requests
- request for information/advice/documentation
- forgotten password
The main incident management processes are the following: - Incident detection and recording
- Classification and initial support
- Investigation and diagnosis
- Resolution and recovery
- Incident closure
- Incident ownership, monitoring, tracking and communication
The incidents that cannot be resolved quickly by the Help desk will be assigned to specialist groups. A resolution or work-around should be established as quickly as possible in order to restore the service. Relationship Incidents are the result of failures or errors in the IT infrastructure . The cause of Incidents may be apparent and that cause be adressed without the need for further investigation, resulting in a repair, a Work-around or an RFC to remove the error. The following diagram shows the relationship between incidents, problem, know errors and RFCs. A problem can be a result of several incident, and it's possible that the Problem will not be diagnosed until serveral incidents have occured. Handlig a problem is different from handling an incidents and is therefore covered by the problem management process. Then the problem become a Known error this mean that the problem has been successfully diagnosed and for which a Work-around is known. Finally the request for changes (RFCs) is the procedure to modify the system to resolve the known error, this process is covered by the Change Management. A request for new aditional service is often not regarded as an incident but as a Request for Change (RFC). Problem Management The goal of Problem management is 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 defined problems and Known error as follow: 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 impaxt 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 differs from Incident management in that its main activity its the detection, resolution and prevention of an incidents, whereas the incident management record the incident. The above diagram shows is the detail of the problem management process. The problem management process is intended to reduce the number and severity on incidents and problems on the business, and report it on documentation to available for the first-line and second line of the help desk. The proactive process to identify and resolve problem before incidents occur. These activities are: - Trend analysis
- Targeting support action
- Providing information to the organization
The error control process involved in processing 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 is concerned with handling problems in a efficient way. The aim of problem control is to identify the root cause and provide it to the service desk, the other activities are: - Problem identification and recording
- Problem classification
- Problem investigation and diagnosis.
The famous technique to identify the root cause of a problem is to use an Ishikawa diagram, 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, in the case of the problem it will be to find the cause and effect of the problem. The following diagram is the meta-model of an Ishikawa diagram: First there is the main subject, its 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 a effect is a double relation, a cause is result of effects, and the effect is the root of causes. But there is just one effect for several causes and one cause for several effects. The following example shows an application of the meta-model. Configuration management The object of Configuration Management in ITIL is to provide a logical model of the IT infrastructure by identifying, controlling, maintaining and verifying the version of all Configuration Items (CIs) in existence. Configuration Management is used to account for all IT assets, to provide accurate information to support other IT Service Management processes, to provide a sound a base for Incident, Problem, Change and Release Management, to verify records against infrastructure and to correct exceptions. There are five basic activities of Configuration Management: - Planning - The Configuration Management plan should cover the next three to six months in detail, and the following twelve months in outline. It should be 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, 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.
Change Management The CCTA define the change management process as follow: 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 to 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
- All documentation and procedures associated with the running, support and maintenance of live systems.
It is the change management process that produces approval, for any proposed change. While change management males the process heppen, the decision authority is the Change Advisory Board ( CAB), which is made up for the most part of people from other functions within 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 RFCs
- Management reporting
The change management process is an important process because everything changes sand, in business, where life is sufficiently complex already, the reliance on information systems and technology causes management to spend an astonishing amount of time. Release Management Release Management is 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. Business Perspective The Business Perspective cover a range of issues concerned with 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.
- Partnerships and outsourcing
ICT infrastructure Missing External links
|
 |
|
| Copyright 2005-2009 OnPedia.com. All Rights Reserved |
|
|