9.1 Justification of the design improvements
The suggested design has two major improvements: clear definition of services and standardized design for all IT Service Management processes. In the figure below enhanced capabilities are summarized. Purpose of the ITSM capability le-vels is to describe quality of different processes in ITSM adjusted CMMI scale.
ITSM Capability Levels
Figure 20. Current and planned capability levels
Designing IT Services is the primary enabler of IT Service Management culture and therefore pivotal design improvement. Process management then increases quality of these services. Process design includes a process map for ITSM that describes the process architecture of IT Service Management for the case compa-ny. Process design is tailored from the case company’s process management stan-dards. Design clearly states the purpose, inputs, activities, roles, measures, verifi-cation steps, outputs and interrelationships of different processes. It is expected to ease customizing IT ERP, simulate weaknesses in IT operations and hence identi-fy new development issues and improve knowledge management of Common IT Services via process-oriented restructuring and organizational documentation. The
design also presents management approach for utilizing CMDB. In addition, sug-gestions for improving process performance are listed in the end of each process management chapter. IT management was consulted in the process of creating this management model.
9.2 Organizational improvements
Most important role is ITSM owner. ITSM owner is responsible for strategic management of IT services. He reports to top management of IT. He also ensures that all processes are performing as agreed and documented. ITSM owner’s sphere of responsibilities includes both service and process perspectives.
From the service perspective two roles are required: service owner and service manager. Service owner orders and pays for a service and service manager guar-antees that the service is delivered as agreed. Service owner also needs to approve all suggested changes regarding the service. Service manager manages the every-day operations related to the service. Service manager reports to the manager of service providing unit. For example, manager of ERP service, reports to manager of Common IT Services unit.
Management of ITSM processes is assigned to nine roles: ITAM manager, Appli-cation Incident manager, Infrastructure Incident manager, Change manager, Change manager, Access manager, Release manager, Configuration manager and Problem manager. Incident Management does not have single manager, but con-flicts can be avoided as the final decision making power is on ITSM owner. Oper-ating Level Agreement between Application and Infrastructure managers should be documented.
Additional roles for ITSM processes emerged. Roles are collected together in ap-pendix 1. Most of the roles are executed by an IT staff member or IT support group.. Appropriate training should be scheduled for all IT staff working with the new processes. Also vendors and customers should be informed of the changes and if necessary trained for the new practices.
9.3 Service Catalog Management
Suggested design for service catalog includes, in ITIL terms, only business vices. The catalog contains two dimensions for a service: service hierarchy, ser-vice details. The first dimension describes how serser-vices are grouped and second dimension, service details, describe all different details that services need to have.
Technical services are not modeled even though they were originally grouped in chapter 7.2 Development scope. Reason for leaving technical services out is that business services can be directly linked to OLAs and supplier SLAs instead of linking them to artificial technical service before the link to supplier SLA. After all ITIL’s technical services are only internal services for IT organization itself.
Also performance measurement is more interested in performance of OLAs and SLAs than performance of artificial technical services. However, if IT organiza-tion finds technical services useful in the future, implementaorganiza-tion of them after-wards should not be difficult as they are only configuration between services and single SLA contracts.
Services are structured hierarchically. Only the highest level of hierarchy is part of this design solution. As stated by Paul Burns (2009) it is better to define the exact service offering while implementing the catalog as some technical and other re-strictions might be discovered. In the list below high level service hierarchy is de-scribed with exemplar services or sub category. Complete hierarchy is advised to be modeled while the service catalog is implemented.
Application services o ERPs
o CRM
o Non-standard software
Information and Communication Technology tools o Workstations
o Standard office software
o Shared equipment (printers and alike) o telephony
mobile
Business mobile phone fixed line
telephone switchboard o Email & Calendar
Access right services o set up user rights
o change user login or password o restrict access
o WLAN access o remote connection
All the services contain the following information: service group, service descrip-tion, supporting services, service access point, service owner, service manager, end-user scope, service providing unit, business impact, business priority, Service Level Agreement, service hours, escalation path, reporting policies, last review date and outcome. Service catalog with exemplary services is in appendix 3.
Implementation of services should start as soon as possible, as development of other processes builds on these services. After implementation service catalog, services become visual for customer and IT staff. The service catalog works as a window for the corporation to observe performance of IT organization. Also IT organization will understand the quintessential objective of their work and act ac-cordingly.
Service catalog is suggested to be implemented into IT ERP, as it functions as the engine of IT Organization. Customer-interface can be built to intranet webpage or as bought module of IT ERP. For deciding whether intranet webpage or IT ERP is a right choice for customer’s service catalog, evaluation of the customer interfaces should be done. Customer interface should be extremely visual to enhance
intui-tive choosing of correct service group. Also service hierarchy should be flexible and the same services might be found from more than one service group, so that customers don’t have to search the whole catalog to find a distinctive service.
Search function could also be considered. As the catalog is going to be a pilot ver-sion, customers should be invited to further develop the catalog, for example by adding feedback and survey functions.
For maintenance of service catalog, performance monitoring and development procedures need to be clear. Performance monitoring can be done according to service hierarchy. Services performance can also be evaluated according to other management processes. For example efficiency of solving incidents related to CRM could be monitored or success rate of changes related to CRM. Service cata-log is recommended to be maintained via Change Management. Service catacata-log achieved capability level 2, as it fulfills the specific objectives of the process.
9.4 IT Service Management process modeling
Good modeling principals were followed according to the theoretical process management framework of chapter 4. A map of processes and process charts were described and modeled.
After the identification of service management processes, a process modeling team was set up. It contained process designer, quality inspector and process man-agers. Top down mechanism was used in the process modeling starting from the process map of IT Service Management. Case company’s business process model-ing framework was used for benchmarkmodel-ing purposes and corporate terminology and rules for process modeling were applied.
The design includes three different description levels: process chart, concept chart and work instruction. All relevant views were listed with documentation explain-ing the objective of them. Then existexplain-ing process charts were matched to process requirements. After that existing models were analyzed by using process models and modeling practices of ITIL, CMMI, WIBAS, Effective IT Service
Manage-ment book by Rob Addy (2007) and corporate business process developManage-ment team, as references for benchmarking. Suitability of reuse was evaluated and po-tential improvements were identified. Some necessary and several useful variants were modeled. Distinctive service request concepts were necessary to model as customers have four different contact points for services. Several fulfillment con-cepts for Change, IT Asset, Access and Incident Management were designed to improve efficiency of these processes. For example, in Change Management it is necessary to separate standard changes from major changes as explained in the theory. Every activity was laid to a certain role to show person or entity responsi-ble of it. After the processes were designed, quality inspector assessed them and corrections were made. After that process simulation for each IT service was car-ried out with the process manager and after the simulations were successfully ex-ecuted, final validation by 2nd quality inspector was done. Simulation was done for services provided from or within Finland and therefore new requirements, which demand tuning the processes, are expected to emerge when the processes are implemented in other countries.
To improve handover between processes, clear Operating Level Agreements are advised to be implemented. Process objectives, input and output are described in the chapters below. Symbols used to describe process elements are described in Appendix 2. Entry and exit points also identify interfaces between different con-cepts. Appendix 2 also contains process chart and an exemplar concept chart to describe the process architecture.
9.5 IT Service Management process design
Designed ITSM Process map can be seen in below in the figure 21. Objective of it is to describe the overall goal of IT organization, delivering IT services, covering the process from customer to customer as advised by Laamanen & Tinnilä (2002, p. 75 - 83). Service delivery process contains those ITSM processes that partici-pate directly in the service delivery. It is divided into three different steps: service request, request fulfillment and request closure. In addition to service delivery process, the process map contains supporting processes. Supporting processes
par-ticipate only indirectly supporting the service delivery process. As shown in the figure below, Service Request Management, Incident Management, Change Man-agement, IT Asset Management and Access Management are fulfillment processes and Configuration Management, Release Management and Problem Management are supporting processes.
Figure 21 Process chart level
As can be seen from the figure above, none of the IT Service Management processes are modeled individually. Instead, Service Request Management is cho-sen as the high level perspective. Concept charts can be identified from process chart level. As figure 21 shows, altogether 18 concepts were modeled. Appendix 2 contains exemplar concept chart. In concept chart level, horizontal cross-functional flowchart design was chosen. Work instructions are linked to activities on concept chart level. For example if concept chart has an activity “closing ser-vice request”, work instruction will tell on detailed level how to close the serser-vice request. Work instruction is not format dependent. It can be for example written or presentation document.
Designed IT Service Management (ITSM) process management solution is sug-gested to be implemented as a part of corporate process library. For the corpora-tion to achieve full benefits of ITSM process management solucorpora-tion, IT organiza-tion should apply it in training of new IT staff, development of IT services and performance measurement of IT organization.
9.6 Service Request Management
The core of IT Service Management is managing service request. Therefore, the whole process map is designed from Service Request Management point of view, as described in chapter 9.5 IT Service Management process design.
Service request are managed in the Service delivery process that contains three steps: requesting services, fulfilling requests and closing requests. First step is re-ceiving service request. After that are the fulfillment concepts of Change, Inci-dent, Asset and Access Management, and finally are the service request closing concepts. Objective of Service Request Management process is to fulfill requests according to agreements and have minimum amount of re-opened service request.
Receiving and closing concepts have the sole objective to manage service re-quests. Performance of concepts and service delivery process are advised to be reviewed on monthly basis. Process achieved capability level four as it is standar-dized according to corporate standards and has clear objectives and ownership in place.
Service request concepts are IT ERP concept, Access Management application concept, Service Desk concept and Key User concept. Request closure concept is called Request closure concept. Service request concepts are named according to point of contacts for customer to request services. In other words customer can request service from Service Desk, by using Access Management Application, directly by typing request to IT ERP or by contacting Key User. Key User is a employee of IT organization. Role description of Key User is to support all other employees in IT related challenges. Service request concepts have three main
ac-tivities: logging requests, categorizing and prioritizing requests and fulfilling or allocating requests. Input is IT related need and output is allocated service request ticket or fulfilled request.
Requests have also three possible closures. All requests do not enter a service re-quest concept, instead they can be closed before. First of all, if rere-quest is typed to IT ERP, it will be closed in the system as well. If however Key User solves the service request or service request is request for access to software, IT ERP does not receive service request and therefore it cannot be closed in the system. In the case of Access Management application, a formal service request is created and closed within the application, but the data is not updated to IT ERP. Key Users do not type request that they can solve themselves to IT ERP as it is seen inefficient to record them. Input is a request with resolution and output closed request and PIR for major incidents and new service request ticket if requester was not satis-fied with the resolution of service request.
Other improvements that are recommended for the IT organization are:
1) Harmonization of service request categorization and prioritization 2) Implementation of follow up function for service request
3) Designing and implementing a common performance measurement system for service requests (requirement for next capability level)
4) Implementing SLAs for business
5) Setting up a common place for all Service Desk instructions within the IT organizations
9.7 Incident Management
Two Incident Management concepts were modeled: incident resolution concept and major incident resolution concept. Objectives of the concepts are to solve in-cidents as fast as possible with minimum harm to business and have as few reo-pened incidents as possible.
Incident resolution concept is the main channel for incidents. It has three major activities: reviewing ticket, investigating and diagnosing incident, and solving or reassigning incident. Major incident resolution concept has some differences compared to incident resolution concept. First of all, incident manager participates actively in the concept. The manager reviews tickets and if the criticality of dent is confirmed, organizes resolution group for the incident. None of the inci-dents are left open, instead, they are allocated to top management if resolution is not found within an appropriate time frame.
Incidents, excluding the ones that Key Users solve, are recorded as service request for IT ERP. Input, for the concepts is a service request categorized as incident or major incident. Outputs of the concepts are incident ticket updated with resolution or information explaining why it was not solved and possibly a change ticket if change is required to solve the incident. Incident Management achieves capability level four with this design, as it is standardized according to corporate standards and has clear objectives and ownership in place.
Other improvements that are recommended for the IT organization are:
1) Common performance measurement for IT organization 2) Harmonize categorization and prioritization of incidents 3) Clear SLAs for all purchased services
4) Implement formal OLAs
5) Use of knowledge management database
9.8 Problem Management
A single Problem Management concept was also designed. Objective of Problem Management is to detect underlying causes of incidents and resolve and prevent problems. Problem Management concept comes into play when the root cause of incident cannot be identified. Problem record is then created to IT ERP and matched to Known Error Database. If a match is found in the database, related incidents can be updated and closed, if open, and if not, then problem record will be in the queue waiting for investigation and diagnosis. If solution is found after
the investigation and diagnosis, problem ticket and related incidents are closed and the solution is implemented. If solution can not be found, Known Error record is created and problem ticket is updated and left open. Input for Problem Man-agement is incident with unidentified root cause and output identified root cause and possibly a new Known Error record.
To achieve support from IT staff for allocating time for Problem Management, IT management should analyze IT organization for existing problems and solve one of them. And after the resolution of the problem, present how the problem solving eases overall work of IT organization. In this way it is easier to achieve support for allocating time for Problem Management. In addition it is important to allocate time for proactive Problem Management to analyze trends of incidents. To achieve capability level two the IT organization needs to also:
1) Develop work instructions for the processes 2) Establish database for problem records 3) Establish database for Known Errors
9.9 Change Management
Change requests are classified as standard, major and emergency change. Each change type has an specific concept. Objectives of Change Management are effi-cient and faultless implementation of changes and minimization of service out-ages. Standard changes are changes with preauthorized acceptance. All standard changes should be placed in a single document or database. Major change concept deals with changes that need additional authorization from CAB and service own-er. As opposed to standard change, major change requires risk assessment, possi-ble testing and post implementation review. Emergency change is a change with top priority. Concept is similar to major change concept, but lighter and faster to execute than major change. For example investigation approval is not needed and Change Advisory Board acts more quickly. Also as soon as decision on approval is done the change requester is called and notified of the resolution. Input for change concepts is a change record. Output of change concepts is approved or
de-clined change, possible implementation and updated change record. Designed process fulfills objectives of CMMI’s defined process.
Other improvements that are recommended for the IT organization are:
1) Implement common database for changes
2) Create performance measurement system and monitor Change Manage-ment
9.10 Release Management
As mentioned earlier, Release Management procedure for ERP development has been modeled. The model was extended with minor modifications to be Release Management of the whole IT organization. Objective of Release Management process is same as with Change Management - efficient and faultless
As mentioned earlier, Release Management procedure for ERP development has been modeled. The model was extended with minor modifications to be Release Management of the whole IT organization. Objective of Release Management process is same as with Change Management - efficient and faultless