The Service Delivery Tool gap?

A recent article raises the interesting question of why there are far more Service Support tools than Service Delivery tools. The IT Skeptic knows why. The underlying assumption of the article that I would skeptically challenge is that there is a role for Service Delivery tools.

Here is an article that raises the interesting question why there are far more Service Support tools than Service Delivery tools.

The article concludes "the lack of powerful and highly touted tools for Service Delivery is a natural consequence of the process definitions and the current marketplace." I don't think so.

I believe the germ of the answer is in the article: "Service Support processes are more tactical in nature while Service Delivery processes are more strategic."

Service Delivery processes are strategic: they can be run on a Word document. As the article also says, there is a need for Knowledge Management to help with that. But not ITIL Knowledge Management: there is no specialist need beyond standard Knowledge Management tools, and everyone seesm to sell one of those these days.

There is a place for point solution tools within each of the Service Delivery processes: service level measurment and reporting, asset register, backup and recovery automation, network and systems performance database... These are well served already by available technology. The article says "few are directly tied to IT Service Catalogs and fewer still to a CMDB ... there are none that cross all the technology domains and also none that roll up their information to assist in developing the ITIL-required Availability Plan". Perhaps the authors are more demanding of software than the IT Skeptic, unlikely :-), or perhaps they haven't looked at the Big Four lately (BMC, CA, HP, IBM), but I would have said those guys covered most things pretty well and roll up to a service view pretty well (as much as can be done by a tool).

But the article looks for a tool for the whole process: "they do not cover any of the other many attributes and requirements of the overall ... process (communication, coordination, documentation, strategic planning, etc.)" The bits of any Service Delivery process that need automating have tools available already. The rest of it is process. It is not a technical problem so there is no need for a technical solution. Tools can't do strategic thinking (perhaps more modelling tools would be good to support that thinking process, but this is point solutions again).

As I have said before: People Process Things, in that order. Technology exists to make process better, where it can. If the process does not need technology, or if the process cannot be done by technology, then don't assume there is a one-to-one mapping from every process or function within a process to some piece of technology.

Vendors can't sell strategic process tools because strategic processes don't need technology solutions.


The Service Delivery Tool gap?

Dear IT Skeptic,

Me thinks thou doth protest too much.

I appreciate your criticism and actually even mostly second it. I think that in this blog post you also find as much to agree with in my article as not. Stepping way back from the details of my article, my goal was to introduce some reality into the ITSM software automation/enablement industry to get the vendors to start ‘taking credit’ for sweeping ITSM support where it does not exist. Caveat Emptor. I think that the challenge of better automating the various Service Delivery processes is probably not as great as that of the Service Support ones because, as you indicate, KM systems already exist. I think, though, that eventually there will be a market for ITIL-specific KM implementations.

Organizations have a hard enough time as it is in developing, maintaining, and frankly using the artifacts of their strategic planning. They would be better served if this aspect of the 5 Service Delivery processes was enabled through software. Such a capability might include workflow, document templates, and other KM management features – all with an ITIL flavor. Furthermore, with the advent of the life cycle focus and features of ITIL v3, the need for a document management ‘system’ will increase and this tool gap (with or without quotation marks) will increase.

So, I take your point that the order of priority is People then Process then Things (tools). I hope my article did not give any other impression. Yes I have seen what the big 4 system vendors have in the way of Service Delivery tools and I am not overwhelmed. My lament is that I believe there is a need for better software support of the Service Delivery suite, that the software vendors are under-motivated to meet this need because the payback is not as demonstrable as it is for the Service Delivery processes, and the vendors most suited to meeting the need (i.e. the bevy of Knowledge Management vendors) do not even have ITIL on their radar screens (as of yet).


OK w/ the Gap

We do agree more than we disagree. I had for some time been evangelizing a 'service delivery' approach to ITSM in fact. However, I found it only increased people's focus on tools in 'ITIL boxes' is where I was coming from. I think that folks need to evaluate tools the old fashioned way (by truly knowing your needs first).

Perhaps I got lost in the zeal of the skeptic's blog (which is why I like it). We are indeed on similar pages. My only concern is that it is needs --- not ITIL boxes --- that should be driving decisions.

Take the payback example. You could implement what you feel is categorized as a 'delivery' tool, however the ROI drivers can come from all parts of ITSM --- particularly service support. If there are no ROI drivers then I would question the need!

I understand the tremendous opportunity for workflow, document management and there are a number of vendors that could be in this game...I just wonder if people looked at needs (and didn't look for vendors participating in the 'ITIL space') if they'd find a solution right in thier own back yard.

John M. Worthington
MyServiceMonitor, LLC

ITIL tools?

I understand why we want to put tools into ITIL boxes (such as Support/Delivery, etc.) -- it's easier for us to process --- but I'm not at all sure that simply because of 'ITIL' the tool game has changed. In fact, I think the more things change the more they stay the same.

While I could suggest that Service Delivery processes are technically considered 'tactical processes and Service Support processes 'operational', I think it would serve no useful purpose and only exacerbate this rant, so consider this...

Isn't it ironic that one of the most important technologies for SLM is monitoring (as stated in the Good Book) but in many organizations 'monitoring' is considered the perview of the 'infrastructure guys'? In reality, it's SLM who is the primary customer/user of monitoring (after all, we're monitoring end-to-end services in ITSM-- not elements anymore, right?).

I think all of us (me included) who put tools in ITIL boxes do us a disservice. The tool game hasn't changed; where is your pain, where do you spend the most money, and what will the tool do to stop the pain, reduce costs and save you the most time?

As far as the Big Four, the big gorillas' "vision" is compelling, and I'm not one with the technical expertise (or desire) to argue the merits of thier wisdom, but I do know that a vision can be very similar to a hallucination.

Take monitoring. The key to effective monitoring is the ability to monitor what is happening at each layer of the infrastructure --- across an array of distributed network, system and application components --- and automatically identify which component layer, in which domain, is the source of the problem.

Show me that (on something other than a powerpoint presentation), and I'm a believer. Most of what I've seen involves shifting staff to maintaining correlation rules, purchasing appliances, limiting the correlation to network/systems and a very long wait (and $$) to see if it "really works".

So, which 'ITIL box' do you want to put that in? The data mined from this kind of monitoring is service reporting data (SLM), but the intelligence directly benefits Incident/Problem Management. In fact, if you can conduct a feasibility study (via SaaS -- try that big gorilla) then you've both reduced your risk AND will likely solve some problems along the way, even if you do eventually drink the gorillas' kool aid.

Am I halucinating? If so I am not alone and enjoying the trip. So, is 'monitoring' Delivery or Support?

Frankly scarlet, I don't give a damn.

John M. Worthington
MyServiceMonitor, LLC

there are ITIL process tools

Hi John

Yes many tools fit at points in the process (asset financial management, capacity modeller); and others are general tools that support multiple processes (systems monitoring, asset register) and so they are not ITIL process tools per se. As you say they don't fit in an ITIL box.

But there *are* ITIL process tools, e.g. Change Management (real tools with workflow management and embedded process, not just change ticket register) or Service Level Management (define catalog of services with SLAs, provision services, monitor alert and report SLAs) or obviously Service Desk.

The writers' expectation was to find a similar all-encompassing Availablity tool or IT Service Continuity tool ... and my argument is that they are not needed because the strategic processes do not lend themselves to automation.

Syndicate content