ServiceNow Implementation

[alexanderbolz]

Hi SN community,

we are pretty new to this community and we are looking to implement ServiceNow as our main ITSM system. We have some experience with other ITSM tools, but we failed during the implementation.

Right now I would like to collect some implementation feedback from other companies.

• How did the ServiceNow implementation work for you?
• Did you have some bigger issues? If so, what was it? What worked fine?
• How quick did you implement it?
• Can you share other experiences?

Thank you!

Alexander

[HugoFirst]

Hello Alexander,

First and foremost, our implementation worked, or I wouldn't be here replying to your post!

My first recommendation is to look at your failed implementations and determine why each one failed.

Did you ( you being your organization ) learn from each failure?   Do so, before you proceed with another effort.

Here's some more advice from my personal experience and from what I've gathered talking to people from other organizations:

1. Don't expect to solve organizational issues with a tool.

2. Find a way to involve your user base from the very beginning.   What works for them now? What pain points do they have?   Collect as many relevant user stories as possible.   These are your functional requirements.

3. If possible maintain or emulate what works for them now in your new system and eliminate the pain points.   Let the user stories serve as the basis for your design.

4. Yes, do have support from the very top of the organization.   Have periodic communications from the executive champions showing support and echoing back the status of your effort, and explaining the importance of this effort.

5. Don't do it all at once.   Prepare a road map and implement first, those milestones which are both easy to do, have a good payoff.

6. Be agile, implement functionality as quickly as possible,   in lots of small increments.   Have your users accept the functionality after each increment.   Back up and re-implement if you need to.

[Kalaiarasan Pus]

One small input.

Don't try to mimic functionalities of old tool on new one. Try to make use of tool's intrinsic features and try to have your setup as close to out of box as possible.

[alexanderbolz]

that is great feedback! thx for sharing this with us.

Yes, we have a lot of lessons-learned out of the previous implementation and we will use this for SN implementation.

Did you implement it via an implementation partner or fully yourself?

[Kalaiarasan Pus]

What I have seen some companies is to use a hybrid model which has inhouse team plus implementation partner.

The inhouse team will help you drive the process.

Will help you have insight into actual stuff being done (Whether process is being followed properly or not, quality of work, etc)

Better sense of overall accountability and responsibility.

Able to retain knowledge (Implementation partners will always have attrition problem)

Inhouse teams better understanding of customers/users will help provide directions in many use cases.

Have smooth transition from implementation partner to another if needed.

[dmaze531]

+1 on staying close to OOB at the start.

We are 3 years on the platform. When I attended Knowledge events I asked other users how their implementations went and what customization did they do. A very common response I heard: "If I had to do it all over again, I would not customize anything for 9 months. Then take a look at how the tool is being used and gather customization requirements for a 2.0 launch".

If I had to do it over again, i would do the same. And probably as such:

1. Take the upfront time to understand/document the as-is process

2.Take the upfront time to understand how ServiceNow handles the same process OOB

3. Determine the delta/gaps between the two

4. Make a list of processes the business can not change to accommodate OOB ServiceNow functionality

5. Make a list of processes the business can change to support OOB ServiceNow functionality

6. Try to move items from bullet 4 to bullet 5.

As a final anecdote. ServiceNow as an ITSM tool, is built upon the ITILv3 book of knowledge as good practices. As such, at it's root, the OOB functionality supports these good practices. What I've found for my company post-implementation is if a delta existed at bullet 3 above, it was a result of the business not following good practice resulting from a limitation of the non-ITIL based legacy ITSM tool we were using.

[HugoFirst]

We use implementation partners for our major projects.   We do a lot of small projects ourselves.

That said, we have changed our approach to how we engage our partners.

In the beginning, we let the partner have fully control, do the work and turn it over to us.

As we became more knowledgeable about the tool, and how to use it, we've taken on more of the requirements definition and design specification.

This allows us to consider issues which are important to our organization, but which do not always come out in a contracted engagement.

In our last engagement, we retained near full control and issued "coding specs" for specific functionality which we did not have the expertise to build.

IMHO, this worked great!

[brukasmj]

What about the cmdb portion ? what should we take into account here ?

Btw i am a member of the poster's team and responsible for this part.

[HugoFirst]

Funny you should mention it,   I'm currently working up a talk on the CMDB for May.  

I don't think I would ruin my talk to share some thoughts with you.

1. Study the CMDB tables in ServiceNow.   Most have names starting with "cmdb_".
      There are so many tables you can't learn them all.   But start at a table that make sense to you, perhaps cmdb_ci_linux_server.

        Become familiar with the fields in the table and then explore the table structure down to the root table.   I like to use the schema tool for this.
        Repeat for those tables that you're interested in.

2. At the same time you're doing #1, identify some users and learn how they will use the CMDB.   What information will they need to perform those functions?

3. Then map your user's information needs to the existing fields where appropriate.

4. Note the user information needs that aren't found in the existing tables, this is the basis for customizing your cmdb.

5. Finally, figure out how you will get the information you need into the CMDB.   Basically you have 3 options:

      - import from existing information sources ( spreadsheets, databases, etc. 0

      - scan the CI's ( note I said CI and not just systems)   to retrieve the information.

      - key it in manually.

6. Remember to train your users in how to use S/N, how to access the CMDB information and how to create reports and how to associate a CI with other records, like incident, change, etc.

One last thought,   this best handled as an iterative process.   Don't think you can implement it as a big-bang type of project.   You'll uncover new requirements from your users even as you implement new features from those requirements you already know.

( Don't even try asset management until you get fairly complete cmdb. )