They can't be freekin' serious: twenty kilo-bucks for a set of ITIL process maps
In the fine tradition of Prada and Rolex, comes an ITIL IP provider who understands that the more you charge the more a minority of buyers will line up to pay for "the best". As a good capitalist I guess I should cheer them on but I'm afraid I just choke at the sight of a twenty thousand dollar pricetag for a set of ITIL process maps. No services, just a download. Well I never.
BTW, they actually provide quite a bit of nice free info on the site. I guess they can afford to.
Made in New Zealand 
Comments
Actually, it makes sense to me.
There's another way to view this - by the value.
The folks at ITIL didn't take the time to provide process maps with their documentation.
If a company actually needs the full set of process maps - and I don't know of many that would - the cost of hiring someone to actually do a good job of creating and validating such maps would be quite high.
35 processes x 3 - 7 days each (let's say 4 on average, depending upon the detail) all decomposed in UML (?) and delivered in Visio - although it would be better in a process tool.
The individual would have to already be ITIL trained - else there would be a lot more rework. So, at least $75/hour.
35 x 4 * 8 * 75 = 84000
It seems to me that in the case of those organizations that feel they actually need such documentation the value of such an investment is reasonable.
Our former employer - CA - is working hard to put together a set of "green books" that will be a comprehensive process description for the different pieces. HP is putting that together. For them, other vendors, and for consultants that actually believe such documentation is necesssary - it may, actually, be cheap.
27 processes????
Cary, Skep,
this is really getting out of hand. Any decent definition of "process" disqualifies the ITIL "chapters" as being processes. They simply are not. Most of them are procedures and functions (even according to the definitions that are adopted in ITIL). That's the reason why the ITIL process maps are still lacking after 20 years: they simply don't exist.
There actually is very little in the ITIL books on processes - but if you look carefully you can find plenty of value amongst all the pages, since you don't need to look for more than a handfull of processes.
So any company offering a set of 27 detailed process maps doesn't understand crap of what they are doing - or applies an exotic definition of the word "process".
Furthermore, since there actually are only very few processes in the ITIL books, it is easy and cheap to produce a detailed set of these true processes. When you apply your calculations to that, your reasoning will stick to a certain limit: buying a set of default detailed process definitions would save a lot of cost. But there would be no more than 6 processes that required documentation, so the sum would be much lower.
And the calculation goes wrong at another point: who would be interested in processes? Maybe 1 in a 100 of the IT staff would be... All others would only be interested in procedures. So unless you replace [process] with [procedure], your calculation doesn't stick in the end.
There's a detailed article on this in the new book that's launched next week at the Dutch ITSMF Spring Conference: http://www.itsmfbooks.com/product_info.php?products_id=413. It explains the difference between processes and functions and applies it to ITIL V2 and V3. There's also highly relevant stuff in there about the introduction of processes and process management in traditional line organizations, that explains how these essential processes can be organized in various cultures. If you follow that, your "ITIL projects" will suddenly be much much easier, and much more effective.
It's high time the consultancy world should stop inventing the wheel time upon time at the cost of the customer.
Caveat Emptor - again
As I said the first time - I can't see why many companies would want such maps.
As to process vs. procedure vs. function - such distinctions are for book writers. You say to-may-to, I say to-mah-to. I don't care, because each client has their own view of this and their own culture.
If competitive knowledge "publishers" wish to trash talk each other, please leave me out of it.
If a company offers a high-priced offering, and they're able to sell it to a customer - that's a transaction between them. And, it isn't my place to criticise either party - I must assume each found value from their point of view. Heck, vendors and the "prestigious" consulting firms regularly show up with a huge team of "consultants" and accomplish little more than installing software - one must assume the client gains the value they seek.
For me, ITIL - any version of ITIL - is a "good practice" reference - I take ITIL at its word. Nothing more. It is not law. It is not even a standard, at least not here in the U.S.
The goal is to help clients achieve actual improvements in their business: real improvements in service quality and/or real reductions in service cost.
I'm not in the publishing business. If ITIL, or for that matter any other reference (we use a bunch - USMBOK, Lean Six Sigma, Time-Driven Activity-Based Management, FullCost, TOGAF, CobiT, IAITAM BPL2, etc.) helps our client's particular situation - then that works for me.
Strict adherence to anything - ITIL, any non-standard reference, or even, a standard - that is not likely to actually result in real improvements for that client at that time (or in the fairly near future) is not of much interest to me for that client. We're in the business of helping our clients by providing evidence-based business results improvements that they can actually adopt, use and grow from - one step at a time.
Not convinced
Sorry Cary, I'm still with Jan on this.
Whether something is a process, function or capability is much more than a matter of different pronunciation. I know I have, and I suspect Jan has, seen many organisations waste time and money by making the category mistake of thinking everything in ITIL is a process. In many case it is a way of thinking that the ITIL community has to take the blame for. Ten years ago I thought we were doing good by getting people to think in terms of process, now I know it is the sort of thinking that can fatally undermine a service management transformation. Sooner or later somebody high up asks "What have you done with your xxxx,xxx dollars over the last year?" and the only thing anyone can point to is a flowchart. End of project, if not career.
Now you are right that the cost of these ready to go processes is a lot less than bringing in consultants, but bear in mind all the consultancies already have process diagrams in their briefcases. If you end up paying them to produce vanilla process maps that aren't specific to your organisation then you are being taken for a ride. They are something you would expect a decent consultancy to pull out on their first day on site. On the other hand if you want process maps that are specific to your organisation then a shrink wrapped solution will only reduce a small part of the cost.
I'm tempted to make a point about mistaking cost and value. Just because you have been charged a hundred consultant days for a piece of work doesn't mean that that is the value of the work. Equally reducing that 100 days to 10 days doesn't mean it is "better value" if the end result does not have intrinsic value. What it is worth is the extra value by which it improves the bottom line. Paying 20000 dollars for something that doesn't deliver at least an equal benefit to your stakeholders is a bad move.
Let me put it another way, whether I throw away a cent for no return, or a million bucks for no return, they are both bad decisions.
Value, like beauty, is in the eye of the beholder
"Let me put it another way, whether I throw away a cent for no return, or a million bucks for no return, they are both bad decisions."
I say the person paying for something gets to decide what value is.
You miss my point. I apologize for being to subtle.
I don't ever engage in judging others for the value they see in a transaction - it is of no use to me. I take my clients as they come and seek to help them with the changes they sincerely wish to make. If someone else wants to spend their money on whatever, I must assume they have reached a fair bargaining point.
For instance, I would (and have) paid quite a bit to sit up close for Eric Clapton. I received value, my version of it. And, I would do it again. Others would think such an expenditure silly - but they might pay for London Symphony, or Snoop Dogg.
As to function, process, procedure or whatever. I just don't see a lot of clients going through the process of creating and documenting company-wide architectures. It's a great idea, no doubt beneficial, I just don't see it a lot.
Perhaps it's just a perspective from my clients - I've only been responsible for implementing a few over 400 ITSM and ITAM clients for Peregrine and CA.
When I was getting my Doctorate in Organizational Behavior one of the many things I learned is that it is most often disastrous for organizational changes to be driven top-down -without the necessary buy-in of the people being "changed." Systems-driven, architected organizational change might work for some. It seems that, mostly, companies are organized around a bunch of other factors too.
There was a movie recently - Wedding Date. In it one of the propositions is that women have the love life they want. Too glib perhaps. But, it seems to me that management, including IT management, has the systems and structures they want. If they want big change, really want it, then they can have it. David Maister does a great thing on this with his, "Strategy and the Fat Smoker."
Let's agree to disagree on this. I just think client managements are generally fairly satisfied with their current way of doing business. Else they would change. If they really want to make a change, they will. If they want help, it's out there to be had.
I'm just not going to second guess smart people after the fact. One man's Clapton is another's Snoop Dogg.
Musical taste
Cary,
I thought it was fairly obvious that I was arguing an extreme case to get a point over ;-)
There are an awful lot of ways of putting a value on something, depending on who you, where you stand in relation to the investment, where you come from and where you hope to be going. A wise approach to investment decisions takes these multiple perspectives into account. The view I was taking, was that the person paying for the investment is ultimately the business, not the IT department.
It isn't always easy. To take your music example imagine that my family has a spare £30. I would spend it going to see Van Morrison, my partner to go and see Russell Watson. Eldest daughter would see James Blunt. Other daughter would go and see some R&B diva, and the son would go and see some band with dodgy dress sense. Snoop Dog is out of the question because he is currently banned form the UK. As a family though, we would compromise. Since we will never agree on music that would probably mean going to the cinema instead to see a film we could all enjoy.
A book I would highly recommend, though sadly no longer in print, is Daffern & Walsh “Managing Cost Benefit Analysis”
As a consultant I consider my first task is to ensure the client understand what their real requirement is, and to help them identify what they are capable of achieving. This differs massively from client to client. Now I am an independent I also have the choice of walking away from clients who I do not believe are committed to the change they claim to be seeking. Within that framework I accept that different clients want different outcomes.
I do see a lot of clients going through large scale transformations, probably because in recent years most of my work has been around service management for organisations that are about to outsource, or who have outsourced and run into big problems. Note this is cultural change stuff, I don't touch the technology side beyond service management tool sets.
400 implementations is pretty impressive, especially if they included cultural change.
Are clients management generally fairly satisfied with their current way of doing business? Hmm, I don't know, perhaps it depends on who you ask, and how far you push them for an answer. My experience is that a lot of IT shops don't understand that the low expectations the business has come to have of them.
Incidentally returning to the start of this thread I should make clear that I do believe process maps add value if you are looking at call/incident and request handling, and in a lot of areas of service transition. It is there application to other areas I am questioning.
all amatter of the circles you move in
Carey
The ITIL client commnity is huge. Your perspective with CA and Peregrine clients is the top end of town. Your clients'management are probably at the top end of the range in nouse and awareness. there are amillon others who don't understand much about ITIL or pocess in generl they are technical folk. Every community takes steps to protect its members from their own ignorance or stupidity. Caveat emptor is a warning for buyers not an excuse for vendors
Just the other day Sharon taylor blogged on ITSMWatch about how wonderful the uptake of ITIL3 is. The same day I discussed with a group of ITIL users about how nobody gives a toss. It is all amatter of the circles you move in. I'm bettng it has been a while since Sharon met anyone from outside the FFortune 500 and the sample would be selfselecting from those who are intersted i ITIL3. i think she needs to get out more
P.S the typig is due to a crppy cafe keyboard - i am in Amsterdam but I did not have the Happy Beakfast
LOL - Caveat emptor is a warning for buyers not an excuse for ve
Caveat emptor is a warning for buyers not an excuse for vendors.
How true.
But, for me, I stick to my knitting. I can only control my own actions and it's best, at least for me, to not judge others.
I practiced law for a while, from that experience I learned the severe limits of advising. As a consultant, one can only advise their client - one cannot control them. It is folly to try. They must make their own changes, all we can do is help guide them.
In the more than 20 years of implementing ERP systems and then ITSM/ITAM I've learned one really important thing - focus on the individuals in management. Technology is not much of a determinant of success; neither is theoretical processes or organization. Senior management's leadership (not management) ability and their team's management ability is the single most important determinant of success or failure.
Because, after all, as Peter Drucker wrote, "The productivity of work is not the responsibility of the worker but of the manager."
As Admiral Hyman Rickover put it, "Good ideas are not adopted automatically. They must be driven into practice with courageous impatience. Once implemented they can be easily overturned or subverted through apathy or lack of follow-up, so a continuous effort is required."
jumping to solutions = jumping to conclusions
I can think of a few excellent reasons why an organization would want to have a process architecture and why it would want to understand the process model. A major reason would be that if you understand your processes, you can derive your procedures from them in a consistent way, which has plenty of benefits, not in the least the fact that it brings you consistent and straightforward procedures. If you jump to the level of applying frameworks that lack a process architecture, then you shouldn't be surprised if the result is of the same quality. Unless you have your own process architecture, that you use to embed the bits and pieces from the frameworks in. But then again - that would mean that you DID use a process architecture...
My statement: anyone jumping to frameworks jumps to conclusions - and we all know the problems that come along with that.
I consider the lack of understanding of the difference between processes and functions one of the main reasons for the failure of many "ITIL projects". And that's actually not the fault of ITIL, but of the people that use ITIL to play organizational change agent - a discipline that often has been highjacked from organization experts by IT experts with a technology background. Why should we wonder this goes wrong so often?
Absolutly
It continues to amaze me that orgainsations pay good money to try and build process maps for everything in ITIL. It is not just the cost of external advice but also the oppourtunity cost of having their staff discuss a visio or aris diagram rather than gettign out their and managing and changing things for the better. Worse still is that consultancies see nothing wrong with selling sucha pointless service.
There are very few things that need to be treated as processes, and most of the process definition can be done as part of building the workflow into the service management toolset.