Itil Problem Management Report6

ITIL Readiness Report
For
Information Technology and Management Support Division Charles Darwin University
Prepared by CSM Technology 20 Catterthun Street Winnellie NT 0820 4 March 2005 CUSTOMER REVIEW DRAFT
ITMS Division, Charles Darwin University
Contents 1 EXECUTIVE SUMMARY .................................................................................. 3 2 INTRODUCTION .............................................................................................. 6

2.1 2.2 2.3 2.4 2.5 Background .......................................................................................................... 6 Purpose ................................................................................................................. 6 Approach............................................................................................................... 6 ITIL ......................................................................................................................... 6 Definitions............................................................................................................. 8
3 CURRENT ENVIRONMENT ............................................................................. 9 4 ITIL READINESS ........................................................................................... 12

4.1 4.2 4.3 4.4 4.5 4.6 4.7 Service Desk ....................................................................................................... 12 Incident Management ........................................................................................ 16 Problem Management........................................................................................ 22 Change Management ......................................................................................... 24 Release Management......................................................................................... 30 Configuration Management............................................................................... 35 Notes on Service Delivery Disciplines............................................................. 38
5 INITIAL RECOMMENDATIONS ..................................................................... 42 6 CONCLUSION................................................................................................ 45
Prepared by CSM Technology 4-Mar-05
CUSTOMER REVIEW DRAFT
EXECUTIVE SUMMARY
This report describes the findings of the Information Technology and Management Support (ITMS) Divisions review of current service delivery practices in comparison with ITIL best-practice. The report provides recommendations as to which steps could be taken to bring current practice closer to ITIL best practice. This report was prepared by CSM Technology for the ITMS Division. Approach The review was conducted by:
! ! !
interviewing key ITMS managers and operational staff examining process documentation and documenting current practice comparing the current practice to ITIL best practice.
A total of three days was spent on initial information gathering with a further four days spent analysing the results. The review focuses on the day-to-day operational support activities performed by the ITMS Division. This corresponds to the ITIL Service Support processes. Review Findings The following examines each of the reviewed ITIL disciplines in turn.
!
Service Desk. The ITMS Division has a Service Desk which provides end-users with well-publicised contact points. While this report has found areas which can be improved on, specifically in ensuring the Service Desk is the single point of contact and that it is accountable for all incidents and service request resolution, the substantial part of the Service Desk function is in place. Incident Management. In spite of the drawbacks of its current Service Desk System, Incident Management as performed by the ITMS Division has all the fundamental elements in place to achieve ITIL practice. However, it is prevented from doing so for two reasons. The first is that insufficient workload information is captured and reported on. This makes it difficult for management to better direct effort and improve current processes. The second is that there is insufficient dayto-day hands-on operational oversight on managing queues and work allocation. Recommendations have been provided in this report addressing those areas. Problem Management. While some elements of Problem Management are currently being performed by the ITMS Division, current practice can be improved substantially by formalising and properly resourcing Problem Management activities. Change Management. The ITMS Division has recently implemented a change management process within two of its internal units. While there are some adjustments that can still be made to this process especially with regard to categorising change types, these internal units are individually very close to ITIL practice. The process now needs to be consolidated and standardised across other ITMS units to bring the whole of ITMS up to ITIL practice. Release Management. Depending on the technical activities of the ITMS units reviewed, varying levels of Release Management are practiced within the ITMS Division. The most mature release management process as used by a unit is integrated with change management as recommended by ITIL. With the
standardisation of this process across all ITMS units and the implementation of a Definitive Software Library, the ITMS division would be close to ITIL bestpractice.
!
Configuration Management. The correct implementation of configuration management requires a database that is able to record and track relationships between all elements of the IT infrastructure. While each ITMS unit maintains a configuration list of the items it manages, configuration management is performed at a very simple level due to the limitations of individual tools used. The only central tool in use, the current Service Desk system does not have the functionality required to perform the centralised configuration management required by ITIL effectively.
Recommendations The following list some of the key recommendations:

!
ITIL Training. Except for one unit manager, no other staff member had formal ITIL training. Training should be provided to all management level staff and selected senior personnel to the ITIL foundation level. Incident Management. A dedicated operational Incident Manager role should be created. The role should be solely accountable for the coordination and resolution of all incidents and service requests across all ITMS units and produce weekly performance reports on incident and service request resolution, staff workload and resource requirements. The Incident Manager role should specifically implement some of the recommendations in this report such as enforcing single-point-of-contact and logging all incidents and service requests. Reporting. Simple incident and service request reporting from the current service desk system should be implemented by allocating programming resources to simplify the data processing and report generation. With classification codes for incident for incidents and service requests, weekly reports should be generated and reviewed. Change Management. A Change Manager role should be created with the authority to approve and/or delegate change authority for all changes within the ITMS Division. Change categories need to be clearly defined and care needs to be taken to differentiate between changes which can be resourced from operational staff without impacting on day-to-day service delivery and projects which will need additional resources. Service Desk System. Implement a Service Desk System that is ITIL compliant and includes modules for all ITIL Service Support disciplines including an integrated Configuration Management Database.
Conclusions In every Service Support discipline reviewed, there are portions of the ITMS Division that is closer to formal ITIL practice than others. It should be noted however that even in those areas where no formal ITIL processes are in place, similar processes are already practiced informally by staff. Hence, in many areas, all that is required to lift current practice to ITIL recommendations is formally defining processes and training staff so that a standard and consistent methodology is followed through ITMS. The effort required for this should not be underestimated. However, the essential foundations are in place for the ITMS division to achieve ITIL best-practice. There is significant management intent and commitment, middle management has already put in place improvement measures and there is a clear recognition across all levels of the organisation that improvements can and should be made.
2
2.1
INTRODUCTION
Background
As part of its strategy to improve customer service and support, the Information Technology and Management Support Division of the Charles Darwin University is auditing major customer service activities against ITIL benchmarks to provide the basis of a service improvement plan.
2.2
Purpose
This report provides an overview of the current ITMS service support environment and compares it with the ITIL methodology highlighting the differences between current practice and ITIL best-practice. The report then provides recommendations as to which steps could be taken to bring current practice closer to ITIL best practice.
2.3
Approach
This report examines three of five ITMS units, the User Support Unit, the Data Centre Unit and the Business Systems Support unit. The review was conducted by interviewing key ITMS managers and operational staff from these units, examining process documentation and documenting current practice, mapping where possible to ITIL best-practice activities. Following this, an analysis of current practice in comparison with ITIL best practice requirements was made. A total of three days was spent on initial information gathering with a further four days spent analysing the results. Due to the amount of time available, only ITIL Service Support disciplines were looked at in detail. Detailed analysis of current processes and procedures were not undertaken and recommendations are provided as an indicative guideline to the amount of effort required. A full implementation of ITIL will require further analysis.
2.4
ITIL
The Information Technology Infrastructure Library (ITIL) is the only consistent and comprehensive documented methodology of best practice for IT Service Management. Used by many hundreds of organisations around the world, a whole ITIL philosophy has developed around the guidance contained within the ITIL methodology. ITIL focuses on the provision of quality IT services, and on the accommodation and environmental facilities needed to support IT. ITIL has been developed in recognition of organisations' growing dependency on IT and embodies best practices for IT Service Management. The ethos behind the development of ITIL is the recognition that organisations are becoming increasingly dependent on IT in order to satisfy their corporate aims and meet their business needs. This leads to an increased requirement for high quality IT services.
Prepared by CSM Technology 4-Mar-05 CUSTOMER REVIEW DRAFT
ITIL is divided into two parts:

!
Service Support focuses on ensuring that the customer has access to appropriate services to support their business functions. Service Support focuses on operational day-to-day services and covers:
#
Service Desk. The Service Desk provides the primary window for customer and end-user contact with the service organisation on a day to day basis. Incident Management. The objective of the Incident Management process is to ensure that the highest possible levels of service quality and availability are maintained. Normal service operations are restored as quickly as possible and to minimize the adverse impact on business operations.. Problem Management. This process seeks to minimize the adverse impact of incidents and problems on the business that are caused by errors within the IT infrastructure and to prevent the recurrence of incidents related to these errors. Configuration Management. This process provides a logical model of the IT infrastructure or a service by identifying, controlling, maintaining and verifying the versions of Configuration Items in existence. Change Management. The objective of Change Management is to ensure that standardised methods and procedures are used for efficient and prompt handling of all changes in order to minimise the impact of change related incidents on service quality and consequently to improve the day-to-day operations of the organisation. Release Management. Release Management covers the planning, design, build, configuration and testing of hardware and software to create a set of release components for the live environment.
Service Delivery covers the services required to provide adequate support to business users. Service Delivery focuses on higher management and strategic processes and covers:
#
Service Level Management. The objective of Service Level Management is to maintain and improve IT service quality, through a constant cycle of agreeing, monitoring, and reporting upon IT Service Achievements and instigation of actions to eradicate poor service in line with business or cost justification. Financial Management for IT Services. Financial Management provides cost-effective stewardship of the IT assets and resources used in providing IT services. Capacity Management. This process ensures that the Capacity of the IT infrastructure matches the evolving demands of the business in the most cost-effective and timely manner. Availability Management. Availability Management optimises the capability of the IT infrastructure services and supporting organisation to deliver a cost effective and sustained level of availability. IT Service Continuity Management. This process supports the overall business continuity management process by ensuring that the required IT technical and services facilities can be recovered within required and agreed business timescales.
2.5
Definitions
The following key ITIL terms are used in this document.. Incident - any event which is not part of standard operation and which causes or may cause an interruption to or a reduction in the quality of services. Service Request Every incident not being a failure in the IT Infrastructure. A service request is often a customer request for a defined service to be performed on the customers behalf. Problem - An unknown underlying cause of one or more incidents. Known error - An incident or problem for which the root cause is known and for which a temporary work-around or a permanent alternative has been identified. Service Level Agreement (SLA) A written agreement with a customer or customers that documents agreed service levels delivered. Change The addition, modification or removal of approved, supported or baselined hardware, network, software, application, environment, system, desktop build or associated documentation. Request for Change (RFC) Form or screen used to record details of a request for a Change to any Configuration Item within an infrastructure or to procedures and items associated with the infrastructure. Release - A collection of new and/or changed Configuration Items which are tested and introduced into the live environment together. Configuration Item (CI) - Component of an infrastructure or an item associated with an infrastructure that is (or is to be) under the control of Configuration Management. CIs may vary widely in complexity, size and type, from an entire system (including all hardware, software and documentation) to a single module or a minor hardware component. Configuration Management Database (CMDB) A database that contains all relevant details of each CI and details of the important relationships between CIs.
CURRENT ENVIRONMENT
Organisational Structure The Information Technology and Management Support (ITMS) Division of Charles Darwin University (CDU) comprises five main units. Most staff are located in the Casuarina campus in Darwin with some staff in Alice Springs. The main units are:
!
User Support - provides helpdesk and desktop support services. It is also responsible for building and distributing desktop images. Data Centre - provides the LAN, WAN and central hosting environment for the CDU along with all associated systems management and administration services. The Data Centre also provides and manages central office services including user authentication, file server services and email. Business Systems Support - performs software maintenance and development work for selected central business applications. Callista Team - a specialised team supporting CDUs student administration system. This team is out of scope for this report. Records - manages and administers CDUs record systems. This team is out of scope for this report.
ITMS operates on a two tiered reporting structure. All team members within a unit report to the units manager. The unit manager reports directly to the ITMS IT Director. The following diagram illustrates the organisational structure at the time of this report. Roles with indicative numbers are also provided on the third tier.
Roy Pidgeon Director, ITMS
Gary Drake Manager User Support
Pat Gould Manager Data Centre
Anthony Kelly Manager Business Systems Support
Dennis Tsang Manager Callista Team
Natalie Peters Senior Officer Records
Darwin Senior Support Officer Info Serv Support Officer Support Desk Officer (X10) Technical Support Officer (X3) Alice Springs Systems Administrator Info Systems Assistant (x2)
Systems support officers (x5) Network Officer Media Officer
Business Analyst (x4) Senior Analyst Programmer Technical Project Officer Blackboard Project Officer
Business Analyst (x3) Project Officer (X2) Statistics Officer (X2) Training and Liaison Officer (X1) Database Admin Analyst Programmer Manager Mngt System Devt Team Callista Contractor
Darwin Records Assistant Records Clerk EDM Project Assistant Mail Clerk Alice Springs Records
ITMS Services ITMS provides services to the majority of the CDUs IT environment. However, some areas are still supported by individual faculties. Specialist computer laboratories are supported by local IT specialists and the Faculty of Education, Health and Sciences maintains its own support team. The environment supported is distributed over two main campuses: Casuarina and Palmerston. Services provided are:
!
Helpdesk services to approximately 1000 FTES and 500 casual / part-time endusers. Services include fault logging and resolution, moves, adds and changes and user account administration.
Desktop PCs. The User Support Unit supports 1500 desktops with around 500 remote devices of various makes and models. The User Support Unit also maintains images and SOE applications for these PCs. Desktop PCs run either Windows 2000 or Windows XP. Included in this service is the commissioning of new PCs. Printers and Peripherals Support. The User Support Unit supports printers and limited support to other peripherals including PDAs and mobile phones. Telephone Supply and Installation. The User Support Unit and Data Centre provides and supports voice network services. Central Laboratory PC Services. The User Support Unit maintains 220 central laboratory machines over two campuses. Two images are maintained, one for each campus. Central user authentication, file and print servers. Services are provided by the Data Centre through central SAMBA servers. LAN, WAN and Internet Connectivity. The Data Centre provides all LAN, WAN and Internet connectivity services. Backup and Restore Services. The Data Centre provides data backup and restore services to end-users. Messaging Services. The Data Centre provides email services to the CDU. Security Services. The Data Centre provides network security services, virus protection on the desktop and server as well as music copyright protection monitoring services. Data Centre Hosting Services. The Data Centre provides hosting and systems management services. Systems hosted include the library system, Blackboard and various web-sites. Central Business systems maintenance and development. Systems maintained include:
# # #
! !
Callista - Student Administration System Alesco - HR and Payroll system Elvis - Financial system
10
Customers ITMS major customers are drawn from CDU and associated agencies. Major internal CDU customers are:
!
Corporate Services. ITMS provides all services to Corporate Services and maintains and manages the central CDU Data Centre and business applications. The Faculty of Law, Business and Arts. ITMS supports all desktops for this faculty with specialist local servers supported by local IT specialists. The Faculty of Technology. ITMS supports the majority of desktops for this faculty with other desktop, laboratory and data centre services provided by the Faculty of Education, Health and Sciences. The Faculty of Education, Health and Sciences. ITMS supports approximately half of the desktops. This Faculty however maintains its own data centre and runs an IT centre of between 8 to 10 staff.
ITMS also provides desktop and server support services to some associated agencies. These include:
! ! ! !
Menzies School of Health Research North Australian Research Unit Sports Association Alice Springs Secondary
11
4
4.1
4.1.1
ITIL READINESS
Service Desk
ITIL Practice
The Service Desk provides the primary window for customer and end-user contact with the service organisation on a day to day basis. The Service Desk provides a single point of contact between customers, users, IT services and third party support organisations. The Service Desk is responsible for incident control and service request fulfilment as defined by the Incident Management process (described in the next section). It is the owner of all incidents and is responsible for managing the resolution process of all registered incidents. As the owner of all service requests, the Service Desk is also responsible for managing the fulfilment process of all registered service requests. As the single point of contact, the other major function of the Service Desk is to maintain communication channels from the IT organisation to and from the customer. The Service Desk is responsible for communicating planned changes to customers. It is also responsible for representing the interests of the customer to the IT service team through various means such as customer satisfaction surveys. For the proper functioning of the Service Desk, ITIL recommends the following:
!
Clearly defined services available and understood by Service Desk staff especially where services vary depending on customer SLA Weekly management reviews held to highlight service availability, customer satisfaction and major incidents areas. A service desk system that can report effectively on incidents and service request performance Regular customer satisfaction surveys.
The Service Desk function is managed by the Service Desk Manager.
4.1.2
Current Practice
The ITMS Service Desk provides operates between 7am and 6pm on weekdays with staff on-call to 9pm. It accepts end-user requests via phone, email, online via the web and fax. It also staffs a Service Counter where students may queue to request services. The Service Desk in practice consists of two formal support lines and an external service provider support line as follows:
!
The first line support, referred to internally as the Helpdesk Team, accepts and logs incidents and service requests and staffs the Service Counter. The first-line has between 2 to 4 staff rostered to handle peak demand periods in the morning, around lunch time and just before the end of the day. During peak periods especially at the lunch time period at the beginning of semester, the Service Counter can have a long queue of up to 15. First-line staff are expected to answer calls while serving the counter. During off-peak periods, staff are expected to complete certain service requests. The first line also refers calls to other service providers such as the Faculty of Education, Health and Science.
12
The second line support completes logged incidents and service requests attending on-site where necessary. It consists of two major units:
#
The Desktop Support Team which has between 4 to 6 staff. Second-line staff are seated with first-line staff but do not provide backup phone support for first-line staff. A permanent staff member is rostered at the Menzies School of Health Research. Second-line staff are also expected to work on projects. Other ITMS units consist of the Data Centre Unit, Business Support Applications and potentially the Callista Team. Staff within these units receive requests from the first-line in the form of logged jobs or informally through email, phone or direct contact. This line also receive incidents and service requests directly from end-users bypassing the first-line entirely.
The third line consists of all external third-party service providers such as the telecommunications service provider or hardware manufacturers.
4.1.3
ITIL Readiness
Single Point of Contact The Service Desk contact details are well disseminated and publicised within the CDU. As well, the Service Desk provides end-users with multiple ways of contacting the ITMS division. This provides end-users with flexibility and choice. Staff are also aware that the Service Desk should be a single point of contact for all end-users. However, there are some end-users who directly contact second-line support staff as a first point of contact. While direct communication is in itself acceptable, it is important to determine that incidents and service requests are not directly requested of second-line staff as these should be logged at the first-line and assigned appropriately. Responsibility for Incident and Service Request The User Support Unit currently has responsibility for logging incidents and service requests. It maintains responsibility for the completion of desktop related incidents and service requests while the completion of other incidents and service requests are left primarily to the Data Centre unit. In practice, this results in the User Support Unit treating all other internal ITMS units as third-party service providers. This effectively divides responsibility for the completion of a logged job and can potentially reduce response times. ITIL recommends that the User Support unit has responsibility for all incidents and service requests by coordinating, tracking and monitoring the completion of all tasks and be empowered to report on the job resolution performance of other internal units. Defined Services The ITMS division currently maintains a list of services and fault prioritising metrics on its web-site. The ITMS division also provides electronic versions of service request forms that can be downloaded by end-users. Together, this information provides customers and staff with an indication of the services provided. The ITMS division currently provides different levels of services to some of its customers. Service Desk staff should be aware of the types and levels of services provided as well as the scope of these services.
13
Weekly management reviews The ITMS division currently runs a fortnightly management meeting which is timed with the directors meeting. This meeting covers:
! ! ! ! ! !
Information and decisions of the board meeting Strategic direction and implication A report on security incidences if any Performance monitoring report for uptimes and WAN linkages Communication opportunities Quality reviews for audit purposes.
The fortnightly meeting is similar to the ITIL recommended weekly management review. However, ITIL recommends the following areas as well:
! ! ! !
Incident and Service request reports including resolution and workload statistics Major incidents Customer satisfaction Staff workload
Service Desk System The current service desk system provides some basic functionality which is not fully utilised. However, it does not meet ITIL requirements especially in regard to reporting. While the current User Support Manager is able to produce some annual reports on Service Desk activity, the process is labor intensive and extremely timeconsuming. The ITMS Division recognises the limitations of its current Service Desk system and is currently in the process of developing requirements for seeking a replacement Service Desk system. As an interim measure, the current service desk system should still be able to quickly and easily provide information on incidents and service request statistics as it appears that the elements are in place for this to be done:
! ! !
The system is able to track total elapsed time taken per job. It permits logged jobs to be classified. It can export raw data in Excel format.
With appropriate job classes entered, the following simple reports can be generated with less effort especially if some programming effort is spent creating automatic scripts to pre-process the exported data:
! ! !
Incidents and Service requests logged by job class over time Open incidents and service requests grouped by elapsed time and job class Closed incidents and service requests grouped by elapsed time and job class
Customer Satisfaction Surveys ITIL recommends that periodic customer satisfaction surveys are conducted. This is currently not performed.
14
4.1.4
Recommendations
!
Send all management level staff and selected senior personnel on the ITIL foundations course. Enforce single point of contact for the Service Desk by clearly defining communication guidelines to all staff and customers. Note that this should include all jobs for the Menzies School of Health Research support person as well. Create an Incident Manager role (see next section) situated within the Service Desk who is solely accountable for the coordination and reporting of all incidents and service requests. Define services provided by ITMS and make available to Service Desk staff for reference. Educate Service Desk staff as to levels of services provided to different customers where these vary. Hold a management review meeting every week and add incident and service request reports to the agenda. Implement simple incident and service request reporting in the current service desk system by allocating programming resources to simplify the data processing step which is currently performed manually. Hold customer satisfaction surveys annually and report results both internally and externally. Start with a pilot satisfaction survey for ITMS use only. Implement a Service Desk System that is ITIL compliant and includes modules for all ITIL Service Support disciplines including an integrated Configuration Management Database.
15
4.2
4.2.1
Incident Management
ITIL Practice
ITIL defines an incident as any event which is not part of standard operation and which causes or may cause an interruption to or a reduction in the quality of services. The objective of the Incident Management process is to restore normal service operation as quickly as possible and to minimise the adverse impact on business operations, ensuring that the highest possible levels of service quality and availability are maintained. Included within this process is service request fulfilment. As described in the previous section, the Service Desk is responsible for this process and maintains ownership of all incidents and service requests. Response and resolution times should be specified and agreed. The fundamental process steps that need to be in place for Incident Management are as follows:
!
Recording All incidents and service requests must be logged. This is critical for workload planning, trend analysis and service level performance tracking. Classification Class codes form the primary reporting matrix of the environment. All incidents and service requests must be placed in a class. Classification also allows staff to specify the service or equipment type, associated SLAs (if any), and selected staff or group to delegate to. Prioritising Prioritising should be done by the impact on the business and the urgency. Impact should be a measure of business criticality of an incident. It is often measured by the number of people or systems affected. Urgency measures the necessary speed required for solving an incident or service request of a certain impact. Resolution Resolution should be performed with the aid of appropriate tools such as access to manuals and documentation as well as access to a Known Error database. Escalation - Two escalation venues exist: functional escalation and hierarchical escalation. Service Desk staff often form the first and second line escalation paths with more specialised groups or third party suppliers forming the other lines. The Service Desk remains responsible for functionally escalated incidents and service requests. Hierarchical escalation takes place when it is likely that a resolution action will not be in time or will be unsatisfactory. This often involves higher level management. Closure Service Desk staff are responsible for closing incidents after confirming its satisfactory resolution with customers. Access to incident closure should be restricted and controlled. Incident closure codes are also recommended.
ITIL also specifies that during a Major Incident, an incident with a degree of impact that is extreme to the user community, Incident Management should coordinate support staff and IT services management, holding meetings with affected parties as required to review progress and determine the best course of action. The Incident Manager is responsible for the Incident Management process and is often an operational hands-on role.
16
4.2.2
Current Practice
As described in the previous section, the ITMS Service Desk consists of two formal support lines and an external service provider support line. Together these support lines perform Incident Management as follows. First-line support First-line support is provided by the User Support Unit staff rostered to the Helpdesk Team. First-line support staff on receiving a call from an end-user will attempt to resolve the call. If resolution is successful, first-line support staff may not log the call especially if this is during peak periods. Counter jobs which are immediately resolved are also not logged. However, if the job cannot be resolved at that point, it is logged. First-line support staff will obtain more details and assign the job a priority of one to six. Priority levels three and above generate email to the User Support Manager or the Data Centre Manager. These priorities also automatically assign a deadline to the logged job based on the fault priorities defined for ITMS services. The jobs are then assigned either specifically to a queue if the job is the responsibility of units external to the User Support Unit or left in the unassigned queue for Desktop Support staff. The first line also refers calls to other service providers such as the Faculty of Education, Health and Science. These are considered independent and separate services that do not require further tracking or monitoring. Currently around 25 jobs are logged per day. Second-line Support Second-line Support is provided by the User Support Unit staff rostered to the Desktop Support Team and also by Data Centre Unit staff and Business Systems Support staff through the following methods:
!
Service Desk system queue. Each member of the Desktop Support team periodically checks the unassigned job queue for unassigned jobs. Assigned jobs are moved to individual staff queues for completion. On resolution, these jobs are closed directly by staff with the system capable of sending validation emails. Automatic notification via email. Assignment to certain queues directly emails the Data Centre Unit or Business Systems Support depending on the type of queue. Direct escalation from first-line support. Desktop Support teams occasionally directly escalate to Data Centre personnel by either phoning, emailing or physically asking Data Centre staff.
17
Direct contact from end-user or from systems monitoring. Data Centre and Business Systems Support staff are often directly contacted by end-users. These jobs are not logged in the Service Desk systems although each unit have their own ways of tracking these jobs:
#
Business Systems Support maintains a job spreadsheet tracking incidents and service requests in progress, the status and the person assigned. Currently 40 incidents and service requests are listed in this spreadsheet. The Data Centre unit maintains a whiteboard system for tracking incidents with each incident currently detected noted on a whiteboard. Only minimal details are recorded with assigned person and date not noted. The Data Centre unit also maintains a spreadsheet tracking projects currently under way.
Third-Line Support The third line consists of all external third-party service providers such as the telecommunications service provider or hardware manufacturers. Third-line support is currently handled and managed as part of resolving the incident or service request. Third party response times and time spent waiting are not recorded.
4.2.3
ITIL Readiness
Recording While staff recognise that all incidents and service requests should be logged, in practice, this does not happen at the following levels:
!
During peak periods, first-line staff do not log jobs that are quickly resolved and may only log jobs that need further attention. They also do not log Service Counter jobs. Second-line staff when out on-site visits may not log impromptu end-user requests. Second-line staff who are directly contacted by end-users do not log these incidents or service requests.
The reasons cited for not logging jobs were predominantly to do with the amount of labour required for job logging. As well, current practice is to log a job for every task in a batch job, for example, adding an application to 25 desktops would generate 25 jobs. While this captures the amount of effort required for a batch job, it also increases the labour required. Batch job effort may be better captured using either class codes or initiating a project. ITIL specifies that all incidents and service requests regardless of effort must be logged. Classification While the present Service Desk system has two keyword fields that can be used as classes, logged incidents and service requests are not classified. ITIL specifies that classification is one of the most important aspects of Incident Management as amongst other reasons, it determines the primary reporting matrix for management information.
18
While further investigation will be required, a possible classification code schema that may be appropriate to ITMS is as follows: Keyword 1 Service Request Keyword 2 (examples) Password Reset Form - Quota Upgrade Form - Lab Account Creation Form - Phone Billing Authority Desktop Laptop Printer Network Server Supported Application External Application Microsoft Office
Fault
Help user Prioritising
The current priority code system of 1 to 6 is close to ITIL practice. ITIL does recommend that priorities are based on impact and urgency but it appears that the current system takes those into account. In all three ITMS units reviewed, staff are expected to prioritise tasks themselves following allocated priority codes and deadlines. In practice, all staff prioritise reactively with highest priority allocated to customer incidents, followed by logged service requests or incidents in the job queue. Projects are not prioritised and hence are given the lowest priority unless staff are reminded by the current units manager. In the User Support unit, while the current User Support Manager may allocate or assign jobs from the unassigned queue, this is not done regularly. Staff generally assign jobs themselves. Also, it is uncertain as to whether assigned queues are monitored regularly. In the Data Centre, job queues are not used except for those jobs logged from the Service Desk. No formal priorities exist outside of the queues. It is difficult to estimate how effective prioritising is as it is up to individual staff work-practices to selfprioritise. Given that Data Centre staff work concurrently on multiple incidents, service requests and projects of varying and sometimes conflicting priorities, it is recommended that greater management oversight and a formal priority system is implemented. The combined effect of this is that while a priority code system exists, it is not being utilised consistently or effectively. Resolution While detailed standard operating procedures documented in MS Word files appear to exist for common service requests, staff do not appear to have access to a searchable knowledge base that lists common resolutions and workarounds for common incidents. There does exist a knowledge base in the current Service Desk system but this does not appear to be used.
19
Staff however are fully aware of the benefits of a knowledge base and would use one if it existed. One staff member reported using an existing knowledge base from a previous workplace. However, any knowledge base implemented would need to be used and populated by at least the User Support and Data Centre units in order for it to be useful. Escalation Functional escalation is currently performed from the first-line to the second and also in between different units within the second-line. Where existing job queues are used, functional escalation conforms to ITIL practice especially where jobs are escalated internally within the User Support Unit from the Helpdesk Team to the Desktop team. The impact of the rotation schedule on escalated jobs needs to be investigated particularly at the handover of jobs on the second-line. There also appears to be multiple informal escalation processes that do not involve using job queues in the existing Service Desk system. This is due partly to the cumbersome nature of the Service Desk system itself and partly because it is not common practice for other ITMS units to check job queues. This results in confusion on the part of User Support staff as to when and how to escalate when escalation procedures are not clear. Business Systems Support staff also often escalate tasks to Data Centre staff. In this case, no formal and defined escalation processes exist from Business Systems Support to the Data Centre. The result is that Data Centre staff are often consistently interrupted in an uncontrolled fashion by staff from other units. Escalation to third-line support or third-party support is not tracked and is handled as transparently as part of the original logged incident. ITIL recommends that performance statistics on third-party services be kept to realistically record true effort spent internally and also to monitor third-party response. Currently, no formal hierarchical escalation processes are in place. This is partly because the existing Service Desk system does not have any automatic alerts in place when agreed resolution or response times are threatened. This is mitigated in part as the logging of priority 1,2 and 3 jobs automatically alerts the User Support Manager or Data Centre Manager. Closure Incident closure is performed by the staff performing the resolution whether this is on the second or third line. The existing Service Desk system can automatically email confirmation messages to specified end-users asking for them to confirm closure by clicking on a link in the email. This measure has met with limited success as many end-users do not respond. ITIL recommends that incident closure be tightly controlled with closure authority delegated depending on the class of incident.
20
4.2.4
Recommendations
!
Ensure that all incidents and service requests are logged through the Service Desk which should be the single point of contact. For this to succeed management support will need to be obtained. Emphasise that this is required for performance monitoring and workload tracking. Implement classification codes for incidents and service requests. In the short term this can be done by using the keyword fields within the existing Service Desk System. Classification codes are required for meaningful management reports. Create a dedicated Incident Manager role on the operational level with the authority to prioritise, assign and escalate all incidents and service requests. Initially, make the Incident Manager the sole escalation point from first-line to second-line. This will enable holistic prioritisation of incidents and service requests, control and simplify multiple escalation paths, clarify escalation processes and insulate Data Centre staff from unnecessary interruptions. The Incident Manager should also be charged with reducing on-site support visits and produce weekly performance reports on incident and service request resolution, staff workload and resource requirements. Note that project work is out of scope of ITIL. Roster duty engineers from the Data Centre to be on second-line support and rotate these duty engineers through. This should shield other engineers from interruptions and permit them to focus on project work or other duties. Implement an integrated searchable knowledge-base. Encourage all staff members to use this especially from the User Support and Data Centre units. Consider providing recognition to staff who perform the majority of updates to the knowledge base or who create entries that are most used. Only allow first-line personnel or the Incident Manager to close incidents. Implement a Service Desk system that permits incidents to be halted while waiting validation so that time spent waiting is not counted towards resolution times. Conduct Major Incident Reviews that includes all operational staff to review what happened, why it happened and to seek improvement in processes and to share any knowledge gained.
21
4.3
4.3.1
Problem Management
ITIL Practice
ITIL defines a problem as an unknown underlying cause of one or more incidents. Problem Management seeks to minimise the adverse impact of incidents and problems on the business that are caused by errors within the IT infrastructure and to prevent the recurrence of incidents related to these errors. This is achieved by discovering the root cause of incidents and then initiating actions to improve or correct the situation. In IT organisations, specialist groups outside of the Service Desk are often responsible for Problem Management. The fundamental processes that need to be in place for Problem Management are as follows:
!
Problem control. A process needs to be in place to identify the root cause of incidents and provide Service Desk with workarounds where workarounds have not already been found or improve existing workarounds. Problem control requires that problems are classified, prioritised and managed. When the root cause and a workaround is identified, the problem becomes a known error and the next process step applies. Error control. Known errors, once found by problem control need to be eliminated when feasible and the cost is justified. Error control should be acted on based on priority and impact and in accordance with Change Management processes. Proactive Problem Prevention. Through periodic trend analysis, Problem Management should identify fragile components, target support action and provide information to the organisation on potential problems.
The Problem Manager is responsible for the Problem Management process. Often this role falls under the responsibilities of a senior technical resource or an Operations Manager outside of the Service Desk. NOTE: It is common to mistake Problem Management as a second or third tier of the Incident Management process. Problem Management is a separate process to Incident Management. Incident Management is focused on getting the user operational as quickly as possible through applying quick-fixes, work-arounds or common resolution actions. Problem Management works to improve those workarounds or applying permanent fixes to underlying causes of incidents. Problem Management is NOT involved directly in getting users operational.
22
4.3.2
Current Practice
The Data Centre and User Support units have access to automated system monitoring and management tools which alert staff in the event of failure. This enables some proactive problem prevention to take place. In general problem resolution activities are predominantly performed as part of the incident management process. Current practice significantly depends on the staff involved. It could vary from applying quick fixes to get the end-user operational without then recording or working on the underlying cause; to staff working on the underlying cause while neglecting to get the end-user operational thus unnecessarily extending the end-users down-time. Some staff perform incident trend analysis but very informally and inconsistently.
4.3.3
ITIL Readiness
As described above, ITIL requires that strict separation between problem and incident management. This confusion between problem and incident management is common to many organisations. As very few elements for Problem Management are currently in place, the ITMS divisions problem management practice can be substantially improved. However, it should be noted that Problem Management will not be difficult to implement as most staff already practice aspects of Problem Management in their operational duties.
4.3.4
Recommendations
!
Train staff in differences between incident and problem management emphasizing that incident resolution should focus on getting the end-user operational as quickly as possible while problem resolution focuses on fixing the underlying cause of the incident. As a short term measure, implement a problem queue in the current system which is used to record detected problems. Note that if this is implemented, a new problem record needs to be logged, incidents must not be assigned to the problem queue. Initially only allow the duty engineer and the Incident Manager to create problem records. Set aside time for problem management activities each week. For example, to start with, the recommended duty engineer could be rotated into a half-day per week of problem management duties after their incident management shift. The duty engineer would then either work to resolve problems or analyse existing incidents to create problem records. Allow the recommended Incident Manager to create problem records as part of their operational activities. Report on problem management activities to monitor progress. Implement a knowledge base to trap and record results of problem management.
! !
23
4.4
4.4.1
Change Management
ITIL Practice
ITIL defines a change as the addition, modification or removal of approved, supported or baselined hardware, network, software, application, environment, system, desktop build or associated documentation. The objective of Change Management is to ensure that standardised methods and procedures are used for efficient and prompt handling of all changes in order to minimise the impact of change related incidents on service quality and consequently to improve the day-to-day operations of the organisation. The scope of Change Management covers hardware, system software, live application software and all associated documentation. Note that Change Management manages day to day change and is no substitute for project specific methodologies like PRINCE2 or for software development methodologies. Instead, Change Management may be involved in the initiation of projects during which those other methodologies apply. Change Management will then apply when projects are completed and handed over for day to day operational support by the IT organisation. All changes to the environment require approval by the Change Manager with advice from the Change Advisory Board (CAB) through Change Meetings. The CAB may vary according to the changes being considered and should involve suppliers, customers and user views. CAB meetings are convened by the Change Manager and can be performed virtually through email or support tools with formal meetings only for major changes. Note that the CAB is an advisory body with the final decision the responsibility of management. In most cases this is the Director of IT and/or the Change Manager as delegated representative. The fundamental processes that need to be in place for Change Management are as follows:
!
Change logging. All Request for Changes (RFCs) must be logged. ITIL recommends that all members of an organisation be authorised to request changes. RFCs are often generated from Incident Management or Problem Management when changes are required to resolve an Incident or Problem. Change Prioritisation. RFCs should be prioritised based on the impact and urgency of the change needed. This determines the order of RFCs considered by the CAB. ITIL defines four priority types: immediate, high, medium and low. Immediate changes, commonly known as emergency changes, require an urgent CAB meeting to be convened.
24
Change categorisation and approval. RFCs should be categories based on the impact due to Change. As the approval requirements often depend on the change category, categories should be predefined and followed closely. The change categories are:
#
Standard change. These changes are identified minimal risk changes that need to occur as part of standard operation for which no or only minimal approval is required. Examples include password changes or account moves. Minor impact only. These changes may also require few build or additional runtime resources. Authority to approve these changes can be delegated by the Change Manager to others to authorise and schedule these changes Significant impact. These changes may also require significant runtime build or runtime resources. The CAB needs to be convened by the Change Manager to approve and schedule these changes. Major impact. For these changes, the RFC should be referred to the organisations Management Board with approval back to CAB for scheduling and implementation. Often these changes will result in projects being initiated.
Change scheduling. Changes should be scheduled into target Releases. The Change Manager should issue a Forward Schedule of Changes detailing which RFCs are being released and when. Change building, testing and implementation. Following approval, authorised RFCs are passed to various technical groups for building. The Change Manager, supported by Release Management, plays a coordination role overseeing change management and is responsible for ensuring changes implemented as scheduled. Change Review. Following a suitable period after implementation, all implemented changes must be reviewed with problems and discrepancies fed back to CAB.
The Change Manager is responsible for Change Management. ITIL specifies that the Change Manager should be a senior level manager. Note that the Change Manager may delegate change authority to other staff.
25
4.4.2
Current Practice
Of the three units reviewed, formal change control processes have been put in place for the Data Centre and Business Systems Support Units. No formal change control processes are in place for the User Support Unit. User Support While there are no formal change control processes, some changes to desktop programs and all changes to images require approval from the current User Support Manager before they are implemented. These change records are kept as the original user request forms. While the Data Centre Manager is consulted if out-of-theordinary desktop programs such as server applications are requested for installation, there are no formal processes to inform the Data Centre of any changes that may affect central systems. Data Centre A change control form and process has been implemented recently and has been in operation for a few months. The change control form captures most of the information required by ITIL. Change control forms are defined as required for nonday-to-day tasks. Currently three to four changes a day are implemented. However, as the change control process is new, not every staff member uses it yet. When changes are required, staff members fill in the change control form and lodge the form with the Data Centre Manager for approval. The Data Centre Manager verifies that the form has been filled correctly, consults with Business Systems Support if required, approves the change and re-schedules if needed. Completed change control forms are kept as records. Changes are then implemented by person at scheduled time. To communicate implemented changes internally and to Business Systems Support, changes once implemented are updated on the whiteboard with the date of the change recorded. This is used as a reference for other activities including incident management. This change record only stays up for a limited time before it is removed. Note that upcoming changes are not formally published internally although outage notices are distributed to customers. The interface between the Data Centre and the Service Desk for communicating changes appears to be inconsistent. This occasionally results in the Service Desk not being informed of upcoming interruptions to Data Centre services. As well, the Service Desk is sometimes not informed of changes to the desktop operating system. Business Systems Support The same change control process is currently being implemented in the Business Systems Support Unit. The current Business Systems Support Manager will approve changes originating from within Business Systems Support ensuring that any changes affecting the Data Centre will be communicated through to the Data Centre Manager for approval before the change is implemented. To communicate implemented changes to the Data Centre, implemented changes are updated on the whiteboard with the date of change recorded.
26
4.4.3
ITIL Readiness
The current change control process used by the Data Centre Unit and the Business Systems Support Unit is close to ITIL practice. However, this process will need to be used by all units within ITMS with overall responsibility for all changes given to a single Change Manager. The Change Manager may delegate change authority to other staff. The following details each process step. Change Logging ITIL recommends that all changes must be logged. Every unit in ITMS should be using the change management process and logging changes. The format of the Request for Change (RFC) form may vary slightly depending on the type of change required, however there should be common fields. The current change control form used is close to that required by ITIL. However, if the RFC is required to resolve an incident or a problem, it is recommended that the identification number of the job be recorded on the RFC form for tracking purposes. This should also encourage the logging of jobs. ITIL also recommends that the change process is defined and documented so that the conditions for its use, the information required in the RFC and the person approving the RFC is clear to all potential change requesters. Change Prioritisation The current change control form has a priority field that is used for the change. The priority codes appear similar to that used in Incident Management. ITIL recommends that an emergency priority is available. This can be done without changing the existing system, for example, the current priority code of 1 could be defined as an Emergency change. Change categorisation The current change control process does not include the concept of change categories. In practice however, the following change categories are in operation:
!
Standard change. These changes are not considered changes as such by ITMS staff but are instead considered day-to-day activities not requiring approval. Minor impact. Approval for these changes are handled informally through conversation. Due to its informal nature, minor impact changes are not consistently reviewed. Depending on individual staff interpretation, some staff may use the current change control process for these changes. Significant impact. Approval for these changes are generally obtained through the current change control forms. Major impact. These changes are often considered projects initiated either by the IT Director or by unit managers.
In ITIL practice, all the change categories above will need to be defined clearly so that operational staff know what a standard change is and when they need to fill in a change control form. The current change control form should be expanded to include a Change Category field to be filled in by staff. The amount of information required for each change category should also be defined so that for example minor impact changes would only need a minority of the form filled in.
27
Change Approval ITIL recommends the following:

!
Minor changes are approved by personnel with delegated change authority. This is currently done informally. Significant changes are approved by the Change Advisory Board who is convened by the Change Manager. Currently, the Data Centre Unit and Business Systems Support Unit consult with each other for certain changes. However, there is no formal CAB with regular meetings to approve RFCs and the User Support Unit is not involved. Major changes are approved by the Board, in this case the IT Director. This is currently done by all units when initiating a project. The IT Director also initiates projects. Care should be taken however to convene a formal CAB with representatives from all affected units when projects are initiated.
Change scheduling Currently, the units interviewed inform the customer on upcoming changes as required by ITIL. However, communications between units of upcoming changes are not consistent. While the Data Centre and the Business Systems Support units communicate upcoming changes with each other, there appears to be no formal way of communicating changes with the User Support unit. ITIL also recommends that to enable customers to plan their activities, a Forward Schedule of Changes should be implemented with fixed scheduled outage windows, for example between the hours of 9pm and 6am every Thursday night. Only emergency changes would be scheduled outside of those windows. This is not currently practiced. Change building, testing and implementation Currently change building, testing and implementation processes do take place. The coordination and oversight role of the Change Manager however is not formalised. Change Review ITIL recommends that significant and major changes be reviewed on completion. There does not appear to be a formal review step for significant changes although unit managers would at times check or verify that a significant change has been completed. Reviews of major changes would depend on the type of project currently being run.
28
4.4.4
Recommendations
!
Create a Change Manager role with the authority to approve and/or delegate change authority for all standard, minor and significant changes. Major changes to be approved only by the IT Director as this will form the interface into project initiation. Convene a CAB chaired by the Change Manager every week or fortnight to approve all non-emergency major and significant changes. Expand the change process to all units and log all changes Define the change process, change categories and change authority levels. Include a change category field in the RFC form Create an emergency change priority that requires immediate review from the Change Manager and/or the CAB Ensure forthcoming changes are communicated to all internal units. Consider implementing a Forward Schedule of Changes and publishing it. Implement a formal Change Review stage after completion of all major and significant changes. Clearly define the difference between changes which can be resourced from operational staff without impacting on day-to-day service delivery and projects which will need additional resources. Consider assigning a project owner at the CAB who is responsible for creating the business case and estimating the resources needed to complete the project. Consider setting up a project office who ensures project methodologies are set up for each project, performs ongoing quality assurance and produces a project shutdown report on completion.
! !
29
4.5
4.5.1
Release Management
ITIL Practice
ITIL defines a release as a collection of new and/or changed Configuration Items (CIs) which are tested and introduced into the live environment together. The objective of Release Management is to take a holistic view of a change to an IT service and ensure that all aspects of a release both technical and non-technical are considered together. Release Management does this by planning, design, build, configuration and testing of hardware and software to create a set of release components for the live environment. The main components controlled by Release Management include:
! !
In-house developed applications software Externally developed software including standard off the shelf software as well as customer written software Utility software Systems software Hardware and hardware specifications
! ! !
The fundamental processes that need to be in place for Release Management are as follows:
!
Release planning. This involves planning for the resources required, producing a backout plan, producing high level release schedule, high level test plans and acceptance criteria and defining the contents of the release. Design, build and configuration of the release. Software releases should be built only from the Definitive Software Library (DSL). The DSL is a secure compound in which definitive authorised versions and master copies of all software CIs are stored. The DSL also holds copies of all old releases to enable backing out. Release Acceptance. In release acceptance, independent staff tests the functionality of the release and the backout procedures. This is performed in a controlled test environment. Roll-out Planning produces an exact timetable of events and lists CIs to install and also performs all communication with customers and training. Distribution and Installation follows the planned roll-out process and results in an updated IT service.
Release Management works closely with Change Management as a release set is a collection of authorised changes defined by the RFCs that it implements. The Release Manager is responsible for Release Management. As Configuration, Change and Release Management are very closely linked, the Release and Configuration Manager role can be combined with the Change Manager.
30
4.5.2
Current Practice
The current practice for Release Management is different between each unit reviewed. User Support User Support currently manages the desktop applications and images for end-user and central laboratory PCs as follows:
!
Central laboratory PCs have a well documented process for the modification of laboratory PC applications which is initiated by end-users. Following user request and approval from the User Support Manager, User Support staff build the image, install on a test machine which the end-user then tests and accepts. On approval, the image is copied and rolled out to the laboratory machines. Previous versions of the images are kept. SOE Management. Desktop PC system images are handled differently depending on the operating system in use.
#
Window 2000 images are stored in a shared file system and referenced by make and model and date. These are complete disk images and are stored either in the carousel or on-line. Together this makes up an image library for the different Desktop models. Besides the operating system and drivers, the actual software loaded on each of these images vary and are often a subset of the approved SOE software list. These images are used predominantly for re-imaging purposes. Re-imaging PCs may then require some SOE applications to be reloaded. As only a single Windows XP image is required for most makes and models, separate images are not kept. Instead, all approved SOE software are stored as Windows XP executables online for installing over the network. User requests for additional applications from the SOE can then be installed remotely or through use of a script. Re-imaging Windows XP images however becomes more labour intensive as every application then needs to be manually loaded on the PC.
End-users often request software to be loaded on their PCs. This is done as a service request with User Support staff often attending on-site to install software. User Support staff are required to ask for proof of ownership from the end-user by viewing licences or original software before installing. These licenses are kept by the end-user with no central licence tracking or accounting. Staff will test the installation at time of fitting. If the requested software change affects many machines, an image may be modified. Re-imaging PCs will require additional user software to be reloaded. As a catalogue of user software loaded and master copies are not kept by User Support, it is then up to the end-user to remember and provide the original software.
The User Support Unit is currently investigating a commercial software management and distribution application to streamline this process. While test machines exist for laboratory desktops, there is no formal test laboratory for desktop equipment. Desktop operating system security patches and updates are the responsibility of the Data Centre.
31
Data Centre The Data Centre maintains the operating system of desktops and the central server environment as follows:
!
Desktop operating system. The Data Centre operates a Microsoft Software Update Service (SUS) server which updates desktop operating systems. This maintains and manages versions currently released and enables scheduling of release. However, operating system patches and updates are not tested prior to release and the Service Desk is often not informed when updates are released into the environment. Central server operating systems. The Data Centre maintains a large number of server operating systems which it manages differently depending on the operating system used. While the Change Control Form contains procedures for installation, verification and backout, there is currently no formal testing of changes before release or implementation. There is a limited test environment for testing of releases with some spare servers and some usage of VMware. While some documentation exists, there is no complete and formal tracking of operating system and underlying service application versions running on each server.
Business Systems Support Business Systems Support maintains central business applications in the following areas:
!
Main enterprise systems. These are critical business applications.

#
Oracle systems. These systems have development, test and production instances. A spreadsheet is used to document changes and test plans with backout procedures are maintained. Small changes are often put immediately into production with the development environment periodically refreshed from production. Lotus Notes systems. These systems have development and production versions with the development template copied from the production template when development needs to be done. Following testing, the production template is copied over with all previous versions kept in the template database.
Adhoc systems. These are assorted non-business critical systems.

#
Built in-house. Control and release of these applications are by various staff members with specific expertise. Proprietary. For these systems, ITMS effectively provides a hosting service with external third-parties doing their own maintenance work.
Business Systems Support also provides Oracle DBA support to the Callista team by implementing patches to the underlying Oracle system. All releases go through the development, test and production cycle for system stability.
While versions of previous releases are kept, Business Systems Support does not maintain a formal version numbering system.
32
4.5.3
ITIL Readiness
Release Management activities are performed at varying levels and to various degrees by reviewed ITMS units. Release planning The Data Centre has the most mature release planning activity which is linked to Change Management as recommended by ITIL. In this unit, release planning is currently performed through the current Change Control form which includes a high level release schedule, installation procedures, verification procedures and backout procedures. While verification implies testing and acceptance, ITIL requires formal test plans to be included along with acceptance criteria. However release planning to this level is not performed by all units. Design, build and configure of the release ITIL recommends a single Definitive Software Library holding definitive authorised versions, source code and master copies of all software in the IT environment. All releases should be built from the DSL and new versions checked in. Currently, software is held separately by each unit with varying degrees of detail and version controlling and indexing. Release Acceptance Release Acceptance is performed at various levels by staff who implemented the release. ITIL recommends a controlled test environment and independent staff testing of both the release and backout procedures. Roll-out Planning Roll-out Planning is performed as part of scheduling or through projects. In daily operational activities, while stringent roll-out planning is not required due to the size of the rollouts, communications is still required to alert end-users and internal units about upcoming rollouts. Currently, while end-users are alerted, roll-outs are not communicated as effectively between internal units.
33
4.5.4
Recommendations
!
Combine the role of the Release Manager into the recommended Change Manager. Expand the current change control form to include test plans and acceptance criteria. Ensure that all units use the change management and hence the release management process. Implement a single Definitive Software Library which is used by all ITMS units. Enforce checking in and checking out mechanisms to ensure only definitive versions of all software is used. Consider including all copies of all desktop software in the DSL so that remote installation can be performed when desktops need to be restored. Create a Configuration Librarian role (see next section) to manage the DSL. When planning releases, nominate or assign an independent release tester to test the release before it can be released into the live environment. Ensure that all releases are tested before being implemented especially desktop operating system patches. Consider combining responsibility for patching desktop operating servers currently held by Data Centre Unit with the SOE image building unit currently with the User Support Unit. Consider implementing a desktop software certification process where end-users must send in a copy of the desktop software for certification and testing (along with licences) before it can be loaded onto their desktop. This certification need only be performed once for a software application version.
34
4.6
4.6.1
Configuration Management
ITIL Practice
ITIL defines a Configuration Item (CI) as a component of an infrastructure or an item associated with an infrastructure that is under the control of Configuration Management. The objective of Configuration Management is to provide a logical model of the IT infrastructure or a service by identifying, controlling, maintaining and verifying the versions of Configuration Items in existence. The scope of Configuration Management includes all hardware, software and associated documentation along with version, constituent components and relationships used in the provision of live, operational services. All CIs should be registered in a single Configuration Management Database (CMDB). Configuration Management requires the establishment of proper Change Management as it is through Change Management that the Configuration Management database is kept up to date. Major activities in Configuration Management involve the capturing of all CIs and their relationships, the control of CIs by registering all CIs and versions, updating records and performing licence control while maintaining the integrity of configurations. Configuration Management also performs status accounting and reporting, performing periodic audits to verify the correctness of the CMDB. Configuration Management is a supporting discipline that enables all other Service Support disciplines to be carried out more effectively and efficiently. Through Configuration Management:
!
Incident Management and Problem Management have the ability to track the history and relationships of all CIs in the environment thus making diagnosis and analysis of incidents and problems easier. Change Management can view the CIs affected by proposed changes and better assess the risk and effort required for the change Release Management is able to plan and tailor releases and backout procedures to the environment.
The Configuration Manager is responsible for Configuration Management. As Configuration, Change and Release Management are very closely linked, the Release and Configuration Manager role can be combined with the Change Manager.
35
4.6.2
Current Practice
User Support The recording of asset information for desktops equipment is conducted externally to ITMS by the Finance and Asset Services Division. This division identifies all desktop equipment with an asset ID number. User Support uses this ID number to track a desktops through EasyAudit. EasyAudit is a network discovery tool which maintains a configuration database of all Microsoft Windows desktops showing current hardware and software configuration. This database is refreshed every 30 days. Macintosh computers and Linux desktops are not tracked by EasyAudit. While the current Service Desk system is able to trace job history records based on the ID number, this functionality is not implemented completely. Data Centre The Data Centre maintains a spreadsheet of all central servers with some details on the configuration of each server and a spreadsheet of central applications and the servers those applications are hosted on. The Data Centre also maintains a spreadsheet of active network equipment such as switches and routers. Business Systems Support Business Systems Support maintains minimal technical documentation. Module tracking and dependencies between modules are not formally documented.
4.6.3
ITIL Readiness
The asset management related tasks of Configuration Management is the responsibility of the Finance and Asset Services Division. Hence activities involving the lifecycle management, licence control, status accounting, reporting and auditing of physical CIs are currently managed by the Finance and Asset Services Division. However, it is important for the ITMS Division to maintain aspects of Configuration Management. The following compares recommended ITIL activities and current practice.
!
Single Configuration Management Database. ITIL recommends a Configuration Management Database that holds all CIs and the relationships between all CIs including links to associated incidents, problems, known errors and RFCs. Currently, configuration information is held in a variety of different sources. As well, the existing Service Desk System does not have enough functionality to record the different ITIL objects and its links. Capturing CI relationships and dependencies for the purpose of Change Management and Release Management. Currently, some relationships between software and hardware CIs such as SOE images for Windows 2000 desktops and applications hosted on central servers are captured and some information trapped by monitoring tools. However sources are held in separate sources with insufficient details. Capturing old CI versions. As mentioned in the previous section, some versions of software and source code are stored but these versions are not tracked. Capturing CI history. The maintenance and incident history of all CIs should be maintained. The current Service Desk system has limited functionality in this area for Desktops.
36
4.6.4
Recommendations
!
Plan for the implementation of a single CMDB by considering the level to which CIs are to be identified and the relationships between these CIs. Amalgamate captured information currently stored in spreadsheets into a single database and ensure staff use this CMDB. Begin with critical CIs such as SOE images, critical active network equipment, critical central servers and core business applications modules and underlying services. Capture dependencies between these CIs and associate RFCs with identified CIs. Commission a Service Desk system with an integrated CMDB that captures links between CIs and incidents, problems, known errors and RFCs. Create the index for the proposed DSL in the CMDB. Add Configuration Manager responsibilities to the Change Manager and assign a Configuration Librarian to assist the Change Manager in planning, implementing, managing and controlling the CMDB and DSL. The Configuration Librarian role may be shared amongst different personnel so long as a single CMDB is used. Consider generating a technical architecture document for critical systems to complement the CMDB. This has an overview of all the key system configurations and guidelines for the implementation of new CIs and the modification of existing ones. All servers and their purpose should be listed in this, as well as technical configuration information such as network configurations, specific services such as IP Address assignment, DNS, DHCP, WINS, AD replication, AD structure, naming standards as well as minimum specifications for hardware and software revision levels.
! !
37
4.7
Notes on Service Delivery Disciplines

While Service Delivery disciplines were not included in this review, summaries of each discipline are included for reference. As well, any observations made during the review are also included.
4.7.1
Service Level Management

ITIL Practice Service Level Management is the name given to the processes of planning, negotiating, coordinating, monitoring and reporting on SLAs. The process includes the ongoing review of service achievement to ascertain that the required service quality is maintained and wherever necessary improved. SLAs contain specific targets against which performance can be evaluated. They also define the responsibilities placed on all parties, in particular binding Service Delivery to offer an agreed quality of service so long as the users constrain their demands within agreed limits. The relationship between Service Delivery and its customers is therefore put on to a formal business-like footing similar to those which exist between Service Delivery and its suppliers. When used in conjunction with the financial management process, service level management provides the basis for running Service Delivery as a business and profit centre. Service level management provides a number of benefits not least of which is that it enables specific targets to aim for and against which service quality can be monitored and measured. Furthermore, service monitoring will allow weaknesses in existing services to be identified, so that the quality of service provision can be improved. Observations Service Level Agreements are in the process of being implemented for some of ITMS customers. For effective implementation however, it is essential that performance indicators are captured to measure service quality as most customers require these within their Service Level Agreements. Currently it appears that only some technical statistics can be generated such as availability and utilisation. Incident and user request response and resolution time reports are not available and those that are available are likely to be inaccurate as not all calls are being logged.
4.7.2
Financial Management
ITIL Practice Financial Management for IT services is concerned with helping the business to assess whether its IT service is doing the best it can with the money it has. The business has to understand the true costs of providing a service and manage these costs professionally. Financial Management implements IT Accounting and Budgeting processes and often Charging processes for these IT services, allocating IT expenditure to services and recovering the costs of those services from the business customers to whom they are provided.
38
Budgeting enables an organisation to:

! ! ! !
Predict the money required to run IT services for a given period Ensure that actual spend can be compared with predicted spend at any point Reduce the risk of overspending Ensure that revenues are available to cover predicted spend where charging is in place
IT Accounting enables an organisation to:

! !
Account for the money spent in providing IT services Calculate the cost of providing IT services to both internal and external customers Perform cost-benefit or return on investment analyses Identify the cost of charges
! !
Charging enables an organisation to:

! ! !
Recover the costs of the IT services from the customer of the service Operate the IT organisation as a business unit if required Influence user and customer behaviours
The scope of Financial Management is taken to cover hardware, software, people, accommodation, external services and transfers. Observations Financial Management is currently the responsibility of the IT Director with funding provided by the Board. Very little time was spent in this area however the following observations may be helpful:
!
Certain services such as software certification and loading applications which require on-site presence are traditionally time-consuming and hence costly services. Charging for these services may be advisable. Project work if specified to be outside of standard operational services should be costed separately so as to ensure existing resources are not over-stretched.
4.7.3
Capacity Management
ITIL Practice The aim of Capacity Management is to match the supply of IT resources to customer demands for them. The process is needed to support the optimum and cost-effective provision of IT services by helping organisations to match their IT resources to the demands of the business. It is concerned with having the appropriate IT Capacity and with making the best use of it. The demand for IT resources is based on agreeing with users of IT services, the levels to which those services will be delivered, based on business requirements. The customers needs are assessed by forecasting the likely growth in demand for current services and by sizing new service elements. The desired service levels required can then be agreed with service users based on business needs. The subPrepared by CSM Technology 4-Mar-05 CUSTOMER REVIEW DRAFT
39
processes associated with Capacity Management are concerned with forecasting workload, sizing applications, and maintaining a Capacity plan in order to meet existing and future needs. The Capacity Plan is beneficial to both Systems Management and Purchasing in order to gain visibility of the schedule and likely infrastructure changes necessary to maintain service at the required levels. The scope of Capacity Management covers the entire technical IT infrastructure. The infrastructure will include the network and everything that is attached to the network such as servers and access points (terminals and PCs). The scope of the process should include both operational and development environments. Observations The ITMS has installed many monitoring and management tools that are capable of trapping and keeping all the data required for capacity planning. Setting aside some resource time annually to produce a Capacity Plan may be advisable so that capacity upgrades are controlled and purchases made only according to the Capacity Plan. This may assist in budgeting for the next year. Alternatively, it may be useful instead to require a capacity plan with a historical capacity usage report and forecast usage justifying the purchase for every significant hardware upgrade or purchase.
4.7.4
Availability Management
ITIL Practice Availability Management is the optimisation of the availability and reliability of IT services and of the supporting IT infrastructure and organisation, in order to ensure that the requirements of the business are met. Availability Management entails systematically undertaking preventative and corrective maintenance of IT services within justifiable cost. Technical, organisational, procedural, security and contractual aspects have an important role in this process.
!
Reliability capability of an IT component to perform a required function under stated conditions for a stated period of time Maintainability capability of an IT component or IT service to be retained in, or restored to, a state in which it can perform its required functions Serviceability a contractual term which is used to define the availability of IT components as agreed with external organisations supplying and maintaining these components Security providing access to IT components or IT services under secure conditions
Observations As with Capacity Management, the ITMS has installed many monitoring and Management tools which trap and produce availability statistics. Currently availability reports are being produced as part of the fortnightly Management meetings. ITIL recommends that an Availability Plan be generated along with the Capacity Plan. The Availability Plan should list overall availability levels, shortfalls at peak demand if any, forthcoming requirements of new services if any and current and planned actions addressing shortfalls and new service requirements.
40
4.7.5
IT Service Continuity Management (ITSCM)

ITIL Practice ITSCM is concerned with the organisations ability to continue to provide a predetermined and agreed level of IT services to support the minimum business requirements following a business service interruption. ITSCM is a vital subset of, and provides support to, the overall business continuity management process by ensuring that the required IT services / facilities (including computer systems, networks, applications, telecommunications, technical support and Service Desk) can be recovered within required and agreed business timescales. The ITSCM process is based on the identification of the required, minimum levels of business operation that are required following an incident and the necessary systems, facilities and service requirements. It is driven by these business needs, not be the perceived needs of the IT community and requires senior management commitment. The process covers:
!
Risk/Priority Analysis Examining the risks and threats to IS services, and the development of an IT risk reduction or mitigation programme to deliver the continuity requirements necessary to provide the required level of business operation. The identification of business operational priorities influences the determination of critical services and data, and their relative priorities in the event of a contingency situation (eg: a disaster). Planning for Contingency this covers the development, proving, sign-off and ongoing maintenance of plans to be invoked in the event of a range of contingency scenarios. The main product is a detailed set of contingency plans. Risk Management this covers the active management of identified risks beyond the normal recovery procedures embodied in contingency plans, with particular emphasis on prevention or reduction of risk.
Observations IT Service Continuity Planning was only briefly touched upon in discussion. However the following observations were made regarding Data Centre disaster recovery bestpractice. Best practice management usually revolves around the disaster recovery kit. This is used in conjunction with backups to restore more dynamic information. The disaster recovery kit is where all patch information and copies of all software required to rebuild each system are kept along with appropriate build documentation. Build documentation is where detailed server build information and checklists are kept. With the software and the build documentation, server engineers should be able to completely rebuild a server from scratch. Ensure that changes to software are reflected in the disaster recovery kit as well. To test that the disaster recovery kit is up to date and accurate, servers hosting critical applications should be rebuilt in the test laboratory at least once a year. Building a box in VMWare is acceptable.
41
INITIAL RECOMMENDATIONS
This section collects and summarises the recommendations provided in the previous sections. The recommendations provided below are predominantly process and role adjustments which can be implemented quickly and with the minimum of software tool upgrades. On the whole, these recommendations can be implemented in phases. This approach is advised so that each phase can be planned, fine-tuned and adjusted to fit the ITMS environment. Also note that these are only initial recommendations. A full ITIL implementation will require further analysis. While release management and configuration management (specifically the Definitive Software Library and the Configuration Management Database) are not included below, they are critical for further service improvements. ITIL Training
!
Except for one unit manager, no other staff member had formal ITIL training. Hence, training should be provided to all management level staff and selected senior personnel to the ITIL foundation level.
Single Point of Contact

!
Enforce single point of contact for the Service Desk by clearly defining communication guidelines to all staff and customers. Ensure that all incidents and service requests into all ITMS units are through the Service Desk and that these are logged. Service Counter jobs must also be logged.
Incident Manager
!
Create an Incident Manager role situated within the Service Desk who is solely accountable for the coordination of all incidents and service requests across all ITMS units. The Incident Manager role should produce weekly performance reports on incident and service request resolution, staff workload and resource requirements. The Incident Manager role should be situated on the operational level with the authority to prioritise, assign and escalate all incidents and service requests. Initially, the Incident Manager should be the sole escalation point from first-line to second-line. This will enable holistic prioritisation of incidents and service requests, control and simplify multiple escalation paths, clarify escalation processes and insulate Data Centre staff from unnecessary interruptions.
42
Incident and Service Request Reporting

!
Implement simple incident and service request reporting in the current service desk system by allocating programming resources to simplify the data processing step which is currently performed manually. Implement classification codes for incidents and service requests. In the short term this can be done by using the keyword fields within the existing Service Desk System. Classification codes are required for meaningful management reports. Hold a management review meeting every week and add incident and service request reports to the agenda.
Duty Engineers
!
Roster duty engineers from the Data Centre to be on second-line support and rotate duty engineers through. This should shield other engineers from interruptions and permit them to focus on project work or other duties. Implement an integrated searchable knowledge-base. Encourage all staff members especially duty engineers to update the knowledge base.
Problem Management Please note that an effective problem management requires an effective incident management process. The recommendations provided here can only be effective if earlier recommendations are followed.
!
As a short term measure, implement a problem queue in the current system which is used to record detected problems. Note that if this is implemented, a new problem record needs to be logged, and incidents must not be assigned to the problem queue. Initially only allow the duty engineer and the Incident Manager to create problem records. Set aside time for problem management activities each week. For example, to start with, the recommended duty engineer could be rotated into a half-day per week of problem management duties after their incident management shift. The duty engineer would then either work to resolve problems or analyse existing incidents to create problem records.
Change Manager
!
Create a Change Manager role with the authority to approve and/or delegate change authority for all standard, minor and significant changes. Major changes to be approved only by the IT Director as this will form interface into project initiation. Convene a Change Advisory Board chaired by the Change Manager every week or fortnight to approve all non-emergency major and significant changes. Clearly define the difference between changes which can be resourced from operational staff without impacting on day-to-day service delivery and projects which will need additional resources. Consider assigning a project owner at the CAB who is responsible for creating the business case and estimating the resources needed to complete the project. Consider setting up a project office who ensures project methodologies are set up for each project, performs ongoing quality assurance and produces a project shutdown report on completion.
43
Change Management Process

! !
Expand the current change control process to include all ITMS units. Define the change process, change categories and change authority levels. Include a change category field in the RFC form. Expand the current RFC form to include test plans and acceptance criteria. Ensure that all units use the change management and release management processes. Create an emergency change priority that requires immediate review from the Change Manager and/or the CAB. Ensure forthcoming changes are communicated to all internal units. Consider implementing a Forward Schedule of Changes and publishing it.
Service Desk System

!
Begin the process of investigating the requirements for a Service Desk System that is ITIL compliant and includes modules for all ITIL Service Support disciplines including an integrated Configuration Management Database.
44
CONCLUSION
In every Service Support discipline reviewed, there are portions of the ITMS Division that is closer to formal ITIL practice than others. It should be noted however that even in those areas where no formal ITIL processes are in place, similar processes are already practiced informally by staff. In many areas, all that is required to lift current practice to ITIL recommendations is formally defining processes and training staff so that a standard and consistent methodology is followed through ITMS. The effort required for this should not be underestimated. However, the essential foundations are in place for the ITMS division to achieve ITIL best-practice. There is significant management intent and commitment, middle management have already put in place improvement measures and there is a clear recognition across all levels of the organisation that improvements can and should be made.
45

Itil Problem Management Report6

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Itil Problem Management Report6

Загружено:

Авторское право:

Доступные форматы

ITIL Readiness Report

Information Technology and Management Support Division Charles Darwin University

ITIL Readiness Report

ITMS Division, Charles Darwin University

Contents 1 EXECUTIVE SUMMARY .................................................................................. 3 2 INTRODUCTION .............................................................................................. 6

3 CURRENT ENVIRONMENT ............................................................................. 9 4 ITIL READINESS ........................................................................................... 12

5 INITIAL RECOMMENDATIONS ..................................................................... 42 6 CONCLUSION................................................................................................ 45

Prepared by CSM Technology 4-Mar-05

CUSTOMER REVIEW DRAFT

ITIL Readiness Report

ITMS Division, Charles Darwin University

Prepared by CSM Technology 4-Mar-05

ITIL Readiness Report

ITMS Division, Charles Darwin University

Recommendations The following list some of the key recommendations:

Prepared by CSM Technology 4-Mar-05

CUSTOMER REVIEW DRAFT

ITIL Readiness Report

ITMS Division, Charles Darwin University

Prepared by CSM Technology 4-Mar-05

CUSTOMER REVIEW DRAFT

ITIL Readiness Report

ITMS Division, Charles Darwin University

ITIL Readiness Report

ITMS Division, Charles Darwin University

ITIL is divided into two parts:

Prepared by CSM Technology 4-Mar-05

ITIL Readiness Report

ITMS Division, Charles Darwin University

Prepared by CSM Technology 4-Mar-05

CUSTOMER REVIEW DRAFT

ITIL Readiness Report

ITMS Division, Charles Darwin University

Gary Drake Manager User Support

Pat Gould Manager Data Centre

Anthony Kelly Manager Business Systems Support

Dennis Tsang Manager Callista Team

Natalie Peters Senior Officer Records

Systems support officers (x5) Network Officer Media Officer

Prepared by CSM Technology 4-Mar-05

CUSTOMER REVIEW DRAFT

ITIL Readiness Report

ITMS Division, Charles Darwin University

Prepared by CSM Technology 4-Mar-05

CUSTOMER REVIEW DRAFT

ITIL Readiness Report

ITMS Division, Charles Darwin University

Prepared by CSM Technology 4-Mar-05

CUSTOMER REVIEW DRAFT

ITIL Readiness Report

ITMS Division, Charles Darwin University

The Service Desk function is managed by the Service Desk Manager.

Prepared by CSM Technology 4-Mar-05

CUSTOMER REVIEW DRAFT

ITIL Readiness Report

ITMS Division, Charles Darwin University

Prepared by CSM Technology 4-Mar-05

CUSTOMER REVIEW DRAFT

ITIL Readiness Report

ITMS Division, Charles Darwin University

Prepared by CSM Technology 4-Mar-05

CUSTOMER REVIEW DRAFT

ITIL Readiness Report