Smart Watches, Kangaroos & Demand Management; Knowledge 16 – Day 1

It’s Vegas baby! Knowledge is an annual event hosted by ServiceNow to share, collaborate and promote their platform. To give you an idea of the scale of this years Knowledge16 event, it has over 11,000 people registered, 160+ sponsors & partners and there are presentations on everything from Agile to password resets.

This year’s event celebrates 10 years of Knowledge so here’s our recap of Day 1.

Opening Keynote: Frank Slootman, CEO ServiceNow

To say the auditorium was packed /out in anticipation of Frank’s opening keynote is a bit of an under statement:

Frank opened with this thought: “Speed is not an issue until someone comes along who is faster than you. Software enables speed and helps you get where you need to be”.

The next part of the keynote focused on ServiceNow as an enabler. Frank shared the stage with representatives from KPMG, Fiser and AGFA Healthcare who shared real life experiences of how ServiceNow helps them to drive their organisations. Frank talked about how the world of ITSM is constantly evolving and talked about how important SIAM and the Internet of Things were in terms of advancement and improvement.

The final part of the session was on innovation. As Frank put it; “our ultimate ambition is to change how people work” and offered up these three things to help organisations make that transformation:

  1. Subscribe & notify; reversing the flow of data so that people can be more purposeful.
  2. Connect & collaborate; applying context so the right people can collaborate in the right way with the right event.
  3. Predict; removing the temporal problem so that organisations can move to real time, using predictive analytics to prevent problems before they occur.

Frank then introduced the rest of his team to promote the ServiceNow take on wearable tech. The team were able to demo a smartwatch where an Incident can be logged with a single gesture.

The team role played a scenario whereby an Incident could be logged and escalated via the smart watch and progressed through the resolution workflow within seconds. Wearable tech which means I could keep an eye on things whilst making my kids dinner? Deal me in!!

Now on Now: How ServiceNow uses ITOM technologies to deliver the most reliable cloud platform – Sridhar Chandrashekar VP & GM of the ServiceNow ITOM Division

Sridhar rocked his session with this opening: “ we use ServiceNow for pretty much everything. We drink our own champagne.” He talked about the complexity of the ServiceNow infrastructure which includes:

  • 4 large datacentres
  • 12 smaller data centres
  • 3.5 million CMDB CIs
  • Over 7,500 servers
  • Over 2,000 network devices

In short, no small task.

Sridhar talked about the importance of maintaining SLAs and customer uptime and how ServiceNow use ITIL and other best practice frameworks to maintain services. ServiceNow process over 7,000 Changes and 6,000 Incidents a month, following a structured model.

The next part of the presentation focused on automation and the cloud. All 16 data centres run off a single instance of ServiceNow and complex automations are used to support service integration. As Sridhar put it “our aim is to automate pretty much everything” and to this end ServiceNow have lodged 25 automation patents. Sridhar explained why having automated cloning and failover processes were so important to ensure customers experience a seamless service and even demonstrated to the audience how easily it is to fail over an instance of ServiceNow to an alternative instance.

DISHin’ up a robust Service Catalogue – DISH Network Corp & Service Now

The next session was run by both DISH and ServiceNow as a team effort. DISH Network Corp are a Fortune 250 company with over 19,000 employees and are America’s third largest paid TV provider. They quite like kangaroos.

Their presentation was about the journey DISH went on to replace their legacy system with a cloud based Service Catalog. So far, so straightford right? Not quite.

DISH had a legacy system combined with a homemade web tool containing over 13,000 Service Catalog items. That’s right, 13,000 separate items. There was no self service option for Incident Management and Request Fulfillment and the CMDB was manually maintained. The asset tool was also a legacy in house app, and daily Change meetings were required to mitigate the risk of Change related failure. It also appeared that the IT department lived in a cupboard:

Enter ServiceNow. Their strategy was as follows:

  • Redefine item & categorisation
  • New tables for approvals & request fulfillment
  • Data driven forms
  • Data driven workflow

The biggest challenge was wrangling over 13,000 Service Catalogue items into a sensible format. Tables were used to great effect along with authorisation models. Check out the sample approval matrix:

Let’s face it, if I had to chose two people to resolve my Incident I’d pick Bruce Willis and Sandra Bullock as well 🙂

Data driven forms were used to support automation and the final product looked something like this:

Mission well and truly accomplished guys, well done.

IT work intake – using idea & demand applications; Debbie Balmos, IT Support Director, HMS

After a quick ice cream break it was time for Debbie’s presentation on Demand Management. Debbie’s session was about using Demand Management to increase transparency and collaboration with business partners with the help of business focused applications.

Debbie started by outlining some of the challenges her IT organisation faced. These included:

  • Unclear work intake
  • Inability to prioritise
  • Disconnect and silos
  • No collaboration with the business
  • No idea of cost per service

The plan? Project Unity to automate the end to end IT service.

Debbie talked about engaging with ServiceNow and how she was able to use it to combine and replace three separate legacy systems. This gave her organisation a holistic view of critical services and enabled her to balance supply with demand.

The second half of Debbie’s presentation focused on demonstrating her new environment and talking through how it worked in real life. The new process routes all Incidents and Service Requests through a single HMS branded self service portal and a defined workflow supports the process. The result? Happy customers!

 

That’s all for now, come back soon to read our recap of Day 2!

Image Credit

Secrets of Request Fulfilment

 

Peter Hubbard
Peter Hubbard

This article has been contributed by Peter Hubbard, Principal IT Service Management Consultant at Pink Elephant EMEA and is based on a recent presentation that he delivered at the itSMF UK Conference and Exhibition.

Request Fulfilment is one of the most useful, yet underrated, areas within IT Service Management. It has been widely recognized for many years that the ‘Front Face’ of IT is the service desk, and so how the service desk performs colours the whole perception the business has of the entire IT Department.

But what is Request Fulfilment? Request Fulfilment provides a channel for users to request and receive standard services for which a predefined approval and qualification process exists. It simple ensures that each request doesn’t have to ‘reinvent the wheel’.  A request model is a way of predefining the steps that should be taken to handle a process.

So how do you implement it?

Getting the basics right

The first thing that you need to do is create a Service Request Catalog. At its most basic level this is simply a list of all the Service Requests it’s possible for the business to make of an IT department.

The easiest way to do this is to ask your service desk staff, after all they spend all day dealing with these very issues. Ask them to write a list of their most frequent service requests, and use this as your starting point to turn an entry in the Service Request Catalogue into a fully mapped and automated Request Model.

The second major thing to do is to make sure that you separate your incidents from your requests in the toolset. After all, they are separate things! Telling a business that 10,000 incidents were received to the service desk sounds like the world is ending. Saying that 1,000 incidents were received, and 9,000 service requests were made for new kit is a very different story.

Build a request model

You MUST do this. Request Fulfilment without Request Models is just mucking about. The whole point of Request Fulfilment is to work out in advance the steps that are required, the information that you need to collect and when, and who performs the required actions & authorizations. This is the soul and centre of Request Fulfilment. Collecting all that information and not transforming it into a model, either as an established manual procedure, or ideally, within an ITSM toolset is just plain silly!

In order to build a request model the simplest method is to bring the people who are involved in fulfilling that request together.

Ask them to verbally walk through the activities involved using post it notes to build a basic flow on the wall. Once the steps have been agreed, and are in the right order, go back and detail what happens at each step: who does it, what information they would need to fulfill that step, any agreed timescales or authorizations required etc. I find this takes about half a day for a moderately complex request like building a new starters laptop and delivering it to them. Once you have the model capture it in a formal document (Visio flowchart with explanations is best) and then use this to configure your chosen ITSM toolset to automate the request.

Request Fulfilment is simple, but that’s not the same as easy?

Many people are often make the mistake in being under the impression that ‘doing’ Request Fulfillment doesn’t take more than a week or two, but let’s say you haves 800+ known types of service request. The rule of thumb is to allow half a day to map a request model as you work out all the steps involved and who does them. Then allow another half a day to document that flow into a format that can be saved, understood, and shown to others. Then add another half a day to put that flow into the toolset. So that 2 weeks worth of work was actually 1200 days work!

My best advice to keep things simple is to start with an easily understood, and not too complex request. Avoid starting with the ‘new starter’ request as a typical new starter request will involved multiple actions crossing HR, Security, Access Mgt, Facilities and IT. I am not saying don’t do it at all, just make sure you start with something simpler to get the feel for the process first.

The most spectacular mistake I have ever seen made with regards to Request Fulfilment was when I saw a CIO promise to his executive board that 95% of all service requests would be completed within 5 days.

It’s safe to say that I almost fell off my chair. I very quietly sidled up to him afterwards and said that it was very courageous promise he had just made…would he mind if I asked a few questions?

Question: Have you defined what a Service Request is as opposed to an Incident?

Answer: No, is that important?

Question: Have you worked out a complete list of all the types of request that you support?

Answer: Not as such 

Question: What is the most common type of request you receive at the Service Desk?

Answer: A request to build a new laptop

Question: Have you worked out the steps involved in fulfilling that request and the timescales involved?

Answer: No, but I know it can’t take long to simply build a laptop!

I went off and built the request model for that request. It turned out that the process to build a laptop took 37 separate steps, across 4 teams, and went to 2 external organizations who had their own response times in their contracts. If everything worked as it was supposed to then it would take 10 days to complete the cycle. Essentially the CIO had just set himself up to fail and the board hammered him for the next 6 months every time they had a meeting.

The moral of the story? Know the steps, and timescales involved before you start committing to SLA targets!

Benefits to Request Fulfilment

I always tell people ‘never keep a dog and bark yourself!’  Most ITSM toolsets are built around perfectly good workflow engines with associated notification rules. Well… guess what…that’s how Request Fulfilment works too.  You work out ONCE what a particular request needs to do, who it should go to, what they should do and so on. Then you take that hard won information and enter it into the toolset as a Request Model. From that point on the tool does the hard work for you. It moves the requests to the right team(s) automatically. It makes sure they have all the information they need on a silver platter, and it even escalates the issue to the relevant authorities if pre defined criteria are breeched.

Someone has to do all of the things I have just listed, and unless you have the tool doing it (supported by your processes of course) then your service desk agents have to do it by hand, which means you’ll soon have your agents tied up manually shepherding requests and explaining to irate users why their laptop is not ready yet. By using Request Fulfilment most of this is done for you by the tool through the Request model; although you should always make sure the final ownership of the requests sits with the service desk as normal.  Trust…but verify!

A final note

Tackle Service Request Fulfilment head on. Handling Service Requests manually is major drain on your resources on the service desk at the moment and the single largest cause of user dissatisfaction.

Do comments such as ‘we never get told what’s going on with our requests?’ or “why does it take so long to get anything done by IT?” sound familiar?

Well, you can either deal with each issue as it arises on a one by one basis, or you can invest some start-up time into identifying the top 10 requests that get made to your service desk, and create them as request models. Then put them in your toolset and automate the notification and assignment rules.

Request fulfilment frees up your service desk, and technicians time from endlessly chasing their tails as they try to find out what the next step in the chain is and who they should be talking to. By automating the basics you free your staff up to concentrate on other areas of greater interest.