IT Service Catalog: Lessons Learned

Transcription

1 IT Service Catalog: Lessons Learned Blythe Fogle, Phillip Ashcraft Associate Directorate for Business Innovation: Service Innovation Division May 4, 2016

2 Why create an IT Service Catalog? To consolidate all IT services and information in one location To give customers the information they need when requesting or troubleshooting a service To give customers the opportunity to learn how to use a service or fix an issue themselves To tell customers the requirements for using each service Slide 2

3 Catalog overview Joint effort between LANL s IT divisions and the Office of the Chief Information Officer (CIO) Planning and initial design began in 2011 First catalog version published in July 2012 Second catalog version published in February 2013 Linked from the LANL internal homepage Provides info and actions for ~80 IT services Slide 3

4 Previous customer experience of IT content At start of catalog project, CIO developed a list of hundreds of LANL internal webpages with existing IT content In general, content was scattered, out of date, not consistently formatted, existed in multiple versions (sometimes with conflicting information), and lacked a lifecycle management process Some information was too technical for customers without an IT background Some services had no information available at all Difficult for customers to determine requirements for requesting a service Support point of contact not always clear Slide 4

5 How to get started: form your band Created a Service Catalog Design Team 2 IT Service Management representatives 1-2 representatives from each IT organization Coordinated with CIO representative Ensured that most customer services were documented from the beginning Encouraged a balanced approach no single organization favored over the others Slide 5

6 How to get started: define service Developed criteria for identifying whether a service should be included in the catalog 9 criteria defined initially, 2 criteria have become the focus of the catalog: Must be user facing: visible and consumed by LANL staff Must be approved through the service onboarding process and ITSM governance (composed of a technical Collaboration Team, a Change Advisory Board, and a Change Manager) Based on defined criteria, Design Team identified ~60 services to include in first draft of catalog Slide 6

7 How to get started: find order in chaos Taxonomy developed as a joint effort between CIO representative and Design Team Items sorted into families of related services rather than by supporting organizations (a significant change and difficult for some organizations to accept) Nine service families identified: 1. Access and Passwords 2. Communications 3. Computer Security 4. Data Storage and Servers 5. Desktop and Mobile Computing 6. High Performance Computing 7. Networks and Connectivity 8. Software and Business Tools 9. Web and Collaboration Slide 7

8 How to write good: drafting service definitions Identified a Service Owner for each service Owner responsible for quality of service, not delivery 12 people identified to write 60 service definitions Writers had backgrounds in management, IT, or both Developed standard template as a guideline for drafting service definitions Issues discovered as drafts were turned in: Despite using standard template, Technical writing inconsistencies: drafts used different layouts and grammar, punctuation, etc. formats to present information Forgotten grade school English Writers had extensive IT classes plagued nearly everyone backgrounds, so drafts were loaded involved with jargon and acronyms Slide 8

9 How to write gooder: editing and standardizing services Design team included student employee with background in technical writing Student edited and rewrote all 60 services to simplify language and provide unifying, customerfriendly voice Rewrites reviewed by Service Owners to ensure no misinformation was introduced during rewrites Rewrites approved for publication by Service Owners Slide 9

10 How to prevent months of rework: choosing the right tool Three tools were initially considered for publication: Remedy Service Catalog Module Pros: Tool already in use with IT support staff Tied in to other ITSM modules already in production Cons: Authentication challenge: users had to log in before accessing Remedy Not mobile-friendly PHP Webpages: Dreamweaver Pros: Many web-based tools already written in PHP format, simplifying migration to the catalog 65% of existing web content about to be migrated was also in PHP format Cons: Required that all catalog editors be able to work in HTML code Not the LANL standard method for presenting web content Content Management System: Cascade Server Pros: LANL standard layout, look, and feel using WYSIWYG tool Archive of previous edits and log of editors actions Cons: No ability to link metadata to web content (initial service drafts included common aliases and misspellings for services) Slide 10

11 How to prevent months of rework: consequences of choosing the right tool Developing catalog in PHP took 9 months of work with only 2 editors dedicated to the effort Around 450 webpages of existing content were migrated and required heavy editing to fix links, images, and other HTML coding issues Dreamweaver s preview feature did not work for one editor, so pages had to be published to development server to check for errors Editors changed content without alerting each other, causing hours of rework No log of who was working on what, leading to miscommunication regarding content ownership CIO resource s focus was divided between content migration and overseeing custom development of CMS landing page Slide 11

12 How to prevent months of rework: choosing the right tool, round 2 It turns out that the CMS could solve many of the PHP issues. PHP Problems CMS Solutions CMS Bonus Features Significant effort required to develop pages using HTML code led to concerns about long term maintenance Links and images were broken during migration and when files were moved or renamed Editors changed content without alerting each other, causing rework to revert to previous version Preview feature was broken for one editor Provides two methods of editing: using a WYSIWYG tool or editing the HTML code directly when needed Automatically compensates for moving and renaming files, so links and images are not broken Reversion feature already included in tool, along with logging feature identifying who makes each change Preview feature works for everyone Quick conversion of content, allowing cut and paste or file relocation rather than code editing Improved navigation, allowing users to keep track of their location using breadcrumbs Blocks feature allows the same information to be presented and updated on multiple pages at once Migrating catalog content to the CMS took an additional 7 months of work. Slide 12

13 How to claim victory: publication phase CMS migration and final publication were completed in February 2013 Benefits of using CMS: Content is easier to edit and preview Change control process streamlined using CMS features (change logs, content reversion, etc.) Backup CMS editors available if catalog editor unavailable Content adheres to LANL web standards Slide 13

14 How to create IT staff buy-in: maintenance phase Encountered some resistance from some IT staff who wanted to retain control of their content Demonstrated benefits of migrating content to the catalog: IT staff no longer have to spend time on webpage maintenance Changes to catalog content usually made within 1 business day Content maintenance performed by qualified professional writer IT staff time freed to work on technical projects Due to benefits and metrics showing increased traffic to catalog, migration of remaining IT content has remained steady Catalog now enthusiastically supported by most IT staff Catalog Updates, Feb-13 Apr-13 Jun-13 Aug-13 Oct-13 Dec-13 Feb-14 Apr-14 Jun-14 Aug-14 Oct-14 Dec-14 Feb-15 Apr-15 Jun-15 Aug-15 Oct-15 Dec-15 Feb-16 Note: February 2015 spike indicates knowledge migration effort. Slide 14

15 How to create customer buy-in: maintenance phase Dedicated a resource to maintaining the catalog Catalog updated on a daily basis for both service content and web maintenance (mobile accessibility, ADA requirements, etc.) Created simple feedback method for requesting changes All customer feedback is responded to within 1 business day, including: Missing and outdated content Clarification of troubleshooting and how-to guides Broken links and images Because customers receive quick responses, they become more willing to speak up about issues and questions Feedback cycle feeds into continual service improvement 100,000 90,000 80,000 70,000 60,000 50,000 40,000 30,000 20,000 10,000 0 Catalog Visits, Feb 2013 Apr 2013 Jun 2013 Aug 2013 Oct 2013 Dec 2013 Feb 2014 Apr 2014 Jun 2014 Aug 2014 Oct 2014 Dec 2014 Feb 2015 Apr 2015 Jun 2015 Aug 2015 Oct 2015 Dec 2015 Feb 2016 Slide 15

16 How to stay in business: continual service improvement Continued coordination with Communications Office to ensure catalog meets user needs and web standards Added search feature to allow for multiple methods of finding information Search confined to catalog pages only Developed simple feedback mechanism that drives the CSI process Simple tool that alerts catalog editors to issues or questions Feedback button used equally by both customers and IT staff Customer base initiates much of the quality control work involved in maintaining the catalog Feedback drives lifecycle management quick response encourages further feedback, which further improves the catalog Formally defined change control process, promoting ease of updates and consistent communication with Service Owners and their designees All changes documented, logged, and reported to management at the end of each month along with web traffic statistics to show concrete evidence of continued buy-in Screencap of catalog feedback feature. Slide 16

17 How to promote IT Service Management: catalog as a focal point Strong catalog foundation has contributed to its status as a central hub for IT information and IT Service Management processes Became central knowledgebase for both customer and technical IT information starting in February 2015 Response to difficulties with Remedy 7.X Knowledge Management module Catalog now hosts ~500 technical knowledge articles for Service Desk reference Technical knowledge became foundation for training Service Desk staff Developing catalog as portal to Request Fulfillment Management process As actions are developed into service request cards or work orders in Remedy, they are linked from the catalog for ease of customer use RFM process used taxonomy developed by Service Catalog Design Team to organize service request cards Slide 17

18 Example of the IT Service Catalog Basic service description provided with other information available under twisties. Contacts block provides phone, web, and help. Search function under lefthand navigation produces results restricted to the Service Catalog. Request block provides quick links for acquiring a service. Knowledge block provides FAQs, training, how-to guides, and additional resources related to the service. Slide 18

19 Questions and contact information Blythe Fogle IT Service Catalog Manager (505) Phillip Ashcraft IT Service Catalog Owner (505) Slide 19