ITP Sites:   ITP Site|TechBlog|TechHub in schools|NZ CloudCode|All Tech Events|Software Escrow NZ

ITP Techblog

Brought to you by IT Professionals NZ
Menu
« Back to Home

Developing and Implementing your Service Management Model - Processes and Tools

Sunit Prakash, Guest post. 19 September 2016, 8:06 am
Developing and Implementing your Service Management Model - Processes and Tools

Part 4 - Developing & Implementing your Service Management Model

This article continues on from Part 3 - Developing and Implementing your Service Management Model - Partners, Customers and People

Processes

Once the high level service model is agreed, the partner model is in place, and the technical design scoped and agreed, you then need to work out the detailed processes.

Typically, I start from "how will the end user or customer get help", then move on to what happens after hours, then what happens if there is an escalation.

The chain looks like this:

Starting at Service Desk, then moving on to Incident Management, Problem Management, Major Incident Process, through to the process for moves, adds, changes & deletes, through to change & release management, I put a focus on alerts and alarms. Who is monitoring system performance, who is alerted in case of an outage or other issue and what happens when they are alerted?

Security related incident management process is often neglected, often with billing process so including both these  in your strategy is paramount. Remember billing needs to cover not just incidences, but also moves, adds, changes and deletes, and also the rate card for professional services.

Finally, reporting and continual service improvement - who is going to put the report together, who is going to front up, who is going to walk a customer through the issues, what is the root cause, how are improvements suggested and made and what are the capacity reports and plans, availability reports and successful and unsuccessful changes?

Tools

The whole solution is underpinned by the toolsets.  It is not just a detailed design for the service management toolsets that is required, but the full attention of an architect to map out what the service management toolset strategy should be.

In a simple world, there would be one single tool, and everyone from customer to internal operational teams through to partners would be using that one single tool.

In the real world, multiple teams use multiple toolsets and this presents issues around end-to-end visibility of system performance from an end user or business perspective, and who from what team, has what level of access to which tool.

It also highlights the issue of coherent reporting, and the ability to compare apples with apples when comparing reports from different CMDB suppliers. 

What I found best, is to do the hard thinking work upfront.  Have we covered people, processes, tools, partners ?  Is there anything else we need to think about ? Oh yes, add security and commercials.  And the whole communication bit with partners and customers.

Then start chunking down from top to bottom, getting more and more granular each time.

It is possible not everything will be known, but make a start, all the time keeping the end in mind.

It is possible that it will not be a perfect solution and not everything will be known, and that's fine. Use the Lean StartUp Methodology. Deliver fast, deliver quick wins. Validate and move to refine. Fail fast.  Pivot quickly. Easier said than done, but not impossible.  

Sunit is a Wellington based IT Service Management Consultant and author of the published book 'Strategic Lean Service'. He's a keen mentor to the start up community and while not at work, can be found hitting the highways and open roads on his Royal Enfield Bullet motorbike. Connect with Sunit on LinkedIn.

 


Comments

You must be logged in in order to post comments. Log In


Web Development by The Logic Studio