Some ITSM technologies are a no-brainer

So there we all were brow-beating this poor guy on LinkedIn because he asked what other Remedy options he should buy [without much idea of any business requirement]. I too put the boot in, but on reflection I realised we were all being sanctimonious and patronising.

There are a few ITSM processes that almost certainly end up needing an underpinning technology.

1) Service desk/request /incident cannot be effectively managed without a tool.
2) Nor can change. People struggle along with a spreadsheet but really you need a tool.
3) I think CMDB is a load of crap, but you do need an asset list to link to incidents and changes.
4) Every ops team needs a central monitoring console to consolidate messages from the environment and automate alerts and notifications (and usually automate responses too, and sometimes auto-create incident tickets). If you are not auto-alerting then it is just a pointless gadget. (This also implies that you have underpinning network and systems monitoring tools!)
5) Everyone should monitor end-user experience at the desktop. I think it is a given.
6) It is a huge manual task to track and report service availability, system performance and human response so a tool almost always pays off for service level reporting too.

These six I think are givens in every site. (Did I miss any folks? Tools that truly are essential everywhere).

[Update: I agree with Tom (see comment below) about:
7) AV
8) Software distribution and patch management
I don't agree that access control and knowledge management are no-brainers. Inexplicably, huge numbers of orgs seem happy to use Microsoft's or Linux's colander-security. And much KM is rubbish - it must be done well to be worthwhile. ]

And they all do the job pretty well across the major vendors. I'd be choosing on vendor, support, community and price not feature/function.

But if you just buy the tool then only the vendor will be happy, nobody else. You need to address people/culture, roles/responsibilities, process/procedures/work-instructions, and tool implementation, for any process.

And no I don't think Catalogue is a no-brainer: not all organisations will find a catalogue software technology useful. Unless you count MS-Word.


Trying to figure out when CMDB crosses the line


You are ok with an integrated Asset tool to which Problems and Changes can be linked...

Are you OK with that Asset tool containing Applications as well as Servers? For example? (Considering Applications as a sort of logical Asset)

Would you be OK with those Applications being mapped to the Servers? (Many to many relationship)

If all of that is OK, I think you do support at least minimal CMDB. And it's not that hard or expensive to get to.

Charles T. Betz

if there is ROI

An asset tool is just a list. The relationships are the hard expensive bit. If there is ROI, go for it. And if there is ROI, welcome to the 5% Club.

Just to clarify some CMDB questions

So, you are saying that only 5% of organizations would see ROI in the basic mapping of applications (not even going to a "service" concept) to servers.

Let's consider the likely cost of this. First you would need, not a general purpose CMDB, but at least three tables in a database. You've already said that the Asset table is OK. I myself have seen many organizations of many sizes also have an "Application" list. Relating servers (between one to ten in smaller shops) to a given application takes (in my experience) on average an hour of SME work to baseline (perhaps with support from an analyst, so 2 hours total) , and perhaps an hour a year (combined) to maintain. These are conservative, by the way; most can be done more quickly.

You also have some marginally increased costs on the Asset tool but I think these are negligible.

These 3 hours a year need then to be balanced against

1) the requests that the SMEs would receive in the absence of this data being collected and maintained,
2) the risk that is run in NOT understanding application dependencies in the event of Incident or Change (remember, without doing this you only understand that you are changing or troubleshooting a server, not even the application running on it)
3) the value that might be lost from not tracking this data over time and using it as an accurate input into IT Portfolio decisions

Of course, if you have an Asset tool that is integrated with your Incident and Change systems, it likely is more robust than just a list. "Related Asset" was a Remedy construct before the CMDB concept came into the picture. I think I have seen it in pretty much all the related tools.

Now, terminology may be hanging us up here. I thought you have also said that it is essential to see what Assets support a given a Service. Humor me by substituting "Service" for "Application" in the above arguments. Do we not need to know what Service is affected by a Change? And is not the relationship between a Service and an Asset, a "Dependency"?

Charles T. Betz

the 5% Club

We are as usual debating terminology :)

Many tools provide some relationships, i.e. subsets of what ITIL defines as CMDB.
SDLC tools link the CIs of an app down to a very fine granularity - the Build, and link versions to environments.
Network managers auto-discover all sorts of linkages of network CIs.
Inventory tools auto-discover the contents of server hard-drives.
Procurement tools link assets to owners, suppiers etc
Operational monitoring tools manually (or sometimes automagically) link services to apps, apps to servers, apps to databases etc

None of these is a CMDB. According to ITIL, CMDB is the uber-repository of all information, exactly as Repository was supposed to be, or in the new CMS vision it is the uber-federator of all information, exactly as X500 was supposed to be. If you have one of that list of CMDB subsets above, or its ilk, you are in the 100% Club. If you can justify the costs of all the coded integration and feeds - and all the manual discovery and maintenance - to get everything in one place, then you have a CMDB and you are in the 5% Club.

Some of the tool-enabled

Some of the tool-enabled things are less glamourous Ops things but valid nevertheless.

Security & Access Mgt. I'm no security guru but tools can help prevent SPAM, viruses and manage access.
Service Request & Access Mgt. Many companies spend too much money resetting passwords so a self-help tool might help.
Request Fulfilment. SW distribution hasn't been done with men in vans and disks for 10+ years.
Release Mgt. SW distribution & patch mgt tools should help.
Knowledge Mgt. Some sort of shared, searchable Kbase is helpful too. Maybe.

Lastly, some companies waste money buying software they don't need so some sort of SW inventory mgt tooling can help.

Syndicate content