<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://www.itskeptic.org"  xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
 <title>The IT Skeptic - Comments for &quot;The Service Delivery Tool gap?&quot;</title>
 <link>http://www.itskeptic.org/node/105</link>
 <description>Comments for &quot;The Service Delivery Tool gap?&quot;</description>
 <language>en</language>
<item>
 <title>OK w/ the Gap</title>
 <link>http://www.itskeptic.org/node/105#comment-482</link>
 <description>&lt;p&gt;We do agree more than we disagree. I had for some time been evangelizing a &#039;service delivery&#039; approach to ITSM in fact. However, I found it only increased people&#039;s focus on tools in &#039;ITIL boxes&#039; is where I was coming from. I think that folks need to evaluate tools the old fashioned way (by truly knowing your needs first).&lt;/p&gt;
&lt;p&gt;Perhaps I got lost in the zeal of the skeptic&#039;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.&lt;/p&gt;
&lt;p&gt;Take the payback example. You could implement what you feel is categorized as a &#039;delivery&#039; 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!&lt;/p&gt;
&lt;p&gt;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&#039;t look for vendors participating in the &#039;ITIL space&#039;) if they&#039;d find a solution right in thier own back yard.&lt;/p&gt;
&lt;p&gt;John M. Worthington&lt;br /&gt;
MyServiceMonitor, LLC&lt;/p&gt;
</description>
 <pubDate>Fri, 16 Feb 2007 13:27:33 +0000</pubDate>
 <dc:creator>John Worthington aka MySvcMon</dc:creator>
 <guid isPermaLink="false">comment 482 at http://www.itskeptic.org</guid>
</item>
<item>
 <title>The Service Delivery Tool gap?</title>
 <link>http://www.itskeptic.org/node/105#comment-481</link>
 <description>&lt;p&gt;Dear IT Skeptic,&lt;/p&gt;
&lt;p&gt;Me thinks thou doth protest too much. &lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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).&lt;/p&gt;
&lt;p&gt;Cheers,&lt;br /&gt;
Mike&lt;/p&gt;
</description>
 <pubDate>Fri, 16 Feb 2007 11:56:43 +0000</pubDate>
 <dc:creator>Mike Drapeau</dc:creator>
 <guid isPermaLink="false">comment 481 at http://www.itskeptic.org</guid>
</item>
<item>
 <title>there are ITIL process tools</title>
 <link>http://www.itskeptic.org/node/105#comment-474</link>
 <description>&lt;p&gt;Hi John&lt;/p&gt;
&lt;p&gt;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&#039;t fit in an ITIL box.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;The writers&#039; 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.&lt;/p&gt;
</description>
 <pubDate>Fri, 16 Feb 2007 04:11:15 +0000</pubDate>
 <dc:creator>skeptic</dc:creator>
 <guid isPermaLink="false">comment 474 at http://www.itskeptic.org</guid>
</item>
<item>
 <title>ITIL tools?</title>
 <link>http://www.itskeptic.org/node/105#comment-473</link>
 <description>&lt;p&gt;I understand why we want to put tools into ITIL boxes (such as Support/Delivery, etc.) -- it&#039;s easier for us to process --- but I&#039;m not at all sure that simply because of &#039;ITIL&#039; the tool game has changed. In fact, I think the more things change the more they stay the same.&lt;/p&gt;
&lt;p&gt;While I could suggest that Service Delivery processes are technically considered &#039;tactical processes and Service Support processes &#039;operational&#039;, I think it would serve no useful purpose and only exacerbate this rant, so consider this...&lt;/p&gt;
&lt;p&gt;Isn&#039;t it ironic that one of the most important technologies for SLM is &lt;em&gt;monitoring&lt;/em&gt; (as stated in the Good Book)  but in many organizations &#039;monitoring&#039; is considered the perview of the &#039;infrastructure guys&#039;? In reality, it&#039;s SLM who is the primary customer/user of monitoring (after all, we&#039;re monitoring end-to-end services in ITSM-- not elements anymore, right?).&lt;/p&gt;
&lt;p&gt;I think all of us (me included) who put tools in ITIL boxes do us a disservice. The tool game hasn&#039;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?&lt;/p&gt;
&lt;p&gt;As far as the Big Four, the big gorillas&#039; &quot;vision&quot; is compelling, and I&#039;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. &lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Show me &lt;em&gt;that&lt;/em&gt; (on something other than a powerpoint presentation), and I&#039;m a believer. Most of what I&#039;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 &quot;really works&quot;.&lt;/p&gt;
&lt;p&gt;So, which &#039;ITIL box&#039; 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&#039;ve both reduced your risk AND will likely solve some problems along the way, even if you do eventually drink the gorillas&#039; kool aid. &lt;/p&gt;
&lt;p&gt;Am I halucinating? If so I am not alone and enjoying the trip. So, is &#039;monitoring&#039; Delivery or Support?&lt;/p&gt;
&lt;p&gt;Frankly scarlet, I don&#039;t give a damn.&lt;/p&gt;
&lt;p&gt;John M. Worthington&lt;br /&gt;
MyServiceMonitor, LLC&lt;/p&gt;
</description>
 <pubDate>Fri, 16 Feb 2007 02:28:36 +0000</pubDate>
 <dc:creator>John Worthington aka MySvcMon</dc:creator>
 <guid isPermaLink="false">comment 473 at http://www.itskeptic.org</guid>
</item>
</channel>
</rss>
