Whilst writing the article on Service Management Reporting the subject of naming services and some of the potential pitfalls around it started to have a life of their own, so what follows are some of the things I have found and some thoughts on ways around the possible mistakes.
Although the subject may sound quite a low level nuts and bolts type issue it can have real ramifications for service management. The consistent use of a name is very important, it does not matter what your service is called so long as everyone calls it the same thing.
The term Unique Identifier crops up frequently in ITIL and it does so because it is important. You would not dream of not uniquely identifying a location, or a server for all sorts of good reasons.
In one particular engagement I was involved in the outsourced infrastructure supplier set up a 'model office' for testing infrastructure connectivity etc. Quite separately the Application Developers, another outsource company, started building the software User Acceptance Test centre in an environment they referred to as the 'model office'.
It is a fact that the chances of being by the coffee machine or photocopier and hearing that 'model office' is down will cause you to immediately assume the wrong one has failed, I do not know why but things like that just seem to happen. Just the possibility of that happening builds in inefficiencies that are easily avoidable. At the other end of the scale why allow confusion into your management reporting?
For example if your service is called Albert. Then Albert will appear in your Service Catalogue where his function will be briefly described along with his availability and any other facts your organisation chooses to maintain in said document. Albert will also be in the Configuration Management Database (CMDB) as a Configuration Item (CI), as a service.
You will see by this that it is important that your potential developers, and the Project Managers that get engaged in Service Design need to think about it, after all in the heightened excitement of a project kick off a simple thing can get missed. Forgive them, project managers need their moments too! - but not for long, having access to the Service Catalogue and consideration for the Service Portfolio should soon ensure no duplicate names.
Now safely entered and fixed (and uniquely named) in the Configuration Management Database (CMDB) we can ensure that the Incident Management processes can report about Albert and his performance (Availability), as can Problem Management, should the poor chap be suffering a recurring major fault. Requests for Change (RFCs) concerning Albert will be impact assessed, all the component parts of the infrastructure that form the end-to-end view of Albert will be related to him. Our Service Level Managers can go to the business and talk about Albert and everyone will know precisely what they are talking about - everyone will be referring to the same Service.
Incidentally, it will help your business customers if the name of a service is used consistently through its' development and into Production - expectations that are managed in this manner has got to be good.
- Get the business to pick the name (they are more likely to use it and stick to it)
- Ensure that there is easy access to the Service Catalogue (or CMDB where service id's should be CIs)
- Get in at stage 1 - project kick off time
- Keep the name throughout the service lifecycle (any change will be difficult and involve re-work [inefficiency]) and given the communications required of questionable benefit
It is not the end of the world if you do end up with a duplicate service name, but renaming a service once it may have 'in-flight' Incidents or changes or has had its Management Information Reporting (MIR) defined is a overhead that can be avoided with consideration and planning in the early days, which makes it a sensible route to take, and is strongly advised.
If service renaming has to take place then detailed changes will be required for all the instances where the service appears in the Service Management documentation, but most importantly publication and communication with the end-users, the customers and stakeholders is essential so that confusion can be avoided as can it's inefficiencies and costs.
About the Author - Colin Mayers is the Managing Director of Mayers Consulting. Colin operates across all market sectors and provides a breath of experience with regards Service Management. As for formal qualifications he holds the ITIL Managers Certificate, ISO 20000 Internal Auditor and Consultant Certificate, also Prince 2 Practitioner.
If you wish to contact ITILnews to comment on this article or if you have had an 'interesting' experience with duplicate service names please use the comment box at the end of this article, ITILnews will ensure they are also forwarded to Colin. For the avoidance of spam, if you are interested in contacting Colin for a potential engagement please use the comment box and ITILnews will forward your details directly to him.