I cannot agree with you more J
I have seen a number of organizations having a KPI of completing the root cause analysis within “x” days from incident closure.This kind of metric, as you rightly pointed out is encouraging bad behaviors as the focus of the exercise is shifting on just competing the RCA as against mitigating risk. Your example nicely explains the relationship between the level of risk and the amount of time and resources an organization should spend on a particular RCA rather than “one size fits all” kind of approach.
I also totally agree with this viewpoint. Let me add that one of the well established, but in my opinion distructive practice with regards to SLAs and outsourcing contract is where the target metric with regards to Problem Management is a target time to find a root cause (or to resolve the problem). This does not help at all, because the incentive is targeted at the wrong thing.
In my opinion, the right target in Problem Management should be associated with mitigating the risk caused by the problem. There are a number of ways to do this depending on how the processes and measures are implemented in an organisation, nevertheless, the point is that executing Problem Management consumes resources, and the associated expenditure should be aligned with the level of risk mitigation it provides. Another way to say it is: if there is an extremely low level of risk and the organisation's risk tolerance is high, don't spend any resources on that problem: however, if the risk is high and risk tolerance is low, the organisation should target the right resources however long it takes to mitigate the risk properly. Closure of the Problem should be associated with a satisfactory mitigation of the associated risk.
Totally agree Rajat! Similar comments have been expressed many times at ITSM PORTAL: just search for the term 'risk' and you'll find lots of sources here.
This can't be said too often. ITIL ignored the role of risk for far too long, concentrating on the technology approach of RCA. Your example illustrates this nicely.
It's not about being right or wrong in terms of what is a 'real' framework, method or reference model, it's about how they are used in practice. And that's where people treat them as alternatives...
Lots of practitioners and companies have developed an aversion against ITIL and now 'use' COBIT or USMBOK or ISO20000 for the same purpose: getting some grip on their service management.
The ISM Method is the only thing I've seen that is defined and developed as a 'method'. In that sense, it can work perfectly well with all other sources.
Secondary thought - what are we doing here? ISO20000 (2011) serves a different purpose - it provider a rather flexible range of conformance with a basic specification for a service management system. It does NOT allow certification of the 'enterprise', in fact it enables a tightly scoped or use of the SMS. Ideal for any sized IT organization. It was arrived at by international consensus and in the latest version consistent with other management system standards such as ISO9000.
ITIL and COBIT are contributions to differing community needs - ITSMF and ISACA based upon the opinions and insights of the respective communities. In the case of the former this was severely limited to two primary authors. They are not standards in any way shape or form.
The USMBOK is neither a standard or a framework. I'll leave JVB to speak to ISM. I know of at least another 20 frameworks that could be considered, over 250 books in my library that add something to the service management discussion (all non-IT), and that goes without addressing organizational change or transformation topics.
So what are we trying to do here - puncture ITIL?
Couple of quick comments - when was ITIL non-commercial? Its always been owned as intellectual property, its always been leveraged and sold by the traditional ITSM community as a product and often as an introduction to private wares. I see the JV as a positive step in addressing a whole host of issues that simply were allowed to continue for many years.
As for the USMBOK being an 'alternative' - thats just wrong and the wrong way to look at any framework. First, the USMBOK serves a different purpose. It is grounded in the original service management born out of product marketing and management. It attempts to act as a Rosetta Stone to over 200 awesome sources of concepts and methods used by service providers to successfully achieve outcomes, design and manage the customer experience using services, and managing costs. It is not positioned or marketed as a 'best practice' framework.
The USMBOK is in fact positioned as the 'ideal companion' to a frameworks such as ITIL, introducing important management philosophies and thinking such as customer centric outside-in.
Also, we need to stop pitting one source or opinion against another - what I have called 'framework wars'. It is not in the best interest of those we serve, our customers.
Each source is a valid contribution to the working set of methods any professional worth their weight in salt should use to address the challenges of today's IT organization, where they are being asked to be more of a service broker than an infrastructure manager.
ITSM has been polluted as a set of thinking, not by any one framework, but by a small set of practitioners. It has become rigid and stale to the extent some has suggested dropping the 'IT', not that would make a diference (!). We all need to respect ITSM is the application of service management thinking to the challenges of IT.
The sources for service management include many outside of IT. We should encourage a more open and vibrant conversation about what works and what doesnt, keeping the interests of the customer at the core of our approach.... shouldnt we...?
BTW: I forgot to state that the PAM Guide p.15 at the line just above the Inputs and Outputs heading is the place where it tells you that the following section is the Process Reference Model (PRM). It needs to be formally labelled as The Process Reference Model - it isn't and this inevitably leads to everyone ( including me initially), thinking that Enabling Processes is the Process Reference Model.
Thanks Geoff! As always, your contributions are highly appreciated and to the point!
Here is my answer to your question, Jan.
As you say the definition of Objective is: "Statement of a desired outcome". (see COBIT 5: A business framework for the governance and management of enterprise IT, p.92)
Each COBIT 5 process does have outcomes defined. These appear in the Process Assessment Model (PAM): Using COBIT 5 (the "PAM book") in Chapter 3 pp. 15-114.
e.g. For process DSS02 Manage Service Requests and Incidents the outcomes are:
DSS02-01 IT-related services are available for use
DSS02-02 Incidents are resolved according to agreed-on service levels
DSS02-03 Service requests are dealt with according to agreed-on service levels and to the satisfaction of users.
The Process Assessment Model (PAM) requires processes that are going to be assessed to be defined using a Process Reference Model (PRM) and a PRM must be conformant with the ISO 15504 Information Technology -- Process Assessment's viewpoint and that is what the PAM book does. This means Process Purpose, Outcomes, Base Practices and Work Products (i,e, inputs and outputs) must be defined for each COBIT 5 Process. Base Practices provide a detailed definition of the tasks and activities needed to accomplish the process purpose and fulfil the process outcomes. Each Base Practice is explicitly associated to a process outcome.
Now, if you go to the COBIT 5: Enabling Processes Book, I would say that the COBIT 5 Processes are defined using terminology that ISACA prefers to use - built on earlier versions of COBIT's approach, too.
In the Enabling Processes book, the 3 outcomes that I have just listed for the DSS02 process are called Process Goals and are word-for-word aligned with the outcomes in the PAM book.
The other point I would make is that what are called Base Practices in the PAM book are called Management Practices in the Enabling Processes book (or Governance Practices for the governance processes: EDM01, EDM02, EDM03, EDM04 and EDM05). Management practices are equivalent to what earlier verisons of COBIT called Control Objectives (NB. Control Objective is auditor terminology - since that was the reason COBIT first appeared 16 years ago).
Also, Activities (more detail) that are given for each Management Practice cannot be specified in a Process Reference Model according to ISO 15504.
So to summarise, what each COBIT 5 process has is: Outcomes that are supported by Base Practices that together define the objectives that the process has to deliver.
Or putting it in the Enbling Processes books's terminology: Each COBIT 5 process has Process Goals that are supported by Management Practices (or Governance Practices for processes in the EDM domain) that together are the objectives that the process has to deliver.
ISO 15504 has forced COBIT 5 to use lots of new terminology!
I suppose the this sum could rise even more after UK Govt. stake sale in ITIL...
That's great branding developed by ITIL...
Thanks @Larry. Yes, my point is that IT should work as a partner with the business, otherwise it can be outsourced.
@jan "The problem here seems to be that IT has made a relative mess of their performance" - yep.
Not sure @aale is sugesting it should necessarily be outsourced - only that if IT thinks it can/needs to operate as a business, it may as well be outsourced.
As I said, many orgs (new and old) are coming to the realization that all facets of their org needs to think less about carving out their own niche as a separate entity within the biz and think more about how they fit into the service chain of delivering valuye to the real client/customer. Internal results are meaningless if the end client/customer results are not met.
@Aale - that would mean that ALL supporting disciplines in an enterprise should be better off when they're outsourced: human resource management, finance, logistics, etc.
Are you serious?
And if not, why should IT be outsourced and HRM not. HRM also has only one customer... And facility management too....
The problem here seems to be that IT has made a relative mess of their performance. An escape to outsourcing doesn't seem such a good idea for a default response, given the fact (IMHO) that insourcers also make a mess of it.
Internal IT does things once for one customer, a professional service provider does the same thing many times. They have the opportunity to become very efficient as long as the customers are standardized. It is a strength and a weakness at the same time.
The IT-as-a-business idea was popular 25 years ago. Many IT organizations were set up as an company at least here in the Nordics. The motivation was what Derek explained. The result were dismal. The large outsourcing companies bought and dissolved these companies.
You forget one thing. A business relationship must include real competition, otherwise it is a monopoly. And a one-customer non-professional service company will lose every time it faces real competition. IT and business should be integrated, not separated. Agree with Larry.
Glad to see that there is some debate being generated here. To me, one of the key points is that IT should start treating its business partners as though they were external clients and offering services that those clients would choose to 'buy' from them.
i do agree with Larry's point that making a profit off its internal business is not going to win many friends but profit is not the key driver; improving services to the business is the key driver. If IT is profitable, it can choose to reduce price or re-invest in IT to improve services
Actually one of the blindspots of IT is that it thinks information techology is the only form of technology in play within a business.
More holistic views of technology are required as business isues have shifted from discrete problem sets to holistic messes - requiring holostic, networked, and collaboratuve approaches in order to resolve them. This is what is what is leading to the blurring of the organizational boundary lines.
The pace of change and the number of creative disruptions are also affecting the whole of the organization - not just IT. It isn't that IT does not have a place - it is that it will no longer make sense (IMHO) for it to continue to consider itself so much apart from the rest of the organization as this article would suggest.
In some of the newer organizations this is already happening - and in some of the older ones who have also figured this out. They are engaging across the whole of their organizations and are changing their practices to go with it.
"When IT tries to operate as a business, its drivers and motivators can easily become skewed towards what is best for IT and less so on what is best for the rest of the organization. "
I think IT already *IS* skewed and very fundamentally so. IT has been driven by technology opportunity since day 1. Half of the IT is there because it CAN, not because we NEED it. And that, for a large part, is also the fault of the technology- and gadget-horny customer.
Now, given the indisputable fact that most organizations have become completely dependent on their IT, how could an IT department NOT try to run its services like a business?
@Aale - Outsourcing may indeed have better results for some highly standardized services like cloud-based application packages. But why would a commercial provider by default offer better results than a competent internal department, with all its understanding of the business processes.
Outsourcing companies are drivern by financial results, because they're run as a business. Internal departments can deliver the same without that commercial drive. I'd say, they have the benefit, as long as they can deliver the same quality - or better (which shoulkdn't really be a problem!).
The idea that IT believes that it needs to create profits off its “internal business” is in my view where the above model is problematic. No other part of an organization thinks like this. It’s also interesting that IT is the only one that grabbed the moniker of “service provider“ for itself as well as talks about itself as needing to be aligned with the business. IT is special – just not in the way it thinks.
With the unrelenting pace of change all around us, cloud computing, the obsolescence of many traditional IT jobs, the business’ need for greater agility in all areas of its operations, the fact that there never really was anything such as an IT-only project, are all pointing to a very different future for IT than one where it can see itself as and try to operate as a business within the business.
IT had ample opportunity over the past twenty years or so to have carved out its place following the model of operating as a business – it failed, miserably. Many organizations today are looking to blur the lines between its different organizational groups, to flatten their operating models, and to have everyone (not just IT) be driven daily by and responding to new business capability needs – as a cohesive working force – not as IT, and HR, and Finance, and Marketing, etc , all operating in their own little worlds.
Outside-in is a good way of thinking – but that starts with the real customers/clients of the organization and works its way backwards through all of the internal groups to define their value delivery contribution. Again, when it is too internally focused, it can become skewed – you need to know WHY you are doing what you are doing and if it can't be related in some way to the customers/clients then you should question why you are doing it. There has to be a level of connectedness throughout the whole of an organization – all parts operating in synchronicity towards its goals while remaining adaptive and supportive of the organization's reason for being.
When IT tries to operate as a business, its drivers and motivators can easily become skewed towards what is best for IT and less so on what is best for the rest of the organization.
So in my opinion, over the coming years, the pressure on IT will be to become far less apart from the rest of organization, as opposed to more so, by trying to operate itself as a business and as a separate profit-centre.
Jan, I did not write those things ;)
The internal IT should work with the business and have same goals as the business. The model should be a partnership.
I think outsourced IT can be better in some ways, a lot depends on the business needs. If the business just needs some standard solutions, outsourcing is probably the right answer.
My point is that the value of having an internal IT is that you may have more flexibility in the relationship. A customer - vendor relationship is a barrier. I suppose that a really good outsourcing service provider can act as a business partner but it is not that common.
@Aale - so an internal IT department should NOT take accountability for their services?
They should NOT make sure they can deliver the best service at the lowest price, in the shortest time-to-market?
They should NOT be the best party to understand the business processes?
In general: do you think outsourced IT delivers better value to the business than IT delivered by an internal department?
I think that the moment internal IT starts to act like a business it is time to ousource it. Professional companies will be more efficient than an internal IT trying to play professional.
The strength of the internal IT is that it does NOT run IT as a business.
Management is ... standing up for your team
Management is ... finding the right competence for the job
Management is ... making your people shine