Pragmatic Service Management - The Service Definition Process - Part I
By jskogsta on May 04, 2007
For a long time, I've been meaning to blog some thoughts around Pragmatic Service Management, and I recon it's about time I get to do it. Hence... here we go:
Pragmatic service management have been an area of specific interest to me for a number of years, and I am referring to the way one can take Service Management 'principles' and create an actionable implementation framework in place to drive requirements into actual architectures. Sounds easy, but in reality it's not. So to give you a brief introduction of what I am thinking of.. consider the 'ideal' state where you as an IT Service Manager can sit down with your business service representative (and owner?), and discuss, define and select the appropriate 'business level requirements' for either an existing service or a new one. Being able to articulate the requirements and document them is key to being able to drive SLA (and OLA!) creation and henceforth the architectural selection. However, it is always prudent to involve the technical 'owner' of that service as well, as the business requirements are generally 'overkill' compared to the cost of implementing and supporting it. So you need a balanced definition of requirements (from business and technical) to ensure a balance that takes into requirements, cost of deliver, sustainability and other factual drivers. In the end, what you agree of requirements can then be used to articulate service levels, which in term are used to select the architecture to implement on, and again preferably a standards based architecture from the defined Service Catalogue.
Have a look at the illustration beneath for the practical framework we've worked on to do this. It's a pretty neat method to drive requirements into standards based architectures, and also have a consistent, defined and agreed way to operate and manage your services.
So what does the illustration really describe? When I am referring to business requirements and technical requirements, I am in reality referring to a negotiation process that occurs. Within our process, we use questionaires and a mapping methodology to define an agreeance based on requirements and an associated service level category. If there is agreeance, the defined service level is driving the architectureal selection which is implemented in the real physical IT architecture that exists. The other important facet here is that all artifacts generated and used throughout the process is saved in the Service Catalogue (and Configuration Management DataBase - CMDB).
Sound good in theory, so does it work in practice? Being realistic, it does to a certain degree. You are able to implement the process, and drive it from there. However, being overly descriptive on how your standards are being used is another thing. hence the role of the service manager is critical, where you will have to assess the requirements of the busines and the teir technical counterparts against the 'costs' of not adopting organizational standards. That's a given, and probably something you will never get out of. However, the process itself is a good facilitative way to drive an understanding that both business and technical requirements have an impact on the organizational ability to plan, implement and operate their services. Just being able to somehow articulate requirements from both sides is a step in the right direction, and also being able to have the artifacts developed to support the agreeance is key. How many times have you seen evidence of this occuring within organizations? Probably not too often! At least I have not.
So what I have experienced with clients that I've worked with is that whatever they have done in the IT Service Management space, they have not defined an actionable framework to address something like 'this'. Most have adopted ITIL, Cobit and other 'standards' in some form. However, they are an organizational adoption of the 'standard' processes, and nothing more. Inherent in this lies the problem: these processes again need further complementing processes and actionable frameworks (could be policies as well) to "enforce" them. The Service Definiton Process is but one example of how to drive true business and IT alignment on the basis of existing Service Management and Governance processes.
I'll leave it at that, and let you ponder about this. I'll provide some more musings on the same topic 'soon', and see where it leads.
Thanks, and all the best ..