ITIL is a framework for IT Service Management, intended to help guide IT professionals and organizations by identifying processes that assist with providing services. ITIL is predicated on thinking about what IT does in terms of the services it provides and plans to provide. Therefore, ITIL's definition of a service is an important one:
A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.
When IT provides a "service," it is buying and maintaining components (hardware, software, server room colocation, disk infrastructure, network, etc.) and packaging up all those things into one "service"--the stuff that one or more departments actually care about. Part of IT's "added value" is in doing a good job at insulating end users from these components and ensuring the service is available. ITIL's processes then focus on specific aspects of providing services, such as ensuring services are tested or ensuring that the impact of a change is known before a service is modified.
The concept of a "Service Asset" is part of the ITIL v3 book Service Strategy. "Service assets" are a strategic concept, but not an ITIL process.
In defining an IT department's strategy, it can be helpful to understand what sorts of "assets" the department has, or could acquire. ITIL v3 groups assets into two groups, "capabilities" and "resources."
The concept of "service assets" helps in creating a department strategy, because it helps planners understand how various assets might need to be developed to underpin the strategy. Also, strategic planning is often centered around the resources needed rather than the capabilities needed--and resources can be acquired directly while capabilities require significant time and effort to develop.
Capabilities are the things an organization has that it cannot buy outright. Capabilities include what a department's culture allows it to do. A great example of a capability is a process itself: no organization can "buy ITIL"--they can hire consultants, and train people, but the department has to build the process over time. Here are ITIL's five capabilities:
Resources are the things an organization has that it can pay for directly. Here are ITIL's five resources:
People are listed in both areas, because people can be hired, but people also have capabilities that are developed.
Utility and warranty are two Service Strategy concepts. It's important to understand the concept of a service to understand utility and warranty.
Utility is whether a service is "fit for purpose"--that is, whether the service does something useful.
Warranty is whether a service is "fit for use"--that is, whether the service has an adequate quality.
In ITIL v3, warranty is broken down into four questions:
These concepts can be applied to an organization, too. An organization that does "a little bit of everything" may have a high utility and low warranty. A decentralized IT department responsible for only one small part of overall IT, on the other hand, may have a very high warranty (for its few services) and low utility.
Someone has to run IT. Often University IT shops will be pushed to have higher and higher utility--that is, to support more and more services--without being able to sacrifice warranty.
It can be difficult for Universities to make strategic decisions about utility and warranty, especially when the University expects IT to "do everything." Ideally, Service Level Agreements govern the levels of utility and warranty for each service.
ITIL v3's "Financial Management" section in Service Strategy is complex and can be difficult to understand. ITIL v2's "IT Financials Management" section in Service Delivery is another source of information on Financial Management.
Financial management requires an understanding of an IT department's services. Please see Service Catalog Management.
Services have two types of costs:
Organizations typically have two types of budgets:
Financial management helps decompose an organization's operational budget into the costs for the services in its service catalog. That is, all operational costs should be tied either directly or indirectly to the offered services.
The cost of the services in the service pipeline should then match the capital budget: all capital costs should be tied to new or re-designed services.
ITIL does not take a position on whether to charge for services. It does lay out three options: not charging, "notional" charging, or charging. "Notional" charging means that IT tells departments how much it would cost, were they to be charged. Charging is sometimes seen as "soft money" when done internally. Charging can be an effective tool for supporting Demand Management.
University IT departments are sometimes funded from student fees. In this case, Financial Management might more resemble a report explaining how student fees are spent by service provided.
Demand management and capacity management are closely related. Demand management is about understanding (and shaping) user demands--looking at the market and knowing what people want. Capacity management is about knowing what IT can provide. Demand management is a service strategy process, because it's about understanding the market. Capacity is a service design process, because it's about designing a solution (ideally, one that matches the identified demand).
Service Strategy is about identifying markets and how IT can meet those market needs within certain cost and risk parameters. Demand management supports the Service Strategy phase by understanding what the market (or markets) want, and potentially shaping that market.
For example, demand management might identify that students want fast network connections between dormitories to play networked games. It might also help point out that email is most often used between 8-9 AM and 4-5 PM. Demand management helps IT understand how customers perceive value.
Demand management may also then try to shape that demand--in this example, by making the network sufficiently fast for network games only between 10 PM and 2 AM. Demand management may work with financial management to use "differential charging" for services based on when they are used.
Universities have many cycles that fit well with demand management, for example semesters. Universities know that registration will occur at a certain time, bills will go out at a certain time, and grades will be received at a certain time. University IT staff often know the impact of these cycles already. This knowledge, if written down, can go a long ways towards a "first version" demand management process.
This video is primarily about project demand management but the concepts are similar to service demand management.
"Service Portfolio Management" is not dissimilar from Project Portfolio Management or Program Management, project management terms. However, Service Portfolio Management manages the "new stuff" and existing services.
Service Portfolio Management is the ITIL Service Strategy process concerned with managing new, current, and retired services. The Service Portfolio Manager balances the three components of the service catalog:
Service Portfolio Management works with Financial Management and other processes to reports on cost allocation, the markets being addressed by service offerings, and they facilitate decisions about how IT's service catalog should change over time.
The portfolio helps align IT with the University, but without an understanding of the University's needs and values the portfolio can become unbalanced. Having a service portfolio management process is much different from having a service portfolio management process aligned with the University's values.
| Attachment | Size |
|---|---|
| Technology Evaluation Form FV1.doc | 60 KB |
The "Four Ps of Strategy" are one technique in IT strategic planning. They are not ITIL's only recommendation on strategy. If this material is interesting please review Service Strategy, especially chapter 3, "Service strategy principles."
The four "P"s of Strategy, as described in Service Strategy, are
For example, a University IT organization may say "We will ensure students have appropriate technology for their education, and it will be available when they need it." This would be the "perspective."
From that, they may say "We need to provide a wide range of services, and partner with other service providers if we cannot provide a certain level of warranty for these services." This would be their "position"--to provide a wide variety of services and outsource the riskier services.
Then they may draw up plans for an updated service portfolio, and the associated design and transition work needed to result in a new service catalog. This would be their "plans."
As the IT shop develops habits associated with this new strategy, such as by checking the availability of services each month to determine whether they are stable enough to continue offering, those habits become "patterns."
The "perspective" should tie into the overall University's strategic plans. For example, if the University is a land grant institution, the IT department's direction should probably include outreach.
University IT departments are often "Type I" or "Type II" providers, serving a single client or a single organization. This makes it difficult for IT to think about "positioning" itself--its market stays relatively constant.
The service catalog should be a list of operational services--the services that already exist. The service catalog and the "service pipeline"--or list of services that are in planning to be created--together create the "service portfolio." The service pipeline and service portfolio are discussed in ITIL v3's "Service Strategy."
Here's ITIL's definition of a "service:"
A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.
The service catalog is the list of "what we do." There are typically two different sorts of service catalogs:
The Business Service Catalog is a deliverable to end users. The Technical Service Catalog helps IT internally keep track of what technical services exist in the infrastructure. Ideally, the two should be linked in some way.
Service Level Management ties what IT is providing to what the University needs. Service Level Management prevents IT from offering "esoteric" services, and assists the University in understanding what is practical.
Please see the Service Level Agreement template, attached to this page. "FV2" is the most recent version, and assumes your organization also has a "Global Service Level Agreement" that covers generic service levels for all services.
| Attachment | Size |
|---|---|
| Service Level Agreement Template.doc | 94 KB |
| Service Level Agreement Template FV2.doc | 108 KB |
Change management is defined in ITIL, COBIT, and other guides. These frameworks can provide a context for understanding change management.
Change management is a prerequisite for many of the ITIL processes. Change management allows other processes, such as configuration management and IT Service Continuity Management, to update their records as production changes.
The "business case" for change management cannot be made as easily in terms of costs, or return on investment. University IT departments must know what they want before they can justify pursuing change management.
| Attachment | Size |
|---|---|
| Service Acceptance Criteria FV1.doc | 41 KB |
| WFU IS First CAB Meeting.pdf | 202 KB |
| CAB Agenda Template.doc | 54.5 KB |
Change categorization is an important component of change management. This page assumes an understanding of the overall "change lifecycle" as defined in ITIL's change management process.
One of the activities in ITIL v2's "Change Management" process is "Change categorization" (section 8.5.4 of Service Support). This v2 activity is a component of ITIL v3's "Assess and evaluate change" activity (Service Transition section 4.2.6.4).
Categorization allows changes to be processed differently. For example, one type of change might need to be reviewed by the CIO, and another type might just need a local authority (such as a manager) to approve the change. Categorization can also ensure appropriate data, needed for subsequent activities and/or reporting, has been added to a request for change (RFC).
Categorization, however, includes several different dimensions of data. ITIL v2 explicitly recommends categorization based on impact and cost:
However, an organization may also want to categorize changes based on what is being changed. ITIL v3's change management process explains several types of changes, in table 4.3:
Arguably ITIL v3 is confusing the issue when it mentions project change proposals and user access requests, as project governance is otherwise frustratingly absent in the ITIL materials and user access requests are covered in another ITIL v3 process, "access management."
Finally, changes may need to be categorized based on why they are occurring. ITpreneurs' ITIL "Release and Control" practitioner training materials mention four change types on slide 22 of their change management training slides:
ITIL v3 expanded on the ITIL v2 concept of Configuration Management, creating a larger process called "Service Asset and Configuration Management."
"Knowledge management" is an ITIL process, first introduced in ITIL as of version 3. The scope of this process can be very broad, potentially including
The term knowledge management is used in different ways in other disciplines; it would probably be a good idea to define the term "knowledge management" carefully before using it.
ITIL v3 describes how information is processed through a "DIKW" flow:
These four phases describe the information itself. Educators might see a parallel to Bloom's Taxonomy, which describes the levels of comprehension:
(These levels are used in the ITIL v3 course syllabi.)
ITIL v3 also proposes the "SKMS"--Service Knowledge Management System--which could be considered the "holy grail" of ITIL v3 the way the CMDB was for ITIL v2. The SKMS would essentially contain all ITSM information.
"Knowledge management" is somewhat of a buzz phrase. The term is not IT-specific, so when talking about "knowledge management" at a University, other departments may have their own definitions.
Release and deployment management is very closely related to change management, and arguably a successor to a good change management program. Please make sure you understand change management before diving into release management.
Release and deployment management is about defining a lifecycle for certain types of changes (e.g. how changes to server operating systems are built, tested, and deployed), and it's about grouping changes together (e.g. all the changes for server operating systems occur at the same time).
For example, Unilever said in their 2007 itSMFusion presentation that their desktop changes are scheduled so that
This process makes it easy to understand how changes are applied to desktops, ensures that changes are tested, and ensures that time and resources are available for the changes. The testing group knows that if their desktop is messed up in the last week of a month, there is probably something wrong with the next load.
Often project management takes on a "release management" role of making sure that the schedule for production changes is understood, that changes are tested, etc. With a strong release management process, project management can trust their changes to release management and then release management can coordinate changes from multiple projects, and relieve some of the effort from project managers.
It is tempting to begin release management with software development projects, as release management defines a standard lifecycle and people are often familiar with their software development lifecycle. However, it's better to focus on areas where
These criteria could apply to your software development lifecycle, but more likely apply to other types of changes e.g. OS patches or vendor-provided application upgrades. You will get much more value for your effort if you start with problem areas, rather than trying to re-define your existing (and working) processes under the title "release management."
Release management is a good time to take care of the "under-the-radar" issues, that need to happen but don't get much attention, to build wins for release management.
"Release management" is not a tool issue. You don't buy a tool and suddenly have release management.
Your release management process needs to work especially well with your change management process.
Really long video from Cambridge about release management in open-source software:
ITIL makes a big distinction in vocabulary between an incident and a problem. Please keep in mind these two are different: a problem is the unknown, underlying cause of one or more incidents.
Incident management is arguably the most important of any ITIL process. Service Strategy, Change Management, and the other processes are all needed, but incident management is the one process that (in my opinion) IT cannot live without. Incident management is the tracking of incidents, which are breaches or potential breaches to service level agreements. In plain English, incident management is about tracking stuff that is currently broken. Without incident management, IT has no way to ensure that users' services get restored when they break.
Virtually all IT organizations have some sort of ticket-tracking system, to keep track of contacts and to help IT staff hand off issues. Virtually all IT organizations also have some form of Service Desk as well, that receives calls, records them, and resolves incidents or escalates them.
Incident management tools ideally track service level targets--for example, when a user is having difficulty checking their e-mail, then the time it takes IT to restore service is tracked against the e-mail service level agreement.
ITIL recommends creating "incident models" for typical issues. For example, at Wake Forest University, our Service Desk often receives laptops that need to be repaired. ITIL recommends creating an incident model to describe the particular process of repairing a laptop.
ITIL also calls out "major incidents" as a particular form of important incident that may require a Major Incident team to resolve. Major incidents are different than problems--major incidents are still trying to get users up and running as quickly as possible (where a problem would be trying to find the underlying cause). Major incidents in an organization could be kicked off by a system-generated page, or whenever a certain number of users might be affected.
Incident management tools allow you to track a lot of information about your users. It can be difficult to map users' department information (e.g. a professor may be teaching in two different departments) and status information (e.g. a student may also be a staff member).
Also, ITIL calls out the option for tracking "VIPs" and handling them separately--if your University marks certain people as VIPs, e.g. the Chancellor, consider this a policy decision. Publicize the policy internally and externally so IT staff understand the purpose of VIP status and so users do not think there is secret favoritism going on within IT.
Find the user groups for your incident management tool and ask your salesperson to put you in touch with other higher education institutions that use that tool.
ITIL defines the word "problem" very specifically. Learning about problem management should go hand in hand with learning about incident management.
Problem Management is the process of investigating the underlying causes of incidents. Problem management relies on three key terms:
A problem becomes an error when it's understood, and a "known error" when there is also a workaround. What does "understood" mean? One itSMFusion presentation recommended that understood means "when you can no longer ask 'why?'"
How is problem management different from incident management? Well, for one the motivations are different. Incident management wants to resolve incidents quickly so users can do their work. Problem management wants to address problems thoroughly so the problems never occurs again.
Problem management is also much more time-intensive than incident management. For example, if a user can't read the text on a web site because they are running Netscape 1.0, incident management might be able to resolve the incident by asking the user to use another browser. Problem management, on the other hand, would have to spend a lot of time debugging Netscape 1.0 to fix the issue. For this reason, prioritization is very important in problem management.
Problems need to be prioritized, then selectively investigated, and then requests for change raised to change management for the errors to be corrected.
Sometimes people "just want it fixed" and are not interested in standing up a process to perform investigation. However, University users, due to their background and varied computing environments, may raise widely different incidents, resulting in a large number of potential problems to investigate and an acute need for problem prioritization.
Problem investigation should ideally be justified by data showing the cost of the problem not being resolved. However, actual cost vs perceived cost can be difficult to account.
ITIL defines Access Management differently from IT Security Management. IT Security Management occurs in Service Design, creates policies, and informs Service Level Management on the access configuration for each service.
Access Management sits in Service Operation, and manages access as defined by IT Security Management.
"Identity management" is very closely related to ITIL's access management. Identity management can be an especially big subject at Universities, tied to both IT Security Management and access management. Additionally identity management does not necessarily address the rights granted to individuals (authorization), which is the core of ITIL's access management process.
Access management maps rights to identities. "Identities" are the people in your organization, being able to prove they are who they say they are. "Rights" are the abilities that identities have on various systems, e.g. the right to create new data or the right to delete data.
Access management works closely with Request Fulfillment and/or Incident Management to receive access requests from the Service Desk. These requests follow a standard process:
Additionally, access management is responsible for "access monitoring and control." Access management should ensure that the access provided continues to be appropriate, for example watching out for potential conflicts of interest.
Access management should work with Human Resources to coordinate access removal and suspension as people change jobs, are put on leave, or leave the organization.
Universities may have a large, difficult-to-define population including students, faculty, staff, alumni, parents, and visitors. In this context getting consistent identity information is in itself very difficult.
Additionally, people are more likely to play multiple roles at a University than in a corporation. For example, a student may also be a teaching assistant, an alumnus, and a parent.
Your organization most likely already has systems generating events, such as syslog messages and network traps. Event management is the idea that the events from all these systems could be put together, correlated, and then incidents or other records generated as appropriate.
Event management tracks automatically-generated events in your environment that are "significant for the management of the IT Infrastructure" or otherwise relevant for services being delivered. It's up to your institution to decide what's "significant." Event management then filters and classifies the events into one of three categories:
Ideally event management performs correlation--the buzz-word here is a "correlation engine." This correlation should help people understand that event #2 (service is back up) is related to to event #1 (service went down). This correlation could also work between systems, e.g. a server's database and applications are generating exceptions because the underlying server is generating exceptions.
Event management can call incident management: exceptions and warnings could then generate incidents for real people to review.
Conversely, other processes can query event management: incident management and problem management could also search the event history for more information about why something broke.
Event management is ideally executed by an automated system. People may design and query the event management tool, but no person reviews every event that is generated.
Event management cannot stand on its own--it needs to work closely together with Service Design to ensure systems are designed to generate appropriate event, and it needs to work with Incident Management and perhaps even Change Management to ensure that appropriate events are escalated.
Vendors want to sell event management tools. These tools need to fit well within your ITSM suite.
Make sure that any event management tool you support can receive events from the systems you already use. An event management tool should be able to gather events from your other systems tracking events.
"Request fulfillment" is an ITIL v3 concept. In ITIL v2, it was considered part of Incident Management. However now the two are separate: incidents are for things that are breaking or about to break, and service requests are for new things.
Request fulfillment is tightly coupled to service catalog management--request fulfillment is when services are actually ordered from the service catalog.
Request fulfillment is the process of providing "normal" services to users, such as the creation of a listserv or a Blackboard course. Request fulfillment calls these requests "service requests" because they are requests for a particular existing service. Service requests should be predictable, and popular service requests can be optimized and automated and "request models" defined for them.
Request fulfillment includes asking questions, such as "How much email quota do I have?"
Vendors try to sell request fulfillment tools, usually bundled as part of a service catalog solution. Request fulfillment and incident management are particularly linked (e.g. when a user is calling you can't be sure whether they're calling about something that's broken or something they want to order), so it is important to consider the integration needs between your request fulfillment tool and your incident management tool.
Request fulfillment often is associated with charging--if you provide a "desktop printer request" service, then people will want to order desktop printers and someone will need to pay for them. However, based on the charging model for a University IT department, it may be more difficult for IT to fund the "goods" supporting a service request. Ironically by doing a good job of request fulfillment an IT department's costs can go up.
"Continual Service Improvement" is one of the five ITIL v3 books. It, along with all the ITIL books, refers to the "Deming Cycle," four phases of both process improvement and process implementation: Plan, Do, Check, Act.
Continual Service Improvement is also very metrics-focused. When learning about Continual Service Improvement it can be helpful to have an understanding of reporting/data analysis concepts, such as how "dashboards" can be helpful.
ITIL's continual service improvement model has six steps:
In this model, an IT organization knows what it wants, then conducts a baseline assessment, sets desired metrics targets (e.g. Critical Success Factors, or CSFs), begins the process improvement proper, and afterwards reviews its metrics to determine whether the improvement was successful.
Each step is important. For example, the baseline assessment ("where are we now?") may not seem necessary, and many IT departments perform improvements without an assessment. However, six months later no one can prove how much better things got, because there was no measurement taken "pre-improvement."
Continual Service Improvement relies on appropriate metrics to support of an overall vision. On page 48 of ITIL v3 Continual Service Improvement, ITIL recommends a continuum, including "Vision," "Objectives," "Metrics," and "Measurements." It's hard to create useful metrics because, as in quantum theory, observing a system changes how it works. For example, if an organization measures how long calls to the Service Desk take, it may encourage Service Desk employees to hang up the phone before the user is satisfied.
Metrics can balance one another; for example, the length of a phone call may be a better measurement when combined with a satisfaction survey. An organization may also have different goals at different times for its metrics; with an Incident Management implementation, a department may want to increase the percentage of tickets resolved by the Service Desk, but then after a Problem Management implementation they may want the opposite.
Universities often have less of a "measurement culture." Introducing metrics can make staff uncomfortable when they are not sure how the metrics might be used.
ITIL recommends setting Critical Success Factors (CSFs), Key Performance Indicators (KPIs), metrics, and measurements for processes and services. Metrics are used throughout ITIL's Service Lifecycle but they have particular importance to Continual Service Improvement.
Continual Service Improvement recommends a connection from an organization's vision into metrics through the following continuum:
Metrics can be used for four reasons:
Metrics can help show others what a great job you did, after an improvement is complete. Metrics also help set a common goal. Metrics, in fact, can be motivating!
Universities may be less likely to have strong metrics because they do not need to justify themselves to stockholders and they do not try to maximize revenue the same way as a public company. Also, it can be difficult to translate an academic vision such as "classroom excellence" into measurable goals.