ITIL at UCSC
Linda Rosewood, ITS Support Center
Ken Garges, ITS Core Technologies
I’m Linda Rosewood the ITS Support Center Manager, in ITIL terms, this is our Service Desk.
Ken Garges is a system administrator in the ITS Core Technologies unit.
UCSC’s is in year three of a consolidating its
IT departments into a single division. Two
years ago, we adopted ITIL as the
framework around which to build the
processes and roles we were consolidating.
This presentation describes our progress.
About three years ago UCSC decided to consolidate its IT units into one division. We
weren’t quite sure HOW to do that, but we did have a vision of what we wanted it to be
when we were through with it. About two years ago we discovered a framework for
understanding the business of IT .One of ITILS attractions was that it appears to be a
collection of best practices, and a vocabulary that would help to communicate with each
other as we were about to undergo a signiﬁcant cultural and political change.
ITIL resources give lots of theory... process
maps... lists... inputs ... outputs... KPIs......
All that is very helpful in getting organized.
But what happens in real life?
The one thing that everyone says about ITIL is that there are lots of resources and training
opportunity, but how is it done, really?
Service Desk Ticket System
Applied Change Management
Change Management Plan
Incident Management and Service Desk
We’ll start by sharing with you the tool we chose to track incidents and service requests.You
can’t begin to do deliver IT to a university without at the very least an ticket tracking tool. Ken
will describe the application and the system architecture, and then he’ll also talk alittle about the
change management processes that we use to maintain it.
I’ll then describe our approach for introducting Change Management to the entire division, and
then return to the ticket system, and our approach for introducting Incident Management in the
We found ITS was already practicing various forms of
The problem was that there was a spectrum of testing
practices, no standards, no common vocabulary, and little
visibility between dependent units and to the campus.
We began with establishing our values, because we know that successful change is all
Many of us are concerned.
Some of that concern is valid.
We’re changing how we think about change.
•testing } Trust this
•communicating } Start here
It is not about second-guessing
or getting in the way of real
Implementing CM means that both workﬂow and culture will change too.
These changes must be addressed on a personal level.
• And the introduction of change management must be made from a simple, successful approach.
All service outages, planned and
unplanned, must be communicated using a
Engineers, developers, and technicians
create and reﬁne the request process.
The real-life tools and processes will be developed by the people who use it the most. The next
steps are about creating the RFC template, establishing communication channels, deﬁning roles,
How are we doing?
Forward Schedule of Changes
October, November, July
December & January
We seek collaboration with other campuses.
UCSC & UC Davis Medical Center
Plan to visit more campuses throughout the year to
develop relationships and share knowledge.
If it’s broken, ﬁx it.
If they need it, provide it.
1. Be Process-Driven
2. Be Client Focused
The ﬁrst thing we learned:
Think about tech support in terms of processes with inputs, outputs, roles, procedures, and
Second thing we learned: focus on the client (aka end user). We thought we were doing that, but
we weren’t. Not really.
• Incident Management is a process that most
IT people do already.
• Beneﬁts realized quickly, efﬁciently.
• Metrics are simple and it is easy to
understand how the process beneﬁts the
• There are operational processes, such as
communication, that IcM doesn’t address.
Use the framework as needed.
• Gained the beneﬁt of a common language:
“incident,” problem,” “workaround,”
“resolve,” “refer,” “escalate”
• Gained beneﬁt of recording all (or most)
work, and beneﬁts are visible internally and
• “First-contact” tech completes and records
ﬁrst three steps before contacting anyone
• Understanding the process keeps focus on
getting client back to work, and away from
the technical and political distractions.
• Roles: helps staff to understand their role in
fulﬁlling the purpose of the unit.
• Used Incident Management processes as
organizing framework of IT Request Manual.
Referral and Resolution
• SC staff are trained in using IcM in their ﬁrst week.
• Instead of using the tool’s menus as our organizing principle we used ITIL processes
• reference to the manual re-enforces understanding of the process’s structure
• manual’s structure is independent of the tool we’re using. Policies and procedures will transfer well to next system.
ITS Major Incident Handling Process Overview
Desk Tech Lead PMG/Comm
division based on
Major Inc MIH
Step 4 Assign
Major Inc Event
Closure Closure Closure
a major incident has the same processes as any other incident except that troubleshooting,
referral, and communications need to be highly organized.
took us a while to ﬁgure out that a major incident wasn’t a problem. Problem management
is an arson investigation. incident management is putting out ﬁres, and well, a major
incident requires the same things that forest ﬁre does--an incident commander.
We already had the business process of
assigning all tickets by the end of the day and
completing recording, classiﬁcation, and initial
diagnosis. So when campus SLA asked us to
make ﬁrst contact within one business day, we
were ready for it.
• ITS Core Technologies System Admin
• Ken Garges, firstname.lastname@example.org
• ITS Support Center Manager
• Linda Rosewood, email@example.com
• ITS Change Manager
• Charles McIntyre, firstname.lastname@example.org