Using service management in the business

We shouldn't get too excited about other units of the business adopting service management in general or ITIL in particular. It is not as if IT invented it.

Ken Turbitt pointed us to this article which is a nice summation of some case studies. But as Ian Clayton said recently on this blog:

I'm a strong advocate of service management as defined and used by Product Management for years. It is largely well defined in these non-IT circles and actually quite different from the descriptions we read about regarding IT Service Management (ITSM). In recent months I have detected a movement "out there" amongst the ITSM and especially the ITIL supporters to drop the IT on ITSM and move ahead with the remaining words, without respecting what is there already, and what has gone before.

I think Ian's own USMBOK is an excellent summation of SM with the "IT" removed.

IT has refined SM and maybe we are currently the centre of excellence for it, and can provide value back to the business by teaching it, but let's not forget we learnt it all from manufacturing and product management. We're not the exclusive owners of the IP.

For me the biggest aspect, besides some credibility for IT, is the opportunity to be a service provider beyond providign IT. We can manage and deliver other services too, as indicated in the linked article.

Comments

CMMI for Services

CMMI for Services is one more model for Service Management. One can download the word document from here http://www.sei.cmu.edu/cmmi/models/index.html. I have just spent some time skimming it.

It has a different approach to Change Managent. Basic Change Management is an activity within Configuration Management. Here is a list of potential CI's according to CMMI

Examples of work products that may be placed under configuration management include the following:
• Plans
• Process descriptions
• Requirements
• Design data
• Drawings
• Product specifications
• Software
• Compilers
• Product data files
• Product technical publications
• Service agreements
• Authorized versions of controlled software and associated licensing information and documentation
• Repositories of asset information

Easy to see that the authors are mainly Software Engineers. Am a bit disappointed with the result.

Aale

Why don't we use the business view of service management in IT?

Having responded to what was a very fair question that asked if it was reasonable to use ITIL to run the business, I thought I would test that by reversing the question.

Is there any value in using the concepts and methods used by the enterprise or business to run IT?

Just consider, Walmart, Dell, Amazon, and so many large and small companies have transformed themselves to 'service providers'. Disney is another pioneer of how to manage the service encounter, identify moments of truth, design service access points, and build glossy 'service catalogs'. With the Internet and global connectivity they have also integrated their catalogs with request systems to facilitate online ordering of information and products.

All this has been orchestrated by the unseen hand of product managers and marketers. Professionals. Now look at what we can achieve by aggregating ALL the available IT developed frameworks.....

So what would your IT look like if it were run by any one of these customer focused, service driven provider?

What would your visit to Disney look and feel like if it was run by ITIL?

Change management without Itil

I was writing about the same thing yesterday at www.pohjoisviitta.fi but as the knowledge of Finnish language in the Southern Hemisphere is schokingly weak, I'll rephrase my point here.

The role of Change Management according to Itil is too wide.It is unrealistic that business would ask permission from IT Infrastructure Management to develop or implement a new service or application. Product development has it own process. If you google "product development process" you get 750 M hits. "Itil process" gives 0,5 M hits. Change management has 128 M hits but if you add the word itil, you get 0,4 M hits.

Aale

All that proves is that by

All that proves is that by adding additional search terms into Google it filters the results.

like a teenage boy thinking he knows everything

I think it is a valid point that there is much more to change than ITIL. ITIL tries to be the owner of change management without the breadth, stature or knowledge. It is like a teenage boy thinking he knows everything.

The discussion is without context

ITIL's view of change management is valid contribution, as are many other references. What seems to be missing is context. A careful read of ITIL leans heavily on the management of the 'configuration' - not the service assets or service infrastructure - the technology configuration. Those who were once ITIL evangelists and now trumpeters of 'service management' have failed to put anything in a proper context.

Generally, change management spans many domains, including products (which follow a dramatically different lifecycle comprised of feature, function, versions and revisions etc), organizational, infrastructure, political, and service. I write specifically in the USMBOK as to how changes to service infrastructure are managed. It is grounded in universally applicable concepts that are then positioned anew and extended to meet the needs of managing services while being respectful of product management needs - quite a tightrope act.

Like Russian Dolls, change contains tasks or work orders. Changes are inside of projects which can be elements of a program. ITIL does not readily offer this context. At the core of any change regime is risk, impact (good and bad), cost of change, and governance. Upstream the change procedure is required to be carefully linked and integrated with the driver for change. As I blogged earlier, for services their are 4 main types of 'maintenance' driving change. Again, ITIL does not go this far.

So its all in the context and use. As has been repeatedly pointed out by others, I feel folks are trusting far too much to ITIL. Its only a contributor. ITIL Change Management is exactly that - ITIL's view of change management. Being certified in thsi means you understand ITIL's view - it cannot mean you can design, develop and manage change within any IT organization. There is so much more to consider. Even APMG/OGG recognize that with their use of the ADKAR model for change, not mentioned at all in ITIL... all change impacts stakeholders and has an organizational impact of some sort....

Remember - caveat emptor - buyer beware....

USMBOK is good

I would say that USMBOK is better as an practical guide than ITIL, COBITT, MOF or CMMI for services.

But I found an tiny error on page 407, Fig 143. There you have CAB and CAB/EC while on page 401 they are valled CRB and CRB/HR. I would prefere CAB.

Aale

Prize Alert!

Aale

Thanks for the plug- the Guide to the USMBOK was written as a blueprint for practitioners with two main sections: 1) Elements of a Service Management System, 2) Roles within a Service Provider Organization.

As for the typo - oops - I know there are many. I wish I could claim they were part of an Easter egg styled hunt or marketing plan to make folks read more carefully but....

Collect a $50 voucher from me directly for spotting the typo and taking the time to blog on it. If you (or anyone else) spots a typo please feel free to enter a comment at the support site (www.sm101-support.com), in fact any comment or question on service management as it relates to the USMBOK.

Its the CRB (Change Review Board) because thats what they do - review the change request. Now I know they also advise on what to do but being as its not a democracy - the Change Manager is ultimately the single decision maker it was named that way.... The HR stands for High Risk - again because that is the primary reason for the Change Manager's sphincter muscle flinching - "above my pay grade" is a comment that springs to mind.

And yes - I could have chosen HC (High Cost) or something else but I feel that if a big investment is at risk in teh form of resources required to effect a change, or the consequences of repair or backout - we are back to HR.....

Syndicate content