Technology does not fix process
People are drawn to IT by a fascination with complex technology. This is most unfortunate because this fascination blinds so many of us to the importance of the People/Process/Product trilogy.
Change and Configuration Management are processes. If the process is working, they collect and maintain good configration data (in a repository that you can call a CMDB if you insist). If the process is broken technology is not going to fix it. Bang your head hard against the desk while repeating five times "technology is not going to fix it".
If your people do not have a service management culture; if your service management processes are not well designed, bedded in to the organisation, and measured and monitored; if you do not have this situation then all the cool tools in the world are not going to fix it dammit!
Once you have the right people doing the right things in the right way, only then can you indulge yourself and spend what is left of the project budget on the shiny geegaws peddled by the vendors.
OK, that is an exaggeration: there is a place, well into the process design, when we identify opportunities for tools to help manage the process and in rare cases even help automate the process. Once we understand our people's capabilities and desires, once we understand exactly what we want the process to do, then yes we may be able to build a solid business case to buy a tool, most likely a service desk but also other operational software or even document management systems etc... START with people, then START with process, then start with technology, so in the end all three streams are in parallel.
That does not in any way undermine my basic premise though: if you have a process problem there is not a technology solution.
Here at the IT Skeptic we are not above picking on organisations, so let me use an example drawn to my attention today: Tideway. I don't doubt their product, Foundation, takes autodiscovery to the next level of embedded intelligence, to try to unravel the service dependencies. I do doubt that they have removed the manual element from the process: there are plenty of clues that they haven't: "Reduces manual effort of building business service views by up to 80%". There ought to be a law defining use of the term "up to" as an illegal business practice. I have already discussed how I'm skeptical of the ability of these tools not to be excrutiatingly stupid.
And most of all I do doubt that, except in the most complex of organisations, there will be a solid business case for replacing "up to 80%" of the manual effort with an expensive, complex, high-learning-curve tool that still requires a manual effort to check it, work out what it did, tell it when it got it wrong, add the really interesting data that it simply doesn't understand, and keep it correct in a dynamically changing environment.
Auto-discovery is very useful where initial data is rubbish: it is good for helping get a baseline set of CIs. If your Change processes are any good then you don't need it after that, though you can use it to audit data quality and detect non-compliance. And if your processes are no good, then it is not a substitute.
So, folks, please let's grow up as an industry. If you are paunchy and aging, buying a red sportscar does not fix the problem. If all the kids shun you at school, a HotWheels set is not going to change that. If you can't get your people to write down what they changed, a shiny "Automated Application Dependency Mapping" (or any of the other gadgets being peddled around the ITIL world right now) is not going to make any difference.