4-ServiceOperation.pdf

28/8/07 14:01 Page 93 | 93 Service Operation The business/customers Requirements Service Strategy Strategies Policies Resource and Constraints Service Design Solution Designs Architectures Service Transition Transition Plans Service Operation we have learned some of the key concepts of ITIL e Manage...

28/8/07 14:01 Page 93 | 93 Service Operation The business/customers Requirements Service Strategy Strategies Policies Resource and Constraints Service Design Solution Designs Architectures Service Transition Transition Plans Service Operation we have learned some of the key concepts of ITIL e Management – Strategy, Design and Transition. f these has demonstrated how they contribute to quality, but it is in Service Operation that the ss customer sees the quality of the strategy, the and the transition come to life in everyday use of vices. e Operation is the phase in the ITIL Service ement Lifecycle that is responsible for business-asactivities. Objectives from Requirements SDPs Standards Tested solutions SKMS Operational services support services. Management of the infrastructure and the operational activities must always support this purpose. Well-planned and implemented processes will be to no avail if the day-to-day operation of those processes is not properly conducted, controlled and managed. Nor will service improvements be possible if day-to-day activities to monitor performance, assess metrics and gather data are not systematically conducted during Service Operation. The purpose of Service Operation is to coordinate and 28/8/07 14:01 Page 94 Service Operation going management of the technology that is used ver and support services. BUSINESS VALUE tage in the ITIL Service Management Lifecycle es value to business. For example, service value is led in Service Strategy; the cost of the service is ed, predicted and validated in Service Design and e Transition; and measures for optimization identified tinual Service Improvement. The operation of is where these plans, designs and optimizations are ed and measured. From a customer viewpoint, e Operation is where actual value is seen. tages of the ITIL Service Management Lifecycle, are distinct processes, functions and activities which ogether to deliver the objectives of Service ion. The following sections in this chapter touch on: ocesses of: ent Management quest Fulfilment ident Management blem Management cess Management evaluation of the impact a deviation might cause to the services. Events are typically notifications created by an IT service, Configuration Item (CI) or monitoring tool (see Figure 7.1). Effective Service Operation is dependent on knowing the status of the infrastructure and detecting any deviation from normal or expected operation. This is provided by good monitoring and control systems, which are based on two types of tools:  Active monitoring tools that poll key CIs to determine their status and availability. Any exceptions will generate an alert that needs to be communicated to the appropriate tool or team for action  Passive monitoring tools that detect and correlate operational alerts or communications generated by CIs. Event Management can be applied to any aspect of service management that needs to be controlled and which can be automated. These include:  Configuration Items:  Some CIs will be included because they need to nctions of: vice Desk hnical Management Operations Management plication Management nitoring and Control.    EVENT MANAGEMENT  stay in a constant state (e.g. a switch on a network needs to stay on and Event Management tools confirm this by monitoring responses to ‘pings’)  Some CIs will be included because their status needs to change frequently and Event Management can be used to automate this and update the CMS (e.g. the updating of a file server) Environmental conditions (e.g. fire and smoke detection) Software licence monitoring for usage to ensure optimum/legal licence utilization and allocation Security (e.g. intrusion detection) Normal activity (e.g. tracking the use of an application 28/8/07 14:01 Page 95 Service Operation | 7.1 The Event Management process Event Event Notification Generated Event Detected Event Filtered Informational Significance? Exception Warning Event Correlation Trigger Event Logged Auto Response Alert Incident Incident/ Problem/ Change? Change Problem Human Intervention Incident Management Review Actions No Effective? Yes Close Event Problem Management Change Management 95 28/8/07 14:01 Page 96 Service Operation Value to business Management’s value to the business is generally t; however it is possible to determine the basis for ue as follows: ent Management provides mechanisms for early ection of incidents. In many cases it is possible for incident to be detected and assigned to the propriate group for action before any actual service age occurs ent Management makes it possible for some types of omated activity to be monitored by exception – s removing the need for expensive and resourceensive real-time monitoring, while reducing wntime en integrated into other service management cesses (such as, for example, Availability or Capacity nagement), Event Management can signal status anges or exceptions that allow the appropriate son or team to perform early response, thus proving the performance of the process. This, in n, will allow the business to benefit from more ective and more efficient Service Management erall ent Management provides a basis for automated erations, thus increasing efficiencies and allowing pensive human resources to be used for more ovative work, such as designing new or improved ctionality or defining new ways in which the siness can exploit technology for increased mpetitive advantage. INCIDENT MANAGEMENT nt Management includes any event which disrupts, ch could disrupt, a service. This includes events Incidents can also be reported and/or logged by technical staff (if, for example, they notice something untoward with a hardware or network component they may report or log an incident and refer it to the Service Desk). 7.3.1 Value to business Incident Management is highly visible to the business, and it is therefore easier to demonstrate its value than most areas in Service Operation. For this reason, Incident Management is often one of the first processes to be implemented in service management projects. The added benefit of doing this is that Incident Management can be used to highlight other areas that need attention – thereby providing a justification for expenditure on implementing other processes. Incident Management’s value to the business includes:  The ability to detect and resolve Incidents which results in lower downtime to the business, which in turn means higher availability of the service. This means that the business is able to exploit the functionality of the service as designed  The ability to align IT activity to real-time business priorities. This is because Incident Management includes the capability to identify business priorities and dynamically allocate resources as necessary  The ability to identify potential improvements to services. This happens as a result of understanding what constitutes an Incident and also from being in contact with the activities of business operational staff  The Service Desk can, during its handling of Incidents, identify additional service or training requirements found in IT or the business. 7.3.2 Incident models 28/8/07 14:01 Page 97 Service Operation | helpful to pre-define standard Incident models – pply them to appropriate Incidents when they occur. dent model is a way of pre-defining the steps that be taken to handle a process (in this case a process aling with a particular type of incident) in an agreed upport tools can then be used to manage the ed process. This will ensure that standard incidents ndled in a pre-defined path and within pre-defined ales. cident model should include: ps that should be taken to handle the Incident ronological order these steps should be taken in, h any dependences or co-processing defined ponsibilities; who should do what mescales and thresholds for completion of the ions alation procedures; who should be contacted and en y necessary evidence-preservation activities rticularly relevant for security- and capacity-related idents). odels should be input to the Incident-handling rt tools in use and the tools should then automate ndling, management and escalation of the process. cident Management process is shown in Figure 7.2. nt logging dents must be fully logged and date/time stamped, less of whether they are raised through a Service elephone call or whether automatically detected via nt alert. 97 looking at Incident types/frequencies to establish trends for use in Problem Management, Supplier Management and other ITSM activities. Incident prioritization Prioritization can normally be determined by taking into account both the urgency of the Incident (how quickly the business needs a resolution) and the level of impact it is causing. An indication of impact is often (but not always) the number of users being affected. In some cases, and very importantly, the loss of service to a single user can have a major business impact. Initial diagnosis If the incident has been routed via the Service Desk, the Service Desk Analyst must carry out initial diagnosis, typically while the user is still on the telephone – if the call is raised in this way – to try to discover the full symptoms of the Incident and to determine exactly what has gone wrong and how to correct it. It is at this stage that diagnostic scripts and known error information can be most valuable in allowing earlier and accurate diagnosis. Incident escalation Functional escalation – As soon as it becomes clear that the Service Desk is unable to resolve the incident itself (or when target times for first-point resolution have been exceeded – whichever comes first!) the incident must be immediately escalated for further support. Hierarchic escalation – If incidents are of a serious nature (for example Priority 1 incidents) the appropriate IT managers must be notified, for informational purposes at least. Hierarchic escalation is also used if the ‘Investigation and Diagnosis’ and ‘Resolution and Recovery’ steps are 28/8/07 14:01 Page 98 Service Operation 7.2 The Incident Management process flow From Event Mgmt From Web Interface User Phone Call Email Technical Staff Incident Identification Incident Logging Incident Categorization Service Request? Yes To Request Fulfilment No Incident Prioritization Major Incident Procedure Yes Major Incident? No Initial Diagnosis Yes Management Escalation Yes Hierarchic Escalation Needed? No Functional Escalation Needed? No Investigation & Diagnosis Resolution and Recovery Yes Functional Escalation 2/3 Level 28/8/07 14:01 Page 99 ces or involving suppliers/maintainers. Hierarchic ion is also used when there is contention about to the incident is allocated. tigation and diagnosis ill include a variety of activities depending on the f incident but should include: Service Operation | Incident closure The Service Desk should check that the incident is fully resolved and that the users are satisfied and willing to agree the Incident can be closed. The Service Desk should also check the following:  Closure categorization. Check and confirm that the ablishing exactly what has gone wrong or being ught by the user derstanding the chronological order of events nfirming the full impact of the incident, including number and range of users affected ntifying any events that could have triggered the ident (e.g. a recent change, some user action?) owledge searches looking for previous occurrences searching previous Incident/Problem Records and/or own Error Databases or manufacturers’/suppliers’ or Logs or Knowledge Databases.  ution and recovery   a potential resolution has been identified, this be applied and tested. The specific actions to be aken and the people who will be involved in taking covery actions may vary, depending upon the nature fault – but could involve: ing the user to undertake directed activities on their n desktop or remote equipment e Service Desk implementing the resolution either ntrally (say, rebooting a server) or remotely using tware to take control of the user’s desktop to gnose and implement a resolution ecialist support groups being asked to implement ecific recovery actions (e.g. network support 99  initial Incident categorization was correct or, where the categorization subsequently turned out to be incorrect, update the record so that a correct closure categorization is recorded for the Incident – seeking advice or guidance from the resolving group(s) as necessary User satisfaction survey. Carry out a user satisfaction call-back or e-mail survey for the agreed percentage of Incidents Incident documentation. Chase any outstanding details and ensure that the Incident Record is fully documented so that a full historic record at a sufficient level of detail is complete Ongoing or recurring problem? Determine (in conjunction with resolver groups) whether it is likely that the incident could recur and decide whether any preventive action is necessary to avoid this. In conjunction with Problem Management, raise a Problem Record in all such cases so that preventive action is initiated Formal closure. Formally close the Incident Record. 7.4 REQUEST FULFILMENT The term ‘Service Request’ is used as a generic description for many varying types of demands that are placed upon the IT department by the users. Many of these are actually small changes – low risk, frequently occurring, low cost 28/8/07 14:01 Page 100 Service Operation ation – but their scale and frequent, low-risk nature that they are better handled by a separate process, than being allowed to congest and obstruct the l Incident and Change Management processes. ocess needed to fulfil a request will vary depending exactly what is being requested – but can usually be n down into a set of activities that have to be med. Some organizations will be comfortable to let rvice Requests be handled through their Incident ement processes (and tools) – with Service Requests handled as a particular type of Incident (using a evel categorization system to identify those Incidents e in fact Service Requests). however, that there is a significant difference here – dent is usually an unplanned event whereas a e Request is usually something that can and should nned! ore, in an organization where large numbers of e Requests have to be handled, and where the s to be taken to fulfil those requests are very varied cialized, it may be appropriate to handle Service sts as a completely separate work stream – and to and manage them as a separate record type. Service Requests will be frequently recurring, so a ined process flow (a model) can be devised to e the stages needed to fulfil the request, the uals or support groups involved, target timescales calation paths. Service Requests will usually be d by implementing a Standard Change (see the e Transition publication for further details on rd Changes). The ownership of Service Requests with the Service Desk, which monitors, escalates, ches and often fulfils the user request. 7.4.1 Request models Some Service Requests will occur frequently and will require handling in a consistent manner in order to meet agreed service levels. To assist this, many organizations will wish to create pre-defined Service Request models (which typically include some form of pre-approval by Change Management). This is similar in concept to the idea of Incident models, but applied to Service Requests. Most requests will be triggered through either a user calling the Service Desk or a user completing some form of self-help web-based input screen to make their request. The latter will often involve a selection from a portfolio of available request types. The primary interfaces with Request Fulfilment include:  Service Desk/Incident Management: many Service Requests may come in via the Service Desk and may be initially handled through the Incident Management process. Some organizations may choose that all Requests are handled via this route – but others may choose to have a separate process, for reasons already discussed earlier in this chapter  A strong link is also needed between Request Fulfilment, Release, Asset and Configuration Management as some requests will be for the deployment of new or upgraded components that can be automatically deployed. In such cases the release can be pre-defined, built and tested but only deployed upon request by those who want the release. Upon deployment, the CMS will have to be updated to reflect the change. Where appropriate, software licence checks/updates will also be necessary. Where appropriate, it will be necessary to relate IT-related Service Requests to any Incidents or Problems that have 28/8/07 14:01 Page 101 Service Operation | st Fulfilment depends on the following critical s factors: eement of what services will be standardized and o is authorized to request them. The cost of these vices must also be agreed. This may be done as part the SLM process. Any variances of the services must o be defined blication of the services to users as part of the vice Catalogue. It is important that this part of the vice Catalogue must be easily accessed, perhaps on intranet, and should be recognized as the first urce of information for users seeking access to a vice inition of a standard fulfilment procedure for each the services being requested. This includes all curement policies and the ability to generate chase orders and work orders ingle point of contact which can be used to request service. This is often provided by the Service Desk through an intranet request, but could be through automated request directly into the Request filment or procurement system f-service tools needed to provide a front-end erface to the users. It is essential that these integrate h the back-end fulfilment tools, often managed ough Incident or Change Management. PROBLEM MANAGEMENT 101 7.5.1 Scope Problem Management includes the activities required to diagnose the root cause of Incidents and to determine the resolution to those problems. It is also responsible for ensuring that the resolution is implemented through the appropriate control procedures, especially Change Management and Release Management. Problem Management will also maintain information about Problems and the appropriate workarounds and resolutions, so that the organization is able to reduce the number and impact of Incidents over time. In this respect, Problem Management has a strong interface with Knowledge Management, and tools such as the Known Error Database will be used for both. Although Incident and Problem Management are separate processes, they are closely related and will typically use the same tools, and may use similar categorization, impact and priority coding systems. This will ensure effective communication when dealing with related Incidents and Problems. Problem Management consists of two major processes:  Reactive Problem Management, which is generally executed as part of Service Operation  Proactive Problem Management which is initiated in Service Operation, but generally driven as part of Continual Service Improvement. fines a ‘Problem’ as the unknown cause of one or ncidents. 7.5.2 Process m Management is the process responsible for ing the lifecycle of all problems. The primary ves of Problem Management are to prevent It is likely that multiple ways of detecting problems will exist in all organizations. These will include: Problem detection  Suspicion or detection of an unknown cause of one or 28/8/07 14:01 Page 102 Service Operation 7.3 The Problem Management process flow Service Desk Incident Management Event Management Proactive Problem Management Problem Detection Problem Logging Categorization Prioritization Investigation & Diagnosis CMS Workaround? Create Known Error Record Change Management Yes Known Error Database Change Needed? No Resolution Closure Major Major Problem Supplier or Contractor 28/8/07 14:01 Page 103 initive cause and suspects that it is likely to recur, so raise a Problem Record to allow the underlying use to be resolved. Alternatively, it may be mediately obvious from the outset that an Incident, ncidents, has been caused by a major problem, so a blem Record will be raised without delay alysis of an incident by a technical support group ich reveals that an underlying problem exists, or is ly to exist omated detection of an infrastructure or application lt, using event/alert tools automatically to raise an ident which may reveal the need for a Problem cord otification from a supplier or contractor that a blem exists that has to be resolved alysis of Incidents as part of proactive Problem nagement – resulting in the need to raise a Problem cord so that the underlying fault can be investigated ther. Service Operation | 103 Problem categorization Problems must be categorized in the same way as Incidents (and it is advisable to use the same coding system) so that the true nature of the Problem can be easily traced in the future and meaningful management information can be obtained. Problem prioritization Problems must be prioritized in the same way and for the same reasons as Incidents – but the frequency and impact of related Incidents must also be taken into account. Problem prioritization should also take into account the severity of the Problem. Severity in this context refers to how serious the Problem is from an infrastructure perspective, for example:  Can the system be recovered, or does it need to be   em logging replaced? How much will it cost? How many people, with what skills, will be needed to fix the problem? How long will it take to fix the problem? How extensive is the problem (e.g. how many CIs are affected)? s-reference must be made to the incident(s) which d the Problem Record – and all relevant details be copied from the Incident Record(s) to the m Record. It is difficult to be exact, as cases may ut typically this will include details such as:  er details vice details uipment details te/time initially logged ority and categorization details ident description tails of all diagnostic or attempted recovery actions en. An investigation should be conducted to try to diagnose the root cause of the Problem – the speed and nature of this investigation will vary depending upon the impact, severity and urgency of the Problem – but the appropriate level of resources and expertise should be applied to finding a resolution commensurate with the priority code allocated and the service target in place for that priority level.  Problem investigation and diagnosis 28/8/07 14:01 Page 104 Service Operation also be accessed and Problem-matching ques (such as keyword searches) should be used to he Problem has occurred before and, if so, to find olution. ten valuable to try to recreate the failure, so as to tand what has gone wrong, and then to try various of finding the most appropriate and cost-effective ion to the Problem. To do this effectively without g further disruption to the users, a test system will essary that mirrors the production environment. are many Problem analysis, diagnosis and solving ques available and much research has been done in ea. The Service Operation publication details the and how to use them. arounds e cases it may be possible to find a workaround to idents caused by the Problem – a temporary way of ming the difficulties. For example, a manual dment may be made to an input file to allow a m to complete its run successfully and allow a process to complete satisfactorily, but it is ant that work on a permanent resolution continues this is justified – in this example the reason for the coming corrupted in the first place must be found rrected to prevent this happening again. s where a workaround is found, it is therefore ant that the Problem Record remains open, and of the workaround are always documented within oblem Record. ng a Known Error Record n as the diagnosis is complete, and particularly so that if further Incidents or Problems arise, they can be identified and the service restored more quickly. However, in some cases it may be advantageous to raise a Known Error Record even earlier in the overall process – just for information purposes, for example – even though the diagnosis may not be complete or a workaround found, so it is inadvisable to set a concrete procedural point exactly when a Known Error Record must be raised. It should be done as soon as it becomes useful to do so! Problem resolution Ideally, as soon as a solution has been found, it should be applied to resolve the Problem – but in reality safeguards may be needed to ensure that this does not cause further difficulties. If any change in functionality is required this will require an RFC to be raised and approved before the resolution can be applied. If the Problem is very serious and an urgent fix is needed for business reasons, then an Emergency RFC should be handled by the Emergency Change Advisory Board (ECAB) to facilitate this urgent action. Otherwise, the RFC should follow the established Change Management process for that type of Change – and the resolution should be applied only when the Change has been approved and scheduled for release. In the meantime, the KEDB should be used to help resolve quickly any further occurrences of the Incidents/Problems. Problem closure When any change has been completed (and successfully reviewed), and the resolution has been applied, the Problem Record should be formally closed – as should any related Incident Records that are still open. A check should be performed at this time to ensure that the record contains a full historical description of all events – and if 28/8/07 14:01 Page 105 Service Operation | Problem review very major Problem (as determined by the zation’s priority system), while memories are still review should be conducted to learn any lessons future. Specifically, the review should examine: ose things that were done correctly ose things that were done wrong at could be done better in the future w to prevent recurrence ether there has been any third-party responsibility d whether follow-up actions are needed. eviews can be used as part of training and ness activities for support staff – and any lessons d should be documented in appropriate procedures, nstructions, diagnostic scripts or Known Error s. The Problem Manager facilitates the session and ments any agreed actions. s detected in the development environment e for any new applications, systems or software s to be completely error-free. It is more likely that testing of such new applications, systems or s, a prioritization system will be used to eradicate ore serious faults, but it is possible that minor faults t rectified – often because of the balance that has to de between delivering new functionality to the ss as quickly as possible and ensuring totally faultde or components. a decision is made to release something into the ction environment that includes known deficiencies, should be logged as Known Errors in the KEDB, er with details of workarounds or resolution es. There should be a formal step in the testing 105 7.6 ACCESS MANAGEMENT Access Management is the process of granting authorized users the right to use a service, while preventing access to non-authorized users. It has also been referred to as ‘rights management’ or ‘identity management’ in different organizations. Access Management is effectively the execution of both Availability and Information Security Management, in that it enables the organization to manage the confidentiality, availability and integrity of the organization’s data and intellectual property. Access Management ensures that users are given the right to use a service, but it does not ensure that this access is available at all agreed times – this is provided by Availability Management. Access Management is a process that is executed by all Technical and Application Management functions and is usually not a separate function. However, there is likely to be a single control point of coordination, usually in IT Operations Management or on the Service Desk. Access Management can be initiated by a Service Request through the Service Desk. 7.6.1 Value to business  Controlled access to services ensures that the organization is able to maintain more effectively the confidentiality of its information  Employees have the right level of access to execute their jobs effectively  There is less likelihood of errors being made in data entry or in the use of a critical service by an unskilled user (e.g. production control systems) 28/8/07 14:01 Page 106 Service Operation y be needed for regulatory compliance (e.g. SOX, AA, COBIT). Basic concepts each user has an individual identity, and each IT can be seen as an entity in its own right, it is often to group them together so that they can be ed more easily. Sometimes the terms ‘user profile’, emplate’ or ‘user role’ are used to describe this type uping. organizations have a standard set of services for all ual users, regardless of their position or job ding customers – who do not have any visibility to al services and processes). These will include services s messaging, office automation, desktop support, ony etc. New users are automatically provided with to use these services. er, most users also have some specialized role that erform. For example, in addition to the standard s, the user may also perform a marketing ement role, which requires that they have access to specialized marketing and financial modelling tools ata. groups may have unique requirements – such as r home workers who may have to dial in or use private network (VPN) connections, with security ations that may have to be more tightly managed. ke it easier for Access Management to provide the priate rights, it uses a catalogue of all the roles in the zation and which services support each role. This gue of roles should be compiled and maintained by Management in conjunction with HR and will often omated in the directory services tools. Management will assess all the roles that a user plays as well as the groups that they belong to and ensure that they provide rights to use all associated services. Note: All data held on users will be subject to data protection legislation (this exists in most geographic locations in some form or other) so should be handled and protected as part of the organization’s security procedures. 7.6.3 Lifecycle activities Within Access Management the following lifecycle flow is recommended:  Requesting access  Verification  Providing rights  Monitoring identity status  Logging and tracking access  Removing or restricting rights. The Service Operation publication provides the detailed workflow for each of these activities. 7.7 SERVICE OPERATION FUNCTIONS 7.7.1 Monitoring and control The measurement and control of services is based on a continual cycle of monitoring, reporting and subsequent action. This cycle is discussed in detail in this section because it is fundamental to the delivery, support and improvement of services. It is also important to note that, although this cycle takes place during Service Operation, it provides a basis for setting strategy, designing and testing services and 28/8/07 14:01 Page 107 Service Operation | e Lifecycle should ensure that measures and controls arly defined, executed and acted upon. 7.4 Single monitor control loop put Norm Control  Closed-loop systems monitor an environment and respond to changes in that environment. For example, in network load balancing a monitor will evaluate the traffic on a circuit. If network traffic exceeds a certain range, the control system will begin to route traffic across a backup circuit. The monitor will continue to provide feedback to the control system which will continue to regulate the flow of network traffic between the two circuits. To help clarify the difference, solving a Capacity Management problem through over-provisioning is open loop; a load-balancer that detects congestion/failure and redirects capacity is closed loop. Compare Complex monitor control loop Monitor Activity 107 Output e monitor control loop e activity and its output are measured using a pred norm, or standard, to determine whether it is an acceptable range of performance or quality e 7.4). If not, action is taken to rectify the situation or ore normal performance. ly there are two types of monitor control loops: en-loop systems are designed to perform a specific The monitor control loop in Figure 7.5 is a good basis for defining how Operations Management works, but within the context of ITSM the situation is far more complex. The figure illustrates a process consisting of three major activities. Each one has an input and an output, and the output becomes an input for the next activity. In this diagram, each activity is controlled by its own Monitor Control Loop, using a set of norms for that specific activity. The process as a whole also has its own Monitor Control Loop, which spans all the activities and ensures that all norms are appropriate and are being followed. One loop focuses purely on executing a defined standard, and the second evaluates the performance of the process and also the standards whereby the process is executed. An example of this would be if the first set of feedback loops at the bottom of the diagram represented individual stations on an assembly line and the higher-level loop represented quality assurance. 28/8/07 14:01 Page 108 Service Operation 7.5 Complex monitor control loop Norm Control Compare Monitor Norm Control Control Compare Control Compare Monitor Activity Norm Norm Compare Monitor Output Input Activity The first level of feedback at individual activity level cerned with monitoring and responding to data facts, codes or pieces of information). The second concerned with monitoring and responding to ation (a collection of a number of facts about which lusion may be drawn). Refer to the Service Monitor Output Input Activity Output Input IT services. And especially – who defines the norm? Based on what has been described so far, monitor control loops can be used to manage:  Performance of activities in a process or procedure. Each activity and its related output can potentially be measured to ensure that problems with the process are 28/8/07 14:01 Page 109 alated. This is done well before the target resolution e for that Incident because the aim of escalating t one activity is to ensure that the process as whole ompleted in time ectiveness of a process or procedure as a whole. his case the ‘activity’ box represents the entire cess as a single entity. For example, Change nagement will measure the success of the process checking whether a change was implemented on e, to specification and within budget rformance of a device. For example, the ‘activity’ x could represent the response time of a server der a given workload rformance of a series of devices. For example, the d user response time of an application across the work. monitor control loop ctivity in a service management process (or each onent used to provide a service) is monitored as part Service Operation processes. The operational team artment responsible for each activity or component ply the monitor control loop as defined in the s, and using the norms that were defined during rvice Design processes. The role of operational oring and control is to ensure that the process or functions exactly as specified, which is why they marily concerned with maintaining the status quo. orms and monitoring and control mechanisms are d in Service Design, but they are based on the rds and architectures defined during Service gy. Any changes to the organization’s Service gy, architecture, Service Portfolios or Service Level ements will precipitate changes to what is Service Operation | 109 support from vendor account managers. Service Design acts as the bridge between Service Strategy and Service Operation and will typically involve representatives from all groups. The activities and controls will generally be executed by IT staff (sometimes involving users) and supported by IT managers and the vendors. Service Improvement spans all areas, but primarily represents the interests of the business and its users. Notice that the second level of monitoring in this complex monitor control loop is performed by the CSI processes through Service Strategy and Service Design. These relationships are represented by the numbered arrows in Figure 7.6:  Arrow 1. In this case CSI has recognized that the service will be improved by making a change to the Service Strategy. This could be the result of the business needing a change to the Service Portfolio, or that the architecture does not deliver what was expected  Arrow 2. In this case the Service Level Requirements need to be adjusted. It could be that the service is too expensive; or that the configuration of the infrastructure needs to be changed to enhance performance; or because Operations Management is unable to maintain service quality in the current architecture  Arrow 3. In this case the norms specified in Service Design are not being adhered to. This could be because they are not appropriate or executable, or because of a lack of education or a lack of communication. The norms and the lack of compliance need to be investigated and action taken to rectify the situation. There are many different types of monitoring tool and 28/8/07 14:01 Page 110 Service Operation 7.6 ITSM monitor control loop Business Executives and Business Unit Managers 1 Service Strategy 2 Continual Service Improvement 3 Service Design Portfolios, Standards and Policies Service Transition Technical Architectures and Performance Standards Users Norm Control Norm Control Compare Activity Control Compare Compare Monitor Monitor Input Norm Output Input Activity Monitor Output Input Activity Output Internal and External Technical Staff and Experts versus passive monitoring: tive monitoring refers to the ongoing interrogation critical devices or systems; or as a diagnostic step when attempting to resolve an Incident or diagnose a 28/8/07 14:01 Page 111 pends on successful definition of events and trumentation of the system being monitored (see tion 4.1 of the Service Operation publication). ve versus proactive monitoring: active monitoring is designed to request or trigger ion following a certain type of event or failure. For mple, server performance degradation may trigger eboot, or a system failure will generate an Incident. active monitoring is not only used for exceptions. It n also be used as part of normal operations cedures, for example a batch job completes cessfully, which prompts the scheduling system to bmit the next batch job oactive monitoring is used to detect patterns of nts which indicate that a system or service may be out to fail. Proactive monitoring is generally used in re mature environments where these patterns have en detected previously, often several times. Proactive nitoring tools are therefore a means of automating experience of seasoned IT staff and are often created ough the Proactive Problem Management process e Continual Service Improvement publication). ational monitoring and Continual Service ovement ction has focused on operational monitoring and ng, but monitoring also forms the starting point for ual Service Improvement (CSI). This is covered in the ual Service Improvement publication, but key nces are outlined here. y is the key objective of monitoring for CSI. oring will therefore focus on the effectiveness of a , process, tool, organization or CI. The emphasis is Service Operation | 111 Monitoring for CSI will therefore tend to focus on detecting exceptions and resolutions. For example, CSI is not as interested in whether an Incident was resolved, but whether it was resolved within the agreed time and whether future Incidents can be prevented. CSI is not only interested in exceptions, though. If an SLA is consistently met over time, CSI will also be interested in determining whether that level of performance can be sustained at a lower cost or whether it needs to be upgraded to an even better level of performance. CSI may therefore also need access to regular performance reports. However, since CSI is unlikely to need, or be able to cope with, the vast quantities of data that are produced by all monitoring activity, they will most likely focus on a specific subset of monitoring at any given time. This could be determined by input from the business or improvements to technology. This has two main implications:  Monitoring for CSI will change over time. They may be interested in monitoring the e-mail service one quarter and then move on to look at HR systems in the next quarter  This means that Service Operation and CSI need to build a process which will help them to agree on what areas need to be monitored and for what purpose. 7.7.2 Service Desk A Service Desk is a functional unit made up of a dedicated number of staff responsible for dealing with a variety of service events, often made via telephone calls, web interface or automatically reported infrastructure events. The Service Desk is a vitally important part of an organization’s IT department and should be the single 28/8/07 14:01 Page 112 Service Operation lue of an effective Service Desk should not be ated – a good Service Desk can often compensate iciencies elsewhere in the IT organization; but a ervice Desk (or the lack of a Service Desk) can give impression of an otherwise very effective IT zation! erefore very important that the correct calibre of e used on the Service Desk and that IT managers ir best to make the Service Desk an attractive place k in order to improve staff retention. imary aim of the Service Desk is to restore ‘normal ’ to the users as quickly as possible. In this context ation of service’ is meant in the widest possible While this could involve fixing a technical fault, it equally involve fulfilling a Service Request or ring a query – anything that is needed to allow the o return to working satisfactorily. c responsibilities will include: gging all relevant Incident and Service Request ails, allocating categorization and prioritization des viding first-line investigation and diagnosis olving those Incidents and Service Requests they able to alating Incidents and Service Requests that they nnot resolve within agreed timescales eping users informed of progress sing all resolved incidents, requests and other calls nducting customer/user satisfaction callcks/surveys as agreed mmunication with users – keeping them informed ncident progress, notifying them of impending anges or agreed outages etc. The following roles are needed for the Service Desk. Service Desk manager In larger organizations where the Service Desk is of a significant size, a Service Desk manager role may be justified with the Service Desk supervisor(s) reporting to them. In such cases this role may take responsibility for some of the activities listed above and may additionally perform the following activities:  Manage the overall desk activities, including the      supervisors Act as a further escalation point for the supervisor(s) Take on a wider customer-services role Report to senior managers on any issue that could significantly impact the business Attend Change Advisory Board meetings Take overall responsibility for Incident and Service Request handling on the Service Desk. This could also be expanded to any other activity taken on by the Service Desk – e.g. monitoring certain classes of event. Note: In all cases, clearly defined job descriptions should be drafted and agreed so that specific responsibilities are known. Service Desk supervisor In very small Service Desks it is possible that the senior Service Desk analyst will also act as the supervisor – but in larger desks it is likely that a dedicated Service Desk supervisor role will be needed. Where shift hours dictate it, there may be two or more post-holders who fulfil the role, usually on an overlapping basis. The supervisor’s role is likely to include:  Ensuring that staffing and skill levels are maintained 28/8/07 14:01 Page 113 Service Operation | ing as an escalation point where difficult or ntroversial calls are received duction of statistics and management reports presenting the Service Desk at meetings anging staff training and awareness sessions sing with senior management sing with Change Management forming briefings to Service Desk staff on changes deployments that may affect volumes at the Service sk isting analysts in providing first-line support when rkloads are high, or where additional experience is uired. e Desk analysts imary Service Desk analyst role is that of providing vel support through taking calls and handling the ng Incidents or Service Requests using the Incident ing and Request Fulfilment processes, in line with jectives described earlier. users users are discussed in detail in the section on e Desk staffing in paragraph 6.2.4 of the Service ion publication. In summary, this role will consist of ss users who act as liaison points with IT in general e Service Desk in particular. The role of the Super an be summarized as follows: facilitate communication between IT and the siness at an operational level reinforce expectations of users regarding what vice Levels have been agreed ff training for users in their area 113 Metrics should be established so that performance of the Service Desk can be evaluated at regular intervals. This is important to assess the health, maturity, efficiency, effectiveness and any opportunities to improve Service Desk operations. Metrics for Service Desk performance must be realistic and carefully chosen. It is common to select those metrics that are easily available and that may seem to be a possible indication of performance; however, this can be misleading. For example, the total number of calls received by the Service Desk is not in itself an indication of either good or bad performance and may in fact be caused by events completely outside the control of the Service Desk – for example a particularly busy period for the organization, or the release of a new version of a major corporate system. An increase in the number of calls to the Service Desk can indicate less reliable services over that period of time – but may also indicate increased user confidence in a Service Desk that is maturing, resulting in a higher likelihood that users will seek assistance rather than try to cope alone. For this type of metric to be reliable for reaching either conclusion, further comparison of previous periods for any Service Desk improvements implemented since the last measurement baseline, or service reliability Changes, Problems etc. to isolate the true cause for the increase is needed. Further analysis and more detailed metrics are therefore needed and must be examined over a period of time. These will include the call-handling statistics previously mentioned under telephony, and additionally:  The first-line resolution rate: the percentage of calls resolved at first line, without the need for escalation to other support groups. This is the figure often quoted 28/8/07 14:01 Page 114 Service Operation sk’s performance – and used for comparison poses with the performance of other Service Desks ut care is needed when making any comparisons erage time to resolve an Incident (when resolved at t line) erage time to escalate an Incident (where first-line olution is not possible) erage Service Desk cost of handling an Incident centage of customer or user updates conducted hin target times, as defined in SLA targets erage time to review and close a resolved call e number of calls broken down by time of day and y of week, combined with the average call-time tric, which is critical in determining the number of ff required. Technical Management cal Management refers to the groups, departments ms that provide technical expertise and overall ement of the IT Infrastructure. cal Management plays a dual role: s the custodian of technical knowledge and pertise related to managing the IT infrastructure. In s role, Technical Management ensures that the owledge required to design, test, manage and prove IT services is identified, developed and refined rovides the actual resources to support the ITSM ecycle. In this role Technical Management ensures t resources are effectively trained and deployed to sign, build, transition, operate and improve the hnology required to deliver and support IT services. forming these two roles, Technical Management is o ensure that the organization has access to the Service Transition and refined in Continual Service Improvement (see other ITIL publications in this series). Technical Management organization Technical Management is not normally provided by a single department or group. One or more technical support teams or departments will be needed to provide Technical Management and support for the IT infrastructure. In all but the smallest organizations, where a single combined team or department may suffice, separate teams or departments will be needed for each type of infrastructure being used. IT Operations Management consists of a number of technological areas. Each of these requires a specific set of skills to manage and operate it. Some skill sets are related and can be performed by generalists, whereas others are specific to a component, system or platform. The primary criterion of the Technical Management organizational structure is that of specialization or division of labour. The principle is that people are grouped according to their technical skill sets, and that these skill sets are determined by the technology that needs to be managed. This list provides some examples of typical Technical Management teams or departments:  Mainframe team or department – if one or more mainframe types are still being used by the organization  Server team or department – often split again by technology types (e.g. Unix server, Wintel server)  Storage team or department, responsible for the management of all data storage devices and media  Network support team or department, looking after the 28/8/07 14:01 Page 115 Service Operation | tabase team or department, responsible for the ation, maintenance and support of the anization’s databases ddleware team or department, responsible for the egration, testing and maintenance of all middleware use in the organization ectory services team or department, responsible for intaining access and rights to service elements in infrastructure ernet or web team or department, responsible for naging the availability and security of access to vers and content by external customers, users and tners ssaging team or department, responsible for e-mail vices based telephony team or department (e.g. VoIP).  Perform line-management for all team or department members. Technical analysts/architects This term refers to any staff member in Technical Management who performs the activities listed in paragraph 7.7.3, excluding the daily operational actions, which are performed by operators in either Technical or IT Operations Management. Based on this list of generic activities, the role of technical analysts and architects includes:  Working with users, sponsors, Application Management  Technical Management roles lowing roles are needed in the Technical ement areas.  ical managers/team-leaders nical manager or team-leader (depending upon the d/or importance of the team and the organization’s re and culture) may be needed for each of the cal teams or departments. The role will: e overall responsibility for leadership, control and cision-making for the technical team or department vide technical knowledge and leadership in the ecific technical areas covered by the team or partment ure necessary technical training, awareness and perience levels are maintained within the team or partment 115     and all other stakeholders to determine their evolving needs Working with Application Management and other areas in Technical Management to determine the highest level of system requirements needed to meet the requirements within budget and technology constraints Defining and maintaining knowledge about how systems are related and ensuring that dependencies are understood and managed accordingly Performing cost-benefit analyses to determine the most appropriate means to meet the stated requirements Developing operational models that will ensure optimal use of resources and the appropriate level of performance Ensuring that the infrastructure is configured to be effectively managed given the organization’s technology architecture, available skills and tools Ensuring the consistent and reliable performance of the infrastructure to deliver the required level of service to the business 28/8/07 14:01 Page 116 Service Operation ut into the design of configuration data required to nage and track the application effectively. IT OPERATIONS MANAGEMENT ness, the term ‘Operations Management’ is used to the department, group or team of people sible for performing the organization’s day-to-day ional activities – such as running the production line anufacturing environment or managing the ution centres and fleet movements within a logistics zation. ions Management generally has the following teristics: ere is activity to ensure that a device, system or cess is actually running or working (as opposed to ategy or planning) s is where plans are turned into actions e focus is on daily or shorter-term activities, hough it should be noted that these activities will nerally be performed and repeated over a relatively g period (as opposed to one-off project type ivities) ese activities are executed by specialized technical ff, who often have to undergo technical training to rn how to perform each activity ere is a focus on building repeatable, consistent ions that – if repeated frequently enough at the ht level of quality – will ensure the success of the eration s is where the actual value of the organization is ivered and measured ere is a dependency on investment in equipment or man resources or both  The value generated must exceed the cost of the investment and all other organizational overheads (such as management and marketing costs) if the business is to succeed. In a similar way, IT Operations Management can be defined as the function responsible for the ongoing management and maintenance of an organization’s IT infrastructure to ensure delivery of the agreed level of IT services to the business. IT Operations can be defined as the set of activities involved in the day-to-day running of the IT infrastructure for the purpose of delivering IT services at agreed levels to meet stated business objectives. 7.8.1 IT Operations Management role The role of Operations Management is to execute the ongoing activities and procedures required to manage and maintain the IT infrastructure so as to deliver and support IT services at the agreed levels. These are summarized here for completeness:  Operations control, which oversees the execution and monitoring of the operational activities and events in the IT infrastructure. This can be done with the assistance of an operations bridge or network operations centre. In addition to executing routine tasks from all technical areas, Operations Control also performs the following specific tasks:  Console management, which refers to defining central observation and monitoring capability and then using those consoles to exercise monitoring and control activities  Job scheduling, or the management of routine batch jobs or scripts  Backup and restore on behalf of all Technical and 28/8/07 14:01 Page 117 Service Operation | Print and output management for the collation and distribution of all centralized printing or electronic output Performance of maintenance activities on behalf of Technical or Application Management teams or departments cilities management, which refers to the nagement of the physical IT environment, typically ata centre or computer rooms and recovery sites ether with all the power and cooling equipment. ilities Management also includes the coordination arge-scale consolidation projects, e.g. data centre nsolidation or server consolidation projects. In some es the management of a data centre is outsourced, which case Facilities Management refers to the nagement of the outsourcing contract. bjectives of IT Operations Management include: intenance of the status quo to achieve stability of organization’s day-to-day processes and activities gular scrutiny and improvements to achieve proved service at reduced costs, while maintaining bility ift application of operational skills to diagnose and olve any IT operations failures that occur. APPLICATION MANAGEMENT ation Management is responsible for managing ations throughout their lifecycle. The Application ement function is performed by any department, or team involved in managing and supporting ional applications. Application Management also an important role in the design, testing and vement of applications that form part of IT services. 117 Application Management high-level role Application Management is to applications what Technical Management is to the IT infrastructure. Application Management plays a role in all applications, whether purchased or developed in-house. One of the key decisions that they contribute to is the decision of whether to buy an application or build it (this is discussed in detail in the Service Design publication). Once that decision is made, Application Management will play a dual role:  It is the custodian of technical knowledge and expertise related to managing applications. In this role Application Management, working together with Technical Management, ensures that the knowledge required to design, test, manage and improve IT services is identified, developed and refined  It provides the actual resources to support the ITSM Lifecycle. In this role, Application Management ensures that resources are effectively trained and deployed to design, build, transition, operate and improve the technology required to deliver and support IT services. By performing these two roles, Application Management is able to ensure that the organization has access to the right type and level of human resources to manage applications and thus to meet business objectives. This starts in Service Strategy and is expanded in Service Design, tested in Service Transition and refined in Continual Service Improvement (see other ITIL publications in this series). Part of this role is to ensure a balance between the skill level and the cost of these resources. In additional to these two high-level roles, Application Management also performs the following two specific roles: 28/8/07 14:01 Page 118 Service Operation vice Design process, but it is also a part of everyday mmunication with IT Operations Management as y seek to achieve stability and optimum formance e integration of the Application Management Lifecycle o the ITSM Lifecycle. This is discussed below. bjectives, activities and structures that enable ation Management to play these roles effectively are sed below.   cation Management objectives bjectives of Application Management are to support ganization’s business processes by helping to y functional and manageability requirements for ation software, and then to assist in the design and ment of those applications and the ongoing rt and improvement of those applications. objectives are achieved through: plications that are well designed, resilient and costective uring that the required functionality is available to hieve the required business outcome e organization of adequate technical skills to intain operational applications in optimum ndition ift use of technical skills to speedily diagnose and olve any technical failures that do occur. cation Management generic activities most Application Management teams or ments are dedicated to specific applications or sets lications, there are a number of activities which they n common (see Figure 7.7). These include:      phase, is expanded in detail in Service Design and is executed in Service Operation. Ongoing assessment and updating of these skills are done during Continual Service Improvement Initiating training programmes to develop and refine the skills in the appropriate Application Management resources and maintaining training records for these resources Recruiting or contracting resources with skills that cannot be developed internally, or where there are insufficient people to perform the required Application Management activities Design and delivery of end-user training. Training may be developed and delivered by either the Application Development or Application Management groups, or by a third party, but Application Management is responsible for ensuring that training is conducted as appropriate Insourcing for specific activities where the required skills are not available internally or in the open market, or where it is more cost-efficient to do so Definition of standards used in the design of new architectures and participation in the definition of application architectures during the Service Strategy processes Research and development of solutions that can help expand the Service Portfolio or which can be used to simplify or automate IT Operations, reduce costs or increase levels of IT service Involvement in the design and building of new services. All Application Management teams or departments will contribute to the design of the technical architecture and performance standards for IT services. In addition they will also be responsible for specifying the operational activities required to 28/8/07 14:01 Page 119 olvement in projects, not only during the Service sign process, but also for Continual Service provement or operational projects, such as operating tem upgrades, server consolidation projects or ysical moves signing and performing tests for the functionality, formance and manageability of IT services (bearing mind that testing should be controlled and formed by an independent tester – see Service nsition publication) ailability and Capacity Management are dependent Application Management for contributing to the sign of applications to meet the levels of service uired by the business. This means that modelling d workload forecasting are often done together with hnical and Application Management resources istance in assessing risk, identifying critical service d system dependencies and defining and plementing countermeasures naging vendors. Many Application Management partments or groups are the only ones who know ctly what is required of a vendor and how to asure and manage them. For this reason, many anizations rely on Application Management to nage contracts with vendors of specific applications. his is the case it is important to ensure that these ationships are managed as part of the SLM process olvement in definition of Event Management ndards and especially in the instrumentation of plications for the generation of meaningful events plication Management as a function provides the ources that execute the Problem Management cess. It is their technical expertise and knowledge t is used to diagnose and resolve Problems. It is also ir relationship with the vendors that is used to Service Operation | 119  Application Management resources will be involved in          defining coding systems that are used in Incident and Problem Management (e.g. Incident Categories) Application Management resources are used to support Problem Management in validating and maintaining the KEDB together with the Application Development teams Change Management relies on the technical knowledge and expertise to evaluate changes, and many changes will be built by Application Management teams Successful Release Management is dependent on involvement from Application Management staff. In fact they are frequently the drivers of the Release Management process for their applications Application Management will define, manage and maintain attributes and relationships of application CIs in the CMS Application Management is involved in the Continual Service Improvement processes, particularly in identifying opportunities for improvement and then in helping to evaluate alternative solutions Application Management ensures that all system and operating documentation is up to date and properly utilized. This includes ensuring that all design, management and user manuals are up to date and complete and that Application Management staff and users are familiar with their contents Collaboration with Technical Management on performing training needs analysis and maintaining skills inventories Assisting IT Financial Management to identify the cost of the ongoing management of applications Involvement in defining the operational activities 28/8/07 14:01 Page 120 Service Operation 7.7 Role of Application Management in the application lifecycle Requirements Design Optimize IT Service Management Strategy, Design, Transition and Improvement Build and Test Operate Deploy Application Development ut into, and maintenance of, software configuration icies gether with software development teams, the inition and maintenance of documentation related applications. These will include user manuals, ministration and management manuals, as well as y standard operating procedures (SOPs) required to nage operational aspects of the application. Application Management 7.9.1 Application Management roles Applications managers/team-leaders An applications manager or team-leader should be considered for each of the applications teams or departments. The role will:  Take overall responsibility for leadership, control and decision-making for the applications team or department  Provide technical knowledge and leadership in the 28/8/07 14:01 Page 121 ure necessary technical training, awareness and perience levels are maintained within the team or partment relevant to the applications being pported and processes being used olve ongoing communication with users and tomers regarding application performance and olving requirements of the business port to senior management on all issues relevant to applications being supported form line-management for all team or department mbers. cations analyst/architect ation analysts and architects are responsible for ng requirements to application specifications. c activities include: rking with users, sponsors and all other stakeholders determine their evolving needs rking with Technical Management to determine the hest level of system requirements needed to meet requirements within budget and technology nstraints forming cost-benefit analyses to determine the st appropriate means to meet the stated uirement veloping operational models that will ensure imal use of resources and the appropriate level of formance uring that applications are designed to be ectively managed given the organization’s hnology architecture, available skills and tools veloping and maintaining standards for application ng, performance modelling etc. Service Operation | 121  Generating a set of acceptance test requirements, together with the designers, test engineers and the user, which determine that all of the high-level requirements have been met, in both functionality and manageability  Input into the design of configuration data required to manage and track the application effectively. 7.10 SERVICE OPERATION AND PROJECT MANAGEMENT Because Service Operation is generally viewed as ‘business as usual’ and often focused on executing defined procedures in a standard way, there is a tendency not to use project management processes when they would in fact be appropriate. For example, major infrastructure upgrades, or the deployment of new or changed procedures, are significant tasks where formal project management can be used to improve control and manage costs/resources. Using project management to manage these types of activity would have the following benefits:  The project benefits are clearly stated and agreed  There is more visibility of what is being done and how it is being managed, which makes it easier for other IT groups and the business to quantify the contributions made by operational teams  This in turn makes it easier to obtain funding for projects that have traditionally been difficult to cost justify  Greater consistency and improved quality  Achievement of objectives results in higher credibility for operational groups. 28/8/07 14:01 Page 122 Service Operation ASSESSING AND MANAGING RISK IN SERVICE OPERATION 7.12 OPERATIONAL STAFF IN SERVICE DESIGN AND TRANSITION will be a number of occasions where it is imperative k assessment to Service Operation is quickly aken and acted upon. All IT groups will be involved during Service Design and Service transition to ensure that new components or services are designed, tested and implemented to provide the correct levels of functionality, usability, availability, capacity etc. ost obvious area is in assessing the risk of potential es or Known Errors (already covered elsewhere) but ition Service Operation staff may need to be ed in assessing the risk and impact of: ures, or potential failures – either reported by Event nagement or Incident/Problem Management, or rnings raised by manufacturers, suppliers or ntractors w projects that will ultimately result in delivery into live environment vironmental risk (encompassing IT Service ntinuity-type risks to the physical environment and ale as well as political, commercial or industrialations related risks) ppliers, particularly where new suppliers are involved where key service components are under the ntrol of third parties urity risks – both theoretical or actual arising from urity related incidents or events w customers/services to be supported. Additionally, Service Operation staff must be involved during the early stages of Service Design and Service Transition to ensure that when new services reach the live environment they are fit for purpose, from a Service Operation perspective, and are supportable in the future. In this context, ‘supportable’ means:  Capable of being supported from a technical and     operational viewpoint from within existing or pre-agreed additional resources and skills levels Without adverse impact on other existing technical or operational working practices, processes or schedules Without any unexpected operational costs or ongoing or escalating support expenditure Without any unexpected contractual or legal complications No complex support paths between multiple support departments of third-party organizations. 28/8/07 14:01 Page 123 28/8/07 14:01 Page 124