• Like
uccsc ITIL demo
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.



  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. ITIL at UCSC Implementation Experiences 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.
  • 2. 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 significant cultural and political change.
  • 3. 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?
  • 4. 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 service desk.
  • 5. IT Request Ken Garges, System Administrator
  • 6. Questions?
  • 7. Change Management We found ITS was already practicing various forms of Change Management. 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.
  • 8. Change Management Our values: agile thorough flexible scalable constantly improved We began with establishing our values, because we know that successful change is all about trust
  • 9. Change Management Many of us are concerned. Some of that concern is valid. We’re changing how we think about change.
  • 10. Change Management •planning •testing } Trust this •scheduling •communicating } Start here It is not about second-guessing or getting in the way of real work. Implementing CM means that both workflow 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.
  • 11. Change Management Step 1: All service outages, planned and unplanned, must be communicated using a division-wide process.
  • 12. Change Management Step 2: Engineers, developers, and technicians create and refine 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, defining roles, and procedures.
  • 13. Change Management How are we doing? Forward Schedule of Changes October, November, July December & January
  • 14. Change Management 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.
  • 15. Incident Management If it’s broken, fix it. If they need it, provide it.
  • 16. Incident Management 1. Be Process-Driven 2. Be Client Focused The first thing we learned: Think about tech support in terms of processes with inputs, outputs, roles, procedures, and policies. Second thing we learned: focus on the client (aka end user). We thought we were doing that, but we weren’t. Not really.
  • 17. Incident Management • Incident Management is a process that most IT people do already. • Benefits realized quickly, efficiently. • Metrics are simple and it is easy to understand how the process benefits the user • There are operational processes, such as communication, that IcM doesn’t address. Use the framework as needed.
  • 18. Incident Management • Gained the benefit of a common language: “incident,” problem,” “workaround,” “resolve,” “refer,” “escalate” • Gained benefit of recording all (or most) work, and benefits are visible internally and to campus. • “First-contact” tech completes and records first three steps before contacting anyone else.
  • 19. Incident Management • 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 fulfilling the purpose of the unit.
  • 20. Incident Management • Used Incident Management processes as organizing framework of IT Request Manual. } Recording Classification Procedures & Investigation Policies Referral and Resolution Closure • SC staff are trained in using IcM in their first 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.
  • 21. Incident Management ITS Major Incident Handling Process Overview Help Inc Desk Tech Lead PMG/Comm Coord Step 1 Recording Incipient Designed “Major Event Tracking Incident Handling” Step 2 Classification Major Incident Classification process for division based on Step 3 Major Inc MIH Tracking Declared Diagnose IcM Create SMT/DLs Prelim Notified Comms Step 4 Assign Tech Lead Build Team Resolution Referral/ Work Incident Major Inc Event Coord Comms Resolution Step 5 Closure 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 figure out that a major incident wasn’t a problem. Problem management is an arson investigation. incident management is putting out fires, and well, a major incident requires the same things that forest fire does--an incident commander.
  • 22. Incident Management Process Metrics We already had the business process of assigning all tickets by the end of the day and completing recording, classification, and initial diagnosis. So when campus SLA asked us to make first contact within one business day, we were ready for it.
  • 23. Contacts • ITS Core Technologies System Admin • Ken Garges, garges@ucsc.edu • ITS Support Center Manager • Linda Rosewood, rosewood@ucsc.edu • ITS Change Manager • Charles McIntyre, mcintyre@ucsc.edu