5 Keys to UCMDB Success

5 Keys to UCMDB Success

Speech-BubbleThere is one conversation we always have with each of our customers. It centers on creating a UCMDB environment that does two things:

  1. has the cleanest data possible
  2. supports every aspect of the HPE ITOM Service Management platform and ITIL processes

In our recent How to Measure UCMDB Data Quality webinar, Erik Engstrom, Effectual’s CEO, discussed the importance of clean data to a UCMDB. Today we’ll focus on the second item, taking your HPE UCMDB to the next level with what we believe are five (5) key practices that will accelerate that evolution to universal UCMDB success.

You’ve heard the horror stories about Configuration Management integration projects. A recent article in Forbes places  the success rate of CMDB implementation projects at a disheartening 15%. That means that a staggering 85 out of every 100 fail. The reasons for failure can be anything from lack of resources, to lousy data quality, to lack of actually trying to use the tools.

Any one of issues would be enough to limit adoption. Together they create a repeating vicious cycle, dooming most UCMDB initiatives before they even have a chance to get off the ground. If many of the following keys break with conventional wisdom, it’s because our experience tells us that much of the conventional wisdom around CMDB has failed to advance with the technology. We think that in order for a UCMDB project to be successful, HPE customers require modern best practices.

 

#1:  Streamline Implementation

Engage Effectual_vertical-07

We’ve written about this before. Most UCMDB implementations start with a lengthy planning process. IT Service & Configuration Management, as both an organization and a practice, take a very “belts and suspenders” approach, which often means months (or more) of planning to ensure all the i’s are dotted and t’s are crossed before the first discovery is even run.  Even when the best efforts are attempted, we see over and over again that the client has little to show for all the expense.

Our experience has taught us that endless planning and justification are not required for success. Customers try to imagine a theoretical end state that they have no certainty of achieving. In practice, the only success most of them achieve is to rack up a great deal of billable consulting hours. Rarely are customers left any closer to the highly defined goals that were planned at such great expense. This lengthy and painful planning stage stalls many CMDB initiatives before they even begin. Endless implementation shouldn’t be the norm. And it doesn’t have to be.

All that’s required is just enough planning to install, configure, and test the UCMDB. Planning has its place, but only after you have a complete understanding of both the collection of data and how that data will be used in your daily operations. In order to plan use cases effectively, you should start with a fencepost-to-fencepost understanding of your infrastructure. Until you see what your system is and is not capable of, use case planning is impractical at best.

The whole point is that the integration and “making it work” period should not be held hostage by the end-state use case design and desired features. You must reach this point of foundational capability before attempting to design a more complex solution. In other words, you can’t evaluate what you will have until you can evaluate what you can have in the system. You can’t evaluate what you will do with it until you’re able to demonstrate that you actually have data and meaningful relationships in the first place.

This idea turns the traditional implementation process on its ear. If you start with PIE, you start out understanding your capabilities, you start with quality data, and completely mapped Discovery. Thus you start out in the best possible position to understand the best use cases and prioritize their development. Understand how the data can be used, then design the Use Cases. This model allows for the CMS/UCMDB to evolve over time,  in alignment to business, operations and financial users trust and perceived value of the CMS/UCMDB. The implementation roadmap is greatly accelerated, and flexibility and value are demonstrated from the outset.

 

#2: Stop Limiting Scope

This is closely related to the first item. UCMDB should function as a central repository for configuration, relationship, and services data. However traditional projects scale back the amount of included data so severely that automatic normalization and reconciliation of large amounts of data, a UCMDB’s most valuable ability, is completely dismantled.

As integration projects become derailed, false blame falls to the customer’s complexity of data or lack of requirements. This usually leads to a radical limiting of scope. Stakeholders are led to believe that the project is too complex, is trying support too much of the infrastructure, or just generally that the project has bogged down due to lack of planning (which usually means a restart). This limited scope, in turn, limits the value and versatility of the UCMDB itself, compounding the initial lack of trust and adoption.

The importance and value of the CMS/UCMDB go up (not down) with the size of the organization and complexity of the environment.  So why attempt to limit the scope of the tool and data?  We believe the problem lies in two primary areas (1) relying on out-of-the-box configurations (along with the suggested architecture) and (2) starting with junk or bad data, with the belief it will improve over time of its own accord.

Neither of these issues are to be ignored or taken lightly. But both of them can be corrected fairly painlessly. Starting with a complete picture, founded on good data, allows you the advantage of scaling back strategically. Think about trying to choose what to eat for dinner. Most people start with what they don’t want before they figure what they do. Before you make a decision, you should have a complete list of available options.

Again, the emphasis falls on foundational capability. When you start with the most accurate, complete picture possible, it’s easier to decide what should and should not be included in the CMDB. When you operate from information instead of guesswork, you get to the real value of using your data to make decisions, support users, and improve Incident, Problem and Change.

#3: Understand the Benefits & Limitations of a Tool

Your UCMDB is only a tool (or rather a matrix of tools). The data it stores is only data. They only become valuable when you understand how both work together in support of your overall HPE ITOM framework. At its core, service portfolio management is about “managing” the delivery of IT services. UCMDB supports service and asset management by providing relationship data associated with those services (down to individual CIs and data elements). If your UCMDB is not fully integrated with both your Asset Manager and Service Manager, then it really isn’t supporting service management.

Integrating a UCMDB is more than just defining what it will do, but also how it will be used and who will use it. It’s about using it for its intended purpose, relying on it to support the delivery of IT services, and to do so as fast as possible, with as little re-checking or filtering of the data as possible. It’s about practitioners’ respective tools being their best, so those practitioners can better do their jobs. In our view, a UCMDB should:

  • Integrate to other HPE ITOM Service Management tools
  • Provide bi-directional data flow, without errors
  • Be fast – both with automated processes (such as Discovery) and ad hoc requests (such as on demand queries and reporting)
  • Be straightforward in design, allowing anyone to utilize the underlying data in their respective tools
  • Support a complex, dynamic computing environment with hundreds of thousands of changes per month
  • Ultimately, provide the basis to quickly reconfigure the services delivered by IT, without reconfiguring data elements or how the overall HPE ITSM platform operates

As IT professionals, we love our technology. But it’s essential that we use that technology to the greatest benefit to our businesses. Your UCMDB is great at storing and delivering complex data. Ensuring quality data, seamless integration, and properly designed service relationships is up to you.

 

#4: Stop Thinking of UCMDB as a “Project”

Configuration Management (UCMDB and Universal Discovery) is not a project in the traditional sense. Yes, there is a “start” which includes planning, and a design and integration phase. However, UCMDB isn’t a one-time analysis, setup, or integration. It’s not a “set it and forget it” toolset and Configuration Management doesn’t have an end or completion date. The only “end” is to get the initial phases right, and to bolster adoption and continued reliability.

When you stop thinking of Configuration Management in terms of a traditional “project” template, you start to understand its value beyond simply tools or applications. UCMDB data is the foundation to managing IT service delivery and quality: creating and maintaining IT services; supporting all Incident, Problem and Change processes; providing end user support; and ultimately delivering a full picture of your environment as it evolves and changes over time.

 

#5: Find & Partner with Experts

Everyone needs help sometimes. We live and breathe this stuff, so we’ve already dealt with the heavy lifting. Configuration Management (and the underlying tools) have been viewed as difficult. As we’ve seen, UCMDB projects take too long (measured in years) and are too expensive (measured in millions of dollars). To be honest, both are true if you take a traditional approach. But, we don’t. We have spent years focused on HPE ITOM Service Management and UCMDB. We have dug deep into the science of both the process and the tools. And we have both the experience and the expertise to debunk the “too long, too expensive” myth.

An integrated, organized, and optimized Configuration Management platform is possible with Effectual’s PIE solutions. But only if you understand how it is unique and how it supports the ITSM/ITIL processes. Most projects fail not because those involved don’t want success, but rather from their being too cautious, spending too much time“planning” and not enough time “executing.” In today’s dynamic business world, people want to see results fast. Our approach is to streamline the implementation process, so a mature integrated system is a starting block, not a destination. For most clients (even large, globally complex organizations) this means weeks instead of years.

Get started today

Request a Live Demo