Case studies  | University of San Francisco

We had a 3-month implementation. I was expecting a year to 18 months from other vendors, so I thought the 3-month implementation from ServiceNow was extraordinary. –Tracy Schroeder, University of San Francisco VP of IT

The University of San Francisco case study is based on an interview with Tracy Schroeder, University of San Francisco VP of IT

USF is a private Jesuit institution – one of 28 in the United States. USF was founded in 1855. We are approaching 9,000 students, and a grand total of 1,500-2,000 employees depending upon the time of year and the count on adjunct, full-time, part-time, etc. We have a large number of alumni, but if you count the alumni active in our portal using our IT services only, we count our active user base at about 20,000.

Past challenges prior to using ServiceNow

The first service desk was implemented at USF back in the 2000 timeframe, and it was before the IT group really knew anything about ITIL or ITSM. We used Remedy in a very componentbased way and not with the perspective of what service anything was a part of. So you'd have category type and item schemes for categorizing incidents that would end up being, say, hardware or other. And it was very difficult to map metrics for the various incidents that would occur to say, "How many incidents did we have this month related to e-mail?" and "What was our resolution time around all of our collaboration and communication services?" 

Ultimately, we were able to do it, but it was an expensive, manual mapping process for us to make that happen given the structure we'd established in Remedy. No fault of Remedy, of course, but just the fact that it pre-dated our understanding of a service-based approach to incident and problem management. That was something that we really wanted to re-do, and a question was whether we should re-do it in Remedy or in a new tool. 

Some of the other issues we had were our workflows and client self-service – everything required custom development in Remedy. In my experience with it, you had to hire consultants, you had to have custom development. Their recommendation for rolling out selfservice was basically that the client would see the same thing that the IT service tech would see, and it was way too much information and many more tools than people needed, and we knew that to point self-service in that direction was going to generate yet more support calls. So we hired consultants, we created customized forms, etc., and that took a lot of time and effort and we were concerned about having to replicate that in a new environment. 

We also had no service level agreement tools. We couldn't build in schedules, alerts or escalations based on priority. I couldn't get an alert if there was a Priority1 incident, except with custom programming, for which we had no budget. If I wanted to know what was going on, I had to log on to Remedy and search and explore, and as a CIO I just don't have time to do that, so I really wanted alerts from a new tool. 

We implemented a tool for change management process, but we had to handle it by e-mail and ended up tracking it in a spreadsheet because developing the workflows to do that in Remedy was just going to be yet another costly services engagement for which we didn't have the resources. 

Finally, our system was at end of life. We knew we had to upgrade, and that it was going to be costly. They made it clear that it was going to be a re-implementation and we would be starting over. At the same time, we were in the middle of an ERP implementation, so all of our programming and administration resources were fully spoken for. 

I couldn't pull programmers or system administrators off of a banner implementation to spend time on a back-office tool for the IT department to be more productive. I didn't even try to make that sell to my client community. We didn't have the resources to put toward an extensive implementation from the infrastructure and programming perspectives.

Requirements for a modern IT service management application

How did we deal with all of those issues? We continued to use Remedy and developed workarounds. We did things the oldfashioned way for several years, and to some extent that was good for us for a few years because it forced us to focus on process, and to learn how we needed our RFC and incident processes to work, how we wanted to prioritize our incidents, and which metrics we wanted out of the system. 

We started building our requirements for what we really wanted, and that we wanted a tool that was going to take an ITIL approach from the beginning and be structured based on services, comprised of elements from the CMDB. We wanted something we could deploy easily, that would not suck up all our programming and admin resources to support. 

We were most focused on incident, problem and change, because we were most mature in these and we knew what we wanted. We had aspirations to do more in other areas, but those were our top three priorities. 

We needed to be able to integrate with our campus portals for single sign-on and with our asset management tool, LANDesk, and our knowledge base, RightAnswers. 

We wanted to be able to customize very simply – adding fields, renaming labels. We wanted to be able to leave a note that if somebody entered data in a given field, it would go to the client. We wanted to be able to do all of this without hiring consultants and without need for a programmer, at least in most cases. 

We wanted our clients to have good, clean self-service that we weren't going to have to build and I wanted to be able to get data out, to be able to show easily what was happening with our services without a lot of manual labor from my assistant for monthly metrics.

Why ServiceNow?

We explored our upgrade options with Remedy and saw it was going to be a re-implementation - as costly as purchasing a new system. So we put out an RFP and got responses from CA, HP, Remedy and ServiceNow, but in 2007 we didn't have the funds to proceed so we sat tight for a year. 

In Spring 2008 we decided we really had to do it. We had a call with a Gartner analyst about what our goals and constraints were, who was new in the marketplace, and they really recommended that we take another look at ServiceNow and a few of the other newer vendors in the space, and we really liked what we saw in ServiceNow. We had more success in talking about the business arrangement with them, and our help desk and technical staff really liked what they saw in ServiceNow as a next-generation application that they would actually enjoy using. 

That helped build internal buy-in for the project. Also, our system administrators saw that they weren't going to have to build this out; they were just going to be able to use it.

Results: three month implementation

We had a three month implementation. I was expecting a year to 18 months from other vendors, so I thought the three month implementation from ServiceNow was extraordinary. 

I get notifications for all of our Priority1 incidents or any level I want. We get notifications when we're escalating. We've set in what our business rules are for when incidents escalate. It has eliminated a lot of manual work for the help desk manager to watch the aging of tickets and see who is moving things through their queue; instead, it's just coming to her, and she knows what she needs to follow up on. 

Our request for change (RFC) process happens entirely in ServiceNow, without issue. We integrated LANDesk and RightAnswers. As an unexpected bonus, we've been able to adopt [ServiceNow Project Management] to track our pending projects and our project queue and track major work items.

Results: metrics

We have streamlined our metrics process, we can get them straight out based on how we've built our service categorization scheme. 

We've also implemented client satisfaction surveys and selfservice ticket submission. We had done these in Remedy, but they were custom development and they were old and had browser incompatibilities, which hindered adoption. We've been pleased by how much of a difference the ServiceNow experience has had on clients' willingness to fill out surveys and to submit their self-service tickets. 

Between March 2008 and March 2009, the number of clients that took the time to respond to our satisfaction survey upon resolution of their incident or service request, more than doubled, and the responses have gotten much more positive about service happening in a timely manner, knowledgeable staff, good customer service and issues resolved to satisfaction. Some of the credit goes to my staff, but at the same time, the tool has certainly helped. 

The most common comment I used to get from my executive colleagues was "Your staff is really great, but all the system sends me is a note with a big numeric string with my ticket number. I can't tell what it is or what it was about." It's good to have something as simple as having a customized resolution notice with the logical name of the incident or service request and who worked on it. One client told me how much he appreciated that he could go into ServiceNow self-service and see the entire work history, and he'd know how we were doing on it and when he could expect it back. Having those simple pieces of the system that touch the client be less of a kludge improves people's perceptions of IT. 

I have a variety of metrics related to our services on the USF ITSF Website www.usfca.edu/its. For example, in March 2009 we resolved about 900 incident tickets and about 600 service request tickets. Our average resolution time has gone up in the last few months, but that's been a conscious choice on our part. We got survey feedback that we were very good at responding, but that we didn't always solve the problem. We've been focused on that and it has increased some of our resolution times.

Integration

We integrated ServiceNow with a single sign-on from our Luminous portal from Sungard. That does use the Sun1 LDAP. And we populated the person or client information with a feed from Banner. The ServiceNow single sign-on uses a somewhat old protocol that the version of Luminous requires, but I think there wouldn't be an issue with single sign-on or LDAP compliance on the part of ServiceNow.

Software-as-a-Service

I was convinced. The university didn't have the resources to host the application locally. The application doesn't contain any sensitive data or academic records or anything of a confidential nature. It didn't fall into a category of being protected by our information security policy. My institution frankly doesn't care how I source something; they want me to source it in the most cost-effective way, and from my perspective, sourcing it through ServiceNow was going to provide probably higher availability and security that we'd be able to provide locally.

What's up next for University of San Francisco?

Next, we're going to work on service catalog, and on building out our CMDB. We have data in it now, but we need to bring in additional components and build out our business service maps. We're also hoping to use our Project Management application more.