In this section, I provide a basic introduction for each of the ITIL best practice categories and offer more granular outlines of possible service improvement initiatives. Many of the suggestions are derived from the proposal selection criteria advanced in the previous section.

Incident Management (sometimes referred to as Event Management) will be one of the first processes an organization will implement. Indeed, all organizations will have some capability to handle Incidents. One of the major insights that ITIL offers is its' pre-occupation with restoring service as an exercise separate and distinct from identifying and solving the underlying root cause of the incident. The logic inherent in this is simple and sublime, but one that requires a consistent and dedicated application by the organization because there will be a natural tendency to seek out root cause during the investigation of the incident. Unfortunately, all too often doing so lengthens the time to restore services. Documented, easily available "workarounds" which can be implemented quickly to restore service as quickly as possible are the stock and trade of good Incident Management. At the same time that Incident Management is seeking to restore a service to defined operating parameters, Availability and Problem Management are working to ensure that problems and "Known Errors" are removed from the infrastructure - so they do not re-occur. Proactive measures by the organizations responsible for these areas will reduce the workload on Incident Management teams. Mature organizations seek to re-direct activity from addressing incidents to removing their existence in the first place. Ensuring quality control in recording information on Incident Tickets provides the data needed to undertake this kind of analysis. Accurate and complete information is, therefore, an important quality of service (QoS) consideration which pays dividends to organizations capable of effectively translating this data into concrete service improvement initiatives. Incident Management Process

Possible Incident Management Improvement Initiatives

• Establish Incident Database - At the most basic level an organization needs the ability to record an incident in order to manage the recovery of any service degradation and to avoid duplication of effort around the reporting of separate instances of the same incident. More mature organizations might improve their documentation and categorization of incidents in order to expedite subsequent restorations due to recurring common cause(s) (ie. identify Known Errors). When the primary purpose of the incident database is only "recording" incidents to manage the immediate service issue the database does not need to be particularly sophisticated and might be developed in using inexpensive software such as MS Access or MS Outlook (leveraging existing investments in these products)^N.
• Establish restoration service targets - Establish service performance targets based upon the assessed severity of the Incident. Severities are assigned based upon relative perceived importance of infrastructure component and urgency for restoration at time of outage (eg., peak service time vs off-hours)
• Create Knowledge Bases - Record recovery methods on the Incident Ticket for restorations. Follow this up with recording diagnostics, Known Errors, restoration methods, etc in an accessible location (eg., web address).
• Establish Major Incident Process - Develop a dedicated and consistent process for handling major incidents^N. Initially, this function might be performed by an Incident Analyst or Restoration Officer. In larger operations, however, this may be the responsibility of Availability Management who have overall responsibility for the availability of systems throughout the enterprise.
• Implement Incident Ticket Quality Assurance - Review Incident Tickets for completeness and accuracy. This provides insurance that the incident has been RESOLVED properly and has a positive affect on Customer satisfaction. The Incident database becomes a reliable tool for analysis rather than only an archive of past incidents. This enhances the ability of Availability Management to review stages of the Incident lifecycle for bottlenecks in an attempt to increase overall infrastructure availability
• Evaluate Incident Lifecycle - Decompose the Incident Management process into lifecycle stages. Ensure that the Incident Ticket logs entry and exit from each stage of the lifecycle. The provision of operational data permits operational analysis of the process to identify consistent bottlenecks and problems in order to decrease recovery time and enhance overall availability. This provides additional information for analysis and review of Problems thereby increasing the effectiveness and efficiency of Root Cause Analysis by Problem Management
• CMDB - Incident Linkage - Link incidents consistently with Configuration Items thereby facilitating improved identification of impact and permitting better prioritization amongst competing restoration tasks. This produces improved quality in the Incident database for Problem Management (identification of problem devices), Availability Management (extrapolations to assess potential failures) and Capacity (extrapolations for capacity issues).
• Incident resolution governed by SLO - Negotiate and publish service restoration objectives. The timeframe for resolution of incidents is governed strictly by Service Level Objectives (SLO) negotiated between lines of business and the IT Provider. Incidents are classified by severity and priority with established levels dictating their priority consideration as set out in service level objectives for that classification. As well, alerts are issued when resolution activity is approaching the established deadlines. This triggers escalation procedures designed to provide additional resources to the restoration effort so that the organization can be more successful in honouring service commitments to client groups.
• Review Incident Lifecycle - It is important to recognize that every Incident passes through a number of stages. This 'lifecycle' view provides an important framework in determining requirements for incident detection, management reporting, diagnostic data capture and for securing needed tools for diagnosis and verification that IT Service has been restored.

Service Desk

In small organization the distinction between Incident Management, the Service Desk and Problem Management may be less pronounced that in larger enterprises. In small organization a single person might perform all three roles. The Service Desk should be the first line of contact for daily user interaction with the IT Department. They specialize in a quick turn-around of the most frequent interactions. Typically these will include service requests, requests for information and recurring incidents which have known parameters and solutions. These functions are subject to automation by way of online request systems, online knowledge bases and bulletin boards to keep user informed of outages. However, if the organization chooses to rely heavily upon automated service desk functionality care must be taken to ensure that the important roles of communication traffic controller and initial Ticket Owner are re-assigned accordingly within the Incident Management System. Service Desk Process

Possible Service Desk Management Improvement Initiatives

• Creation of SPOC - Initiate Incident reporting through a single point of contact. The source may be physically distributed and may be composed of multiple Help Desks constituted to form a single 'virtual' help desk.
• Customer Communications - Establish communication policies and procedures designed to ensure customers and stakeholders are kept continually informed of service requests and outages - pending, in-progress and completed. This allows Users to plan activities around a service disruption on the basis of best estimate of a restoration time and allows them to mitigate the worst effects of an outage. It might also help ensure needed resources are on alert in the event the incident needs additional resources.
• Service Request process description - Develop processes for fulfilling repetitive service requests^N. Typical service requests include:
  • new employee technology setup
  • request for information - HOWTO
  • password setup
  • hardware / software Move, Add or Change (MAC)
  Doing this will permit the organization to become more efficient over a range of repetitive tasks.
• Monitor customer satisfaction - Aligning customer perception and satisfaction is paramount to the success of any support operation. It is the customer's perception, rather than availability statistics or transaction rates, that, in the end, defines whether the Service Desk is fulfilling its' vital roles of first point of contact and communications conduit. Satisfaction surveys are an excellent method of monitoring customer perception and expectation and can be used a powerful marketing tool. The Service Desk should conduct regular surveys of customer satisfaction, and, in addition to reporting the results, develop recommendations for improvement based upon the survey data.
• Service Request Reference to Service Catalogue - Develop an online service catalogue which the Customer can use to order services. The catalogue should include items on HOW TO ACCESS a service with reference to the Service Desk as the point of initiation.
• Self-Help SR Initiation - Every company would like to reduce the cost of customer service. Migrating service-oriented calls and emails to self-service channels is a low-cost, high-impact way to achieve this goal
• Online KB Access - Access to online Knowledge Base information describing common issues, workarounds, existing known errors and problems within local environment

Change Management

Poorly executed releases and changes are a primary cause of incidents. Therefore, improvements in change management processes can result in a quick return on investment for the organization. The evidence linking infrastructure changes to user incidents is large and conclusive R. Many organizations< however, are reluctant to undertake basic changes in this area. Doing so requires the many distinct platforms (eg., mainframe, desktop, operating environments, major business applications) to relinquish elements of control to a central body. The organizational "silo" in this case loses some control over the timing and manner in which they make changes, while many of the benefits are realized in other areas of the enterprise. Whenever gains accrue to a different organizational unit from the one incurring the costs, senior management must be involved to approve and direct any financial re-alignment or to enforce the change in responsibility on behalf of the overall organization. In many organizations separate and distinct Change Management forums proliferate in subject areas (eg., servers, desktop, application areas, etc.). There may even be separate Help Desks to record and initiate activity - each doing their own thing, unmindful of the cascading affects that a change to their area may have on other infrastructure elements or other business areas. Consolidation of Change Schedules is one of the first change management procedures which should be implemented. This should be quickly followed by either consolidating Change Advisory forums or ensuring proper communications amongst them. A Configuration Management Database will enhance Change Management's ability to analyze the effect of changes by quickly displaying the potential impact of a change - including other forums and areas affected. Any information which improves the organization's ability to review the risks associated with a change will have a positive affects. Change Management Process

Possible Change Management Improvement Initiatives

• Consolidated Change Schedule - Consolidate all Change calendars used throughout the organization into a single event calendar. This ensures that Changes are coordinated across the enterprise and that scheduling will take into account other changes. It provides more complete information on pending changes and reduces any risks resulting from scheduling conflicts (CI interdependencies, time and resource availabilities, overall structural complexity in the infrastructure). The Calendar can also provide an important data source for assessing past change events and their interrelationships.
• Develop RfC and CAB structures - Develop a standard Request for Change template to be submitted and appropriate change approval procedures. These procedures may vary with the size and complexity of the organization and the deemed importance to the organization of changes. Procedures might include:
  • peer review of changes
  • manager sign-off of changes
  • local and corporate change Advisory Board (CAB)review
  • executive management review and sign-off

  Combination of different boards might be used depending upon the assigned importance and risk associated with the change.

• Qualitative risk assessment process - Risks are primarily assessed by reviewing their assessment of risks as described on the RfC. The ability to properly assess risks associated with changes is determined by:
  • the accuracy and completeness of the information recorded on the RfC
  • the breadth of infrastructure representation involved in the review
  • the inclusiveness and description of the upcoming change schedule (review of change inter-dependencies)
  • the quality of the review process
• CMDB Reference - The ability to assess the risks of a change is enhanced with the existence of a CMDB which describes the interdependencies of CIs in the infrastructure. With a CMDB reference, Change Management is able to determine with increased precision, what and how CIs are affected. Change Management will be responsible for ensuring that successfully implemented Changes have their associated CIs recorded or modified in the CMDB^N.
• CM documentation libraries - Policies and procedures designed to integrate process repository into Change Management. These would include:
  • rules for checking out documentation - including versioning
  • an RfC (or derivative form outlining need for document revision)
  • rules governing review of revised documentation
  • acceptance criteria
  • rules governing checking in of new documentation containing revisions
• Pre-approvals Library - Recurrent low risk changes are pre-approved through an initial presentation of procedures to the followed for its' fulfillment^N. These procedures are kept in the documentation repository (part of CMDB) and, as long as the prescribed procedures are adhered to, the change needs only to be recorded and considered in the Change Calendar. Any deviations or abnormalities associated with following the procedures will require clearance through Change Management (which, because of their continuing classification as low risk can usually be cleared by a Corporate or Local Change Manager).

Problem Management

An important insight advanced by ITIL is the distinction to be drawn between Incident and Problem Management and the recognition of the distinct goals, governance, processes and procedures separating the two services. Problem Management engages more analytic, quantitative procedures which are often found in more mature organizationsN. Initiating Problem Management practices will challenge organizations unwilling or incapable of assuming a more proactive or predictive view of the infrastructure. Sometimes an organization will embrace Problem Management, but lack the necessary management commitment or resources to devote to the effort. In these situations attention will almost always be redirected to fire-fighting (ie, urgent, immediate) activities the moment any resourcing pressures arise. Nonetheless, there is strong evidence that efforts spent in identifying and removing infrastructure faults will produce significant benefit to the infrastructure's overall stability and have a positive rate of return on the investment. Yet, like Change Management, issues can arise with regard to the distribution of the rewards. It is in the nature of process re-engineering undertakings that the realization of benefits will often accrue to a different part of the organization than where the costs are incurred. Without supporting benefit-cost data and in the absence of senior management support (above the organizations incurring the costs and benefits) the promise of benefits may not be sufficient to overcome bureaucratic hurdles.

Problem Management Process

Possible Problem Management Improvement Initiatives

• Incident Referral - Incidents which are restored using a workaround will be referred to Problem Management for offline consideration. Problem Management undertakes to determine the root cause of the incident in an attempt to achieve a permanent resolution for the incident so that it will not re-occur. The benefits of a separation of Problem analysis from system restoration will result to an improvement to overall availability by achieving speedier (though temporary) restoration of high impact services. It also provides the ability to attend to the Problem using structured techniques and without interference or pressures resulting from the pressure of restoring service. These techniques include specialized skills in RCA. In organizations with many unresolved errors in the infrastructure, procedures may be required to prioritize Problems in a manner which best ensures that the highest-impact of them get early considered.

• Problem Management database - Selection, creation, population of Problem Management database identifying Known problems and errors in the infrastructure

• Error Control - With the availability of a reliable data source on the existence of Known Errors and Problems in the infrastructure, PM can begin to proactively investigate, analysis and systematically control their adverse affects.

• Predictive PM - Predictive PM activities focus on identifying and resolving Problems and Known Errors before Incidents occur. Problem prevention ranges from prevention of individual problems, such as repeated difficulties with a particular feature of a system, through to strategic decisions (eg., review of MTBF of infrastructure components and a strategic replacement or mirroring strategy to reduce the chance and/or impact of a failure). The latter may require major cost to implement, such as investment in a better network. Problem prevention also includes information being given to Customers that obviates the need to ask for assistance in the future. Analysis focuses on providing recommendations on improvements for the Problem solvers. Problem analysis reports provide information for improving service quality. The objective is to identify potentially 'unstable' components of an IT infrastructure and investigate the reasons for the instabilities.

Configuration Management

Because there is a shared corporate obligation to monitor the assets of an organization, most corporations will have developed an Asset Management system and have an Asset database describing the financial attributes of items. This asset, while highly useful for tracking software licensing and machine movement does not describe the inter-relationships of IT devices within the infrastructure. These dependencies are important for developing incident containment strategies and assessing the impact of releases and changes. The Asset database must either be amended to include additional fields (due to the nature of inter-relationships most financial databases are ill-suited for this extension) or a CMDB purchased or developed. Ideally, asset data can be migrated from the Asset system into the CMDB, or, alternatively both systems may continue to operate with bridges built between them - a logical CMDB. Many organization have purchased or built a CMDB and populated it only to find that these task are easy compared to keeping the data accurate and current. Doing this requires a concerted organization commitment. Discovery Tools can be used to search and discover infrastructure components (ie. Configuration Items). Using these tools to perform monthly updates of the CMDB is a low cost way to keep the CMDB accurate. It may not, however, be easy to update other important fields so that items pertaining to any individual Configuration Item may be in varying states of currency. An important consideration in establishing a CMDB is the level of granularity for which Configuration Items should be described. The fewer the number the easier the maintenance - but, the less useful the database will be. A good rule of thumb is to get control of the organization's major application areas (where the business impact of service outage is the most severe). This data can then be used to support Incident and Change Management processes. The organization can then continue to enhance the CMDB's inclusiveness until a point of diminishing returns occurs where further infrastructure elements (coverage) and/or details on each item (granularity) fail to be worth the additional effort in maintaining them. Configuration Management Process

Possible Configuration Management Improvement Initiatives

• Tool Selection - Unlike other process areas, tool selection will have a significant impact upon the operation of Configuration Management. Obtaining a database to record configuration items can be a significant expenditure. Additionally, the CMDB is central to a mature ITSM implementation because it represents the heart of the information view of the organization. Reloading into another system and adding field and functionality at a later time are significant undertakings and will lead to service disruptions during the process. To a large extent it will determine who and how configuration items are loaded, modified over their lifecycle and retired. For these reasons, you need to get it right the first time. Consequently, the selection of a Configuration tool should be decided upon early.

  This does not mean that all the tools features need be implemented immediately. Populating the CMDB may be difficult, but it is a minor problem compared to keeping the information current and accurate. The logic is to start small and build upon your experience.

• Load Asset Information - Most organizations will have some Asset information retained by Finance or retained in individual spreadsheets by lines of business. The information from these source should be consolidated into the selected CMDB. At a minimum, loading asset information extents the use of this information to the Service Desk. For organizations lacking this information it permits new capabilities in terms of licence rationalization and warranty provisioning.

• Load Basic CMDB for Change Mgmt - Loading Asset information allows the organization to deliver an existing service in new, more useful ways. Augment this information with additional fields geared to the Change Management process (ie. the relationships between a Configuration Item such as a server and other CI's such as applications). The initial information should encompass major application attributes of vital importance to business operations. A rule of thumb would be to find the 20% of items which would result in 80% of the major outages. This provides basic experience with Configuration Management and provides important information to the Change Management.

• Operate CMDB - At this point is important to have a period of stability for the operation of Configuration and Change Management processes in order to assess the successes and improvements needed in the processes.

• CMDB Expansion - Populate the CMDB with the configuration information for the remaining assets not configured as part of the previous stage. This extends the benefits and completes the information of how one item relates to another. Since the Service Desk is the usual point of entry for changes in Configuration Items it should be charged with updating CIs resultant from service request fulfillment.

  Note the following caution.

  "the jury's out on whether CMDBs can be made to work, at least in their holistic, 'framework' sense. Most successful CMDB implementations to date are targeted at a subset of possible functions and specific management processes and applications." Dennis Drogseth, Vice President, Enterprise Management Associates, quoted in The Fastest Payback for Your ITIL Investment, Integrien, White Paper, October, 2005

• Validate CMDB using discovery tools - Use discovery tools to validate the accuracy of the CMDB.

  Discovery Tools might also be employed to update the CMDB. At a minimum all anomalies identified should be investigated since they might indicate improperly implemented Changes (which are reported to Change Management - an important metric for them).

Release Management

Many organizations will confuse Release and Change Management. Both processes are concerned with introducing changes to the "known and trusted environment" and often Release Boards are established to manage changes associated with specific applications. Change Management should be the final arbitrator of what gets introduced into the infrastructure. Release Management is like a furniture mover. Their prime task is to ensure a smooth migration of furniture (ie. code and machinery) from one location to another (ie., test environments into the production environment). Their tools are project management and migration tools (such as Microsoft Solution Framework). Their jobs are frequently large, typically involving multiple milestones and interactions with Change Management.

Release Management Process

Possible Release Management Improvement Initiatives

• Establish Release Policy - A Release policy document for an organization should be produced to clarify the roles and responsibilities for Release Management. There may be one document per organization, or an umbrella set of guidelines and specific details for each supported system or IT service. The Release Policy may be part of the organization's overall Change Management plan.

  A Release Policy is revised or extended when an organization adopts a new technical infrastructure. Piloting of new Release Management procedures should form part of a project to implement a new infrastructure. For example, a new approach to releasing software may need to be developed when an organization decides to adopt a new hardware or software platform. This may be something as small as a new programming language or as major as a completely new hardware platform with its own operating system, or a network management system.

• Develop Definitive Software Library - The 'Definitive Software Library (DSL) is the term used to describe a secure compound in which the definitive authorized versions of all software CIs are stored and protected. In reality, this single storage area may consist of one or more software libraries or file-storage areas. It contains the master copy of all controlled software in the organization. The DSL should include definitive copies of purchased software (along with licence documents or information), as well as software developed on site. Master copies of controlled documentation for a system will also be stored in the DSL in electronic form.

  The exact configuration of the DSL that is required for Release Management should be defined before development commences. The DSL forms part of the Release Policy or Change and Configuration Management plan for the organization.

• Roll-out Planning - Procedures, templates and guidance should be planned to enable the central Release Management staff to take products from application groups and projects, and then to release the software and hardware efficiently and effectively.

• User Acceptance Procedures - Rigorous assurance that User is satisfied with the amount of testing done before a release is made into the infrastructure. These assurances should be an item in any SLA with the Customer. The possible levels of testing required in a User Acceptance Test Plan are:
  • New System Test: where the application to be tested is entirely new (is not an enhancement or system upgrade).
  • Regression Test: where the amount of change in an existing application requires a full system retest.
  • Limited Test: where the amount of change in an existing application requires only change specific testing.

• Defect List Mgmt - Institute procedures to ensure that defects are rigorously measured and tracked during development phases and all defects not fixed at the time of the release are re-constituted as Known Problems or Known Errors (root cause known but solution not yet implemented). Wherever possible, additional information on workarounds should accompany the list as a contingency action for the occurrence of an incident. The Defect List is made known to the service desk (potential source of incidents) and responsibility is transferred to Problem Management who have responsible for tracking Errors in the infrastructure. The movement of defects should be explicitly mentioned in the Release Policy.

Service Level Management

The quality of a Service Level Management process will determine how well the IT Service provider promotes its' client's interests. The definitive document in this process is the SLA. It replaces anecdote with fact, and in doing so, provides a more solid basis for discussion and negotiation between service provider and service customer(s). It positions the IT Department as a seller of services at defined costs, therein promoting a more business-focused relationship. Many organizations have developed SLAs which have failed to deliver on their promise because the organization lacks the ability to monitor and report consistently on the performance of the included services. Quickly, the SLA documents get ignored - just another piece of paper. The approach advocated here recognizes the inherent difficulties associated with negotiating the multi-varied relationships involved. Much internal discussion within the IT division (ie. getting the house in order) should precede negotiating service parameters and levels with business units. This can be accomplished through the publication of a Service Catalogue by the IT provider - listing available services, service options and costs. Unlike many other ITIL areas which can be targeted for a generalized implementation in concert with the achievement of a specific level of organizational maturity, there are aspects of Service Level Management at all maturity levels. Few organizations will achieve a Level 5 implementation - optimized service provision through continuous adjustment based upon the provision of real-time information of performance. Many, however, can put in place key elements, reflective of the organization's level of maturity at any point in time. These elements will establish and promote improvements in the relationship between IT provider and customer and establish key enablers to implement other service improvement initiatives. Service Level Management Process

Possible Service Level Management Improvement Initiatives

• Establish Basic Service Catalogue^R - A basic catalogue develops the service hierarchy based upon a logical framework (eg., existing org structure, Utility metaphor, COBIT governance model). For each service^N the following elements are described:
  • a description of the service offering
  • a description of to whom the service is offered and how it is accessed
  • activities associated with the service (note: activities can themselves become services depending upon the level of granularity desired - the acid test will always be whether or not the offering has a distinct recognition by the Customer base)
  • Offered variations in the service provided
  • service participants involved in the delivery of the service (the service chain)
  • contact information

• Develop & Pilot Prototype Operational Level Agreement - A good example is the NEW EMPLOYEE SERVICE - that suite of services provided when a new employee joins the company. This is an excellent example because...
  • it involves a known and easily identifiable service chain (since it has been institutionalized through the Service Request process)
  • is usually initiated through the Service Desk (though it may be automated)
  • requires coordination and "hand-off" to fulfill the service
  • involves existing and well articulated participants

  Based on the service chain associated with the NEW Employee service develop an Operational Level Agreement between the participants and the Senior Leadership Team of the Division offering the service.

• Develop SLA OLA - UC Architecture - Choose on basic SLA structure (architecture):
  • service based - an SLA for a particular service written to pertain to the entire client base
  • customer based - an SLA targeting a specific line of business and covering all services provided
  • multi-level SLA - a mixture of the above two

  The third type is often the most efficient. It can outline a broad spectrum of services offered to the entire customer base for generalized services (including level variations - ie. silver, gold, platinum). Then more specialized or targeted services such as specific application ideosyncratic factors can be offered as addenda or side deals to affected clients^N.

• Pilot Memorandum of Understanding (MOU) - Develop Memorandum of Understanding for service delivery. The MOU would itemize roles and responsibilities and describe services which are delivered but would not contain financial or performance data. This can provide a quick win by and can "institutionalize" the documentation of relationships while skirting more difficult questions of performance and financing that may prove challenging for many organizations.

• Describe participant obligations in the delivery of services - Develop Operational Level Objectives for all participants in the service chain as described by their service chains maintained in the service catalogue. This requires that many of the service parameters be negotiated, particularly around "hand-offs" (eg. length of time - elapsed and latent involved in the hand-off between participants).

  The exercise may be coordinated by a Service Manager who, based upon the collected OLOs, develops a composite Service Level Objectives. This measure is often contrasted with industry benchmarks. Discrepancies require explanation. The objective is to advance SLOs which describe expected (and perhaps stretch) service performances.

  All current contracts with third party providers should be reviewed for their internal consistency with the OLOs and SLOs. Performance requirement deficiencies should be noted and remedied at the earliest contract renewal opportunity.

• Establish OLAs & UCs - OLOs should set out serialized, specific back-to-back targets for support groups that underpin the targets included in SLAs. For example, if the SLA includes overall time to respond and fix targets for Incidents (per priority level), then the OLAs should include targets for the each of the elements in the support chain (target for the Service Desk to answer calls, escalate etc, targets for Network Support to start to investigate and to resolve network related errors assigned to them). In addition, overall support hours should be stipulated for all groups that support the required service Availability times in the SLA. If special procedures exist for contacted staff (e.g. after hours telephone support) these must also be documented.

  It should be understood that the Incident resolution targets included in SLAs will typically not mirror targets included in contracts or OLAs. SLA targets will include performance specs for all process steps in the support cycle (e.g. detection time, Service Desk logging time, escalation time, referral time between groups etc, Service Desk review and closure time - as well as the actual time fixing the failure). Each OLO target will have achievement parameters (eg., achieved 95% of the time over the course of a month). The sum of the achievement parameters for all process stages are not multiplicative (ie., 95% times 95% times 95%). This simply implies that over the course of an entire service chain it is not expected that a service delay will exist at each stage. Rather, one might expect that a service deficiency may occur at one of the stages 5% of the time - but we don't necessarily know at which stage the delay will be experienced.

  Before committing to SLAs, it is therefore important that existing contractual arrangements are investigated and where necessary, upgraded. This is likely to incur additional costs, which must either be absorbed by IT, or passed on to the Customer. In the latter case the Customer must agree to this, or the more relaxed targets in existing contracts should be agreed for inclusion in SLAs.

  OLAs should be monitored against these targets and feedback given to the Managers of the support groups. This highlights potential problem areas, which may need to be addressed internally or by a further review of the SLA.

• Develop Service Level Objectives - Develop the Service Level Objectives based upon the composite of OLO defined in the respective service chains. This exercise involves more than just adding the response times associated with each stage in the service chain. Doing this would likely provide response targets out of line with industry best practices. Each stage of the process must be reviewed in the context of its' distribution (ie. earliest possible, mean and medium time, latest possible) and then statistically analyzed against the entire service chain to derive overall earliest, mean and latest response times. These times are then reviewed against industry standards and major deviations explained.

• Evaluate Memoranda of Understanding (MOU) - Evaluate success of MOU as a devise to establish written obligations of participants.

• Service Catalogue Upgrade - Extend functionality of Service Catalogue to include:
  • Financial service information - Establish the models for accurate internal pricing. Systematically gather both tangible and intangible costs incurred to deliver a service. Provide pricing in advance, but resist the temptation to over-simplify the structure. Indicate any charges for services performed outside of normal parameters or durations.
  • Service Level Objectives - cite performance objectives including assumptions implicit in their usage
  • Service Chain Descriptions - Outline participants in the delivery of the service and their obligations to each other (and the overall corporate entity which collectively might represent those obligations.
  • Performance Reporting - real-time reporting of actual performance against Objective targets^N.

• Collect Service Level Requirements - Once the SLA structure has been agreed upon, a first SLA can be drafted. It is advisable to involve business clients from the outset, but to start discussions a first outline draft can be advanced to build upon. Be careful though not to go too far and appear to be presenting the Client with mandated services - they should have some input into the kind and quality of the service to be offered.

  It can be difficult to draw out requirements, as the business may not know what they want - especially if this is their initial introduction to the concept of negotiated service. They may need help in understanding and defining their needs. Be aware that the requirements initially expressed may not be those ultimately agreed - they are more likely to change where charging is in place (since the Business Customer may have to make compromises based upon the costs of delivering the service). Several iterations of negotiations may be required before an affordable balance is struck between what is desired and what is achievable and affordable.

  Many organizations have found it valuable to produce a pro-forma that can be used as a starting point for all SLAs. The pro-forma can often be developed alongside the pilot SLA.

• Develop Service Level Agreements - With the existence of a Service Catalogue the SLA becomes an expression of the agreement between parties as to the levels of service to be offered as described in the catalogue. This has the effect of focusing negotiation and removing repetition from the documentation. The SLA becomes the expression of that negotiation. The wording of SLAs should be clear and concise and leave no room for ambiguity.

  Using the draft agreement as a basis, negotiations must be held with the Customer(s), or Customer representatives to finalize the contents of the SLA and the initial service level targets, and with the service providers to ensure that these are achievable.

• Manage Customer Relationship - Whether charged for IT services or not, the customer's impression of the quality and quantity of services is a barometer of success. IT must recognize that the process of setting customer expectations is multi-dimensional. To begin with, the customer expects to be more productive through the utilization of the services that IT provides. This sets expectations by IT staff for reliability, availability, cost effectiveness, and so on. The second set of customer expectations, and one that is frequently overlooked, is the customer's responsibility in the process. The customer should be aware that they are responsible for effectively utilizing the technology at their disposal by becoming more proficient through education and experience. They also are obligated to report performance issues appropriately as specified in SLAs and be a proactive advocate and participant within the overall SLM process. They must understand and accept the agreed-to guidelines, timeframes, and limitations of the offered services.

  Where charges are being made for the services provided, customer demands can be expected to be more reasonable than in environments where there is no charge mechanism in place. Where direct charges are not made, the support of senior business managers must be enlisted to ensure that excessive or unrealistic demands are not placed upon the IT provider by any individual customer group.

• SLM Basic Reporting - Nothing should be included in an SLA unless it can be effectively monitored and measured at an agreed point. Inclusion of items that cannot be effectively monitored almost always result in disputes and eventual loss of faith in the SLM process.

  Existing monitoring capabilities should be reviewed and upgraded as necessary. Ideally this should be done ahead of, or in parallel with, the drafting of SLAs, so that monitoring can be in place to assist with the validation of proposed targets. It is essential that monitoring matches the Customer's true perception of the service - in practice achieving this is often elusive.

  Reporting can be broadly divided into two categories: real-time and periodic. Reviewing and improving services is the validation of Service Level Management^N. Because it implies performance (and, hence, internal compensation and rewards) performance reporting is sensitive and may imply major cultural and organizational shifts. It should, therefore, be approached cautiously and in stages corresponding to increasing organizational maturity capabilities. This usually implies a movement from ad hoc, to regular, to automated to real-time reporting^N.

  Real-time reporting should be the ultimate goal for service-level reporting. On a real-time basis, clients need to know the status (i.e., health) of the service. A simple, positive confirmation that the service is believed to be functioning normally is often sufficient. Some companies with SLM tools denote this status check with an icon similar to a stop light, with red, amber and green lights, with the obvious meanings.

• Review Service Level Management Process - Review SLM process in conjunction with other ITIL processes for internal consistency and general harmony. The results of the review should include specific recommendations for improvement. A basic objective of the review is assess the organization's readiness to proceed towards Level 4 maturity processes.

• Quantitative SLM - Few organization will seek (or even need) to establish this kind of sophisticated reporting. In most organizations, Key Goal and Performance Indicators are used to measure the overall performance of the organization - the provisioning of IT services contribute to but are not always considered central to those the realization of business strategic goals and objectives. However, for organizations whose business is IT provision KGI and KPI may be critical. Such organizations must have IT processes greater levels of maturity since their survival is determined by them. To these organizations, the provision of IT services is the primary revenue generating vehicle (and not a supporting function). These practices reflect Level 4 and or 5 maturities - the performance of processes is controlled using statistical and other quantitative techniques, and is quantitatively predictable. At maturity level 3, processes are only qualitatively predictable.

  The expected process performance can be used in establishing the project's quality and process-performance objectives and can be used as a baseline against which actual project performance can be compared. This information is used to quantitatively manage the project. Each quantitatively managed project, in turn, provides actual performance results that become a part of the baseline data for the organizational process assets. The associated process performance models are used to represent past and current process performance and to predict future results of the process. For example, the latent defects in the delivered product can be predicted using Six Sigma techniques of defects identified during service verification activities.

  When the organization has measures, data, and analytic techniques for critical services and service characteristics, it is able to do the following:

  • Determine whether services are repeatedly achieving their SLOs and have stable trends (i.e., are predictable)
  • Identify bottlenecks where the performance is within natural bounds that are consistent across service chain boundaries
  • Establish criteria for identifying whether a service or service activity should be statistically managed, and determine pertinent measures and analytic techniques to be used in such management
  • Identify service activities that show unusual (e.g., sporadic or unpredictable) behavior
  • Identify any activities and processes that can be improved in the organization's set of standard processes
  • Identify the implementation of a defined process which performs best and recommend other arenas for its' adoption in the organization (ie. building on success)

  A key to proliferating organizational successes is the establishment and maintenance of baselines and models which characterize the expected process performance of the organization's set of standard processes.

  To undertake quantitative SLM requires an enhanced ability to measure Availability in real-time, so there is a pre-requisite on Availability Management's ability to achieve Level 4 maturity.

  Maturity level 5 focuses on continually improving services through both incremental and innovative technological improvements. Quantitative service-improvement objectives for the organization are established, continually revised to reflect changing business objectives, and used as criteria in managing service improvement projects (SIPs). The effects of deployed service improvements are measured and evaluated against the quantitative SLOs. Both defined processes and the organization's set of standard processes are targets of measurable improvement activities.

  Process improvements to address common causes of process variation and measurably improve the organization's processes are identified, evaluated, and deployed. Improvements are selected based on a quantitative understanding of their expected contribution to achieving the organization's process-improvement objectives versus the cost and impact to the organization. The performance of the organization's processes and services are continually improved.

  Optimizing processes that are agile and innovative depends on the participation of an empowered workforce aligned with the business values and objectives of the organization. The organization's ability to rapidly respond to changes and opportunities is enhanced by finding ways to accelerate and share learning. Improvement of the processes is inherently part of everybody's role, resulting in a cycle of continual improvement. ^Ref

Availability Management

All organizations, regardless of their maturity level, must undertake some availability management. Organizations who ignore Availability Management experience chronic outages with severe and persistent business impacts. Like the other service delivery elementsN, Availability Management must be acknowledged within the organization even if actions are haphazard, uncoordinated and unfocused. ITIL's contribution is the recognition of these elements as identified tasks common across technology platforms. Creating identified responsibilities for these functions (whether by creating identifiable organizational units or through cooperative venues in which individuals resident in subject areas which commiserate on common processes and documents such an Availability Plan) may benefit organizations of a size large enough and mature enough to entertain this kind of functional specialization.

Availability Management Process

Possible Availability Management Improvement Initiatives

• Formalize Application Sizing undertakings - A system development project will normally include an assessment of the hardware, network bandwidth and support requirements of new applications. Formalizing the requirement as IT policy will ensure that the requirements of new applications are better acknowledged over their forseeable lifespan.

• Consolidate Availability Requirements - Most organizations will have some process for assessing minimum application availability requirements and the rationales supporting system redundancies, backup procedures, clustering and mirroring technologies. Collecting and storing this information in a central place facilitates the regular review of the requirements in a consolidated context. This review should consider new technological initiatives, leveraging economies of scale amongst applications as they surface during review.

• Create the Availability Plan - This plan represents the culmination of much of the planning activities associated with Availability Management. It should form an integral part of the annual operational review, and, will relate availability needs to available revenue and expenditure forecasts. It contains summaries and rationales for the availability strategy, feasibility assessments and design activities. The plan should encompass:
  • Summary of IT funding and investment policies and how they affect availability requirements
  • Detailed recommendations for optimizing availability and reducing downtime costs
  • Identification of key areas for improvement and specific actions and services to consider
  • Benefits and costs for each recommendation, so implementation decisions can be confidently supported
  • Listing of all assumptions made and infrastructure changes implemented to increase availability
  • availability performance over the previous year in terms of variances from availability targets set in SLAs
• Establish AMDB - The source of availability information collected in the preceding tasks can be retained in a data repository supporting Availability data analysis. This might form a physical or logical division of a CMDB. In addition, there can be vast amounts of availability data extracted from monitoring devices. This data should be maintained in a source easily accessible to Availability Management. Availability Management could also design key summary statistics and maintain this in lieu of the raw data.
• Define CI Targets for Availability, Reliability and Maintainability - Availability Management can maintain records of the availability, reliability and maintainability/serviceability of Configuration Items (CIs). The best place to do this is in a CMDB. Comparing the targets for component availability with actual failure rates would provide Availability Management with valuable information for Availability improvement initiatives. It would also allow them to compare the MTBF rates amongst competing devices thereby permitting the gradual infusion of more reliable devices into the infrastructure.

  These infrastructure components can be analyzed for evolving trends which will provide information and insights into potential availability issues and suggest opportunities to strengthen overall availability.

• Initiate Systems Management - System management involves toolsets, policies and procedures to keep mission-critical systems up and running. It includes the monitoring, diagnostic and automated error recovery to enable fast detection and resolution of potential and actual IT failure. It makes performance adjustments based on dynamic circumstances by …
  • Monitoring the amount of disk space required providing early warning of potential space issues
  • Checking that backups have been performed and that they are viable input into the recovery procedures
  • Performing analysis on index usage; tuning indexes to maximize index usage; creating, dropping and altering indexes as required for performance improvement
  • Monitoring internal database space for fragmentation that can lead to excessive page chaining resulting in poor performance; schedules database reorganizations to correct excessive fragmentation
  • Recording resource shortages in the area of CPU and memory making recommendations on need-to-acquire resources
  • Constantly checking error log file for warnings or errors reported by the database management system and taking appropriate measures to resolve root cause
  • Determining timing of updating internal database statistics to improve optimizer performance
  • Verifying structure integrity of database schema and takes corrective actions as required
  • Providing reports on performance and resource trends for proactive environment management.

• Automate Availability Toolsets - The provision of Systems Management tools positively influences the levels of availability that can be delivered. Implementation and exploitation should have strong focus on achieving high Availability and enhanced recovery objectives. In the context of recovery, such tools should be exploited to provide automated failure detection, assist failure diagnosis and support automated error recovery.

  Collection techniques fall into one of two primary categories:

  • Event-driven Measurement - the times at which certain event happen are recorded and then desired statistics are compared by analyzing the data
  • Sampling-based Measurement - taking a scheduled, periodic look at certain counters or information access points

Capacity Management

Capacity Management, like Availability Management, will be done within the IT organization. ITIL main contribution to service management in this regard is the recognition of the elements as identified tasks common to many technology areas. Grouping these functions together, whether by creating identifiable organizational units or through cooperative venues in which individuals resident in subject areas commiserate on common processes, documents (ie., a Capacity Plan) will benefit the organization. The timing and nature of Capacity Management processes is different from those of Availability management by virtue of a heavy reliance upon common technologies and toolsets. Because there are economies to be achieved in purchasing bandwidth and software licensing there is a great need to consider overall capacity requirements for the IT Department. On the other hand, Availability requirements will be specific to individual application areas. Thus Capacity Management requires much greater activity coordination than availability and this need is frequently reflected in units charged with consideration of overall capacity issues. Capacity Management Process

Possible Capacity Management Improvement Initiatives

• Establish Capacity Requirements - develop the initial baseline of the organization's capacity needs based upon current levels of service (documented or implicitly recognized). To do this the infrastructure resources encompassed by those needs must be recognized so that their utilizations or performance can be measured. This determination is made based on current knowledge about which resources are most critical to meeting future capacity needs. In many shops these resources will revolve around network bandwidth, the number and speed of server processors, or the number, size, or density of disk volumes comprising centralized secondary storage. The resources identified should be measured as to their utilizations or performance. These measurements provide two key pieces of information:
  1. a utilization baseline from which future trends can be predicted and analyzed
  2. the quantity of excess capacity available for each component ^[Note].

  Current utilizations should then be compared to maximum capacities. The intent here is to determine how much excess capacity is available for selected components. The utilization or performance of each component measured should be compared to the maximum usable capacity. ^N

  Then collect meaningful workload forecasts from representative users. User workload forecast worksheets should be customized and used as much as possible to meet the unique requirements of your particular environment. These forecasts are then re-stated as resource requirements. Measurement tools or a senior analyst's expertise can help in changing projected transaction loads, for example, into increased capacity of server processors. The worksheets also allow you to project the estimated time frames during which workload increases will occur. ^[Note]

• Create Capacity Plan - The Capacity plan is the formal description of the organization's Capacity requirements. It needs to show what capacity is needed in the future and at what cost and should permit prediction of what hardware upgrades or additional equipment would be needed to meet future service level objectives. It will include information on sizing of any new systems proposed and needs to reflect cost constraints and availability or reliability requirements.

  The capacity plan should document the current levels of resource utilization and service performance, take into account business strategy and plan in its forecast of future requirements for resource in support of IT services delivered or new services planned. Any recommendations made in the plan should include quantified details of necessary resource, any relevant impact, associated cost and benefits.

  The production and update of a capacity plan needs to occur at pre-defined intervals, preferably yearly in line with the business or budget cycle. A quarterly re-issue of the updated plan may be necessary to take into account changes in business plans, to report on the accuracy of forecasts, and to make or refine recommendations.

• Establish CDB - The CDB holds information about workload, and performance, for example, of how heavily a customer relationship management database is being used, and data allowing trends for future forecasted growth of storage requirements. It provides information for producing reports, the capacity plan, monitoring performance, managing resources, and demand.

  Inputs to consider for the CDB are:

  • Financial data – costs
  • Hardware data
  • Development data
  • Service data - problem/change
  • Contingency data - hardware, and so on
  • Technical data - availability data, and so on
  • Business data - future direction and strategy

  Other detail input for the CDB includes:

  • Capacity plan - current in place; DTP software
  • Model generators - parameters for sizing and modeling
  • Sizing software results
  • Modeling software results
  • Resource utilization monitors - threshold exceptions
  • Service level management - threshold exceptions
  • Other performance/surveillance software
  • Workload performance monitors

  Capacity management issues can dramatically affect the business if they cause unplanned downtime of a vital business function. This requires considerations for capacity and availability management to be intertwined and solution designs consistent. Service continuity management is weighing risk versus cost for scenarios outside the normal availability design. Its contingency planning relies on capacity forecast and recommendations to move forward in documenting a chosen contingency measure. It follows, that the clear and distinct requirements of each process have correlated capacity and performance data identified and properly recorded in the CDB. It is important capacity detail data in the CDB relates to OLA and associated OLA and/or SLA information is tracked in the configuration management database (CMDB). Because there is an implied dependency of availability management information on the proper integration of performance and capacity measurement data, capacity and availability staff often shares common monitoring tools and management solutions.

• Establish Monitoring, Analysis & Tuning - Monitoring should be specific to particular operating systems, hardware configurations, applications, etc. Some of the monitors should be free utilities within a hardware or software product, while others form part of a larger systems management tool set and need to be purchased independently. It is important that the monitors can collect all the data required by the Capacity Management process, for a specific component or service.

  In considering the data that needs to be included, a distinction needs to be drawn between the data collected to monitor Capacity (e.g. throughput), and the data to monitor performance (e.g. response times). Data of both types is required by the Service and Resource Capacity Management sub-processes. The data should be gathered at total resource utilization level and at a more detailed profile for the load that each service places on each particular resource. This needs to be carried out across the whole Infrastructure, host or server, the network, local server and client or workstation.

  Part of the monitoring activity should be of thresholds and baselines or profiles of the normal operating levels. If these are exceeded, alarms should be raised and exception reports produced. These thresholds and baselines should have been determined from the analysis of previously recorded data, and can be set on:

  • Individual components, for example monitor that the utilization of a CPU does not exceed 80% for a sustained period of one hour.
  • Specific services, for example monitor that the response time in an on-line service does not exceed 2 seconds and that the transaction rate does not exceed 10,000 transactions per hour.
  • All thresholds should be set below the level at which the resource is over-utilized, or below the targets in the SLAs. When the threshold is reached, there is still an opportunity to take corrective action before the SLA has been breached, or the resource has become over-utilized and there has been a period of poor performance.
  • Often it is more difficult to get the data on the current business volumes as required by the Business Capacity Management sub-process. These statistics may need to be derived from the data available to the Service and Resource Capacity Management sub-processes.

  The data collected from the monitoring should be analyzed to identify trends from which the normal utilization and service level, or baseline, can be established. By regular monitoring and comparison with this baseline, exception conditions in the utilization of individual components or service thresholds can be defined, and breaches or near misses in the SLAs can be reported upon. Also, the data can be used to predict future resource usage, or to monitor actual business growth against predicted growth.

  The use of each resource and service needs to be considered over the short, medium and long term, and the minimum, maximum and average utilization for these periods recorded. Typically, the short term pattern covers the utilization over a 24-hour period, while the medium term may cover a one-week to four-week period, and the long term, a year-long period. Over time the trend in the use of the resource by the various IT Services will become apparent.

  It is important to understand the utilization in each of these periods, so that Changes in the use of any service can be related to predicted Changes in the level of utilization of individual resources. The ability to identify the specific hardware or software resource - on which a particular IT Service depends -is improved greatly by an accurate, up-to-date and comprehensive CMDB.

  When the utilization of a particular resource is considered, it is important to understand both the total level of utilization and the utilization by individual services of the resource.

  The analysis of the monitored data may identify areas of the configuration that could be tuned to better utilize the system resource or improve the performance of the particular service.

  The implementation of any Changes arising from these activities must be undertaken through a formal Change Management process. The impact of system tuning changes can have major implications on the Customers of the service. The impact and risk associated with these types of changes are likely to be greater than that of other different type of changes. Implementing the tuning changes under formal Change Management procedures results in Less adverse impact on the Users of the service. Increased User productivity, increased productivity of IT personnel, a reduction in the number of Changes that need to be backed-out (including the ability to do so more easily) and greater management and control of business critical application services.

  It is important that further monitoring takes place, so that the effect of the Change can be assessed. It may be necessary to make further Changes or to regress some of the original Changes.

• Implement Demand Management - In the short-term Demand Management should be aware of the business priority of each of the services, know the resource requirements of each service and then be able to identify which services can be run while there is a limited amount of memory available. In the longer term, Demand Management may be required when it is difficult to cost-justify an expensive upgrade.

  Demand Management can be carried out as part of any one of the sub-processes of Capacity Management. However, Demand Management must be carried out sensitively, without causing damage to the relationship with the business Customers or to the reputation of the IT organization. It is necessary to understand fully the requirements of the business and the demands on the IT Services, and to ensure that the Customers are kept informed of all the actions being taken.

• Implement Capacity Modeling - Modeling is associated with level 4 or higher maturity organizations.

  Baseline Modeling is the first stage in modeling is to create a baseline model that reflects accurately the performance that is being achieved. When this baseline model has been created, predictive modeling can be done (i.e. ask the 'what if?’ questions that reflect planned Changes to the hardware and/or the volume/variety of workloads). If the baseline model is accurate, then the accuracy of the result of the predicted Changes can be trusted.

  Analytical Modeling involves representations of the behavior of computer systems using mathematical techniques, (e.g. multi-class network queuing theory). Typically, a model is built, using a PC-based software package, by specifying within the package the components and structure of the configuration that needs to be modeled, and the utilization of the components, e.g. CPU, memory and disks, by the various workloads or applications. When the model is run, the queuing theory is used to calculate the response times in the computer system. If the response times predicted by the model are sufficiently close to the response times recorded in real life, the model can be regarded as an accurate representation of the computer system.

  Simulation Modeling is even more sophisticated and involves the modeling of discrete events, e.g. transaction arrival rates, against & given hardware configuration. This type of modeling can be very accurate in sizing new applications or predicting the effects of Changes on existing applications, but can also be very time-consuming and therefore costly.

  When simulating transaction arrival rates, have a number of staff enter a series of transactions from prepared scripts, or use software to input the same scripted transactions with a random arrival rate. Either of these approaches takes time and effort to prepare and run. However, it can be cost-justified for organizations with very large systems where the cost (millions of dollars) and the associated performance implications assume great importance.

  Effective Service and Resource Capacity Management together with modeling techniques enable Capacity Management to answer the 'What if' questions. 'What if the throughput of Service A doubles? "What if Service B is moved from the current processor onto a new processor - how will the response times in the two services be altered?'

Financial Management

As an IT management tool, budgeting is ignored or under-used. Budgeting provides a starting point for cost cutting, as it forces one to think about how to provide the same service with less money. In an IT environment budgeting is notoriously difficult, because while logic demands an IT budget follow the business budget, reality mandates a simultaneous budgeting process. An IT budget should be made after the goals for the business are set, after the budgets for all other supporting departments are set, and after it is known what the actual business needs are. IT budgeting is made more difficult when the Capacity Management process is incomplete or does not function properly. IT groups typically are organized in highly politicized functional silos, and planning for the needed capacity often is pure guesswork or - even worse - a result of carefully crafted political compromises. Accounting practices in many IT organizations can also be chaotic and misunderstood. Changes in the IT department and lack of control over these changes provide headaches to most IT accounting people as most uncontrolled change creates chaos. Reporting, in conjunction with Service Level Management, is non-existent in most companies and "fire fighting" considerations determine where the dollars go. Internal billing practices often are considered "funny money" and a burdensome bureaucratic control. As a result, the potential benefit of billing and thus influencing end-users' behavior often is ignored or unknown. Even in companies where sophisticated service level monitoring is being practiced, it is normal for the end-user to face a lack of transparency around charging practices. The end-user seldom has a clue what the service is actually costing or what his or her department is being charged for the use of any IT service. Financial Management Process

Possible Financial Management Improvement Initiatives

• Service costing definition - It is desirable to determine the cost of services to customers, taking into account the external specification of design of the service (the design that comes from the process of Service Planning that specifies the "what" of the service). While the IT Division may not actually charge business the full cost of IT Services (some may be consider "corporate" services, a form of "notational" budgeting permits the IT Division to identify and track service costs. The IT Division should also consider the costs projected for the capacity and availability requirements.

• Analyze the revenues projected according to the charging and pricing policies to the customer - For each service, it is necessary to review the projected revenues for each level of service described in the external specification of the design (Service Planning). Evaluate the feasibility of these projections compared against the market and the charges that the customer is willing to accept. Then analyze the revenues against the delivery of the service through the time that the service will be available to the customer.

• Determine Service Costs - Service level management and the resulting IT services that it enables come at a substantial cost to the enterprise measured by both monetary and human resource requirements. In order to make an intelligent decision relative to service provisioning, IT must accurately identify all costs of the services being evaluated, perform a ROI analysis and engage the customer to fund the service. This is true for existing services being provided and new services being considered. In order to identify costs, all components of the IT infrastructure that combine to enable a service need to be considered. In all areas, these costs can be significant. It is necessary that a comprehensive ROI analysis be performed on each activity to determine if the expected return to the organization, both directly financial (cost vs. benefit) and indirect effort (cost vs. increased or maintained customer productivity levels) is worthwhile. In cases where the ROI process indicates that the service does add enough value to the enterprise to be worthwhile, the service will not be implemented. In instances where the ROI process has established that the service is of value to the organization, the service will be implemented. In some cases, the service requested may be simple in nature. It does not significantly impact the areas of service provisioning that the cost analysis is designed to evaluate. The service level manager makes a "judgment call" in these cases and may elect to establish the new service without formally executing the financial analysis process.

• Provide Customer Detail - Calculate the true costs to the customer by use of the service. Determine the usage of each specific service in order to generate the corresponding charges.

• Establish charging policies - Determine margins affecting the rates and the prices relative to recovery of the costs. Determine whether charging will be informational, notional, or actual to the customer. Four factors govern the requirements of charging policies:
  • Complete recovery of all cost (direct, indirect);
  • Influence the service usage by the customer;
  • Recovery of costs according to the usage of the services;
  • The service is aligned to the market in terms of availability, capacity and cost;

  Determine how the costs of service delivery to customers will be allocated and accounted. The cost structures must consider any economies of scale that are related to the delivery of several combined services or increases in volume.

• Financial Activity tracking - Track and analyze for each service by customer:
  • Asset usage including the Return on Assets (ROA);
  • Purchasing actuals and trends;
  • Changes to inventory.

• Benchmark TCO - Determine like-industry averages and cost breakdowns as a benchmark against which the organization can be compared.

• Determine Services TCOs - Given a specific service (for all the customers and based on the standard costs) determine the total cost of assets which the customer uses throughout the life of the service.

• Market Service Catalogue - To communicate and promote the effective use of services in relation to their costs and to educate customers as to the value of the services as based on their cost to deliver and the economies of scale related to maintenance of the IT system for Service provisioning. Gain the trust and commitment of the customer. Gain consensus on policies that balance load and capacities, for example:
  • Increased prices for older technology and" discounts" or advantages in terms of charges for newer and more supportable technologies;
  • Increased charge for services during peak operations and discounts during times of lower demand for the service.

• Introduce Cost reporting in Catalogue - Report actual costs either directly into the calendar or through a monthly feed. Variances represent FM's ability to properly flow and manage costs.

  In reality, linking any IT initiative into the total existing IT environment involves a cost. the amount of that cost depends not only on the size and complexity of the initiative being undertaken, but also on the state of the current IT environment. Mark D Lutcheon, managing IT as a business, John Wiley & Sons, 2004, ISBN: 0-471-47104-6, p. 137

Service Continuity Management

Almost all large organizations have Disaster Recovery Plans for their major, business-critical applications. There is an abundance of evidence about the pitfalls of organizations which have tried to save money by cutting corners on these plans. Efforts to maintain and update the plans, however, often suffer due to the absence of a highly visible and permanent responsibility for their maintenance. Consequently, efforts in this area are often sporadic and in consistent. Theoretically, Service Continuity Management is an adjunct of Availability Management. The two areas share a common goal. However, because this area represents such a severe threat to business interests, most business units will wish to maintain tight control over plans and recovery strategies. Because of this pre-occupation Service Continuity is frequently not considered during ITSM improvement projects. It is considered tangential to or outside the sphere if the iT Division. IT service managements efforts devoted to Availability Management are seen as the most appropriate vehicle for the provider to exercise some influence and direction over continuity plans. Service Continuity Management Process

Possible Service Continuity Management Improvement Initiatives

• Business Risk Assessment - Before planning to protect the environment and recover from potential outages, the organization must ensure the appropriate disaster avoidance measures are in place. A review of the current environment is conducted to ensure processes and practices are in place to deter or prevent a disaster from happening.

  In addition to disaster avoidance, a risk assessment or analysis is performed to identify and define potential risks to the organization. Based upon the risks, preventative measures are implemented to mitigate the affect of the risk or threat.

• Complete Business Impact Analyses - A key driver in determining ITSCM requirements is how much the organization stands to lose as a result of a disaster or other service disruption and the speed of escalation of these losses. The purpose of a Business Impact Analysis (BIA) is to assess this through identifying:
  • critical business processes
  • the potential damage or loss that may be caused to the organization as a result of a disruption to critical business processes.

• Develop Recovery Strategies - Systems Recovery Procedures for Survival Critical applications should be maintained by Services Continuity Management. These procedures should be readily available to Availability Management in the event of the need for quick service restoration. In addition, Availability Management may maintain sets of generic restoration procedures for such things are file servers, back-up servers, routers, etc which can be referenced to ensure speedy restoration of these devices. Availability Management should undertake to have recovery procedures created for all Survival and Mission Critical applications and for services for which recovery is sufficiently complex that documenting and implementing standard processes for recovery will provide greater assurance of success and less chance of creating further incidents. These procedures should be controlled through Change Management methods including testing them in a pre-production environment.

• Develop Disaster Recovery Scenarios - A Disaster Recovery Strategy is developed for each major application taking into account the estimates of risks and the type of recoveries which should be implemented.

  These strategies are placed under Change Management and will form part of SLAs negotiated with lines of business.

• Maintain Disaster Recovery Processes - Disaster Recovery should be identified as a service and recorded in the service catalogue so the costs and benefits of maintaining it (with annual testing) are accounted for.

Strategies

Getting Started