What is the service level of your CMMS supplier (Part 2 of 2)

Transcription

1 Alain April Claude Y Laporte School of Engineering, École de Technologie Supérieure, Montréal, Canada Abstract Many important factors are involved in the successful operation, support maintenance of CMMS software. In Part 1 of this paper (published in the last issue), on obtaining better service levels from CMMS suppliers, help was offered in identifying Service Level Agreement (SLA) conditions which will constrain a CMMS supplier (whether internal or external to the organisation) to be more responsive when a failure occurs in their software. Here, in Part 2, the complexity of the Service Level Agreement architecture is explained, as well as the process that needs to be in place for a successful implementation of an SLA. THE TWO BASIC TYPES OF SLA To reach agreement on service levels, a consensus must be developed between the customers the CMMS supplier about the relevant concepts, terms measures to be used. Service Level Agreements (SLAs) are said to be internal when they are exercised entirely within a single organisation. They originally appeared in large computer operations centres during the 1950s. During the 1970s they progressively extended their reach to all IS/IT service-oriented activities. However, many IS/IT organisations still do not have SLAs in place today. Some attempts to identify exemplary practices propose SLA maturity models have been made recently. S 3m, for example, is a set of exemplary practices, used by IS/IT improvement managers, which identifies describes practices that must be implemented in order to meet the IS/IT auditor s requirements for SLAs as recommended by COBIT (Control Objectives for Information related Technology), more recently, contained in the Sarbanes-Oxley regulations 1. It identifies the definition management of the service level as an essential practice, with the measurement of the quality of service as its main objective. S 3m COBIT describe five maturity levels for an SLA (non-existent, ad hoc, repeatable, defined, managed/measured optimised). The trademark S 3m also represents other software engineering that are directly related to software maintenance contractual agreements. 34 maintenance & asset management vol 21 no 2

2 Even though many publications have presented detailed elements of SLAs, little is known about the key underlying principles at work in these types of agreements. One such principle is that an SLA should be based on results rather than on effort. For example, in many instances attempts have been made to describe the results of a CMMS support maintenance activity in terms of the quality levels to be achieved, with the expectation that this is to become the basis for assessing whether or not the terms of the SLA have been met. This agreement is called a results-based SLA, is an approach which requires that a consensus be reached on quality levels that some quantitative measure be assigned to all services offered by suppliers. CMMS suppliers, including consulting firms, are known to avoid this path to claim that all sorts of technical hurdles exist to prevent this type of agreement from being applied. It has been observed in practice that, where there is no consensus on a proper description of results, the fall-back position is to describe only the effort costs to be expended on maintaining the CMMS software. This is what is promoted by these suppliers CMMS consultants all over the industry. Such agreements are called effort-based SLAs. They cannot, however, be easily controlled. A suggestion made in the literature is that an inventory of guideline templates be kept for use in specifying an SLA document between the CMMS supplier the customer. An important asset in using this approach is a good sufficient knowledge of the parties involved, because the difficulty of establishing service measurements between a supplier a customer should not be underestimated. Moreover, the SLA needs to clarify the expectations requirements of each maintenance service. In the context of an internal agreement on software maintenance services between the maintenance organisation their users or customers two approaches have been observed, viz. (1) On the one h, the customer wants to concentrate on his business expects a homogeneous service from his IS/IT CMMS support organisations. The result of this homogeneous service for the customer is the ability to work with the CMMS system without interruption, whatever the source of the failure. The way in which the CMMS system its infrastructure are constituted is of little interest to the customer, who would like his end-user vision to be reflected in his SLA. This means that a results-based SLA should apply to the total service (including the help desk, maintenance, computer operations the CMMS supplier) not only to the individual/partial CMMS components (i.e. a server, a network, the software). (2) On the other h, the CMMS supplier is only responsible for a portion of the service as perceived by the customer (as reflected in Figure 1), who is often quite ready to provide a results-based SLA for their part of the service chain. However, in this case, the CMMS software operates on infrastructures that are not their responsibility (desktop, networks, platforms database), as they only interface with the help desk computer operations. To achieve integrated measurement of all the components of the CMMS software all the groups concerned have to be involved, someone in the IS/IT organisatin must own an overall, end-to-end, SLA where all the IS/IT services are described in a chain of services. When a CMMS failure occurs users typically call a central help desk (also called Level 1 Support, which is mostly workstation access level help). If the help desk cannot address the CMMS issue it refers the problem to the maintenance support team (Level 2 Support). Investigation may result in the maintenance & asset management vol 21 no 2 35

3 identification of an infrastructure or CMMS software failure. When the problem is not a CMMS software issue, the call is referred to operations support (Level 3 support), which takes an in-depth look at desktop issues, telecommunications, middleware, database management systems, the operating system, disks other operating systems, basic software-related hardware-related issues. Operations may involve third parties (Level 4 support, like Dell, IBM, HP), one of which is the CMMS supplier. WHY IS MAINTAINING AND SUPPORTING A MODERN CMMS SO COMPLEX? CMMSs have evolved are now developed using modern software architectures. CMMS client/server applications are configured in a similar way to any modern software system, they are composed of a large number of components potential points of failure. For example, a CMMS software can be dependent on eleven individual components, as illustrated in Figure 1. If each of its components has to be available more than 99% of the time we still have a resulting workstation net value that drives down the availability to only 97.8% of the time. Downtime for the operations would approach 8 hours/month, which is unacceptable for critical applications. Although distributing computing may deliver significant business value, it also challenges IS/IT to optimise its problem resolution process or it will fail in providing a stable operational environment to its customers, which is something they had been able to count on for many years with their older centralised mainframe CMMSs. Component Availability Objective Workstation Net Availability Objective Client Hrdwr. 99.9% 99.9% Client O/S 99.5% 99.5x99.9=99.4% Client Middlwr. 99.9% 99.9x99.4=99.3% Client Applic. 99.9% 99.9x99.3=99.2% Cable Hub/Router 99.9% 99.9x99.2=99.1% Network Server 99.8% 99.8x99.2=98.9% Net. Server O/S 99.9% 99.9x98.9=98.8% Database System 99.8% 99.8x98.8=98.6% Server O/S 99.6% 99.6x98.6=98.2% HOW CAN THIS COMPLEX ISSUE BE SOLVED? Identify the SLA co-ordinator. If there isn t one, create the role within your organisation. The general responsibility of the SLA co-ordinator is to document CMMS support changes, a process in which the emphasis is placed on accurately outlining the service limitations costs of production application maintenance support, infrastructure operations. The specific organisational responsibilities of the Information Services SLA co-ordinator in terms of controlling changes are the following Developing SLA support characteristics Amending service descriptions Costing SLA services Negotiating, agreeing on, a yearly SLA Server Middlwr. 99.8% 99.8x98.2=98.0% Server Applicat. 99.8% 99.8x98.0=97.8% Figure 1 Cumulative effect on availability 36 maintenance & asset management vol 21 no 2

4 CMMS Rep OPERATION MGR IS/IT MGR CMMS User Rep Ensures that SLA questionnaires are sent Ensures that SLA questionnaires are reviewed service description overall costs / allocate costs to the CMMS Ensures SLA appendix describes CMMS services in detail SLA service description Ensures SLA appendix is agreed on OPS services description costs Prepare customer SLA presentation using KPI s from current year Present negotiate SLA with customer rep Negotiate Document feedback, complaints improvement opportunities Distribute report Figure 2 The yearly life cycle negotiation process of the CMMS Service Level Agreement Figure 2 shows the yearly CMMS SLA negotiation process. The first step is to ask the CMMS support representative to submit a service level questionnaire to the CMMS users to document their satisfaction level the service level they expect in the coming year. This important information will be used as an input to prepare SLA yearly negotiations. The second step is for your IS/IT maintenance support team (Level 2 support) to identify the internal resources (in-house personnel assigned to maintain support the CMMS internally) as well as the CMMS contract costs (Level 4 support costs) that will be paid to the CMMS supplier to meet these service level requirements. The third step is for the IS/IT maintenance support personnel to document this information, jointly with the CMMS supplier, in an appendix to the SLA which describes, in detail, the agreed-upon service level for the CMMS system for the Level 2 support activities. The fourth step is to use the main maintenance & asset management vol 21 no 2 37

5 text of the SLA (described in Part 1 of this paper) to describe, in some detail, the SLA services offered to the end-users. The final step is for the operations personnel (Level 3 support) to work hard to determine the percentage of infra-structure manpower costs that will be allocated to support the CMMS. This is what needs to happen in all the operations manager s steps (see Figure 2). Operations personnel will have reviewed the questionnaire results amended the detailed description of their part of the support services (infrastructure, networks, desktops database software) described them in the SLA appendix. Once this descriptive work is done, IS/IT management can review the overall costs proposed services in a management meeting. When all IS/IT groups (Level 1, 2 3 support groups) have agreed among themselves, they can visit the customer s management discuss explain the possible services costs trade-offs to fully support the CMMS software. In conclusion, what initially looked like a simple third-party contract has now evolved into a multilayer agreement between many organisations. Each technology layer of the CMMS software hardware requires careful description. The resulting support will only be as strong as the weakest link in this service chain. Using the S3m maturity model will facilitate underst the maturity level of your SLA practices. The supplied road maps show how to move from where you are to where you should be. For a maintenance organisation, achieving a higher capability level can result in (a) lower maintenance support costs, (b) shorter cycle time intervals, (c) increased ability to achieve service levels, (d) increasing ability to meet quantifiable quality objectives at all stages of the maintenance process services, (e) increased customer satisfaction.. Each technology layer of the CMMS software hardware requires careful description. The resulting support will only be as strong as the weakest link in this service chain. REFERENCE 1. S 3m is the trademark for the Software Maintenance Maturity Model (see: ) Using the Key Process Indicators, which are measures of performance of the CMMS (failures problems) over the preceding twelve months, it is possible to debate how much productivity loss has been observed how much investment is warranted to ensure that the CMMS availability percentages are kept at the best operating level in the next year. 38 maintenance & asset management vol 21 no 2