Case studies  | REI

"...at a meeting early on, when our VP asked "What kind of training will there be?" One of my IT colleagues held up an iPhone and said, "Did you get training to use your iPhone?" Of course, everybody replied, "No," and I said, "It's going to be like that." – Lois Lowther, REI IT service management manager Webinar Press Release In the News Download Case Study

This ServiceNow case study is based on an interview with Lois Lowther, REI IT service management manager.

As the manager of IT service management at REI, I have the overall responsibility for our service management practice here, and that includes the service desk. REI is a national outdoor retail cooperative, dedicated to inspiring, educating and outfitting our members for a lifetime of outdoor adventure and stewardship. We were founded in 1938 by a group of Pacific Northwest mountaineers. We have 110+ stores throughout the continental U.S. and we employ about 10,000 people. Most of those are in our retail stores. 

We have about a thousand employees at our headquarters in Kent, Washington, and in our distribution centers: one in Sumner, Washington and one in Pennsylvania. For at least the past ten years we've been listed on the Fortune Top 100 companies to work for in the U.S. 

Our IT department is centralized and located in our Kent headquarters. We have about 170 full-time IT staff and we augment our staff with contractors from time to time. We support all 10,000 employees centrally.

Before ITIL

We started our ITIL efforts in about 2005 with incident and change management processes, and had some success there. We got folks introduced to the concepts, we started using the language and we implemented incident and change in the tool we were using. Back in 2005 or so, we were probably a 1 or 1.5 on the Capability Maturity Model (CMM) maturity model. 

But over the next couple of years we found that our older, heavily customized version of Remedy that we couldn't upgrade had begun to hamstring us. We kept throwing things onto the too-hard-to-do pile because of all the customization that we had implemented. Also, our IT users tended to fight the tool because it was so difficult to use, and I think that hampered our growth in the maturity model. In fact, we were bending our processes to fit the tool, so by 2007 or 2008 we started looking at new tools.

Search for a new tool

We had several strategic requirements, paramount was that the tool had to be easy to use. We needed something aligned with ITIL, modern, Web-based and mobile-device friendly. We needed a tool that could grow with us as we took on other ITIL processes and we wanted one that could help us mature in those processes. We had to have a short timeframe for implementation. 

We wanted to lower our IT costs by consolidating a couple of applications, so we needed a smooth integration path. We had been using Remedy as our ticketing system and another product, newScale, for service catalog and we hoped to reduce hardware and licensing costs. Last but not least, we needed disaster recovery. Our data center is in a prime earthquake fault and flood zone. 

So we began looking at ITSM tools and vendors: Remedy 7.1 or 7.2, because they'd been our vendor for so long, EMC, CA, and ServiceNow. Some of us had seen a ServiceNow demonstration at a Pink Elephant conference a few years before, and we were impressed. Finally, our desire to go the software-as-a-service (SaaS) route, combined with ServiceNow meeting all of the other requirements I've mentioned, was so strong that it was a relatively easy decision for us.

Five weeks to implement incident and change

Then we began the implementation. We already had incident and change with Remedy and, even though people didn't like the tool, we did know those processes. So we started implementing incident and change in a big bang approach from day one because those were our most mature processes. 

We also included some problem management, project management, CMDB, and a small, custom application for time tracking our management team wanted. A few months after rolling those out, we were able to implement service catalog, replacing the old tool in a more gradual, phased approach. 

The whole process went very quickly, and it was quite a departure from our previous ITSM experience. 

We were fortunate to have two experienced engineers who also understand ITIL process very well. We started our contract negotiations with ServiceNow, and even before those were finished, the engineers started gathering requirements and updating workflows for incident and change, then shopping the major ones – incident and change – around to the entire management team to get support. By the time the contract was signed and we were able to start the configuration process, we were nearly finished. We began testing within about five weeks. 

I'm pleased to tell people that we did almost no formal training on ServiceNow for our employees. We had this discussion at a meeting early on, when our VP asked "What kind of training will there be?" One of my IT colleagues held up an iPhone and said, "Did you get training to use your iPhone?" Of course, everybody replied, "No," and I said, "It's going to be like that." This was a huge change for us, for the better. 

We offered a couple of lunch-and-learn classes, and we did a few internal webinars to teach people some of the little tricks that might not be obvious, but attendance was not mandatory. The interested employees took us up on the classes and were able to use the tool from the very beginning. We held follow-up sessions and answered questions as time went on, but there was very little training required. Even for catalog, several months later, we decided that no real training was required.

Implementing CMDB

When we switched from Remedy to ServiceNow, we didn't have a CMDB in place and we didn't have any process in place that we thought would help us manage that much data. On the other hand, we didn't want to adopt the old category structure again, so we picked something in between. 

We had recently done a business impact analysis with our business units in which we asked them to tell us what their specific functions were and which IT-supported applications they used to perform those functions. So, based on strong data about these specific services and applications, we started with a very flat CMDB at the service or application level. It's like a list of everything that we support right now, and our intention was to take the data we had gathered, start managing it and connect our incidents and changes to actual things instead of arbitrary categories. I guess that puts us in the middle, because we're not using CMDB in a robust diagram of multiple levels of components, but rather as an advanced category structure so that we have better information.

Implementation lessons

First, it's really important to have processes in place and to be comfortable with them before implementing the tool. You need to vet those processes very well with your staff and management team so that they can support you through the implementation. 

Keep in mind that ServiceNow uses partners to help with the rollout. Make sure that you clearly establish what ServiceNow does, what the partner does and what you do. 

If, as we did, you can identify a couple of good engineers with experience in ITIL processes, you'll enjoy a tremendous advantage. Our engineers could not only translate those processes into design, but also sell it inside the organization. We sent them down to the ServiceNow administrator training a month or so before we started the rollout, and they learned enough to do a lot of the configuration work themselves with limited help from the implementation partner. That saved us time and money. 

It would have been helpful if those engineers had had some Java training, to understand what's there, look under the covers and be able to follow through.

Custom application and smooth upgrades

We had a custom time-tracking application for resource planning that we had implemented in Remedy. It was important to upper management, so when they realized that it would go away with Remedy, they urged us to replace it. Fortunately, it turned out that ServiceNow had already built this kind of application for another customer with a similar requirement and we were able to adopt it. 

Most people don't know that it's possible to customize, configure, extend and even build applications in SaaS, but it is. And, in this case, there were no additional costs for the custom application because we were able to use it from ServiceNow as is. We may have modified it a bit to suit our needs, so we would have had internal costs, but the people using it were already licensed, so it didn't really make any difference to our cost. 

Then there's concern about the customizations surviving the upgrades. We've been through several upgrades already – some major and some minor – but they have not affected any of our customizations in the least. We planned downtimes for the major upgrades, when services are unavailable during a fiveminute window. These usually happen in the middle of the night when our datacenter is expecting to use the tool, but as long as we prepare them for the outage, we really don't have any issues.

Implementation benefits: consolidation, reporting and ITIL

The biggest benefit we've seen so far is that we've been able to consolidate our tools and lower our costs across IT. We found that integration with some of the other applications such as our monitoring systems was so easy that we've been able to discontinue several manual processes that required sending email messages. 

We use Big Brother and Patrol for event management and our monitoring expert was able to grab those events and get them into ServiceNow through Web services. That's all automated now through ServiceNow. We've also discontinued use of newScale and consolidated our service catalog by using ServiceNow. 

Reporting has made a big difference for us as well. Getting information out of Remedy was painful and cumbersome, but ServiceNow is designed so well that people can run and create their own reports. 

As far as ITIL, I think that we've probably risen to about 2 in the CMM, but I know for certain that our IT staff members are extremely happy with the tool and find it easy to use. For example, it takes us a few minutes to create a change request instead of a few hours with our previous tool. We've been able to implement lots of suggestions quickly to make it even more user-friendly.

Mobile ITSM

Several of our business users have been happy with the mobile device browswer interface to ServiceNow. Not only can we access the typical ITSM functionality, but also managers can approve requests that come from the service catalog. So we've been very happy with the ServiceNow mobile browser interface so far and will use it a little bit more this year.

Asset management and more custom apps coming

We have big plans for ServiceNow over the next couple of years. First, we want to expand the asset management and CMDB portion. We don't use it much now, but we see a lot of upside to it. We want to learn more about release management and apply the tool to help us. We're using very light problem and project modules, hoping to make more use of those in the future. We plan to integrate with Altiris, which we use for software deployment. 

We also have a couple of applications – one for HR and another for our real estate department – that use Remedy for specific, non-IT needs and we're going to create custom apps in ServiceNow to replace those. Since Remedy is going away, we've met with the department heads, gotten their requirements and determined that we are going to use ServiceNow instead. 

HR has an employee call center where people call in, log their requests and get phone help, so we plan to have ServiceNow. com log those calls in a ticketing system just for HR. Our real estate department manages our new store development, and those projects have a great number of tasks associated with them, so we're planning a task management system in ServiceNow.