ITSM Process Maturity Assessment

(1)

April 2011

Prepared by: Brian Newcomb

(2)

T

ABLE OF

C

ONTENTS

Executive Summary ... 3

Detailed Assessment Results and Recommendations ... 5

Advisory Group Survey Results (External Survey) ... 7

Readiness and Awareness (Internal Assessment) ... 10

Maturity Assessment Results (Internal) ... 13

Detailed Process Information ... 24

Common Process Improvement Recommendations. ... 24

Incident Management: Current Process Maturity 2.62 ... 24

Problem Management: Current Process Maturity 0.73 ... 24

Change Management: Current Process Maturity 1.11 ... 24

Configuration Management: Current Process maturity 0.37 ... 24

Service Desk: Current Maturity 2.45 ... 25

Service Level Management: Current Maturity 1.29 ... 25

Availability Management: Current Maturity 0.66 ... 25

Security Management: Current Maturity 2.16 ... 26

IT Service continuity Management: Current Maturity 1.11 ... 26

Other ITIL Processes ... 27

Release Management ... 27

Service Portfolio Management ... 27

Service Catalog management ... 27

Demand management ... 27

Capacity Management ... 28

Financial Management ... 28

Supplier Management ... 28

Transition Planning and Support ... 28

Service validation and Testing ... 28

Knowledge Management ... 28

Evaluation Management ... 29

Request Fulfillment ... 29

Access management ... 29

Event management ... 29

7-‐Step Improvement Process ... 30

(3)

E

XECUTIVE

S

UMMARY

F

INDINGS AND

R

ECOMMENDATIONS

A process maturity assessment was completed to determine a current maturity for many of the IT Infrastructure Library (ITIL) based IT Service Management processes within the Office of the CIO (OCIO) at The Ohio State University. The scores were based on a 0-‐5 scale as defined in ITIL’s Process Maturity Framework (PMF). This framework, based on concepts developed by the Software Engineering Institute at Carnegie Mellon details levels of maturity by assigning the following numeric values: 0-‐none, 1-‐Initial, 2-‐ Repeatable, 3-‐Defined, 4-‐Managed, 5-‐Optimized. These values represent the level to which the process is executed in a consistent and efficient manor and are not necessarily a direct measure of performance.

The following results were obtained.

This assessment was performed at an executive level and serves and is compared against the identical assessment from 2009 as part of an ongoing assessment and improvement effort within the IT Service Management Program. Ideally, an additional assessment process should be established to query deeper into the organization.

While this was an internal review of process maturity, members of the CIO Advisory Community completed an external survey. Results from this survey were used to validate the findings of the review from an ‘external’ perspective. No contradictions were noted when evaluating this data.

2.16 1.11 2.45 2.62 1.11 0.73 1.29 0.66 0.37 2.40 1.65 1.43 1.23 0.95 0.79 0.75 0.70 0.60 0.00 0.50 1.00 1.50 2.00 2.50 3.00 3.50 4.00 4.50 5.00 Security Continuity Service Desk Incident Change Problem Service Level Mgt Availability Concig P ro ce ss

Process Maturity Score

(4)

Significant increases in the maturity scores for Incident Management and the Service Desk are seen as compared with those two years ago. With the exception of an increase in Service Level Management due to significant progress with the service catalog, the other processes remained relatively unchanged.

With the improvements made in reactive processes such as Incident Management and the Service Desk, focus may now be turned to increasing control and proactive efforts. The assessment indicated that some of the next priorities for improvement include change management and problem management. Configuration management, while not a ‘top pick’ from the audience assessed will also be a critical process to improve as the organization looks to gain control of the environment and become more proactive.

In addition to the maturity assessment, an internal readiness and awareness assessment was performed. This assessment identified an increase in training from the previous assessment, as well as improvements in the use of a common vocabulary but left plenty of room for improvement. Other areas within the readiness assessment were relatively unchanged from 2009 further identifying opportunity to better promote a culture of customer focus and a service-‐based organization. Additional communication using multiple delivery methods should be continued and combined with continued training, which provides the reasoning to address why certain processes are being developed and designed a certain way. Training, along with other communication and organizational change efforts, continues to be critical in a successful process improvement program.

The IT Service Management Program provides a level of coordination and leadership to IT process improvement efforts. This program was established following the 2009 assessment and continues to work with the organization’s leadership to identify priority opportunities, allocate resources, and provide support for the advancement of a customer focused, service based organization.

(5)

D

ETAILED

A

SSESSMENT

R

ESULTS AND

R

ECOMMENDATIONS

2011 2009 Security 2.16 2.40 Continuity 1.11 1.65 Service Desk 2.45 1.43 Incident 2.62 1.23 Change 1.11 0.95 Problem 0.73 0.79

Service Level Management 1.29 0.75

Availability 0.66 0.70

Configuration Management 0.37 0.60

A number of process control questions were presented to the assessment group made up of senior directors and directors within the Office of the CIO. The participants were asked to submit a response of 0-‐5 for each question. These responses were then averaged to determine a final value for each process.

An external facing survey was also released to the CIO Advisory Community. This survey had 19 questions and served to validate the results obtained from this internal assessment by ensuring that self-‐rated answers were not over or under stated.

Both the internal assessment and the external survey were delivered in the same way and with identical questions as the 2009 assessment, which served as the initial and baseline assessment for the OCIO. The 2011 assessment resulted in maturity scores ranging from 0.37 (near non-‐existent) to 2.62 (between repeatable and nearing ‘defined’). Clear increases in maturity were seen in both the Incident Management process and the Service Desk function. This is consistent with the goals of very specific and high profile improvement efforts undertaken as a result of the previous assessment. Another noted increase was within Service Level Management. While this process is currently being implemented, further analysis shows that the increase is largely attributed to a significant increase in the one specific question within the Service Level Management section of the assessment that asked about the existence of a service catalog. Another major effort recently published the first definitive service catalog for the OCIO, and this was reflected in the assessment.

The remaining processes did not change significantly. With focus over the last two years on Incident Management, Service Catalog Management, and the Service Desk, other processes continued to operate as in the past. Some minor decreases are also noted. While not significant, it is possible that operational needs resulted in ‘ad-‐hoc’ efforts in advance of formal process improvement that have introduced additional inconsistency. It is also possible that current process states are more visible and the OCIO is ‘raising the bar’ internally leading to slightly tougher rating.

(6)

2009 assessment and, given that this assessment is completed at the senior director and director level, demonstrates support and commitment from the organizations leadership. Continuing this training at deeper levels of the organization will support advancing the overall concepts of IT Service Management.

Improvement efforts over the last two years have proven successful at a process level for the targeted areas. Still, opportunity for continued growth in several other key process areas exists. The improvements in Incident Management and the Service Desk provide a more effective way to react. To take the next step at an operational level, efforts must focus on reducing the amount of reactive work, providing better planning and control to the organization and allowing resources to allocate more time to proactive activities.

Looking ahead, the assessment revealed that the next most important process to improve was Change Management followed close by Problem Management. The external survey validated this and also served to reflect on the improvements of Incident Management, which was the top of the list for this question two years ago. Other significant areas of opportunity noted in the external survey align with ongoing improvements in Service Level Management and Request Fulfillment.

Other areas of priority include IT Service Continuity Management and Information Security Management. Efforts are underway to improve a number of security items and the coordination of efforts with applicable ITSM processes and best practice should continue. IT Service Continuity Management is still assessed at an ‘initial’ level of maturity. In fact, although a minimal change, this process is one that showed a decrease in maturity. Caution is advised in delaying priority of this process improvement. Unfortunately, this process usually calls for a significant investment with no promise of return, and is often minimized for that reason. Priority should be placed on improvement of this process before a disaster forces ‘emergency prioritization’. An IT Service Management program was established following the 2009 assessment and services to coordinate improvement efforts, manage implementation projects, and provide leadership to assist the organization’s adoption of consistent and efficient processes based on leading best practice. While the organization has committed to several key initiatives outside IT Service Management, resources are always tight and the program must work with the organization’s leaders to invest resources in a way that provides the most improvement balanced against other key commitments and day to day operation. Temptation to initiate IT process improvement outside the program should be avoided to avoid future rework and additional inconsistency. This will allow the best opportunity for the OCIO to advance as one organization and deliver the most value to The Ohio State University.

(7)

A

DVISORY

G

ROUP

S

URVEY

R

ESULTS

(E

XTERNAL

S

URVEY

)

0 10 20 30 40

2011

Always Usually Sometimes Never 0 10 20 30 40 I am advised of proposed

changes that affect my IT-‐ related services. (Change Mgt)

Expectations for the performance of the services

delivered by the IT organization are available to

me. (SLM) Reviews of measurement

around the delivery of IT services are available to me.

(SLM)

I am able to make IT service requests from a single location (one stop shopping) containing details, costs, etc. for the request. (RF/Tools) I know when each IT service is expected to be available, or

I know where to cind that information. (Availability

Mgt) Periods of IT service downtime for regular maintenance are known and acceptable. (Availability Mgt/

SLM)

There is a commitment within the IT management team and other IT staff to protect the organization's information.

(Security)

IT staff members work with me when changes to the security of a service may affect my ability to handle the

business of my area. I am aware of safeguards in place to ensure continuation of the services upon which my

business depends. (Service Continuity)

(8)

0 10 20 30 40

2011

Always Usually Sometimes Never 0 10 20 30 40 When I report an IT issue, it

remains open until it has been concirmed by me that the issue has been resolved to my satisfaction. (Incident My IT issues are handled in a consistent manner each time I contact the IT organization.

(Incident Mgt) Staff with the required skills

are identicied and assigned to work with me to investigate and analyze more

complex issues. (Incident The "root cause" of my IT issue is communicated to me.

(Problem Mgt) When instructions to resolve

my IT issue is found, I have access to that information.

(Service Desk/Tools) I have an opportunity to provide input into major changes to my IT services.

(Change Mgt) When there is an issue with an IT service that affects me, the IT staff seem to know

what to investigate to resolve the issue. (Concig There is a single area I can contact for any IT issue I may

have. (Service Desk) The IT Service Desk stays involved with my issue until

I am satiscied with the outcome. (Service Desk)

(9)

External Opinion Question:

The aspect of IT Service improvement that is most important to me, is:

35% 20% 32% 13%

2011

My IT service issues are consistently resolved quickly and efciciently. (Incident Mgt) My IT service issues are prevented or don't reoccur. (Problem Mgt)

My productivity doesn't

decrease due to system changes. (Change Mgt)

I know what IT services are available and how to get them. (SLM/Availability) 47% 17% 23% 13%

2009

My IT service issues are consistently resolved quickly and efciciently.(Incident Mgt) My IT service issues are prevented or don't reoccur. (Problem Mgt)

My productivity doesn't

decrease due to system changes. (Change Mgt)

(10)

(11)

(12)

(13)

M

ATURITY

A

SSESSMENT

R

ESULTS

(I

NTERNAL

)

0 1 2 3 4 5 The Organization has clearly decined

process goals, objectives, documented policies, activities and procedures for Clear roles and responsibilities for the Incident Management process have been

identicied, decined, documented and The decinition of an Incident is clearly

understood as distinct and separate from a Problem; this decinition is applied

There are clear policies and decined and consistent procedures for logging all

Incidents.

Incidents are categorized using a method that enables meaningful

reporting.

A measurement framework has been established for Incident Management that identicies, measures and reports on

All Incidents are assigned a priority based on impact and urgency. The decinition of and procedure for handling a Major Incident based on

impact and urgency is clearly Customers are informed of the status of Incidents that affect them in a consistent

and decined manner.

Incident closure policies and procedures state that Incident closure be performed only by the Service Desk and that closure

Procedures are in place to assess the user satisfaction levels related to the

resolution of the Incident. There is a searchable Knowledge Database that contains work-‐arounds, resolutions, and known-‐errors, as well Incident Management exists as a standardized and repeatable process

across our organization.

Incident Management

(14)

process goals, objectives, documented policies, activities and procedures for the Problem Management process. A Clear roles and responsibilities for the Problem Management Process have been identicied, decined, documented

and appointed.

There is a procedure by which potential problems are classicied in terms of category, urgency, priority

and impact and assigned for The Problem Management process owner undertakes proactive problem

management (looking for potential areas of failure, before they occur). The Problem Management process owner analyzes incident information

to look for incident trends. Problem records include current status of the problem investigation, categorization of the problem, and any

changes in status for the problem. Problem Management ensures (following a Post Implementation

Review) that Changes have been successfully implemented before All Problems and Known Errors are linked to Conciguration Items when

relevant. (PM to SACM) A measurement framework has been established for Problem Management that identicies, measures and reports

on metrics aligned to Key Problem Management exists as a standardized and repeatable process

Problem Management

(15)

process goals, objectives, documented policies, activities and procedures for the

Change Management process. A shared repository of Change Management Clear roles and responsibilities for the Change Management Process have been

identicied, decined, documented and appointed.

A role exists within the Change Management process which is responsible

for the coordination of each Change being built, tested, implemented, then reviewed according to the specicications contained

A Change authorization model decines various Change categories, and what level of authorization is required for the different

Change categories.

A Change Advisory Board (CAB) exists as a formal body responsible for reviewing and

authorizing Changes.

An Emergency CAB to review and authorize emergency Changes exists.

An IT Management Board is responsible for reviewing and authorizing Changes bearing signicicant risk to the business and/or that impact multiple services or organizational

areas

Business representatives (from non-‐IT areas of the University) are involved with

the review of major proposed changes. Changes are assessed for potential impacts

to existing services as decined in Service Level Agreements. (Chg to SLM)

Change Management

(16)

0 1 2 3 4 5 A measurement framework has been

established for Change Management that identicies, measures and reports

on metrics aligned to Key A Request for Change is used to record

and control all information related to Changes and proposed changes. The priority for a submitted Change

Request is determined through the assessment of the Change impact and

urgency.

A "calendar of Change" is communicated to all Change stakeholders (which includes the

Service Desk).

All Changes (including emergency Changes) are tested prior to

implementation. The scope of Change Management

includes Changes to the Service Portfolio, Changes to existing services, impacts to the Security Plan, as well as

Change Management exists as a standardized and repeatable process

Change Management Cont.

(17)

process goals, objectives, documented policies, activities and procedures for

A Service Asset and Conciguration Management process owner with accountability for the process across Clear roles and responsibilities for the Conciguration Management Process

have been identicied, decined, All Conciguration Items (CIs), attributes, owners, and relationships

are recorded and maintained in a The Conciguration Management Database (CMDB) provides a logical

model of all service assets used in Conciguration Items (CIs) contained in

the CMDB include services, systems, hardware and software components, There is a Decinitive Software Library

and a Decinitive Hardware Store within the organization (physical A measurement framework has been

established for Service Asset and Conciguration Management that Registered Conciguration Items are physically identicied through labeling

according to organizational policy A scheduled and regularly occurring audit is used to verify the accuracy of

the Conciguration Management The Conciguration Management Database audit includes a comparison

of Conciguration Items in the Service Asset and Conciguration Management provides up to date information about infrastructure and Conciguration Management exists as a standardized and repeatable process

Con=iguration Management

(18)

process goals, objectives, documented policies, activities and procedures for the

Service Desk function.

Clear roles and responsibilities for the Service Desk function have been identicied, decined, documented and

appointed.

There is a Service Desk in place which is the known contact point for all IT

inquiries and problems.

Calls recorded by the Service Desk are distinguished as incident, request for

change, or service (or information) request.

The Service Desk ensures that the end users are advised of upcoming expected

service changes and/or outages. Reports for service Desk metrics, such as

numbers of calls received, types of calls, etc. are easily accessible.

There is a user satisfaction survey system in place.

The Service Desk provides trending information and customer satisfaction

rating reports to Management. The Service Desk proactively advises users of the status of their calls when

certain time limits are reached. There is an escalation process in place for calls that cannot be resolved at cirst point

of contact with the Service Desk. There is a regular, reported review of

Service Desk performance against expected Key Performance Indicators (KPIs) and Critical Success Factors (CSFs).

Service Desk

(19)

the Service Level Management process. A shared repository of

Service Level Management A Service Level Management process

owner with accountability for the process across the organization has been appointed. The process owner

has the authority to ensure compliance to and governance of the Clear roles and responsibilities for the Service Level Management Process

have been identicied, decined, documented and appointed.

Service Level Agreements (SLAs) -‐-‐ which decine all the services and levels of services provided by IT for the customers -‐-‐ exist for all services. Operational Level Agreements (OLAs) -‐ which are aligned with requirements

decined in the SLAs -‐-‐ have been documented and agreed among individual provider IT groups within

the organization. Service Level Agreements are regularly reviewed to ensure they are

current and aligned -‐-‐ and re-‐ negotiated when needed -‐-‐ with

customer requirements.

Supplier Management exists as a process to manage contracts with

external suppliers.

Service Level Management

(20)

0 1 2 3 4 5 There is a Service Catalog that

describes the services offered by the IT organization.

Service levels achieved by all operational services are monitored and measured against targets within

SLAs, OLAs, and Contracts. Regular communications and reports concerning levels of service contained

within Service Level Agreements occur with IT management, the

Service Desk, and all internal Service review meetings are held regularly with customers to discuss Service Level achievements and any plans for improvements that may be

required.

Service Improvement Programs are used to improve the quality of services

and are initiated for services that are underperforming.

Service Level Agreements, Operational Agreements and Underpinning Contracts are stored in a Decinitive Document Library and are controlled

as Conciguration Items in the Service Level Management exists as a

standardized and repeatable process across our organization.

Service Level Management Cont.

(21)

process goals, objectives, documented policies, activities and procedures for the Availability Management process.

A shared repository of Availability An Availability Management process

has the authority to ensure Clear roles and responsibilities for the Availability Management Process have been identicied, decined, documented

and appointed.

The Availability Management Process area provides information to the Change Management process area about the impact of proposed changes.

There are regular reviews of current infrastructure against required availability (KPIs and CSFs), with a

view to optimizing equipment (lowering cost) while maintaining Accepted periods of service downtime

for maintenance are known and accepted by the customer/business

representative.

There is an accepted procedure for investigating reasons for high

unavailability.

Trend analysis is carried out on availability data, to help identify potential future bottlenecks. Availability Management exists as a standardized and repeatable process

Availability Management

(22)

A Security Management process owner with accountability for the process across the organization has Clear roles and responsibilities for the Security Management Process have been identicied, decined, documented

There is a clear understanding in the organization of who is responsible for

IT security.

There is a commitment within the IT management team and other IT staff

to protect the organization's There are physical barriers in place

preventing unauthorized access to critical IT equipment. There are preventative systems in place to protect against electronic

attacks (e.g.. Firewalls). There are clear steps in place for handling and reporting any security

breaches.

The cost of providing security is known and balanced against the value

of the information being protected. There are procedures in place to ensure that the systems protecting the

organization are updated to the latest There are regular reviews with suppliers to ensure that their security

measures are adequate. There are regular reviews with clients/customers to ensure that the IT security measures do not hamper

Security Management exists as a standardized and repeatable process

IT Security Management

(23)

the Continuity Management process. A shared repository of Continuity A Continuity Management process

has the authority to ensure Clear roles and responsibilities for the

Continuity Management Process have been identicied, decined, documented

and appointed.

There is a regular Business Impact Analysis (BIA) that reviews the services used by the business and the impact (monetary and non-‐monetary)

if they are lost.

There is a documented and tested recovery plan in place which is understood by the service providers

and customers for each service. Regular backups of critical data are taken, tested, and these backups are

stored securely.

The cost of continuity planning is balanced against the value to the

business.

There are regular reviews (including testing) on performance of this process area against documented Key

Performance Indicators (KPI's). Continuity Management exists as a standardized and repeatable process

IT Service Continuity Management

(24)

D

ETAILED

P

ROCESS

I

NFORMATION

P

ROCESS DEFINITIONS AND RECOMMENDATIONS

C

OMMON

P

ROCESS

I

MPROVEMENT

R

ECOMMENDATIONS

.

To increase the consistency and efficiency of any process, the following common activities are recommended. Efforts should be made to apply these to any process established.

• Clearly define process goals, objectives, documented policies, and procedures for the process. • Define a process owner and establish a RACI authority matrix for the process.

• Provide appropriate communication and training to staff as applicable. • Maintain all process documentation in a shared, communicated location.

• Establish a measurement framework that identifies, measures, and reports on metrics aligned to Key Performance Indicators (KPI’s) and defined Critical Success Factors (CSF’s)

I

NCIDENT

M

ANAGEMENT

:

C

URRENT

P

ROCESS

M

ATURITY

2.62

The primary objective of incident management is to return the IT service to users as quickly as possible. Based on the results of the previous assessment, a major effort to improve Incident Management was undertaken. This resulted in a formal process, new tooling, and provided the foundation for future ITSM efforts.

P

ROBLEM

M

ANAGEMENT

:

C

URRENT

P

ROCESS

M

ATURITY

0.73

The primary objective of problem management is to prevent incidents from happening and minimize impact of incidents that cannot be prevented.

Recently, improvement efforts were undertaking to define the problem management process for the OCIO. Process documentation and tooling are in place, however, resource constraints led to holding off on the remaining work to roll out the process.

Next steps which lead to a more mature problem management process include: • Provide awareness and training on the documented process

• Implement the process within the OCIO

C

HANGE

M

ANAGEMENT

:

C

URRENT

P

ROCESS

M

ATURITY

1.11

The primary goal of change management is to enable beneficial changes to be made with minimum disruption to IT services.

Currently, a major effort is underway to formally define this process and implement it across the OCIO

C

ONFIGURATION

M

ANAGEMENT

:

C

URRENT

P

ROCESS MATURITY

0.37

(25)

The need to better track assets and various levels of configuration item tracking continue to result in an extremely inconsistent, inefficient set of activities across the OCIO. It is likely that a level of re-‐work will be required when formal process is defined. The amount of rework will increase as additional time passes with the current approach.

Key activities which will lead to a more mature configuration management process include: • Define the lifecycle process for assets from procurement to disposal.

• Maintain a configuration management database with configuration items that include services, systems, hardware, software, databases, documentation and support staff roles.

• Establish documentation defining the relationships of CIs to business processes and services to the business.

• Schedule a regular audit to compare configuration item information in the organization to the data in the CMDB.

S

ERVICE

D

ESK

:

C

URRENT

M

ATURITY

2.45

The service desk serves as the customer’s single point of contact for all IT services.

Together with the Incident Management improvements, the service desk has been re-‐aligned under the guidance of the Customer Experience organization within the OCIO. The efforts are clear in the increased maturity score for this area.

Recommendations which will lead to an even more mature service desk include:

• Continue to consolidate user contact points within the OCIO for increased efficiency.

• Establish a consistent process for customer and user communications regarding any changes to services.

S

ERVICE

L

EVEL

M

ANAGEMENT

:

C

URRENT

M

ATURITY

1.29

The service level management process involves agreement among the customers and the providers of IT services regarding the definition and expectations of the service.

Current efforts are underway to document the Service Level Management process and define agreed service levels for OCIO services.

Key actions to follow on the current efforts include:

• Continued communication and awareness. This process is key in advancing toward a business focus and beyond the constraints of a ‘technology’ focus.

• Establish a process whereby regular communications and reports regarding SLA KPIs and CSFs occur both internally and with the customers.

• Establish a service improvement program for underperforming services.

A

VAILABILITY

M

ANAGEMENT

:

C

URRENT

M

ATURITY

0.66

(26)

• Establish a process for availability management to participate in the Change Management process by providing input about the impact of proposed changes.

• Establish a procedure for the investigation of reasons for the unavailability of a service.

• Establish a method by which trend analysis is carried out on availability data to proactively identify potential future service issues.

S

ECURITY

M

ANAGEMENT

:

C

URRENT

M

ATURITY

2.16

The security management process ensures that the security aspects with regard to services and all service management activities are appropriately managed and controlled in line with business needs and risks. Key actions that would lead to a more mature security management process include:

• Ensure all appropriate security related policies are documented, accessible, and communicated. • Ensure policies define an appropriate level of security relative to the type of data, risk, and business

requirements.

• Implement controls specified in ISO 27002

• Establish a formal Information Security Management System (ISMS) as suggested in ISO 27001.

IT

S

ERVICE CONTINUITY

M

ANAGEMENT

:

C

URRENT

M

ATURITY

1.11

IT Service Continuity Management (ITSCM) supports the overall business continuity plan (BCP) by ensuring that the required IT technical and service facilities can be resumed within required and agreed business timescales.

The OCIO maintains emergency plans based on university business continuity program requirements, but no formal service based ‘continuity’ process is defined or owned.

The importance of this process is often minimized until it is too late.

Key actions that would lead to a more mature IT security management process include: • Perform regular Business Impact Analysis (BIA) and risk analysis.

• Ensure that IT service continuity recovery plans are defined and tested for each service.

• Ensure the cost of recovery planning is balanced against the value to the university and included in the overall cost model of the service.

• Provide information to Service Level Management to better set customers’ expectation of services.

(27)

O

THER

ITIL

P

ROCESSES

Processes defined in ITIL that were not formally assessed are listed below. For each of these, recommended actions include all activities noted in the common activities above. Additionally, specific information is noted when available.

R

ELEASE

M

ANAGEMENT

Release management is the process responsible for planning, scheduling, and controlling the movement of releases to test and live environments. The primary objective is to ensure that the integrity of the live environment is protected and that the correct components are released.

Release Management currently exists across the OCIO in multiple levels of maturity. Most formally, this process exists as part of the Software Development Lifecycle (SDLC) within the Enterprise Applications organization and the Configuration Management team within the Infrastructure organization. Opportunities to improve consistency and increase maturity will develop as a result of improved performance of Change Management.

S

ERVICE

P

ORTFOLIO

M

ANAGEMENT

Service portfolio management is a method for governing investments in service management across the enterprise and managing them for value. The service portfolio includes the service pipeline (new services being developed), the service catalog (services currently offered in operation), and retired services (services no longer offered).

Key components of The Service Portfolio Management process have been implemented with success while future opportunities also exist to provide even more value to the OCIO. The service catalog has been created. While establishing the catalog, visibility to services earlier in the lifecycle have been realized. Visibility of OCIO services in one place along with the total cost of ownership efforts of Financial Management have also provided data for decisions regarding retirement of services. Future improvement opportunities for the Service Portfolio Management process include definition of formal ownership and a defined approach to making the strategic decision about whether a service should be offered.

S

ERVICE

C

ATALOG MANAGEMENT

The goal of Service Catalog management is to provide a single source of consistent information on all of the agreed services and ensure that it is widely available to those who are approved access to it.

Service Catalog Management is a formally recognized process within the OCIO with a named process owner. Recent improvements established a consistent definition for a ‘Service’ and presented an official list of OCIO Services in a web accessible service catalog. The value of the catalog will continue to grow as data from Service Level Management becomes available and is published. While this process was not formally assessed, one specific question within the ‘Service Level Management’ section may provide some information of progress moving from an average response of 0.69 to 2.65 over the two-‐year period. See the top of page 19 of this report.

D

EMAND MANAGEMENT

Activities of demand management are focused on understanding customer demand for services and the provision of capacity to meet these demands. This is strategically accomplished by analysis of patterns of business activity and user profiles.

(28)

C

APACITY

M

ANAGEMENT

Capacity management ensures that the capacity of IT services and the IT Infrastructure is able to deliver at agreed service levels in a cost effective and timely manner by considering all resources required to deliver the service.

Capacity Management presents a clear area of opportunity for the OCIO. As more reactive processes are stabilized, resources and supporting data will become available to investigate these opportunities.

F

INANCIAL

M

ANAGEMENT

Financial management, both a process and a function, is responsible for managing and IT service provider’s budgeting, accounting, and charging requirements.

Financial Management is a formally recognized process within the OCIO with a named process owner. Recent improvements provided a defined service based cost model and templates for calculation of total cost of ownership ‘TCO’. Efforts continue to produce a TCO for each OCIO service that will support validation of fees and charges, budgets, and accounting.

S

UPPLIER

M

ANAGEMENT

Supplier Management is the process responsible for ensuring that all contracts with suppliers support the needs of the business, and that all suppliers meet their contractual commitments.

Supplier Management is a formally recognized process within the OCIO with a named process owner. Current efforts have provided more visibility and improvements in ‘end of term’ contract renewals. Contracts ‘custodians’ have also been associated with each contract to serve as a primary contact within the OCIO at renewal and negotiations. While no specific section of the assessment addressed this process, one specific question in the Service Level Management section focused on Supplier Management (bottom page 18). The average response for this question moved from a 0.63 to a 1.35. Further efforts may include increased communication of the process, establishment of a supplier scorecard and more formal link from suppliers to OCIO services and service levels.

T

RANSITION

P

LANNING AND

S

UPPORT

Transition planning and support is the process responsible for planning all service transition processes and coordinating the resources that they require.

The activities of this process align with the OCIO’s project management methodology. Improvements continue to be implemented under formal leadership of the Portfolio and Program Management Office within the OCIO.

S

ERVICE VALIDATION AND

T

ESTING

The service validation and testing process is responsible for validation and testing of a new or changed IT service by ensuring that the services matches its design specification and will meet the needs of the university.

Activities from this process are currently being considered within the Shared Services Group within the OCIO’s Enterprise Application team. Formalization of testing and quality assurance processes within this group will inherently work to improve this process.

(29)

Knowledge management is responsible for gathering, analyzing, storing and sharing knowledge and information within an organization. The primary purpose is to increase efficiency by reducing the need to rediscover knowledge and making that knowledge available to enable better business decisions.

The OCIO has a start to Knowledge Management on a number of fronts. Traditionally, the ‘Knowledge Base’ used by the service desk has been the key component, however, Knowledge Management, encompasses much more. Many other systems in place, including Service Knowledge Management System, record new data every day that feed the Knowledge Management process.

E

VALUATION

M

ANAGEMENT

The evaluation process assesses a new or changed IT service to ensure that risks have been managed and to help determine whether to proceed with the change. It is also performs comparisons between the actual outcome and the intended outcome or one alternative with another.

At a high level, some of these activities are performed within the OCIO project management methodology. Further maturing of this methodology along with improvements in Change Management and Strategy/Service Portfolio Management will continue to refine the activities.

R

EQUEST

F

ULFILLMENT

Request fulfillment is focused on managing the lifecycle of service requests – managing the request from start to finish. This process is often closely associated with the service desk.

Request Fulfillment is an officially recognized process in the OCIO with a named process owner. Improvements in Request Fulfillment have begun in close coordination with Incident Management, Service Catalog Management, and Service Level Management. Major customer visible improvement will be realized with the release of a self-‐ service request catalog that allows users to order or request items from the OCIO and track their progress.

A

CCESS MANAGEMENT

The access management process is responsible for allowing users to make user of IT services, data, or other assets. Access management helps protect the confidentiality, Integrity, and availability of assets by ensuring only authorized users are able to access or modify the assets. Access management is often referred to as Rights management or Identity management.

This process continues to mature as efforts within the Identity Management program define process and implement new tools for management of OSU identities.

E

VENT MANAGEMENT

The event management process is responsible for managing events (any change of state which has significance for the management of a configuration item or service i.e. an alert or notification) through their lifecycle.

(30)

7-‐S

TEP

I

MPROVEMENT

P

ROCESS

The 7-‐step improvement process defined in ITIL consists of a standard, continuous approach to improvement based on the Plan, Do, Check, Act cycle described by W. Edwards Deming. The 7 steps include:

1. Define what you should measure. 2. Define what you can measure. 3. Gather the data.

4. Process the data. 5. Analyze the data.

6. Presenting and using the information. 7. Implementing corrective action.

After processes are documented and implemented as part of the IT Service Management program, the 7-‐step