Developing a Service Catalog for Higher Education Information Technology Services
•Download as PPTX, PDF•
1 like•556 views
This presentation summarizes the process of developing a new IT service catalog and web site for Hobart and William Smith Colleges' Information Technology Services. I presented this at the 2009 SIGUCCS Service and Support conference.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (17)
Similar to Developing a Service Catalog for Higher Education Information Technology Services
Similar to Developing a Service Catalog for Higher Education Information Technology Services (20)
Recently uploaded
Recently uploaded (20)
Developing a Service Catalog for Higher Education Information Technology Services
- 1. Developing a Service Catalog for Higher Education Information Technology Services Andrew H. Lyons Hobart and William Smith Colleges lyons@hws.edu Geneva, NY
- 2. Introduction Provide better service with a service catalog Meet customer needs Easy and quick Take action Continue ITIL implementation
- 3. Situation Old IT Services site Lots of massed information Organized by technology Complex structure Redundant content and links
- 4. Situation Customer needs Access information when they want it Take action Instructions Request submission Know what to expect Problem Old IT Services site ≠ Customer needs
- 5. Proposal Rebuild the IT Services Web site Simplify layout, organization, wording Get rid of dead weight (redundancy, orphans) Focus on customer needs What services we provide How to request the services or get instructions Where to get help
- 6. Plan Scale Product Technology Features People Team Input from users and IT department
- 7. Plan Priorities Customer-oriented Simple organization Searchable Actionable Regular language (not jargon) Internal Consistency Set expectations
- 8. Plan Timeline Hard deadline for launch Define phase goals, documents, and milestones Set schedule Phase Task Days Planning 25 1 Determine services and categorization 80 2 Define and document services with service level agreements 50 3a Design service catalog and templates 20 3b Build catalog from content and templates 20 3c Test catalog release candidate 5 3d Initial launch 2 4 Review response, edits, plan new content 50 5 Review effectiveness and plan development 50
- 9. Preparation Services Collect, review, cull, add Template for standardized definitions Service Name: Summary (what you get): Services included: Prices: When customer receives it: What is not included: Related information: Where/how to request this service: Where are requests routed?
- 10. Preparation Categories: How to group services By technology with user-friendly names? Too many and still complex Questions customers might ask? Too long and too many Simply the kind of need Do something Show a film, record A/V, install anti-virus software, ship a package, reset password… Need something Network folder access, equipment loan, new e-mail address… Fix a problem Request immediate help Get information Policies, instructions… Buy something Computer repair (prices), print credits, software, computers (specifications)… Work in IT Jobs list Offer an idea/ask a question None of the above
- 11. Creation Build services from template Forms Always available (no hours) Standardize information captured Flexible input on one page
- 12. Forms
- 13. Execution Partnered with Communications Tweaks Instructions General informational content Link to service request database
- 14. Result Increase in traffic Improved information in requests for services Increase in customer satisfaction Decrease in call volume
- 15. Result
- 16. Result
- 17. Finished? Feedback Continual Development Edit, add, remove Service level agreements Future Plans Database/CMS-driven dynamic content Role-based authentication to available services Automated approval process
Editor's Notes
- Our goal in Information Technology Services is to provide the best service we can to the consumers of IT at Hobart and William Smith Colleges. To achieve this goal, we undertook a project to develop a formal service catalog to make clear what we can do for our customers, what they can do for themselves, and where they can get help when they need it. This project is part of our ongoing effort to implement several ITIL framework best practices recommendations.
- At the beginning of this project, our Web site presented a lot of information up front and under many different categories. It was a great improvement on its predecessor, but not great. The content was roughly organized by technology, but available through multiple paths which had splintered over the years and become more of a mess than a structure. There was a lot of redundancy, outdated material, broken links, and orphaned or hard to find content (I even learned of a few things during the project).
- Our customers need three things from us: Information about what we do and what we provide for them to use whenever they want to get it The ability to take action either by helping themselves with information or instructions or by submitting a request for assistance Finally, they must know what to expect in terms of service level, features, cost, and expected completion time The problem we had was that, while our old site did provide a lot of things, it was not effectively meeting the needs of our customers. We saw a lot of room for improvement and had an idea of where to start.
- To improve the content, services, design, and structure of our site, we proposed rebuilding it from scratch. This approach allowed us to not be stuck answering “how should we reword this piece?” and endlessly edit, but work with only the subjects for starting points. In doing this, we simplified the text and structure dramatically, while clarifying many points that had been previously vague or inconsistent. By starting over, we very easily got rid of many redundant or orphaned pages and documents that had grown up over the years. We focused on how best to meet our customer’s needs by highlighting what services we provide, how they can request those services or help themselves to services such as wireless networking setup, and what their options are for requesting assistance if they are stuck or have an emergency.
- To effectively begin the project, we had to do a lot of planning, beginning with scale: how much could we reasonably accomplish? Though, we had many ideas of what a service catalog might be, we had limited time and resources to work with, so we first determined the appropriate technology and features to include. We also had to plan a useful, but efficient project team and methods to get departmental input and buy in throughout the project. For technology, we stuck mostly with simple HTML with a few small applications, but nothing too dramatic. For the team, we picked two project managers, a lead-level supervisor, and a developer to consult. For departmental content input and review, we were granted wide access to assign requests and deadlines, thanks to enthusiastic support from our CIO.
- Again, the priorities we set were to keep the entire project customer-oriented while helping it work better for us. We did this by keeping the organization simple (details to come), using key words in the content to facilitate searching, providing links and contact information to allow easy submission of requests, and using as much normal language as possible to help prevent confusion among our customers that jargon may cause. To help the catalog serve us better, we aimed to make it as consistent as possible by using more references for content that may change over time and by structuring customer input to include what we need to know. We also set expectations for the level of service and timeline as much as possible so that our customers know what to expect and we can avoid trouble from different perceptions of difficulty or priority.
- The next step of planning was determining our phases and milestones and creating a schedule of how we can define meeting them and how much time we allow to do so. We had a hard deadline for launch (roughly the new fiscal year and we were in October), so the actual schedule was quite important.
- After we had the schedule planned, we set to work on what to do with the services we provide. We began with the existing services from the old site’s list, reviewed them for duplicates and relevance, purged those we did not want, and added a few that were missing or had developed since that list was made. We also created a template for the service definitions. The template is similar to the format of our service level agreement documents, but more customer-friendly and simplified for use on the Web.
- Once we had the services together, we had to figure out how to categorize them. We worked through a few options, each with their pros and cons, and settled on grouping by the kind of need from the customers’ perspective, figuring we can route service requests internally, but the most important part is communicating.
- With the service list, categories, and templates, we developed the service definitions. The project team filled in some basic information and then distributed each service to the team that would complete it to elaborate descriptions and fill in the details of what information needs to be captured, expected completion, and precise definition, while continuing to discourage jargon. At this stage, we also determined that the best way to assure we get the information we need to fulfill requests and make it easy for our customers to provide it is to have Web forms for as many services as appropriate. With the necessary information data from our services, we determined a basic set of form fields for any request and then what fields each of the relevant services would need. We had previously used separate pages for each form, creating some customer confusion and maintenance hassle, so we made the forms on one page with a static (all forms) section and a dynamic (service specific) section that changed based on the service selected.
- Our forms in action. The lower section changes for each service selected. The form creates an e-mail from the user to our Help Desk account, which ties to our service request management system, automatically generating a request with all of the form data.
- To create the final site, we worked with our Communications office to integrate our technical needs and internal design with the greater HWS site, of course with some tweaks and fixes along the way. We also updated old instructions and created many new documents to post along with general information about our department and technology on campus. We also rebuilt a link to the service request database, allowing customers to check the current status of their open requests online at any time.
- Since the deployment of our service catalog, we have seen: Increase in traffic to the IT Services site and catalog (attesting to improved utility) Improvement in the completeness of information submitted in requests for services (thanks mainly to the forms) Increase in overall customer satisfaction from the improved quality of information available (positive feedback) Decrease in call volume around some of the most frequent requests now that we have more easily available instructions (indicating that our customers are empowering themselves through the self-service options)
- The service catalog (IT Services landing page). The categories with examples. Request Help button direct to the form page. Other information (policies, bulletins, search, etc.).
- A sample service: the “how to change a password” page. Like the template, but unused fields removed. Category services and other categories on right. Help Desk contact information on every service.
- Now that the service catalog is live, are we finished? Never! Since deployment, we have added and modified several services, especially to accommodate changes in the technology that supports them (VPN, Wi-Fi, NAC/IDS, personal printing). We also plan to develop and closely tie the services with formal service level (customer oriented) and operational level (internal, technical) agreements. We also have dreams for further development of the catalog, mainly developing it in a database-driven, dynamic environment to improve scalability, site-wide changes, and allow for other developments. Other potential options include role-based authentication to more sensitive services and automated approval for access or purchase requests.