The IT Skeptic - Comments for "ITIL Problem versus Risk"

ISO 9000

aroos — Tue, 29 Mar 2011 06:22:05 +0000

Just heard that new version of ISO 9000 will drop proactive activities for the sake of clarity, there will be just Control and Improve. I suppose one should have many improvement queues.

Aale

commoditization of ITSM

jvbon — Thu, 24 Mar 2011 09:46:08 +0000

Of course there are many types of risks. They may vary in terms of likelihood, impact, etc. Even an opportunity is a type of risk. But if you look at the process, it's all the very same.
Therefore, to make this simple, you can do with a single pure process in an integrated service management process model. We practice this with great success everyday, in the ISM Method.
'Practices' like Security Management are functions, not processes. As a consequence, they use the elements People, Process and Product to achieve their specific goals. This simply means that Security uses the processes of contracting, changing, restoring, delivering, preventing, etc. Security also uses People: we're currently developing a management guide on this in the Roles books, to be published by TSO around this summer. And you can imagine the Products that are used for security goals.
Setting up a Security Management function is easy, once you have a management system that covers all three elements. Achieving an ISO standard is a lot less difficult if you have this in place.
Believe me - this is much easier than everyone is led to believe. Just look trough the ITIL papers and see the structure. Once you see that, you can speed up the results of your projects by a factor 10, and create lasting results.
This is how ITSM is now commoditized in the Netherlands. We put the ITIL books at their rightful place, the bookshelf. We take them off when we want to be inspired by the best practices that are described in the books. We use an integrated service management system to realize these practices.
I've written plenty of articles that provide details about the architecture and the view of this methodology. It's not rocket science, it's easy to learn, and it brings great results. Once you've got it, you can focus on all the topics that really require attention....

No you are not

aroos — Thu, 24 Mar 2011 07:53:22 +0000

If you wish, you can check my presentation at Pink11 (Session 809, 4th slide from end) where I have Security, Capacity, Availability, Continuity and Problem mgmt as all part of both risk management and continuous service improvement. Risk and CSI are the opposite ends of the box, so yes they have much in common. But then there is a difference. For example availability, CSI and risk management all want to reduce interruptions. Improving availability by reducing response times is not risk management; it is service improvement.

I have been wondering is there any need for separate availability, continuity and capacity planning functions (they are not processes). My recommendation has been to make a service plan according to ISO 20000 which contains plans for availability etc. For example planning for service desk capacity needs is quite different from planning storage needs, there is no benefit in trying to centralize those under one "process". I suppose all those things can be split in risk and CSI.

The difference is in the procedure. Risks can and should be identified and recorded. CSI is more of a collection of proposals, programs, activities etc. There can also be some tension between the two, password rules are a good example. Security (risk) wants to have complex passwords and force people to change them often, CSI sees password resets as a recurring incident which reduces customer satisfaction.

Aale

centralised management of an improvement programme

skeptic — Thu, 24 Mar 2011 02:06:03 +0000

I can't see that. even if they were in one repository or queue, they'd be there as subtypes with different owners. I'm all for centralised management of an improvement programme - in fact I do that for smaller clients. But down to the level of each improvement task in one queue??? I suppose so, but my instinct is still that this is abstracting beyond the useful.

less theoretical

Charles T. Betz — Thu, 24 Mar 2011 02:01:28 +0000

I've consulted with the owners of formal risk, problem, and continuous improvement processes, with specific attention to the nuts and bolts of how they work and their enabling data structures.

At the end of the day, they are all relatively unstructured efforts (compared to formalized transactional processes like originating a mortgage) that need identification, scoping, assignment (typically to overutilized SMEs), and tracking to completion.

I see no reason why both Risk and Problem could not be seen as subtypes of a more generalized Improvement Opportunity, which might also include dimensions such as Capacity, Availability, Architecture, Continuity, Security, and so forth.

I think the practical benefit in a generalized Improvement Opportunity process is queue reduction; queue proliferation I think is one of the biggest problems in large, complex, matrixed organizations.

Charles T. Betz
http://www.erp4it.com

Every management practice is

skeptic — Wed, 23 Mar 2011 18:34:27 +0000

Every management practice is aspecial case of PDCA. I think that generalises to the point of being unhelpful. I was worried that calling problem a case of risk was similarly over-abstracting, but Everything maps to PDCA surely?

PDCA and Risk

Charles T. Betz — Wed, 23 Mar 2011 17:34:09 +0000

Got a number of interesting hits when I Googled "PDCA and Risk." Including a Van Haren publication, Information Security based on ISO 27001, which advocates using PDCA for implementing a risk management program.

I think I am not the first person to see essential similarity here. Can you be more specific on why it would be harmful to see risk as a continuous improvement opportunity? On a practical level, both need tracking and often involve the same sorts of investigations. At least that's been my experience in working with business partners on both kinds of effort. Certainly, I have been involved in any of a number of continuous improvement reviews that have resulted in risk identification. I've also seen risks identified that resulted in a continuous improvement cycle.

Charles T. Betz
http://www.erp4it.com

Different things

aroos — Wed, 23 Mar 2011 16:50:15 +0000

Charlie, you should talk with your business people ;)

Risk as a special case of continuous improvement

Charles T. Betz — Wed, 23 Mar 2011 14:59:13 +0000

And why would we not see Risk Management as one form of Continuous Improvement?

Charles T. Betz
http://www.erp4it.com

There is no Problem Management

aroos — Wed, 23 Mar 2011 12:44:10 +0000

I spoke about this in Pink11 but unfortunately you were doing an interesting panel discussion at the same time.

Problem Management appears only in ITIL, there is no such thing anywhere else. ITIL PM is the unhappy marriage of Problem Solving and Risk mgmt. Problem solving is not a process but a capability or practice which support needs. If an incident (request for support, consumer problem) is hard to solve, you need to activate the problem solvers in your organization but you do not need to start a new process, IM will do just fine.

If you use a workaround and are unable to fix the cause of the incident, there usually is a risk that it will repeat. That would then be a moment to open a risk ticket. All known errors contain some risk and can cause various incidents. This activity is reactive risk management, proactive risk management seeks to prevent things from happening the first time. Managing risk and solving technical problems are two very different practices.

Aale

PS
Excellent post and I also agree completely regarding customers in ITIL. Service lifecycle management without customers, sales, business relationship mgmt etc is just plain silly.