I wrote this in response to 'IT Skeptic' at http://www.itsmwatch.com/itil/article.php/11700_3635131_1 - an article suggesting that ITIL is not 'Best Practice':
I enjoyed your article on ITIL as a 'Best Practice'. I too have wondered about this in the past and felt it important to have a clear picture of how it is defined. Unfortunately your web-site doesn't have a section below for replies - I think it would be a useful addition.
In reply to your useful analysis, I'd make a few points. ITIL has always had continuous service improvement as the basis of 'best practice' - organisations that do this do better than those that don't - so, properly, ITIL itself is a continuously evolving 'best practice'. You're confusing 'best practice' now with 'best practice' over time, two quite different matters. There was a 'best practice' of making glass several centuries ago - it was a carefully guarded secret in Venice. The best way of making glass today is quite different!
You say that Asia is 'experimenting' with ITIL and service management, and that ITIL is euro-centric. My book 'Metrics for IT Service Management' was reviewed (as part of the process of establishing it as 'Best Practice') by people from all over the globe, including Asia. In fact the book was a result of work that I did with Samsung in Seoul in South Korea - so, in this case, Asia was part of the cutting edge in the definition of 'Best Practice' world wide! Samsung's board of directors had selected ITIL because they, after an exhaustive search, had decided that it was the best practice available for Service Management. I know that is only anecdote, but, since this started over three years ago, I think it a little unfair to describe Asia as 'experimenting' with ITIL - Samsung is quite a big company!
I agree that more rigour needs to be added to ITIL. It has been a practical and pragmetic matter to date. I'm working with the itSMF to create a Journal of IT Service Management that can host peer-reviewed academic research into Service Management and ITIL. I believe that this will provide the foundation required to establish that it is the 'best practice' in particular fields. At the moment we have to rely on the fact that there are no known better methods!
Just for the record, I'm the South African representative on the itSMF committee for publications, the IPESC, though this reply is all my own opinion.
Tuesday, 10 October 2006
Wednesday, 4 October 2006
Benchmarking Project
I've been thinking about the idea of benchmarking, in various forms, for a very long time - sad person that I am! The basic idea is very simple. Companies subscribe to a central server that provides them with the metrics that they need, their results are then fed back to the server which uses the combined results to produce statistics showing how various industries and companies at different stages of maturity manage the job of getting Service Management (in this case) to work.
This allows managers to get an objective view of exactly how well they are doing relative to their peers so that their Service Improvement Plans (SIPs or CSIPS, for continuous) set appropriate goals with properly defined objectives.
That's the theory!
When I was consulting to Samsung Semiconductor in Seoul, South Korea, a couple of years ago, I was very exercised with the problems. That was when I wrote the metrics that became the book 'Metrics for IT Service Management'. I realised then that, without a comprehensive and properly thought out set of metrics the project wouldn't even get off the ground - back then there were virtually no metrics for ITIL or other Service Management disciplines. It is true that Cobit provided a good set of audit tools to see if the processes were working - but these didn't help that much in saying exactly how to get them working.
In other fields some companies are already doing this. With, it has to be said, varying success. Many have foundered on the practical difficulties.
The difficulties are easy to list:
- Having the metrics is the first; putting together a set of metrics requires deep analysis of both the technical processes and the management and business requirements they have to satisfy. It is easy to either produce a high-level wish list for the business that doesn't work in practice or to produce a highly technical set of metrics that are useless for day to day management. I was lucky in having many years experience in providing consulting to companies on both the process management and the technical side - having a B.Sc in Maths and Physics also helped me with the more technical matters. This work has now been done - though it will, of course, require much change, over time, as various businesses use the metrics and, through the SIP process, identify weaknesses and improvements. To capture all these improvements is one job of the benchmark project. I hope that the second edition of the book will include many improvements!
- Security and confidentiality is the next; The results of metrics are part of a company's intellectual property, they give an intimate picture of exactly how well, or badly, the company is doing. No organisation would be prepared to expose this to the outside world - particularly to their close competitors! Consequently the benchmarking central site has to emply utterly reliable (and how many software projects are utterly reliable?) security measures. The consolidated data must be well enough stratified to help companies in the same field or state of maturity, but never precise enough to identify any particular company. This is a very strong requirement that can't be dodged.
- Comparability, for want of a better word, is the final major obstacle. If two companies are using the same metrics, but measureing different processes, then their results are not comparable, they're like apples and oranges. Most companies, rightly, tailor their processes to meet their business needs and to conform with existing processes. ITIL, and other Service Management disciplines, do not recommend uprooting everything the company does well and replacing it with some externally derived fixed process. This is a difficult circle to square. If companies are not prepared to follow the same process, at least for those processes that are being benchmarked, then the project won't get off the ground. Users of the benchmark system have to be persuaded that it is worth their while to use standard processes. Once they have agreed to this (a difficult task in itself) that isn't the end of the matter. The SIP requires that processes are changed to improve them once improvement activities are identified. With a central benchmarking system this SIP has, somehow, to be coordinated across different companies. This isn't just a technical difficulty. If one company, through its SIP, discovers a really valuable improvement, do they have an incentive to share this discovery with other memmbers of the benchmarking community?
- Finally, an important technical problem is that there are many different tools used to implement processes in different companies. The benchmarking project has to find a way to both standardise processes across these, measure the metrics from different sources and ensure that these different processes are comparable. This is no mean feat - particularly as Service Management tools are known for their incompatibility at the moment. The incompatibility isn't deliberately worked into the products, but there is little incentive for a vendor of tools to have them too compatible as that can lead to their product being migrated out of the solution in favour of a competitor. We do live in the real world!
So, with all these very significant problems, is it worth trying to do this?
A few years ago, I'd have said (and most people would have agreed) certainly not! Now, though, I think that the industry has matured to a level where it is feasible, or, at least, worth a shot.
Many of the problems that I mention above are not unique to benchmarking. The Holy Grail (as some have called it) of an enterprise wide configuration management database (CMDB) is eagerly sought by many companies who are serious about Service Management. The vendors, and the ITIL refresh project (that is updating the ITIL at the moment) are working hard to understand how to produce an inter-operable distributed CMDB.
There is an active project to explore this need to inter-operate that was started by BMC, CA, IBM, Fujitsu, Hewlett-Packard, all major players in this field. I'm hoping that we will have an interim report soon.
The tools needed for the job are also being produced. The acronym SOA (Service Orientated Architecture) is being bandied about by marketeers for all the major players. This is a vision of web-based interoperability based on services. It isn't a new idea, years, back in the '80s, ago something called EDI (Electronic Data Interchange) was the great hope for solving this problem. Then, much more recently, came CORBA (Common Object Request Broker Architecture) and HP produced a simplified version called E'speak. These all went some way to solving the problem but the end result was much less than ideal.
The problem has become more urgent and recent developments have been coming thick and fast, mainly from the W3C now. It is all based on XML and derivations from it. Much of the failure of earlier attempts was in getting a common language to describe interactions between companies, something known as a name space or, now, an ontology.
To define how exactly processes work, so that a generic service (it doesn't matter what language it might be working in, though Java has been a favourite) can supply the necessary support to them is the problem. OWL and OWL-S are languages that allow somebody to define an ontology that can be used for this. Some big projects have found them too slow and a language developed at Hewlett-Packard laboratories called Jini has been used in at least one large project to define and use a SOA.
This does have the feel, if you're used to this sort of thing, of a bleeding-edge technology. It's true, it is. It might be sensible to wait a few years until the dust has settled and start then. It is like buying a new PC, though. You know that, if you buy one now, you'll be disappointed in a few months time to see one that is cheaper with better specifications - but you do have a job to do today, so you have to take the plunge when your need is matched by the technology.
I think that we are at that time now. Benchmarking is a vital need. I've seen lots of interest around the world in getting this project off the ground. The Netherlands has been at the forefront of ITIL and Service Management development for many years and people there are eager to get started. I was at the itSMF annual conference in Sydney a couple of months ago, giving a presentation on Metrics and Benchmarking and the enthusiasm for it was palpable. This is something whose time has come.
Obviously I'm involved in a lot of technical and commercial detail at the moment, so I have to, as in this entry to the blog, confine myself to generalites. I hope that, if you've read this far and are interested, you'll contact me with your ideas. I'll try to keep this blog updated as things develop. I think that later posts will be shoter than this one! I hope they'll be informative though...
This allows managers to get an objective view of exactly how well they are doing relative to their peers so that their Service Improvement Plans (SIPs or CSIPS, for continuous) set appropriate goals with properly defined objectives.
That's the theory!
When I was consulting to Samsung Semiconductor in Seoul, South Korea, a couple of years ago, I was very exercised with the problems. That was when I wrote the metrics that became the book 'Metrics for IT Service Management'. I realised then that, without a comprehensive and properly thought out set of metrics the project wouldn't even get off the ground - back then there were virtually no metrics for ITIL or other Service Management disciplines. It is true that Cobit provided a good set of audit tools to see if the processes were working - but these didn't help that much in saying exactly how to get them working.
In other fields some companies are already doing this. With, it has to be said, varying success. Many have foundered on the practical difficulties.
The difficulties are easy to list:
- Having the metrics is the first; putting together a set of metrics requires deep analysis of both the technical processes and the management and business requirements they have to satisfy. It is easy to either produce a high-level wish list for the business that doesn't work in practice or to produce a highly technical set of metrics that are useless for day to day management. I was lucky in having many years experience in providing consulting to companies on both the process management and the technical side - having a B.Sc in Maths and Physics also helped me with the more technical matters. This work has now been done - though it will, of course, require much change, over time, as various businesses use the metrics and, through the SIP process, identify weaknesses and improvements. To capture all these improvements is one job of the benchmark project. I hope that the second edition of the book will include many improvements!
- Security and confidentiality is the next; The results of metrics are part of a company's intellectual property, they give an intimate picture of exactly how well, or badly, the company is doing. No organisation would be prepared to expose this to the outside world - particularly to their close competitors! Consequently the benchmarking central site has to emply utterly reliable (and how many software projects are utterly reliable?) security measures. The consolidated data must be well enough stratified to help companies in the same field or state of maturity, but never precise enough to identify any particular company. This is a very strong requirement that can't be dodged.
- Comparability, for want of a better word, is the final major obstacle. If two companies are using the same metrics, but measureing different processes, then their results are not comparable, they're like apples and oranges. Most companies, rightly, tailor their processes to meet their business needs and to conform with existing processes. ITIL, and other Service Management disciplines, do not recommend uprooting everything the company does well and replacing it with some externally derived fixed process. This is a difficult circle to square. If companies are not prepared to follow the same process, at least for those processes that are being benchmarked, then the project won't get off the ground. Users of the benchmark system have to be persuaded that it is worth their while to use standard processes. Once they have agreed to this (a difficult task in itself) that isn't the end of the matter. The SIP requires that processes are changed to improve them once improvement activities are identified. With a central benchmarking system this SIP has, somehow, to be coordinated across different companies. This isn't just a technical difficulty. If one company, through its SIP, discovers a really valuable improvement, do they have an incentive to share this discovery with other memmbers of the benchmarking community?
- Finally, an important technical problem is that there are many different tools used to implement processes in different companies. The benchmarking project has to find a way to both standardise processes across these, measure the metrics from different sources and ensure that these different processes are comparable. This is no mean feat - particularly as Service Management tools are known for their incompatibility at the moment. The incompatibility isn't deliberately worked into the products, but there is little incentive for a vendor of tools to have them too compatible as that can lead to their product being migrated out of the solution in favour of a competitor. We do live in the real world!
So, with all these very significant problems, is it worth trying to do this?
A few years ago, I'd have said (and most people would have agreed) certainly not! Now, though, I think that the industry has matured to a level where it is feasible, or, at least, worth a shot.
Many of the problems that I mention above are not unique to benchmarking. The Holy Grail (as some have called it) of an enterprise wide configuration management database (CMDB) is eagerly sought by many companies who are serious about Service Management. The vendors, and the ITIL refresh project (that is updating the ITIL at the moment) are working hard to understand how to produce an inter-operable distributed CMDB.
There is an active project to explore this need to inter-operate that was started by BMC, CA, IBM, Fujitsu, Hewlett-Packard, all major players in this field. I'm hoping that we will have an interim report soon.
The tools needed for the job are also being produced. The acronym SOA (Service Orientated Architecture) is being bandied about by marketeers for all the major players. This is a vision of web-based interoperability based on services. It isn't a new idea, years, back in the '80s, ago something called EDI (Electronic Data Interchange) was the great hope for solving this problem. Then, much more recently, came CORBA (Common Object Request Broker Architecture) and HP produced a simplified version called E'speak. These all went some way to solving the problem but the end result was much less than ideal.
The problem has become more urgent and recent developments have been coming thick and fast, mainly from the W3C now. It is all based on XML and derivations from it. Much of the failure of earlier attempts was in getting a common language to describe interactions between companies, something known as a name space or, now, an ontology.
To define how exactly processes work, so that a generic service (it doesn't matter what language it might be working in, though Java has been a favourite) can supply the necessary support to them is the problem. OWL and OWL-S are languages that allow somebody to define an ontology that can be used for this. Some big projects have found them too slow and a language developed at Hewlett-Packard laboratories called Jini has been used in at least one large project to define and use a SOA.
This does have the feel, if you're used to this sort of thing, of a bleeding-edge technology. It's true, it is. It might be sensible to wait a few years until the dust has settled and start then. It is like buying a new PC, though. You know that, if you buy one now, you'll be disappointed in a few months time to see one that is cheaper with better specifications - but you do have a job to do today, so you have to take the plunge when your need is matched by the technology.
I think that we are at that time now. Benchmarking is a vital need. I've seen lots of interest around the world in getting this project off the ground. The Netherlands has been at the forefront of ITIL and Service Management development for many years and people there are eager to get started. I was at the itSMF annual conference in Sydney a couple of months ago, giving a presentation on Metrics and Benchmarking and the enthusiasm for it was palpable. This is something whose time has come.
Obviously I'm involved in a lot of technical and commercial detail at the moment, so I have to, as in this entry to the blog, confine myself to generalites. I hope that, if you've read this far and are interested, you'll contact me with your ideas. I'll try to keep this blog updated as things develop. I think that later posts will be shoter than this one! I hope they'll be informative though...
Audiobooks on Service Management
I'm currently in the process of producing a set of audiobooks on Service Managment. These should be useful aids to study for anybody taking the ITIL Foundations or ITIL Service Manager training courses.
I've been teaching these courses over the past few years for both Hewlett Packard and Foster-Melliar and I'm registered as an ITIL trainer with both the ISEB and EXIN.
I've loved teaching for over twenty five years. I've taught technical subjects like programming, from Pascal to HP1000 microcode through things like HP Openview (NNM, Service Desk, Operations and Service Navigator etc.), Unix Security and such oddities (now) as X.25.
I think that teaching might be in my blood as both my parents were teachers as were my brother and sister at times.
I'll be advertising the series through a podcast covering the whole of Service Management in half an hour. I'm finding it a pleasant challenge to put together a short introduction to such a wide field!
I'm hoping to have the series published by Christmas 2006, though, with all the logistics, I realise that this might be a little optimistic!
The audiobooks will also be aimed at anybody intending to implement Service Management, or a part of it, practically. They're the sort of thing that will give you a refresher as you listen to them in the car on the way to work.
I've been teaching these courses over the past few years for both Hewlett Packard and Foster-Melliar and I'm registered as an ITIL trainer with both the ISEB and EXIN.
I've loved teaching for over twenty five years. I've taught technical subjects like programming, from Pascal to HP1000 microcode through things like HP Openview (NNM, Service Desk, Operations and Service Navigator etc.), Unix Security and such oddities (now) as X.25.
I think that teaching might be in my blood as both my parents were teachers as were my brother and sister at times.
I'll be advertising the series through a podcast covering the whole of Service Management in half an hour. I'm finding it a pleasant challenge to put together a short introduction to such a wide field!
I'm hoping to have the series published by Christmas 2006, though, with all the logistics, I realise that this might be a little optimistic!
The audiobooks will also be aimed at anybody intending to implement Service Management, or a part of it, practically. They're the sort of thing that will give you a refresher as you listen to them in the car on the way to work.
Metrics in IT Service Management
I might as well start by including information on the metrics book from my publisher's web-site:
http://en.itsmportal.net/en/node/14034
Synopsis:
http://en.itsmportal.net/en/node/14034
METRICS for IT Service Management
17 Sep 2006, read 156 times—Title:
METRICS for IT Service Management
Publisher:
Van Haren Publishing for itSMF-NL
ISBN:
9077212698
This is an ITSMF-NL publication, developed in cooperation with members of several other ITSMF chapters. It clearly adds highly desired value to existing publications in the ITSM field, it is complementary to- and completely aligned with ITIL.
The publication can be used for ‘beginners’ who need to understand how metrics can be used, as well as for senior IT service managers, who can apply the specific metrics. Important qualification of the book is that it provides meaningful metrics instead of measurable metrics: this way it supports the standardization of metrics in the service management arena (facilitating future benchmarking projects), and it can put an end to the well-known – but meaningless - enormous reports on measurable data.
All material is copyrighted by ITSMF-NL. The book was launched at the ITSMF-NL Spring Conference, April 20, 2006.
From the Acknowledgements section:
Following feedback from members, Metrics guidance has been high on the ITSMF agenda for a long time. The fact that existing publications offered limited information has led to many requests from members for more detailed and practical guidance. The first publication in the ITSM Library to cover structured information on metrics was the "pocket guide on CobiT". This publication was developed with the intent to bring valuable information on Key Performace Indicators and Critical Success Factors for IT management processes to the field of IT Service Management. But it filled only part of the gap. So when Peter Brooks approached us, we were delighted to have the opportunity to extend the information on metrics for IT Service Management. May 2005 we started the joint community project to document the common best practice in metrics guidance.
With his deep level of expertise, Peter Brooks took the role of author in the editorial project. Tieneke Verheijen acted as coordinating editor with responsibility for all the quality improvements we have delivered through a thorough review process. The project was run under the guidance of ITSMF-NL's chief editor Jan van Bon who was responsible for the Project Management.
To ensure international knowledge and experience was reflected, a broad panel of experts was installed as the Review Team. The resulting editorial team formed a community, comprising the author, the editors, experts from the ITSMF chapters and the ITSMF International Publications Executive Sub-Committee (IPESC). This editorial team developed the scoping of the book by agreeing a Table of Contents.
The project was then turned over to the author and the editors: they gathered the best practices on metrics that they could find, using their own experiences, existing literature, many other sources and, of course, the web. In an intense and iterative peer review many other experiences were added by the Review Team. The result is this book: a thorough introduction to the field of metrics for IT Service Management, and a very valuable practical description of the best metrics we could find.
We owe Peter Brooks huge thanks for his never-ending enthusiasm and persistence, and his willingness to listen to the reviewers and seriously consider their issues. This has enabled us to develop a true common best practice on metrics for IT Service Management.
We also wish to thank our international Review Team, that has contributed their huge collective experience and knowledge. They provided encouragement, criticism and useful new ideas, to ensure that the book reflects the very best practice. Their input has really made a difference, especially in agreeing the structure and the initial table of contents, and adding very useful metrics to those already provided by Peter Brooks. But, most of all, they have ensured that difficult or unclear topics are explained in such a way as to provide an easy-to-read and practical book.
The Review Team consisted of:
- Rolf Akker - Atos Origin, the Netherlands
- Raul Assaf - Santa Monica Consulting, Argentina
- Bert Bouwmeester - Steenbok Adviesgroep BV, the Netherlands
- Gerard Brantjes sr. - Brantjes Advies Bureau, the Netherlands
- Alison Cartlidge - Xansa, United Kingdom
- Janaki Chakravarthy - Infosys Technologies Limited, India
- Young Sug Choi - BSI Korea
- Federico Corradi - Cogitek Consulting, ITSMF Italy
- Bart den Dulk - Port of Rotterdam, the Netherlands
- John Groom - West-Groom Consulting, United Kingdom
- Ton van den Hoogen - Tot Z, the Netherlands
- Chris Jones - Ariston Strategic Consulting, Australia
- Henk de Jong - AEGON Nederland NV, the Netherlands
- Laurent Koelink - Quintica Consultants, the Netherlands
- Steve Mann - SM2 Ltd, United Kingdom
- Christian F. Nissen - Itilligence, Denmark
- Douglas Read - Pro-Attivo Limited, United Kingdom
- Ulrich Erik Redmann - Vattenfall Europe Information Services, Germany
- Adriaan van de Rijken - Quint Wellington Redwood, USA
- Parmjit Sangha - Quint Wellington Redwood, Canada
- Russell Steyn - Foster Melliar, South Africa
- Antonio Valle - Abast Systems, Spain
- Wilfred Wah - IBM Global Services, Hong Kong
Their expert help has been invaluable.
We also want to thank the representatives of ITSMF chapters in IPESC. They assessed the quality of the content of this ITSMF publication, and the process by which it was produced, and have given their formal endorsement to this book in a unanimous vote. As a consequence this book is part of the core of the uniform understanding of ITSM knowledge and best practices, as it is used within the global ITSMF organization. This is the best compliment we could get.
Peter Brooks (FISM), Author
Tieneke Verheijen, Coordinating editor
Jan van Bon, Chief editor ITSMF-NL
Some quotes of the reviewers: and readers of the ITSMF Metrics guide:
"I believe I would be delighted to use the published book as a rich and solid source of metric-related information, complete with its ready-made set of examples."
"I'm sure I will add it to the references I add in my training courses."
"From our recent experience we feel the market is looking for a book like this to get them started on measuring IT performance."
"The book is extremely extremely relevant to the topic and whole ITSM environment."
"This is more than a book, it’s a practical, useable "A to Z" of IT Service Management Metrics!"
"I don’t carry many books around with me, this one, I most certainly will!!"
"With all the focus on IT Governance and IT Business process management. It is easy to see why metrics are becoming hugely important for the management of organisations. In reality however, getting the right set of metrics in place is by no means a simple exercise.
Metrics for IT service organisations can be a great help. Using ITIL as the basis the book lists many useful examples of metrics. But what is more important, is that it gives us insight into to creation of "good" metrics and the dangers of "bad" metrics."
Given that itSMF is the source, readers of this book will naturally expect a "best practices" view on metrics, and a highly practical reference text. More partcularly, though, the special merit of the text is its carefulness in stressing that metrics must be both useful and meaningful, and that the meaning comes from the business perspective on IT management processes -- a perspective always represented by a stated business objective. By encouraging readers to seriously commit to defining clear business objectives, the text aims the reader at measurement that avoids excess or irrelevance.
Subscribe to:
Posts (Atom)