"...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."
- 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.
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
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.
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.
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
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
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
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
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
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
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.