The process of selecting and implementing DCIM successfully is a journey, not a one-time event as many believe. The following blog post helps identify tips to being successful with DCIM.
I often talk to data center folks who are looking at implementing a DCIM solution and are wondering if they can justify the cost and effort to implement the solution. Often this is because, like me, they have seen failed installations that took 18 months or longer and have never delivered on the initial promise – whatever that was. However I know it is possible to get a sensible return on a DCIM implementation, but it requires a different mindset than I suspect a lot of the industry wants a prospective customer to have. This post discusses that alternative approach.
Why can a DCIM implementation fail to deliver?
In essence the core reason I see DCIM implementations fail is when vendors and customers together try and do too much on too large a scale. At the heart of this is often the sheer scope of DCIM solutions and what they can do. After the RFP process and picking a vendor there are internal and external pressures to implement the full scope of the RFP and chosen DCIM solution. In reality this is often over reaching and missing core needs, it’s also expensive and difficult.
When this “complete” approach is taken it can be successful, but many times it is not. It often proves to be too hard to get all the features and functions implemented across all the involved groups and geographic scope. It is hard for multiple reasons, including current data quality, misunderstanding what is really required, over selling by the DCIM vendor, reluctant participation from the various groups involved, different work practices across sites and even staff availability. Often 12 months in, it’s either a project that’s been brought in-house to ‘finish’ because the budget ran out or there is general disillusionment with the DCIM solution in place because it is only being used for 30% of the original scope and the ROI is out the window. I believe this is why IDC stated that in their DCIM survey over 50% of customers said they plan to change DCIM solutions in 2014 . I guarantee there are some people involved in every DCIM implementation project saying to themselves “I can always go back to my spreadsheets, they worked just fine”.
So that’s all a bit gloomy, time to take a look at what does work.
DCIM Success
So, what will work? There are two hints from the scenario above. First, what actually gets delivered (the 30% in the scenario above) is often the really important functionality that tends to get implemented when it all starts going wrong and the project scope is cut. The second hint is the spreadsheets that were being used to capture data points before the DCIM project started; that’s the data that was critical to run the business, right?
My top 4 suggestions to start a DCIM implementation:
- Treat the DCIM implementation as a journey and start with what’s critical to you. That does require you to take a step back and perform a bit of introspection after the RFP process and 10+ DCIM demos. I suggest taking a “just enough” approach to DCIM implementation and defining the scope to only include what people have in their spreadsheets today. The assumption being that people currently track only what they really care about in spreadsheets (or homegrown databases or other smaller commercial solutions). This approach defines a reasonable scope and will get people’s buy-in far more readily than “we are going to be taking over the world”. It does help to look further out than this when initially deciding how to configure the solution, but that’s different from capturing and managing all the data.
- Limit the geographic scope. Start with a single site to limit the project management scope of the initial deployment. This gives you a chance to bed down processes, to uncover the quirks of the solution and to demonstrate success.
- Communicate the strategy. Assure everyone that ‘everything’ will eventually be in the DCIM tool and if necessary, define future phases at a high level.
- Look for quick wins. A classic example is a data center full of SNMP-enabled power strips and nothing monitoring them. Those quick wins can be successfully added to the initial scope if they are truly straight forward implementation.
If you take the approach above you will have the chance to bed down processes, uncover the quirks of the solution and demonstrate success and, if the ROI was reasonable to start with, see a return.
The DCIM Journey
Once you have delivered relatively quick and pain-free success, the ability to roll out that initial functionality set further becomes much easier as internal resistance falls away. In fact, further implementation becomes significantly cheaper as you now know what works and what does not.
In essence what we want a DCIM project to look like is this:
Despite its cyclical appearance, the figure above represents the continuation of the journey.
Each new iteration starts with defining a set of requirements. The requirements often come from one of two areas of need.
The first requirement need is the obvious one of using additional functions of the DCIM tool, perhaps based on the original RFP requirements gathering process or based on forthcoming enterprise data center initiatives. In either case it’s the process of incrementally adding data collection, analysis and management that keeps the DCIM project manageable and working for the enterprise.
The second requirement need is that, in my experience, additional use of the DCIM solution is often unexpected and driven by unplanned requirements. For example, we had one customer who got the initial implementation done and had then expected to roll out power monitoring. However, based on senior management concerns about unused equipment in DC store rooms, the customer used the DCIM solution to provide visibility and ‘discover’ what turned out to be tens of millions of dollars of brand new equipment sitting in store rooms for long periods of time. The customer then decided to link user demand for new equipment with on-site and ordered supply. Doing this freed up a huge amount of wasted capital and they now have a 90 day plus view of what is going to be required (for both physical and virtual servers) and from where that demand will be met. This particular customer has added to their DCIM solution in about 5 phases so far which have included basic equipment and location, equipment demand, deployment planning, connectivity, interfacing to the corporate asset database, power monitoring and most recently, metrics analysis and environmental monitoring.
Summary
In summary, when DCIM solutions are being evaluated, look at the grand vision along with each DCIM solution and ask if it can function in a phased deployment approach. If the ROI for a phased model does not make sense or the solution demands a lot of data (or the vendor demands you do a lot), that should be a red flag. However, if you can find a vendor who will partner with you and who understands that DCIM is a journey and that the ROI is reasonable, then you are on the right track. Certainly some of Cormant’s customers have surprised us with the direction they have taken their DCIM solution. They have also partnered with us to develop functionality that has benefited them and many of our customers. We have customers up to 11 years old who are still finding additional uses for their DCIM solution; it is ever-evolving and growing. Now that’s real DCIM success.
For more information on tips to a successful DCIM implementation, read “10 Tips for Successful DCIM Deployment,” as seen as the cover story of the May/June 2014 issue of BICSI’s ICT Today.
Author:
LinkedIn: Paul Goodison
Twitter: @CormantCS