WORK ORDER MANAGEMENT: PROCESS AND PRACTICE

Transcription

1 Whitepaper Submission of the Year 2013 WORK ORDER MANAGEMENT: PROCESS AND PRACTICE By Sergei Guzik and Alexey Lamykin

2 Sergei Guzik Has worked in the IT field since 1997 with Ecotech, Taurus Technologies, Aquarius Consulting, and Jet Infosystems. Since 2005, CEO of GSV Consulting company. Member of the founding committee of Russia s itsmf Chapter. Member of the Executive Board of the Foundation for Support of Engineering, Standardization and Project Management (FOSTAS Foundation). svguzik@gmail.com Alexey Lamykin ITIL Expert, PMP. Worked in the corporate IT units of the National Training Foundation, R. J. Reynolds Tobacco International (JTI), UCLA, and Indymac since Since 2000, has worked in systems integration and IT consulting. Currently Lead Consultant at GSV Consulting. alamykin@gmail.com This article was originally published in Russian in the Information Management magazine (#5, 2013). The authors wish to thank Konstantin Zimin, Chief Editor of the magazine, for his support and cooperation. Synopsis ITIL, COBIT, and other modern IT management frameworks are mostly concentrated on service management and IT governance processes. Meanwhile building complete end-to-end IT management process model also requires process organization of operational activities. The article proposes the approach to the work order management process including design of task cards (similar to incident, request and change models in ITIL), control over work order execution, and analysis of tasks fulfilled. Advantages of the proposed method include linking everyday activities of IT staff to IT services, better visibility of personnel workload and possibility of limiting work in progress, easy integration and control of scheduled maintenance tasks. Work order Management: Process and Practice 2

3 Provisioning of IT services has to be intelligently organized to meet numerous requirements. It should be effective and efficient. In connection with this, IT management often faces the following questions: How to best plan activities of the IT department? How to compare the IT units effectiveness? How to stimulate the personnel? Who of the employees deserve bonuses? How to reveal available reserves and optimize activities of the IT department? In order to respond to these and many other questions, the IT management should be able to properly plan, prioritize, and control the entire scope of the work performed by the IT staff regardless of whether this work is aimed at resolving incidents, implementing changes, or performing scheduled maintenance. Work order management in the IT management frameworks Unfortunately most of today s IT management frameworks almost disregard work order management. Some of them just make reference to work orders or operational procedures. However, they neither describe the way work orders or operational procedures should be managed, nor regard work order management as a stand-alone process. For instance, COBIT 5 describing the BAI06 Manage Changes process refers to the change planning and scheduling, as well as to the subsequent status tracking. Also, DSS01.01 Perform operational procedures practice, inter alia, includes the following activity: Maintain a schedule of operational activities, perform the activities, and manage the performance and throughput of the scheduled activities 1. It envisages the planning, scheduling, and monitoring of the IT operations. However, in both of these cases neither the details of the planning mechanisms are specified nor is the work order term used. Microsoft Operations Framework (MOF) version 4 considers mostly operational work related to the IT operations (Operations Service Management Function). MOF describes the planning processes (Process 3: Plan Operational Work) and operational work execution (Process 4: Execute Operational Work). However, in MOF task management, mechanisms are limited to the operational work and are not applied to the other IT service lifecycle stages. ITIL 2011 refers to work orders in the change management process 2. It is pointed out that the best practice is to use work orders implementing changes: Authorized changes should be passed to the relevant technical groups for building the changes. It is best practice to do this in a formal way that can be tracked, e.g. using work orders 3. Work orders are also referenced in the Request Fulfillment process: Requests will need to follow a predefined standard fulfillment procedure. This implies that a documented request model be in place that communicates a predefined process flow for each of the services being requested. This should also include all procurement policies, roles and responsibilities, which functions will be assigned to execute the model, and the ability to generate purchase orders and work orders 4. 1 COBIT 5 Enabling Processes, ISACA 2012, ISBN , page See, for example, ITIL Service Transition, 2011 Edition, ISBN , page 71, Figure 4.3 Example of a process flow for standard deployment request 3 ITIL Service Transition, 2011 Edition, ISBN , page 79 4 ITIL Service Operation, 2011 Edition, ISBN , page 96 Work order Management: Process and Practice 3

4 ITIL approaches work order management most closely when it describes models of incidents, changes, and service requests 5. Particularly, it advises establishing a set of operational models (templates) used to resolve typical incidents and execute standard service requests. These models should specify: Steps required to resolve incidents or execute requests Order of these steps should be taken into consideration if there are dependencies Responsibilities for implementing these steps Timescales (implementation deadlines, threshold values) Escalation procedures related to implementing these steps As a matter of fact, ITIL describes here a system of task cards. However, ITIL does not consider work order management as a stand-alone process. ITIL specifies neither the way incidents and request models should be designed nor the valuation of time and skills required to perform the tasks. Notably, when it comes to the practical implementation and automation of IT management processes the service desk tool developers often apply the work order management mechanisms. For instance, Hewlett-Packard Service Manager supports the task mechanism (Tasks) applicable to certain processes (such as change management and problem management). Naumen Service Desk supports the comprehensive task and work order management mechanism, which includes such options as work order template pre-setting, different responsibility allocation methods, and actual labour input logging 6. The BMC Remedy and OmniNet OmniTracker systems also offer similar functionalities. Work order management process Despite the fact that the current IT service management frameworks generally disregard the work order management process, we believe that its implementation as a stand-alone process provides significant advantages, especially when it is used in a broader context and is not limited to the operations management or service support. Based on our experience of implementing the work order management process in a number of projects, we consider it a good practice. Let us proceed making the following assumptions: 1. Most activities carried out by the IT staff can and should be described in the form of tasks and registered as work orders. 2. All executed tasks should be linked to the head objects, which in turn should be related to the process or project activities. In other words, the work orders executed by IT personnel should be related to relevant incidents, changes, service requests, scheduled maintenance operations, or projects. 3. Activities categorized as work orders require certain practices for registration, control, and reporting. Some basic terms and definitions are listed below: Head object an incident, change, service request, scheduled maintenance procedure 7, or project that serves as the basis for the task execution. 5 See, for example, ITIL 2011 Service Operation sections (page 75) and (page 88) and ITIL 2011 Service Transition section (page 67) 6 Source: 7 Under scheduled maintenance procedure we mean a document which outlines the scope and order of activities executed by IT staff on an established schedule aimed at reducing the number of incidents or meeting the external and internal requirements (regulations, standards, and policies). Implementation of scheduled maintenance operations is beyond the scope of this article. Work order Management: Process and Practice 4

5 Task activity related to the provision of services, resolution of incidents, implementation of changes, or IT projects. Work order a record containing details of the task assigned to an individual performer. Task card a document describing the operational work that enables a standard set of tasks to be performed (for instance, standard change execution). Task cards stored in the database can be accessed by other processes and used to create work orders based on head objects. The work order management process purpose is to ensure high-quality and timely execution of tasks required to provide IT services and IT infrastructure maintenance. Work order management process objectives are: To enhance the IT service s efficiency by improving work planning mechanisms To ensure stable and predictable performance and quality of work To improve the interaction of parties involved in the process of providing IT services The work order management process performs the following tasks: Design and improvement of task cards and work standards Controlling the task routing and execution Task recordkeeping and appropriate reporting The work order management process is schematically shown in Fig. 1. Planning Task cards Work request Task registration Work orders Task execution Task closure Task execution reports Analysis Analysis results Fig. 1. Work order management process The process includes the following activities: Planning. This procedure provides design of the task cards and job standardization. Task cards are developed for all major repeatable operations such as moving the workplaces, standard software Work order Management: Process and Practice 5

6 installation, data backups, and so on. They describe necessary tasks, skill requirements, and predetermined labour input. The task cards database can be accessed from all IT service management processes. Requesting a certain task to be fulfilled, it is possible to refer to the task card in the database. Planning is also responsible for valuation of requests that are not described by existing task cards. De facto planning procedure sets up methodological framework for work order processing. Task registration. Based on requests and task cards, work orders are registered and prioritized. After that, work orders appear on the performer s queues. Different algorithms can be used to prioritize work orders. Generally they relate to the types of the head objects and their priority (for instance, the priority of tasks connected to a large-scale incident may be higher than that of a scheduled maintenance procedure). The work order distribution among the parties executing relevant operations involves two basic mechanisms: push a work order gets assigned to a specific employee (by a dispatcher or automatically in compliance with established rules) pull a work order gets assigned to a working group or company unit, employees accept the above work order for execution on their own It is quite frequent that both mechanisms are combined. Even if pull mechanism is used, it is important to control whether or not a work order is accepted. If the work order has not been accepted for execution within the established timeframe it shall be escalated to the head of the working group, who shall appoint a performer in charge of its execution. Regardless of what mechanism has been applied at this stage, an automation tool shall be used to monitor the workload by limiting the number of work orders assigned to one performer simultaneously. Task execution. The performer selects a work order from the task queue and starts its execution. The work order status shall change accordingly. If the job cannot be fulfilled without additional information provided or another job fulfilled, the performer may suspend the work order execution, stating the reason for the delay. In this case the work order execution timer shall be stopped. Either way, at this stage it is important to monitor work order execution time and properly escalate if necessary. Task closure. Upon completion of the task, the performer changes the work order status and reports work completed and results achieved (both in case of success and failure). This report shall normally be a part of the IT management automation system record. Both predefined and non-standard reports can be used. Predefined reports are prepared in advance depending on the type of work order (for instance: The printer cartridge has been routinely replaced, no problems/complaints reported ) and can be selected by the task performer in the automation system. Non-standard reports are prepared by the performer (for instance, a detailed report of changes to a software module describing modified functions). The work order execution control and final closure shall be exercised by the person in charge of the head object to which the relevant work order relates. A work order can be closed automatically if no claims to the work scope and quality have been made within the established timeframe (usually 1-3 business days). Analysis is an essential part of the work order management process. The entire work order processing cycle (Registration Execution Closure) is used to gather data required for the subsequent analysis. This phase includes analysis of output, productivity, and deviations from task cards and established Work order Management: Process and Practice 6

7 standards. It also provides identification of bottlenecks and ways for improvement 8. Analysis enables the management to reveal a number of unobvious aspects of the IT service activities, which we largely ignore if the work order management process is not used. For example, a huge number of work orders assigned to an employee or a workgroup waiting for a long time in execution queue will show a typical bottleneck, limiting productivity of the IT department on a whole. It is equally important to see the staff workload broken down into the types of head objects: are we spending more time doing firefighting (incident resolution) or performing purposeful activities aimed at the development and support of the infrastructure and services (projects, changes, and scheduled maintenance)? The work order management process inputs, outputs, and the responsibility assignment matrix are shown in Tables 1 and 2. Table 1. Inputs and outputs of the work order management procedures Inputs Outputs Planning Data required to develop task cards (job Task cards descriptions, established standards, work performance statistics, etc.), requests for the design of task cards Task registration Work requests Work orders Task execution Work orders Work orders (status: Fulfilled ) Task closure Work orders (status: Fulfilled ) Work orders (status: Closed ) Analysis Task fulfillment reports Analysis reports including improvement initiatives, data required to design and update task cards Table 1. Work order management process roles and their responsibilities 9 Process manager Technologist Task initiator 10 Head of the functional workgroup Member of the functional workgroup Planning A R C C Task registration R I I Task execution C A R Task closure I A R Analysis A R С C C Management objects hierarchy The use of work orders forms a three-tier hierarchy of management objects (see Fig. 2). 8 Task analysis has much in common with quality management, but does not replace it. Data gathered within the work order management process can also be used for quality control. The correlation and interaction of these processes is a subject for a separate discussion. 9 Responsibilities are stated using the usual RACI matrix terminology, where R means Responsible, A Accountable, C Consulted, I Informed. 10 The task initiator is generally the person in charge of the head object (change, incident, service request, etc.) Work order Management: Process and Practice 7

8 Tier I Customer horizon (direct speech of the end-user) Interaction Tier II Service management horizon (head objects) Incident Service request Request for change Tier III Technical staff horizon (IT tasks) Work orders Work orders Work orders Fig. 2. Management objects hierarchy The interaction with the customer is placed in the upper tier and in effect represents the user s direct speech. In most cases the end-user will not care about lower-level classification of his address he just has an issue and needs IT to resolve it. So it is advisable to record and keep all the communications with the customers at this level. A user address may include one or several requests. Analysis and classification of this address is generally a function performed by the service desk s first line. As a result it creates requests and incidents, representing IT service management process head objects. The principal task of managing interactions is to record user requirements. Therefore an interaction does not require complex processing and its lifecycle is simplified to the maximum ( Registered Processed Closed ). The head objects (incidents, service and change requests, etc.) are placed in the middle tier constituting service management horizon. At this level all the major processing and decision-making is fulfilled, including request categorization, authorization, and prioritization. Therefore the head object s lifecycle appears to be more complicated and may include different stages depending on its type. Fairly complicated escalation mechanisms, which, for instance, may depend on services provided, may be applied at this tier. Work orders are placed in the bottom tier. As the end-users, technical personnel may not be aware of the service management concepts and different types of requests. So it may be beneficial for IT staff to have a single prioritized task queue. The major processing has already been performed at the second tier; therefore this tier s primary target is to ensure the efficient execution of relevant tasks and their monitoring. The work order lifecycle is quite simple and depends mostly on the task assignment mechanism (push or pull) applied. Emerging issues are usually escalated to the head of the workgroup or direct supervisor of the person in charge of the task. A typical set of work order statuses will include: Assigned In queue Work order Management: Process and Practice 8

9 Work in progress Fulfilled Closed The status implications are included in Table 3. Additional statuses can be used to process abnormal situations such as wrong work order assignment, task suspension waiting for additional information or another task to be completed, reclamations caused by low quality. Table 3. Work order statuses Status Assigned In queue Work in progress Fulfilled Closed Status meaning The work order has been registered, its attributes have been specified (including responsible workgroup) The person responsible for task execution has been identified, the work order has been placed into his queue and is awaiting execution The task is being fulfilled The task has been completed, task report submitted The person in charge of the head object has confirmed the work completion The work order lifecycle is closely related to that of the head object. ITSM tool should normally monitor the status of underlying work orders and not only inform head object owner of the task completion, but also prevent the closure of the head object or its phase change before the fulfillment of the tasks assigned. Detailed design of the work order and head object lifecycles is generally a part of the ITSM process design. An example of the management objects lifecycles is shown in Fig. 3 below. User interaction Registered In process Processed Closed Incident (head object) Work orders First line support analyses information received from the customer and creates an incident record Both interaction and head object records are closed upon the receipt of the positive feedback from the customer or expiration of control time Incident is resolved, customer is notified and proposed to provide feedback Registered Assigned Work in progress Resolved Closed Activities required to resolve the incident determined, necessary work orders created The person in charge of the head object is notified upon the completion of tasks The head object owner confirms that the tasks have been fulfilled, work orders are closed Assigned In queue WIP Fulfilled Closed Assigned In queue WIP Fulfilled Closed Assigned In queue WIP Fulfilled Closed Fig.3. Management objects lifecycles interrelation example Conclusion What practical benefits can be gained from the implementation of the work order management process? Our experience shows that it permits: Work order Management: Process and Practice 9

10 To standardize and record working time To make staff workload more transparent providing visibility of process work for functional managers and possibility for limiting work in progress To provide single task queue with proper task prioritization for IT personnel To give a fair assessment of the contribution of each IT staff member To identify bottlenecks impacting IT productivity Work order management also simplifies pre-emptive planned maintenance. Maintenance activities could be described in the form of task cards and fired on schedules stored with CI records in the CMDB. Implementation of work orders could also help with further IT automation. Splitting typical operations into smaller tasks could reveal many opportunities there is just one step from assigning Create a virtual server from template task to a person to performing it with a script. The major advantage of the work order management process is its ability to establish the link from practically all the activities carried out by IT personnel through head objects to the IT services, thus providing capabilities for enhancing planning and deep analysis, serving as the basis for intelligent managerial decisions. Work order Management: Process and Practice 10