Kelly's SN implementation Blog Post #5

[kellykaufmann]

Requirements & Process Discussions

This week we kicked off our implementation consultant-led discussions to determine our future processes for incident management and for requesting hardware/software/onboarding/offboarding employees, etc. (service catalogue).

The 'intro' day was easy, since it was basically our core group confirming the processes determined thus far. We finished the day an hour early, and I took that opportunity to let the group know that Eureka had just gone into 'general release', and since we had not yet initiated development, we may want to again consider implementing in Eureka. It was a quick discussion & decision — we will immediately upgrade to Eureka. Woohoo! I was most excited about this for selfish reasons - because of the new Demand Management functionality like the bubble charts to help with decision-making when prioritizing projects and the CIO Roadmap to give the organization a complete picture of the in-flight projects and requested projects. This project functionality is still officially scoped for Phase 3, but I still have hope of setting some of this up behind the scenes in case leadership gets hungry for the information prior to Phase 3. We also discussed possibly renaming/rebranding our SN module — but after discussions decided to keep the module name as-is.

The all-day incident workshop took an incredible amount of guidance from our implementation consultants (AOS). While I love process discussions and brainstorming, this was painful. Really painful. I don't envy them having to guide a room full of people representing many different areas and with varying level of experience discussing processes and varying level of abilities in collaborating on a vision & plan and turning that into more detailed requirements.

More pain: AOS warned us last week, and at the beginning of the categorization discussion, that categorizing would be slow and painful. And oh was it. I didn't think it would be, as it seems relatively straight forward. But after an hour, we realized we were back at the starting point. And apparently this is normal. We decided to table the categorization decision for the time being (which they said many clients decide to do at the beginning). I'm concerned about this because I know we'll need categorization for certain reports when we are ready to start reporting. And by then we will have time-machine-remorse - we won't be able to go back in time and identify categories and tag incidents to categories to start building data for reports, and chances are we won't want to look through thousands of tickets & retroactively categorize by hand. So we'll choose categories and then start growing the data for reporting against categories. I do respect that by looking at our incidents retroactively, it will give us a good set of data to determine categories and to test our categories against.

During the requirements sessions this week, we also covered impact/urgency/priority, SLA's, cause & close codes, surveys @ incident closeout, and much more. This was definitely a week of progress!

While AOS led the process & requirements discussions, I started creating a log of items that will need to be communicated to certain groups, what we will need cheat-sheets & training material on, communication on, etc. We requested a part-time change management resource. We still have a gap of who can help with communications and training.

Base Config & Active Directory Planning

This week, our developers met with some of our technical team members to plan out the base config, including setting up single sign-on. It sounds like this is a pretty quick process that should be ready within the week.

Like many organizations, our Active Directory (AD) hasn't been perfectly set up and isn't perfectly maintained. With our plan to have ServiceNow using so much of this information (for routing approvals, glancing at your team's work, etc.), this SN project is a good impetus to have us get A.D. kicked up a notch. Of course, this means the SN project could become what I call a "kitchen sink" project, where somehow the scope expands to be everything but the kitchen sink.   For example, we realized that what is missing from AD is in an HR directory. Which means we need to pull data (which means we have to program to connect them, since the org still wants to use this HR directory) from the HR directory to AD to SN. And we need to determine how to maintain the information. We also have acquired companies that are not yet in our AD that we need to figure out how to pull that info, or we'll have to figure out several different approaches to getting the information we need, and getting this set up prior to going live with Phase 1. Here comes the kitchen sink putting our Phase 1 timeline at risk.

Centralized Service Desk Updates

For our new centralized service desk, it was clarified that we will have all incidents start with our first tier, who will gather additional information & route accordingly. Since I came from an environment that leveraged SN's auto-routing functionality to get certain incident types immediately to a particular group within I.T., I was a bit sad that we won't be using auto-routing yet for incidents. Baby steps, Kelly. Baby steps.

SDLC/Scrum Updates

On to my favorite topic: SDLC/Scrum. We had planned a demo to take place this week, but with scheduling conflicts we had to push it out a few weeks. I'm getting antsy, but trust that everything will fall into place at the time it's meant to. Speaking of — we had been planning on using Requests (REQ###) for people to submit ideas for enhancements, new functionality, etc. But now that we're going to Eureka, we need to decide if we should handle all project-potential items via the new Demand (DMND###) module. The Demand module is new for everyone, so we need to start doing some investigation to make sure it will meet all of our needs.