What is the best ITIL V3 or ITSM tool?
We go round this question every week on LinkedIn. My answer is getting pretty well honed.
1) You know what tool you need (or rather you know a shortlist) if you've done the process reengineering/improvement.
2) Get an expert to help with the processes.
3) Don't listen to anyone who only recommends one tool. ITSM tools all work, depending on your requirements (see 1). Anyone who says one ITSM tool stands out (a) only knows one tool or (b) has a vested interest in that tool
4) Don't buy tools on feature/function. That's the criteria for buying toys. Buy tools on fit to requirements (see 1), vendor and price.
5) You cannot buy an ITIL, despite what BMC tell you. ITIL is about transformation of existing culture and processes: you can't get that in a box, that's vendor bullshit.
6) You don't want to buy an ITIL. You want to achieve some goal with identifiable ROI. Along the way to that goal you may need to apply some ITSM principles. ITIL may be a good framework to help guide you in those principles (or not). ITIL is not an end in itself.
7) Technology. Does. Not. Fix. Process. Say it aloud.
Still want to start by buying an ITIL tool? Still believe you can buy an "ITIL solution" from a software vendor? Please send me the million dollars and I'll send you some spreadsheets and an Access database that will do the job just as well as any vendor can without requirements, process improvement program or cultural change program. You are not competent to be holding that money anyway.
See also
Made in New Zealand 
Comments
...and the best ITIL tool is...
1. A4 Counter Book
2. Bic pen
Honourable mention:
- Notepad.exe
- Post-it Notes
I wrote about this topic here: http://thinkingproblemmanagement.blogspot.com/2008/07/flawed-itil-aligne...
Please stock up the IT Skeptic shop
Skep, please stock up the IT Skeptic shop with the above stock. (even get them pink-certified?)
process compliant
I don't think the Bic pen is process compliant: it has no data storage
BiC perspective
Actually - it has PLENTY of storage. You just need to develop a writing process to retrieve it.
Well, I have a friend who's
Well, I have a friend who's a middle-IT manager in the UK. He's who is in the middle of a journey to grow in size & "implement ITIL v3". We drank a few bottles of red the other night. Poor guy - they're committing all of the 10 deadly sins.
1) Try to "buy ITIL" out-of-the box from a toolset vendor (who think that adding Request Fulfilment makes their tool v3 and Learning = knowing what the buttons in their tool do). Check.
2) Do all of this based on a suspect business case that nobody really remembers who authored. Check.
3) Create a project team of external consultants who are governed by themselves, pay themselves and create funding requests for themselves. Check.
4) 6+ months in, no coherent communications strategy, end-to-end project plan. (but lots of confusing powerpoint presentations) Check.
5) Day-to-day Ops excluded from strategic, design and implementation decisions. Check.
6) Project Team & Human Resources Department unhappy with shotgun wedding. Check.
7) Loads of Prince2 chatter but not alot of real work. Check.
8) CMDB centre of the universe but nobody really knows why. Check.
9) Project team & Ops starting to play "blame ping-pong". Check.
10) Project plans, deliverables etc are "confidential to the central project team". Check.
He's doomed I tells ya.
Any suggestions on what he should to do from here? (besides run, keep running & don't look back)
when the going gets tough, the weird turn Pro
better switch to something stronger, and quickly! His desire to implement the Guidance is likely to drive this death march into more and more wickedness... unless he's ready for the Savage Journey, he will surely regret it. Forget about cultural change, I think his organization's ready for the revolution.
viva ITIL!
and remember, when the going gets touch, the weird turn pro
John M. Worthington
MyServiceMonitor, LLC
well
well actually this guy is having ITIL "done to him".
I honestly pity his situation.
the unremitting grind
Yes we consultants and especially we online pundits are real good at saying "you must" "you should" "it is essential that" but it's all bullshit really. The real world simply doesn't work like that. 90% of organisations work like your friend's.
I had this conversation just yesterday about the unremitting grind of working for a dysfunctional org. His options are:
1) turn to drink or drugs
2) give up, get cynical, and try to have as much fun as he can
3) push really hard for a really long time in the hope that he can deflect the battleship two degrees to port
4) search long and hard in the hope of finding one of those 10% of organisations who have their s*** together. In the meantime fix as much as he can so as to learn as much as he can
5) scrabble up to the CEO role and make a real difference
P.S. I just loooove your 10 deadly sins. Brill.
10 sins are real...
That is the scary thing. They are all real things that are happening.
It gets worse. Looking back, Consultant A used to work for a big integrator of Toolset A. This guy did an "independent" analysis of the incumbent toolset "B" and ascertained that it was sub-standard. He also did an "independent" analysis of their merger candidate's toolset "C". That wasn't up to scratch either. So he wrote the RFQ specs, stacked the evaluation panel with either meek and mild ops people or people on his payroll. No surprise Toolset "A" came out of the clouds and won the RFQ.
And this joker, working for himself has been collecting 100 quid an hour for his time and has the guy "in charge" of all of this thinking that Consultant A is absolutely indispensible.
Not good at all.
where medicine was
not good and not uncommon. IT consulting is where medicine was about two hundred years ago. The funny thing is, leeches turned out to be a good idea
Do you read my hard disk?
Rob
I have an unpublished article for Jan's ITSM Portal. It starts like this.
Best Practice and leeches
Let’s be honest. We ITSM experts are just as good as the 18th century physicians. We know a little but we cannot distinguish knowledge from superstition. Most of our results come from common sense (if we have it), good bedside manners (if we have them) and authority brought by our certificates (yes, those we share).
Aale
I hate it when that happens
haha I hate it when that happens. i have over 40 unpublished posts awaiting finishing (contrary to popular opinion this isn;t the only thing I do) so guess how often i take a hit like that? :D
Snake oil
I do worry that sometimes we might be no better than sellers of snake oil.
That is why I'm fairly certain that we aren't!
Consultants
My opinion of the current crop of ITIL consultants isn't high, but then I've blogged on that.
What is lacking so often is any realisation that people have been doing ITIL, and making mistakes, for years, and that you could learn from those mistakes.
Instead everyone ties to do it based on what "should" work according to their understanding of the theory, which is often sketchy at best anyway.
Incidentally am I alone in thinking it is foolish getting the firm who are going to do the consultancy to also do your ITIL assessments?
I've thought before know of selling some sort of ITIL project health check to protect people from just this sort of situation.
Assessing the Assessor...
James,
It's not foolish -- not one bit!
In fact, I think it would be worthwhile to have two independent assessments before going to RFP to do remediation or start an initiative. If two teams (unaware of each others conclusions and recommendations) came up with similar conclusions, that could be used as a targeting system (of sorts) to focus in on what the issues are more effectively than just trusting one source. It works (generally speaking, anyway) in medicine and is very uncommon in ITIL/ITSM-land. That's also not to say that there wouldn't be challenges doing it.
The only insurance a customer has against potential misuse/abuse of the assessment process by the provider is to act smart. How? By taking some simple actions, such as:
There are other factors to consider that I work through with my customers, but I consider these to be big enough to discuss constantly. Anyone that doesn't address these items should prepare to get fleeced.
kengon
Pass to space
I believe I understand what you mean with item 4, but also believe that buying tools to currently understood requirements may create problems later.
Risk to projects does not usually arise from technical failure, but from a steady drift in intent, often caused by increased knowledge, which persistently widens the gap in expectations between the technologists and their customers. Simply put, as you and your customers implement, you learn, and the technology chosen when still ignorant may not satisfy later needs.
Once acquired and implemented, however, sunk cost, status quo biases, and just plain loss of face, will keep people with a tool that has little capability and fails to meet their needs. They would rather do more tailoring to the tool or add on more tools to supplement (often at greater cost than reimplementing with a better tool) than admit to their original error - rather like buying an off the rack suit and paying much more for the tailoring. How many companies do you know that have ITSM technical support staff greater than ten working constantly on improvements?
Yet, customers rarely use more than half of the OOB functionality of an ITSM tool.
Processes don't do work, people do. Good technology can help. And, a good process helps, although the process should be constantly change for the better but so often gets ossified by poor implementation of the tool. What really matters is consistent, reliable execution of a good, but not necessarily perfect, process. Realized benefits are primarily an outcome of good management and not necessarily the best technology or process.
Cary King
Minerva Enterprises
Managing Partner
www.MinervaE.com
What is the answer?
(Most of my past clients have had ITSM staff of zero unless you count underlying operational tools.)
Good point. What is the solution to the very valid dilemma you present? How does one choose for the future? [Patrick Bolger used the phrase "sufficient process headroom" on a LinkedIn thread. I think that comes back to point 2 - have expert help]
And specifically in ITSM does it really matter? is there that much difference between service desk or SLM (or catalogue?) tools?
In some cases, a lot of difference
There is, actually, quite a bit of difference amongst the tools. Not for Incident and Problem, of course. Or even in the Change risk management cycle. That's where most look when they are beginning, and that's where they often get stuck.
Since you bring it up, the service catalog is a good place to look for differentiation. Does it help with actual actionable management of service requests - and fulfillment of the associated work breakdown and job routing - or does it just take requests? How hard is it to add new requests and the associated fulfillment activities? Does it help you implement Lean and Sig Sigma measurements? Does it help you collect time-driven activity-based costing information?
SLM - does it just report on past happenings like an accounting system - too late to do anything about it except get whipped at the next monthly meeting? Or, does it help your staff understand when the cumulative OLAs and likely times will cause a failure - so you can make the "were not going to make it" call early?
Services and Assets are on a separate life cycle but account for more than 50% of your costs. Does the system hook with Asset Management and Procurement so that good financial management is more likely? Does it hook to the AM and Procurement pieces enhance the possibilty of reaching something like a CMDB?
Will the customer have to architect many products together? Can they afford that? Or, is it one product that can be easily tailored with standard language (e.g., Jython)? If the company is really big, then it may not matter because they can afford the best. If it is a company of 10,000 employees, or less, it may matter a lot.
The solution? Instead of focusing on your current, perhaps narrow, view of requirements, go with something more general. Acquire the ITSM equivalent of a minivan. Then get truly expert individuals (not the junior staff sent by the big consulting firms) to help you discuss and triangulate your needs, your wants, your value, your processes and the technology implementation. Keeping in mind that people and processes are 75% of the deal, and technology a supporting 25% - no matter how hard that is for IT people to acknowledge.
Best to assume that your organization will grow to use these other pieces over time. Actually, we ask our clients to set a vision - then manage Service Management like products with releases every 4 to 6 months. The big project and then nothing approach doesn't work well because management doesn't seem to focus attention on the problem again until things are in bad shape.
Think through the decisions that are likely coming your way over the next five to ten years and how you will support them - Virtualization and that consolidation, new software licensing models and software increasing as a percentage of your spend, Cloud and that consoldation, Thin Clients, more bobile equipment, more storage, more outsourcing, more standardization, etc. How will you manage the likely transition to using significantly more amounts of outside services?
Think through how you will manage the likely transition from being the end-to-end producer to the new role as steward for the enterprise's information resources acting as prime contractor with lots more subcontractors? How will you develop evidence of what your current services are and what they cost - so you can make rational decisions about "buying" outside services? If you don't, won't the CFO just go on his gut decision that's influenced by the vendors who are now talking to her instead of you?
I'm reminded of the quote from Eric Shinseki, then Chief of Staff of the U.S. Army, "If you don't like change, you're going to like irrelevance even less."
Pick a tool that will support that change. Pick a tool from a vendor that will help your organization grow into success with that new role. Play the ball into space. Pass to where you're gonna be, not where you are now.
Look forward, not backward. As Peter Drucker wrote, "The best way to predict the future is to create it."
Cary King
get professional help
Great summation Cary, thankyou.
So summed up: get professional help. You need to know what you don'rt know and to see what you can't see in the future.
Re 75% people/process, 25% technology, a tech from a major vendor said on twitter "Humans are awful at process. Technology is awesome at process. That's you ITIL and ITSM folks screwed then." Sad, I thought we were maturing beyond that.
Wow... really... Humans are awful at process?
I can only imagine who tweeted that comment. I get beyond the academic, philosophical and theoretical definitions of what a process is - and it comes down to this; A process is how people and poeple, or people and systems, or systems and systems are supposed to work together. The actors in a process can be thinking human beings, or systems.
Technology does not make the process, technology is what supposed to automate the process. Therefore the measures of purchasing technology to for process sake, become how much more does technology make a process effective and at the same time efficient and cost effective.
The problem with a lot of tools in ITSM is they are effective (they can pass the OGC and Pink tests), but when they take considerable time, money and effort to modify, change, upgrade, (read continually improved) etc. then the potential efficiencies are lost. Business people get this, I think Technical people sometimes miss it... When I hear of IT organizations spending $6mm to implement Incident and Problem management, I have to ask; Will the company be better off because that $6mm was spent? Could a LOT less been spent to acheive the same outcome?
(Answers; NO, YES)
John M. Clark
And the best one is...
The one that:
It is... the one between your ears -- your brain.
If you don't use that one, you'll be in a big pile of dung trying to sort out all of the "technology solutions".
Think about it! Is that too much to ask?
Ask not what the tool can do for you...
...but what you can do with the tool.
In my recent experience even a mid market ITSM toolset is capable of doing a lot more than most IT departments are capable of deploying