In an ideal world our ITSM discipline would be mature enough to not require the use a separate process. A passport document outlining the current service state would already exist in the Configuration Management System, all dependencies would be mapped and would understand support and warranty levels for everything.
Project teams could go to the CMS, the Service Acceptance Criteria (SAC) process would be invoked followed by RFC and Release management ending with a migrated service.
In reality though it is often suggested that a “Passport Process” should be utilised to handle IT transformation activities.
Recently I’ve spent some time looking at Microsofts System Center Service Manager 2012. In doing this i’ve been investigating not only the technology aspects but also the service management aspects. Often implementing a service management tool these days would normally be to replace an exiting system, however there are still a number of businesses who do not have tools.
With this in mind i’m developing best practises based on standard frameworks to provide a summarised view on recommended approaches to implementing a new service management tool. Whilst drawing from information in my head is useful i deci to go back to the books. A recent conversation made this statement stand out:
“a fool with a tool is still a fool”
I think its important for us not to underestimate the complexities of implementing or changing a service management tool. I have a tool (i know i just said about tools)that i created based on ITIL’s PMF (process maturity framework) to help assess clients ITSM maturity and give me greater insight into the environment (this tool requires knowledge to be effective).
Both ITIL and TOGAF have guidance on how to make change successful, my advice is to follow the standard rules, however good a product (component in this case) can be, if you don’t have the people, process and technology in alignment then your heading down a path for an upset user base, late nights troubleshooting and most likely increasing call volumes.
So the fruits of my research so far:
- Use existing reference architectures (ITM tools have been deployed before)
- Follow the guidance of ITIL, while it may not be specific for this product the advice is sound and having the correct policies, processes and procedures is key.
- ITIL has tool selection guidance.
- A framework that is iterative should be used (damming’s based)
- Understand the as-is not just in terms of technology, but also in terms of people and process.
- Don’t rush, getting this right should be more important than getting this “installed”
- Requirements, Communication and Training…you need all three
If your embarking on a ITSM tool greenfield or refresh implementation then good luck, if you follow the well established guidance you should be moving to a good place.
(Here is a reference I came across (SDLC), haven’t had time to read all the content yet but it seems like it has some good material in it – http://msdn.microsoft.com/en-us/library/bb756611.aspx)