Are these rules of game applicable in such a volatile environment, where the business process are ever evolving with time and in an age of mergers & acquisitions?
Thanks for your comment and the name of a tool and framework that is new to me. I have no experience of this tool other than recently downloading it to look at it.
It provides detailed documentation for PRM-IT processes that are based on (aligned with?) those used in ITIL V3 & V2, COBIT, CMMI and other well-known frameworks. Its database is read-only, so if you don't want to use the processes "as-is" but want to develop your own, then you need to buy IBM ITUP Composer.
Addressing your Question
I looked specifically at ISO 20000
The ITUP tool includes a mapping from ISO 20000 to PRM-IT processes that provides documentation for the processes used in ISO 20000 (that ISO20000 groups under):
- Service Delivery Processes,
- Business Relationship Management
- Resolution Processes
- Control Processes
- Release Processes
Assuming these documented processes are compliant with ISO 20000 rather than solely ITIL, then ITUP looks a useful free tool, for sure. Even if the processes are not 100% compliant with ISO 20000, it will be a good basis.
However, those processes are NOT the service management system that is also required to meet ISO 20000 certification,
The service management system specifies:
- Management Responsibility
- Documentation Requirements
- Communication, Awareness and Training
The service management system, is NOT a process.
( To see what is contained in ISO 20000, particularly the service management system, please see "ISO 20000 on a single page! free download at www.maatconsulting.com)
As far as I could tell, ITUP does not provide documentation for a service management system although many of the requirements could be met by putting in place some of the other PRM-IT processes.
PAS 99 helps you to "unify" a service management system across ISO 20000 and other standards e.g. ISO 27001 as listed in the original column.
I'd welcome confirmation or correction of my viewpoint from anyone at IBM, or elsewhere, who has used IBM Tivoli ITUP for ISO 20000 certification and can comment on its usability.
Well, how about taking the direction from other consultants that are pushing the ITUP PRM-IT "framework" as a solution, which is based on ITIL V3...well, ITUP has 46 processes and not sure I agree with these processes being part of IT, as they seem to better fit in the PMO area, such as Risk Management. Risks are identified at the IT level, but should be managed from a Program/Project level. Then there is this Service Execution process. Is this not the actual execution of a service? Are we now having to write a process to execute services? I thought services are managed operationally by way of the typical Service Support processes and adjusted through CSI activities. Service Level Management will provide the oversight and management of services from a Service Delivery aspect - ALL POINTS COVERED!
ITIL is a framework that should be used for guidance in the development or implementation of business processes. It is ultimately those business requirements that will drive to the desired results for successful implementation. If someone dictates to a task level how to perform specific processes (activities) then there is greater risk that you will miss key requirements. I do believe that is the primary reason that ITIL only describes high level activities (process level) and not the how. There are too many different industries, functions, and situations that should drive the desired end state of any implementation effort. If your implementation does not primarily focus on the business drivers - requirements, policies and standards, then you will miss the boat.
Amazing how hotly debated this is.. This column was meant to be light hearted. It wasn't about ITIL and GPS - it was about the warnings that come with a GPS, and more importantly, the phrase "Doing ITIL". I just happened to groc the GPS analogy, and was then in some meetings where people introduced themselves and said they were "doing ITIL".
I never said I was the original person who said it wasn't a journey or destination. Like most LinkedIn discussions, 20 people made that point before me- I just asked if it really mattered what it was....
Comparing ITIL to a GPS not only misses the point, it potentially sends the wrong message. ITIL doesn't provide directions, a GPS does. ITIL is (quoting OGC forward) an "...approach to IT Service Management...."
From the Chief Architect's Forward to the CSI volume:
"ITIL service management practices are based on a solid framework of concepts, processes, functions and activities that exert positive outcomes on business value. One of the constant features of these practices is the objective to improve in maturity and therefore service excellence in every possible way."
Improvement and maturity in service management represents approaching a moving target -- something the GPS can't handle.
Btw, I read the LinkedIn thread, and you were not the one who suggested that ITIL wasn't a journey or a destination.
Is ITILv3 not a service management framework realizes IT service management which in turn is directed to achieving the goals listed? Does it really matter whether it is described as a destination, a journey, a framework, a set of principles or a pile of horse droppings? Are we not wasting a great deal of energy on fruitless discussion? Just do it! It doesn't have to be perfect. It must however evolve.
I think the idea of fixing the errors and lack of consistency is a good idea. Anyone who had to write courseware witn the previous version was shocked from the get-go at the lack of consistency just in coming up with the Purpose, Goals, Scope and Objectives of each process. When something as simple as that was hard to find - we knew we were in for a treat on the rest of it!
What I have issue with is the extra cost and burden it places on small training organizations such as ours who will have to buy new books so we can update all of our courseware which will likely be a very large undertaking and hence cost.
Before looking to the future, one should look at the present. What already exists in the organization? As was already said, change mgmt, of some form, is likely to exist and be more mature than configuration mgmt. Even if the opposite is true, the point is still the same. Working with what you have is going to meet far less cultural resistance and can establish a good opinion of process improvement. Starting with what exists, and easing the impact of change, will create greater buy-in. Understand the organization first. This is not a process decision to be made in a vacuum.
--Damian
Yes, you are right it is ahead of its time considering the majority of organizations and I do not hide this in the article... but the path is set by the best practices (ITIL v3) and the standards (ISO/IEC 20000) and some organizations have started their journey. More are joining every day and this is also a act.
Sounds like a "Chicken or the Egg, which comes first?" question.
Some may say that Configuration Management process should be implemented first. Some may even say it should be the first ITIL process to be implemented since this process underpins all other ITIL processes.
The fact is that many companies have implemented some form of Change Management process, without a formal Configuration Management process. In organizations that have implemented both processes, the maturity of their Change Management process is usually far more than the other.
In summary, it would be ideal to be able to plan and implement both processes concurrently. But if you are constrained by time, money or project resources, you may choose to postpone the Configuration Management process implementation and focus on getting Change Management process up and running first. Getting the benefits of an improved process earlier (Achieving Quick Wins) is an important consideration when you are on the IT Service Management (ITSM) journey. Also, with the Change Management process introduced, there is a better understanding of how to scope and plan the Configuration Management implementation to link both processes together later on.
I hope that we have finally got an answer mutually. Lets have another topic of discussion, does any one have any?
This seems to be a recurring misunderstanding of the most basic principles of traceability for many ITIL implementations. "You can't change manage what isn't configured."
This issue has been a recurring cause of many failures of defence projects. Configuration and change management have been clearly defined for decades as the proper means to manage complex systems. ITIL seems to be the 'newest flavour' of configuration and change management but the basic principles don't change.
In my experience the most common attempt to implement an appropriate complexity management method (ITIL, CMII, etc) is often applied as a 'big bang' approach. Very few organisations, or their staff, can cope with this type of revolution. My advice is always to start small with the most innovative people. Once the most appropriate mix of process, experience and tailoring is well understand and proven to work then the lessons learnt can be progressively rolled out through the rest of the organisation.
I came across this discussion whilst searching google for the definition of 'Resolved.' Don't know if anyone is still tracking this forum, but as an ITIL author, examiner, trainer and user since version 1, may I clear up some common misconceptions?
1) An incident NEVER becomes a problem! Repetitive incidents or major incidents or incidents that have exceeded their service level to fix are NOT problems. I always find it helpful to think of the incident as the event or symptom and the problem as the cause. Therefore EVERY incident has an associated problem, although in practice, a problem record is only raised if there is sufficient justification in carrying out separate investigation into the root cause to prevent incidents recurring, for instance, based on cost/benefit analysis.
2) An incident is NOT just a case of something broken or failed. ITIL 3 is careful to point out that an event that COULD cause a failure or service disruption is ALSO an incident. This is typically an exception event as defined in Event Management.
3) A service request is NOT an incident because the person making the request has not suffered an interruption to or failure of service. In the first instance quoted above, a user unable to save files IS suffering an incident. This is NOT a service request but a Change (increase the file space available). However, if the user had correctly diagnosed the cause of their inability to save the file as a lack of file space and asked for more, thier contact should indeed be logged as a service request. This means that the definition of incident or service request should be based on the customer's perspective (not the limitations of the toolset!)
4) A user requesting a password reset because they have been locked out of a system or service is NOT an incident but a service request since their has been no failure of the system, service or component.
5) Sadly, many if not most incident management tools do not distinguish between incidents, service requests or problems at the highest level, only at a sub-level, perpetuating the belief that they are synonymous. Better tools create different records that makes life easier for people like the Problem Manager in analysing trends.
6) Incidents are FIXED, problems are RESOLVED. The difference is that resolved also means 'Prevented from recurrence' which is most often what the Problem Manager does with a problem but rarely what the Service Desk does with an incident (particularly when applying a workaround.
Other examples of service requests:
"I can't create a table in MS Word, can you help?"
"I have a new team member who can't sign-on because they don't yet have a user-id, can you please create one for them?"
"My printer has run out of toner, can you please send some more?"
Hope this helps!
John Sansbury
I visited this sight for the first time and found it much informative and knowledgeable but I would like to add that currently we are living in the era of IT but unfortunately more than half of world population is illiterate. Out of those a few are computer and internet familiar so the target market for internet marketing is niche. Therefore the developed nations should promote IT as well as computer literacy in these developing areas so the target market can be increased in future.
Having managed teams of people trying to implement ITIL, having trained hundreds of people on ITIL, and having run sim's myself, I truly wonder if it is the question: "Can't people see the practicality of ITIL?". I recently made a trip with one of our sales reps to a client in Texas. I listened to all the disconnect between IT and the business from the leadership team. I immediately said to myself "here we go again, IT tinkerers with their head in the sand". Then we came back the next day for a round of interviews with the mid-level and front-line folks. I was completely blown away. All these folks were ITIL certified, and were speaking of everything ITIL had to offer. All they wanted to do was please the business, and deliver the business service. However. one simple fact prevented them - Distraction. While they had education & experience, they were too broadly focused on competing agendas.
I suggested with great emphasis that they participate in a round of simulations, not to gain the practical value, not to even experience the pain, they are already doing that. But to see and hear from others in their organization that they are not alone. That they are on a journey of improvement, and its hard and it takes time. I told them I would personally deliver this sim, as I was inspired by this team, and want to do everything I can to help them keep the faith. That's also why I think certification is important (and I'm not be exclusive to ITIL V3) any cert is a level of achievement. It can be a great motivator and a great filter on those who are not going to push themselves to the next level. It certainly is not "THE" guide, but it is a guide to measure the capability.
Here is a link to the press release from IVI's annual conference in Boston in early Feb 2010 indicating successes from adoption of IT-CMF by several of its IVI Consortium members e.g. Merck, Chevron and BP.
It is also stated that 250 CIOs and IT executives are engaged with IVI and that IVI expects two-thirds of Fortune 500 companies to be using IT-CMF within 5 years. Also the US Dept. of Homeland Security has recently joined IVI Consortium.
Interesting input but I also found some really nice architecture tips at 10bomb.com so you might want to check it out.
Gretta
Are these rules of game applicable in such a volatile environment, where the business process are ever evolving with time and in an age of mergers & acquisitions?
Thanks for your comment and the name of a tool and framework that is new to me. I have no experience of this tool other than recently downloading it to look at it.
Background
IBM's Tivoli Unified Process (ITUP) tool based on IBM's Process Reference Model for IT (PRM-IT) is a freely downloadable web-based tool.
( http://www-01.ibm.com/software/tivoli/governance/servicemanagement/itup/... )
It provides detailed documentation for PRM-IT processes that are based on (aligned with?) those used in ITIL V3 & V2, COBIT, CMMI and other well-known frameworks. Its database is read-only, so if you don't want to use the processes "as-is" but want to develop your own, then you need to buy IBM ITUP Composer.
Addressing your Question
I looked specifically at ISO 20000
The ITUP tool includes a mapping from ISO 20000 to PRM-IT processes that provides documentation for the processes used in ISO 20000 (that ISO20000 groups under):
- Service Delivery Processes,
- Business Relationship Management
- Resolution Processes
- Control Processes
- Release Processes
Assuming these documented processes are compliant with ISO 20000 rather than solely ITIL, then ITUP looks a useful free tool, for sure. Even if the processes are not 100% compliant with ISO 20000, it will be a good basis.
However, those processes are NOT the service management system that is also required to meet ISO 20000 certification,
The service management system specifies:
- Management Responsibility
- Documentation Requirements
- Communication, Awareness and Training
The service management system, is NOT a process.
( To see what is contained in ISO 20000, particularly the service management system, please see "ISO 20000 on a single page! free download at www.maatconsulting.com)
As far as I could tell, ITUP does not provide documentation for a service management system although many of the requirements could be met by putting in place some of the other PRM-IT processes.
PAS 99 helps you to "unify" a service management system across ISO 20000 and other standards e.g. ISO 27001 as listed in the original column.
I'd welcome confirmation or correction of my viewpoint from anyone at IBM, or elsewhere, who has used IBM Tivoli ITUP for ISO 20000 certification and can comment on its usability.
Geoff
Hello,
If you're just starting with this effort, you can use my guidelines document to help as well.
It's available @ http://musabq.blogspot.com/2008/02/it-service-catalogue-guidelines.html
Regards,
Musab Qureshi
Well, how about taking the direction from other consultants that are pushing the ITUP PRM-IT "framework" as a solution, which is based on ITIL V3...well, ITUP has 46 processes and not sure I agree with these processes being part of IT, as they seem to better fit in the PMO area, such as Risk Management. Risks are identified at the IT level, but should be managed from a Program/Project level. Then there is this Service Execution process. Is this not the actual execution of a service? Are we now having to write a process to execute services? I thought services are managed operationally by way of the typical Service Support processes and adjusted through CSI activities. Service Level Management will provide the oversight and management of services from a Service Delivery aspect - ALL POINTS COVERED!
ITIL is a framework that should be used for guidance in the development or implementation of business processes. It is ultimately those business requirements that will drive to the desired results for successful implementation. If someone dictates to a task level how to perform specific processes (activities) then there is greater risk that you will miss key requirements. I do believe that is the primary reason that ITIL only describes high level activities (process level) and not the how. There are too many different industries, functions, and situations that should drive the desired end state of any implementation effort. If your implementation does not primarily focus on the business drivers - requirements, policies and standards, then you will miss the boat.
Nice column imo. It shows that ITIL isn't a holy grail and that the destination is more important then the tooling.
Amazing how hotly debated this is.. This column was meant to be light hearted. It wasn't about ITIL and GPS - it was about the warnings that come with a GPS, and more importantly, the phrase "Doing ITIL". I just happened to groc the GPS analogy, and was then in some meetings where people introduced themselves and said they were "doing ITIL".
I never said I was the original person who said it wasn't a journey or destination. Like most LinkedIn discussions, 20 people made that point before me- I just asked if it really mattered what it was....
If nothing else, the "warning label" for the ITIL books is a great idea!
Comparing ITIL to a GPS not only misses the point, it potentially sends the wrong message. ITIL doesn't provide directions, a GPS does. ITIL is (quoting OGC forward) an "...approach to IT Service Management...."
From the Chief Architect's Forward to the CSI volume:
"ITIL service management practices are based on a solid framework of concepts, processes, functions and activities that exert positive outcomes on business value. One of the constant features of these practices is the objective to improve in maturity and therefore service excellence in every possible way."
Improvement and maturity in service management represents approaching a moving target -- something the GPS can't handle.
Btw, I read the LinkedIn thread, and you were not the one who suggested that ITIL wasn't a journey or a destination.
Nope, GPS misses the mark!
Is ITILv3 not a service management framework realizes IT service management which in turn is directed to achieving the goals listed? Does it really matter whether it is described as a destination, a journey, a framework, a set of principles or a pile of horse droppings? Are we not wasting a great deal of energy on fruitless discussion? Just do it! It doesn't have to be perfect. It must however evolve.
So, where does the IBM Tivoli Unified Process (ITUP) with PRM-IT fall within this logic?
More curious who the authors are.
I think the idea of fixing the errors and lack of consistency is a good idea. Anyone who had to write courseware witn the previous version was shocked from the get-go at the lack of consistency just in coming up with the Purpose, Goals, Scope and Objectives of each process. When something as simple as that was hard to find - we knew we were in for a treat on the rest of it!
What I have issue with is the extra cost and burden it places on small training organizations such as ours who will have to buy new books so we can update all of our courseware which will likely be a very large undertaking and hence cost.
What ever happened to the need for integration of data and how is it going to be sloved in the cloud?
OK. You say you "need to come up with a consensus on the definition of the term body of knowledge." Why?
Where are you going with this?
Are you proposing something?
Suggesting something?
How did writing this article get you closer to "consensus"?
Not to be too blunt or harsh about it, but why should anyone continue to pay attention to this topic?
Before looking to the future, one should look at the present. What already exists in the organization? As was already said, change mgmt, of some form, is likely to exist and be more mature than configuration mgmt. Even if the opposite is true, the point is still the same. Working with what you have is going to meet far less cultural resistance and can establish a good opinion of process improvement. Starting with what exists, and easing the impact of change, will create greater buy-in. Understand the organization first. This is not a process decision to be made in a vacuum.
--Damian
Yes, you are right it is ahead of its time considering the majority of organizations and I do not hide this in the article... but the path is set by the best practices (ITIL v3) and the standards (ISO/IEC 20000) and some organizations have started their journey. More are joining every day and this is also a act.
thanks for the knowledge. This is a very interesting subject to know. I hope my idea with this one will grow as I continuously read your posts.
Sounds like a "Chicken or the Egg, which comes first?" question.
Some may say that Configuration Management process should be implemented first. Some may even say it should be the first ITIL process to be implemented since this process underpins all other ITIL processes.
The fact is that many companies have implemented some form of Change Management process, without a formal Configuration Management process. In organizations that have implemented both processes, the maturity of their Change Management process is usually far more than the other.
In summary, it would be ideal to be able to plan and implement both processes concurrently. But if you are constrained by time, money or project resources, you may choose to postpone the Configuration Management process implementation and focus on getting Change Management process up and running first. Getting the benefits of an improved process earlier (Achieving Quick Wins) is an important consideration when you are on the IT Service Management (ITSM) journey. Also, with the Change Management process introduced, there is a better understanding of how to scope and plan the Configuration Management implementation to link both processes together later on.
I hope that we have finally got an answer mutually. Lets have another topic of discussion, does any one have any?
Regards,
Yusuf
This seems to be a recurring misunderstanding of the most basic principles of traceability for many ITIL implementations. "You can't change manage what isn't configured."
This issue has been a recurring cause of many failures of defence projects. Configuration and change management have been clearly defined for decades as the proper means to manage complex systems. ITIL seems to be the 'newest flavour' of configuration and change management but the basic principles don't change.
In my experience the most common attempt to implement an appropriate complexity management method (ITIL, CMII, etc) is often applied as a 'big bang' approach. Very few organisations, or their staff, can cope with this type of revolution. My advice is always to start small with the most innovative people. Once the most appropriate mix of process, experience and tailoring is well understand and proven to work then the lessons learnt can be progressively rolled out through the rest of the organisation.
I came across this discussion whilst searching google for the definition of 'Resolved.' Don't know if anyone is still tracking this forum, but as an ITIL author, examiner, trainer and user since version 1, may I clear up some common misconceptions?
1) An incident NEVER becomes a problem! Repetitive incidents or major incidents or incidents that have exceeded their service level to fix are NOT problems. I always find it helpful to think of the incident as the event or symptom and the problem as the cause. Therefore EVERY incident has an associated problem, although in practice, a problem record is only raised if there is sufficient justification in carrying out separate investigation into the root cause to prevent incidents recurring, for instance, based on cost/benefit analysis.
2) An incident is NOT just a case of something broken or failed. ITIL 3 is careful to point out that an event that COULD cause a failure or service disruption is ALSO an incident. This is typically an exception event as defined in Event Management.
3) A service request is NOT an incident because the person making the request has not suffered an interruption to or failure of service. In the first instance quoted above, a user unable to save files IS suffering an incident. This is NOT a service request but a Change (increase the file space available). However, if the user had correctly diagnosed the cause of their inability to save the file as a lack of file space and asked for more, thier contact should indeed be logged as a service request. This means that the definition of incident or service request should be based on the customer's perspective (not the limitations of the toolset!)
4) A user requesting a password reset because they have been locked out of a system or service is NOT an incident but a service request since their has been no failure of the system, service or component.
5) Sadly, many if not most incident management tools do not distinguish between incidents, service requests or problems at the highest level, only at a sub-level, perpetuating the belief that they are synonymous. Better tools create different records that makes life easier for people like the Problem Manager in analysing trends.
6) Incidents are FIXED, problems are RESOLVED. The difference is that resolved also means 'Prevented from recurrence' which is most often what the Problem Manager does with a problem but rarely what the Service Desk does with an incident (particularly when applying a workaround.
Other examples of service requests:
"I can't create a table in MS Word, can you help?"
"I have a new team member who can't sign-on because they don't yet have a user-id, can you please create one for them?"
"My printer has run out of toner, can you please send some more?"
Hope this helps!
John Sansbury
I visited this sight for the first time and found it much informative and knowledgeable but I would like to add that currently we are living in the era of IT but unfortunately more than half of world population is illiterate. Out of those a few are computer and internet familiar so the target market for internet marketing is niche. Therefore the developed nations should promote IT as well as computer literacy in these developing areas so the target market can be increased in future.
by james
Great article, thanks!
Paul,
Having managed teams of people trying to implement ITIL, having trained hundreds of people on ITIL, and having run sim's myself, I truly wonder if it is the question: "Can't people see the practicality of ITIL?". I recently made a trip with one of our sales reps to a client in Texas. I listened to all the disconnect between IT and the business from the leadership team. I immediately said to myself "here we go again, IT tinkerers with their head in the sand". Then we came back the next day for a round of interviews with the mid-level and front-line folks. I was completely blown away. All these folks were ITIL certified, and were speaking of everything ITIL had to offer. All they wanted to do was please the business, and deliver the business service. However. one simple fact prevented them - Distraction. While they had education & experience, they were too broadly focused on competing agendas.
I suggested with great emphasis that they participate in a round of simulations, not to gain the practical value, not to even experience the pain, they are already doing that. But to see and hear from others in their organization that they are not alone. That they are on a journey of improvement, and its hard and it takes time. I told them I would personally deliver this sim, as I was inspired by this team, and want to do everything I can to help them keep the faith. That's also why I think certification is important (and I'm not be exclusive to ITIL V3) any cert is a level of achievement. It can be a great motivator and a great filter on those who are not going to push themselves to the next level. It certainly is not "THE" guide, but it is a guide to measure the capability.
Just my thoughts -
VigilantGuy
Latest News
http://communications.nuim.ie/press/040210.shtml
Here is a link to the press release from IVI's annual conference in Boston in early Feb 2010 indicating successes from adoption of IT-CMF by several of its IVI Consortium members e.g. Merck, Chevron and BP.
It is also stated that 250 CIOs and IT executives are engaged with IVI and that IVI expects two-thirds of Fortune 500 companies to be using IT-CMF within 5 years. Also the US Dept. of Homeland Security has recently joined IVI Consortium.
Geoff