So what’s the secret sauce to achieving a successful systems management deployment?
It all boils down to one word – adoption.
In fact this may be the dirty little secret that all the other vendors don’t want you to know. After all, anyone who sells software would try to say that a flaming logo, a long client list, a huge list of collected metrics, or a huge feature matrix is what people traditionally want to talk about.
Ask yourself, what good are ANY of the above, if the system isn’t focused on maximizing adoption from day 1 of your initiative, to day 300 of your initiative?
What amazes me time and time again, is that when I visit prospect sites, their number one complaint about their existing system is that nobody uses it, nobody trusts the alerts anymore, or that nobody trusts the underlying data because collection is unreliable. So instead of being that unifying force, the catalyst for change or achieving the “single pane of glass” – the incumbent tool becomes a source of frustration and a wedge between different teams.
Think about it, if nobody is using the tool, if nobody trusts the tool, or nobody feels that it’s worth the time or effort to try and figure the tool out and use it – all of your investment in the systems management initiative is lost.
And there’s a bunch of really great reasons why nobody is using or adopting those tools, for instance here are some of the questions I hear people rhetorically asked in client and prospect meetings all the time:
What good are systems that are hard to rollout and administer, thus alienating the deployment team?
What good are systems that generate seas of alerts for any given event, thus causing people to create email filters?
What good are systems that don’t ensure that alerts and actions are based on stringently verified trouble conditions, thus causing people to create even more email filters?
What good are systems that don’t allow you to tune those actions and messages to meet your corporate standards, thus resulting in confusing when alerts are actually delivered?
What good are systems that are hard to navigate through on an ad-hoc basis, or are hard to generate reports, thus resulting in users deciding it’s quicker to fire up a niche console tool? (How about to schedule them?)
What good is a system that doesn’t accomodate for your success? i.e you have to throw it out because a new business unit or technology group needs tools outside of your preferred stack, or you acquire other businesses that use a totally different technology stack? (long term adoption, scalability and suitability)
What good is a system that doesn’t provide value to everyone involved in delivering value in IT, from your helpdesk staff, to operations, to capacity, to individual technology silos?
The secret sauce is to drive adoption, and the way to make the secret sauce is to create a product that overcomes the challenges posed by the questions above, and to create an organization that speaks your language, understands your challenges and delivers not only the technology, but the dialogue and guidance that will ensure that your systems management roll-out acts as a catalyst for your success from day 1 to infinity.
Who says that your systems management solution can’t be “nutritious and delicious”?
