IT: disconnected from the business?Mend the divide by creating a healthy CMDB

Body

Written by:

Brian Kerr, Senior Managing Consultant, Axios Systems

 
CMDB wellness: learn from time travel

Imagine if you could travel back in time to revisit life before your current Configuration Management Database (CMDB) situation. Do you recall the giddy sensation of being caught up in a certain rose-colored utopia, soaking up the realization that this new CMDB had the power to make life simple, insightful, forward-focused?

 

As these grand expectations flourished, how much effort did you invest? How much resource did the business allocate? Critically, was the project well-supported after go-live, in terms of capturing and maintaining the right data at the right points?

 

Here we are again in the present. What’s the state of your CMDB? Is it properly maintained? A truly accurate system of record? Is it positively regarded and trusted throughout your team and wider organization?

 

In my experience as a senior IT consultant, I’ve seen many organizations go through the process of producing multiple iterations of a CMDB before they achieve the desired vision. You can’t always blame the actual CMDB. From gathering requirements to constructing relationships between data, continuous refinement is key to executing the long-term vision.

 

Perhaps you’re happy with the state of your CMDB — in which case, congrats! But is it as optimized as it could be? You should still explore the insights here, because we’ll offer you some ideas on how to further weather-proof your CMDB.

 

However pleased or displeased you may be with your CMDB, here’s what you can’t ignore: The business needs to be able to inform IT of long-term plans, including requirements for expansion or new technologies. For this to be possible, you must be able to produce contextualized, relevant reporting insights. And in order to be able to deliver on this fundamental obligation, your CMDB must be designed and populated to reflect the appropriate business requirements. If, from the start, you don’t get this piece right, you will inevitably have to start again.

 

Ultimately, if you’ve not built and maintained this framework, then none of the business benefits of your CMDB can be exploited to their full potential. This paper is designed to help get you back on track, stay there, and move to higher ground.

 

We’ll show you how to couple your CMDB with change management, management information/reporting, and knowledge management. We’ll also discuss how it should work with and enable the population of your Service Catalog. These areas equip your team to make informed decisions when creating and managing infrastructure changes. Fundamentally, they help you provide key services required by the wider business, rather than simply being considered in terms of what IT offers.

 

Without question, when you first implement ITIL®, building a CMDB can seem daunting, and no one ever promised a CMDB would be easy to create or maintain. The real question you ought to ask is, can you afford not to?

 

Without a well-managed CMDB, the rest of your service management strategy will fall short of departmental expectations, disappointing business stakeholders.

 

Ignorance may be bliss, but at what cost?

ITIL enthusiasts will recognize that a CMDB is a repository of information that encapsulates the authorized configuration of the IT system. But what does it mean to business stakeholders who don’t work in IT? And — critical to IT receiving the right investment and support to develop a top-performing CMDB — why should those stakeholders care?

 

The benefits to stakeholders include a reduction in operational costs and an improvement in the efficiency and quality of service provision. A well-performing CMDB also strengthens relationships between the business and IT by improving communication. It can reduce the risk involved with change and provide increasingly flexible and expeditious delivery of new services required by the business.

 

One of the biggest problems with many poorly performing CMDBs is that they aren’t able to provide accurate asset/configuration information. When it comes to configuration management, the reality is that most organizations don’t know the true story and cost of their assets, including:

 

  • What they have
  • Where it is
  • Who uses it
  • How much it costs
  • Who supplied it
  • Whether it’s under maintenance
  • Whether it’s fit for purpose
  • Whether it meets business requirements

 

The net result is that organizations end up spending more money than necessary to meet service requests, which could be fulfilled with existing assets. After all, when you don’t know how many spare laptops, desktops or software licenses are available, you end up buying new ones.

 

Supplier costs also become an issue. These are often based on supplier information rather than what you record about the supplier performance against agreed SLAs, or which assets are covered by which contract.

 

When you undertake an honest assessment of your CMDB capabilities, you should consider these challenges:

 

  • Can you easily identify when the assets come out of maintenance?
  • What are the initial and ongoing costs of the assets, and the depreciation values?
  • Do the assets meet basic baseline requirements to meet current and future business requirements?
  • Can you easily identify trends in product or model types, based on positively or negatively performing products?
  • Are there relationships between services, business processes and the underlying supporting infrastructure?
  • Are there sufficient software licenses to avoid prosecution?
  • Have SLAs been defined and agreed to support the services?

 

If you’re struggling to answer those questions, you may also discover that poorly performing hardware is almost impossible to consistently identify. This makes it difficult to ensure infrastructure optimization and to share insightful information with Finance for new negotiations with suppliers.

 

And if you’d rather cover your ears when these questions are whispered, let alone shouted, it’s time to address the foundations of your CMDB.

 

The top 5 questions (and answers) about planning a CMDB

The CMDB has always been viewed as the cornerstone for all of the ITIL processes. But in reality, many teams struggle to understand how to structure it and what to include (similar, in many ways, to the types of questions that often arise when building a service catalog).

 

Here are the key questions likely to get asked by colleagues and stakeholders:

 

1. What does the CMDB do?
In essence, the CMDB holds data (traditionally, IT data). It is regarded as the cornerstone for all other ITIL processes. Many interpretations or descriptions have been recorded. The Axios Systems’ Wiki details the CMDB as:

“A repository that acts as a data warehouse for Information Technology (IT) organizations. Its contents are intended to hold a collection of IT assets that are commonly referred to as Configuration Items (CIs), as well as descriptive relationships between such assets. When populated, the repository becomes a means of understanding how critical assets, such as information systems, are composed, what their upstream sources or dependencies are, and what their downstream targets are.”

2. Beyond the CMDB, how should you handle federated data sources?
A CMDB is one data source, but organizations will often have multiple federated sources of data, for various reasons related to governance, legislation, etc. These can take the form of inventory lists or spreadsheets. They may hold different information about the same entity, as would be the case when HR maintains an employee’s background checks, while Finance maintains the same person’s bank account details.

Different parts of an organization may have homegrown databases or information relevant to them. These need to be identified by format and to gain an understanding of which data need to be centralized.

It’s perfectly acceptable for these federated sources to exist, and in some cases, unavoidable. The important thing is that you identify feasible opportunities to centralize data. In the long run, this will help you streamline processes, produce better quality reporting, etc.

3. What goes in the CMDB?
You’ll find starter checklists below, addressing data, assets and asset attributes. The core inclusions continue to evolve, particularly as organizations introduce the Service Catalog and Enterprise Service Management (ESM). This means we must now consider not just traditional IT assets, but services and business processes from different business units, including HR, Facilities, Finance and others.

4. What is a CI?
I have been involved in some workshops relating to creating a CMDB and found it extremely interesting to ask the question for participants’ views on what constitutes a CI.

Some of the responses sounded quite surprising, but only proved the point that not everyone really understands the concept. I remember one interesting suggestion in particular, that incidents and changes should be treated as CIs, rather than as processes underpinned by the CMDB.

You could argue that there’s no right or wrong answer about what constitutes a CI, but what does need to be present is an enterprise-wide understanding of what needs to be held within the CMDB to support business objectives and services.

Teams need to move away from the idea that a CI is an IT-focused entity, and should focus CMDB development on anything affecting or impacting on business requirements. These factors should be recorded, tracked and monitored within the CMDB and Service Catalog. This will be the data which will provide meaningful management information to the business.

There is no reason why people, buildings/rooms, contracts/SLAs, knowledge articles or other documentation cannot be recorded as CIs, and effectively come within the control of change management. Don’t be surprised if these questions get asked multiple times throughout the service management lifecycle. Many organizations will be on their second attempt, or beyond, at creating a usable CMDB. This has been further complicated by the introduction of multiple federated sources, which were ostensibly introduced in ITIL v3.

You must consider what data from these sources should be included within the CMDB, or held externally. As a starting point, consider what is relevant or used on a frequent basis rather than periodically. Think of it like a wardrobe: some pieces of clothing are only worn rarely or seasonally at best (i.e., a winter coat or dinner jacket), and are perhaps best tucked away elsewhere to save space for the clothing you wear more often. Whether storage is internal or external, you must be able to guarantee the security of information.

5. How does the Service Catalog affect the CMDB?
Some organizations will use the implementation of a Service Catalog as a starting point to building the CMDB. Prior to the creation of a CMDB, (or indeed, a Service Catalog), ask yourself:


  • Does IT understand the business?
  • Does IT appreciate new technology?
  • Can IT measure current performance?
  • Can the business measure IT performance?
  • Can the business predict growth and direction?
  • Are IT and the business aligned?

Part three of the next section goes into further detail on how the Service Catalog can be a catalyst for improving the CMDB.

 

A three-point plan to avoid CMDB failure

When organizations set out to create a CMDB, they commonly do so without clearly defined goals. IT will typically look to populate the CMDB with detail to the Nth degree, unsupported by rationale for why the data has to be there, or how it will be maintained, let alone if it is linked to business requirements. These decisions should be made based on cost/effort compared to business value.

 

All too often, those requirements will not have been discussed with the business, with IT being quite happy to provide what they can provide, rather than what the business actually needs.

 

Sound familiar? For better or worse, habits are hard to break, so create the right ones along the journey. Time and again, we see many recurring reasons for CMDB failure, including:

 

  • No clear objective
  • Lack of ‘buy-in’ from senior management
  • Broad and deep or ‘boil the ocean’ approach
  • Ill-defined roles and responsibilities
  • Bad data
  • No confidence in the data
  • No ability to maintain currency and accuracy

 

How do you avoid falling into those pitfalls? Follow these key strategies for building a framework to facilitate better communication and outputs between IT and the rest of the business.

 

1. Rally stakeholders to discuss shared objectives
Engage stakeholders from across the business in regular meetings to eliminate the ‘perceptual barrier’ which has long existed between IT and other business units. These conversations can help eradicate the idea of IT being a black hole where things go into but nothing comes out of.

Invite leaders to briefings that reveal how the CMDB can support overarching business objectives. Seek enough clarity and direction for those objectives to help you produce a broad but focused dataset within the CMDB. Over time, this will help facilitate contextual reporting that helps justify and validate business decisions, or offers insight into better courses of action, as needed.

Both parties need to understand each other, using open and frequent communication focused on eliminating the ‘perceptual barrier’. Initial meetings to establish the role of the CMDB in supporting business objectives are a great starting point.

2. Fight in-fighting with good data
But where does this ‘perceptual barrier’ originate? Often, our reporting strategy can either directly or indirectly play a role.

Commercial breakdown becomes a greater risk when IT does not act as a single unit to deliver what the business requires to remain in business. Do the headline messages of your reporting often result in internal arguments about responsibilities and blame? If that’s the case, it’s definitely time to revisit the data held by your CMDB, because this data affects the quality, nature and overall message of your reporting.

As you reevaluate the quality and selection of data to be included in your CMDB, consider: Does your reporting focus inwardly on IT, rather than the wider business? Are you enabling ‘blame culture’? Or, is your CMDB equipped to help the team contextualize information, supporting informed business decisions that drive the organization forward?

Once your CMDB is operational, continue the dialog to ensure that IT remain looped in on evolving business objectives. The business needs to be able to involve and inform IT of long-term plans, including requirements for expansion or new technologies, etc. Reports can only be created based on the data captured. As such, the type of business reports required should also play a key role in deciding how to populate the CMDB or create a Service Catalog.

Organizations are drowning in data but starving for information. As champion of the CMDB, your challenge is to engage decision-makers and allow the team to create reports enabling decisions based on accurate content. At a foundational level, this requires purposeful design of data, easily packaged with context.

3. Conquer the Service Catalog
The creation of a Service Catalog can also be the catalyst for reviewing the content and structure of the CMDB, or indeed the reason for creating one.

At the start of designing your Service Catalog, check that:
 

  • Services have been defined
  • Services have been agreed with the business
  • Review processes and reporting have been agreed
  • Sufficient supporting infrastructure for service delivery exists

 

To help move the process forward, we really need to move away from the more traditional view of IT as being tech-focused, and towards a service attitude, focused on delivering what the business needs rather than what we think it should have or what we can provide.

Think about the Service Catalog as being the shop window to the business. A ‘one stop shop’ for IT and non-IT services.

Just like a CMDB, many organizations struggle when it comes to deciding what a service is and what they should publish within the catalog. Typically they ask if it should be a list of software and hardware provided by IT.

To help explain the basic workings of a Service Catalog to non-IT colleagues, it’s useful to talk about online shopping, where we commonly encounter Service Catalogs in action. Let’s take an example of grocery giant Tesco, based in the UK:

Online shopping is one of the principle services of the Service Catalog we might visualize from Tesco. While shopping, as you select and add items, you see details of costs, quantities and delivery options. These are like asset attributes.

Beyond the basic shopping service, Tesco also offer other non-grocery services, such as home and car insurance, banking, opticians, etc. And possibly less tangible but equally important, you’ll also find customer support services, including information about how to get in contact, make a complaint or process a return. As Tesco adds newer services, the Service Catalog continues to diversify into areas that customers may not have once expected, but are willing to consider if additional needs can be solved. On either side of the interaction, Return on Investment (ROI) of the Service Catalog increases, alongside the perception of value.

Once you’ve completed and paid for your shopping, your order is then processed by many teams behind the scenes who work together to provide what should, in essence, be a seamless customer experience.

In IT or elsewhere, Service Catalogs need to offer customers the right selection of services to solve their needs, supported by a sufficient level of detail to enable customized requests. The entire experience must be underpinned by a seamless fulfilment process.

Like the Tesco model, we ought to seek ‘one-stop shop’ functionality within our Service Catalogs. Providing shopping basket functionality is fantastic, and expanding the catalog into non-traditional areas is becoming the norm. This can include the ability for customers to log their own incidents and view progress. The Service Catalog can also provide common non-technical FAQs, which encourage users to self-resolve issues or to find information about HR policies, for example. We can also use it to publish information about upcoming events, such as maintenance, downtime, training courses, etc.

From the start, we need to define the objectives we want a Service Catalog to achieve. We want to articulate our value in business terms understood by customers. We also need to be able to demonstrate our value by regularly measuring and reporting usage and performance to the business. We need to show that we understand the business needs and that we can provide services that are cost effective, relevant and reliable.

Remember that the customer is not really interested in the technology required to provide the service, or what goes on behind the scenes to provide the service, or who is involved in its provision. Customers are only interested in whether services are guaranteed, and whether they meet their needs, within budget. They also expect good quality and value for money.

Basically, we need to know if IT understands what the customers/business need to perform their day-to-day activities, and whether we deliver the required support at the right time and at the right cost.

We also need to be aware of new technologies which are either available or being developed. How can we use these for our current delivery, or for future services the business may decide to pursue?

As a starting point, sit down with non-IT and IT users to establish your customer base. Use these discussions to establish the most important processes from a business perspective, and whether your IT services map to and support those processes. Ask the customers if they feel that the services are clearly defined, and set out the costs, deliverables and time scales for service delivery.

Talk to the customers about what they would like to see in a Service Catalog and what would deliver value to them. Use plain business language rather than IT jargon.

We need to discuss this with the business to make sure that we have the correct understanding of the business requirements. Colleagues outside IT can help make us aware of what they have that works, what doesn’t and what changes are needed.

What level of detail does the business require? Do we know its location? Has the team responsible for maintaining it been identified?

We need to ask the business what information they need to allow them to make good business decisions. Is it important to them how many times the phone rings before someone answers? This may be important, but equally they may be more interested in what are the most or least commonly requested services. Of these, how many are delivered based on pre-defined timescales and on budget? What trends, seasonal- or demand-based, are there for services?

Do they have the ability to request services not listed in the catalog? How many of these do we get and do these services need to be provided?

Document the existing services which IT provide and try to map those to the business process, then list the shortfalls not currently provided.

Review old change requests. Use these to look for potential services which have previously come through as changes.

These may be non-IT related or not obviously services, but could include new email accounts, software installations or hardware upgrades.

You should also consider how you deal with things like room bookings, parking spaces, or requests made on behalf of new colleagues. All of which can easily fit into a Service Catalog.

Ensure your Service Catalog includes:

 

Service descriptions: these should be brief and use business language

Service levels: every service should clearly describe the agreed service levels

Support: every service should describe how the business customer should report problems or make requests

Service conditions: set expectations for any specific terms of usage and operational maintenance and change periods

Cost: establish actual or notional costs to the customer

Features and functions: a brief description of the value these services offer customers

Related services: links to complementary services of interest to the customer, or services that form part of a core service package

 

Checklists: capture these requirements before you design the CMDB

As you prepare to launch communications and define reporting requirements, you’ll need to define the components of your CMDB.

 

Traditionally the CMDB was seen as something to hold IT information about hardware and software. With the expansion of Service Catalogs and ESM, we need to broaden our view of what we will hold in the CMDB to meet these requirements.

 

It’s also essential that you document the process and designate process owners. Without these, you’re more likely to encounter grey areas resulting in poorly updated data, or data lacking updates altogether.

 

Consider these traditional IT infrastructure data and asset requirements at the forefront of planning your CMDB:

 

Data

What data do we have?

How valid is this data?

What data can we get and how?

Automated/manual?

How much effort will it take?

Business as usual requirements?

What do we need to support the business?

What data will help us deliver better services?

What have we promised?

What does the business need?

How do we maintain this data?

 

Assets

PCs

Servers

Software

Network items

Documentation

Services

Telecommunications

 

Asset attributes

CPU

Memory size

Number and type of slots

Disks – free space

Network cards

CD-ROMs

Patch versions

Software installations

Services accessed

 

You should also consider non-IT assets:

 

Non-IT assets

Vending Machines

Audio equipment

Desks and Chairs

Rooms

Video equipment

Parking Spaces

Catering

 

Checklists: validate, implement and evaluate

Once you’ve started a discussion around the fundamental requirements of your CMDB, you should next consider the processes of validating data, implementing the CMDB and evaluating outcomes.

 

Start with the basics of data validation
If working with existing data, you should be assessing whether you can guarantee its validity.

 

Have we identified all sources?

How current is it?

How accurate is it?

How is it maintained?

Who maintains it?

Is the data duplicated in other sources?

 

We need to ensure that we have identified all potential sources of data, including automated discovery tools, barcode files, spreadsheets and other databases. Data could be from an existing ITSM tool or from other non-IT areas.

 

Decide on an implementation approach

You will also have to decide on the implementation approach which will be taken. Will it be ‘Big Bang’, line of business, physical location or asset type?

 

Perform in stages if required

Identify ‘must haves’ and ‘nice to haves’

Identify priorities

Set realistic targets

Don’t lose focus

Prioritize quick wins

 

Meet goals with specified SLAs

Service Level Agreements (SLAs) underpin the performance of your CMDB. These relate directly to the services provided. Once these have been agreed and documented, they can be held within the CMDB. These should be agreed based on contracts with suppliers involved in service delivery or fulfilment. Based on the SLAs, IT can then agree to provide the business with internal Operational Level Agreements (OLAs) in support of SLAs.

 

OLAs should clearly establish what the review periods will be and who will be involved in those reviews.

 

OLAs should also clearly define which penalties, financial or otherwise, are to be applied for failure to meet the agreed SLA values.

 

Reflect:

 

Have SLAs been defined and agreed?

Review periods agreed?

Internal, operational, underpinning supplier contracts

Costing and charging issues

 

Measure progress against KPIs

Decide on Key Performance Indicators (KPIs). These should be specific and measurable, for example:

 

Increase in percentage of assets under control

Decrease in percentage of failed or emergency changes

Reduction in incident resolution time of certain percentage

Increase in percentage of system availability

Increase of Incidents meeting SLA targets

 

The KPIs will provide an indication of service or process improvements and should be constantly reviewed. They must be able to convey to the business when something allows them to make informed decisions and will be a measure of Continual Service Improvement (CSI).

 

When you prepare KPIs, consider how accurately they can be measured. There’s no point in setting values that can’t be measured in a consistent and accurate way. KPIs also have to be realistic. Targets need to be achievable, or they have no value.

 

Are you measuring an insight which is appropriate to enterprise decision-making, enabling informed decisions? Or have you fallen into the trap of reporting on data purely because that’s the way it’s always been done, even if it lacks significant value to the enterprise?

 

Seek to establish users’ perceptions of what is provided. Use this to improve the service and the perception.

 

Can KPIs be accurately measured?

Are they realistic?

Are they appropriate?

Are they business focused?

What’s the user perception?

Don’t lose focus of overall aim

 

Are you focused on business-IT unification?

The rose-tinted vision we dangled at the start doesn’t need to forever remain a vision. With the right planning and partnerships, building a CMDB with purposeful CIs and meaningful reporting outputs allows you to progressively deliver essential business insights. Aligned with the longer-term business strategy, these insights are integral to establishing the core value of IT in the wider organization.

 

Remember the key message we shared at the start?

 

“The business needs to be able to inform IT of long-term plans, including requirements for expansion or new technologies. For this to be possible, you must be able to produce contextualized, relevant reporting insights.

And in order to be able to deliver on this fundamental obligation, your CMDB must be designed and populated to reflect the appropriate business requirements. If, from the start, you don’t get this piece right, you will inevitably have to start again”.

 

Whether you’re at the start of creating a CMDB, or finessing a current one, here’s the fundamental reason why your CMDB must take center-focus of your service management strategy: without a well-managed CMDB, the rest of your service management strategy will fall short of departmental expectations, disappointing business stakeholders. You’ll be less likely to receive support for other IT projects and investments. The gulf between IT and the rest of the business will widen further yet.

 

To facilitate the most advantageous outcome, keep in mind that the type of business reports required should play a major part in deciding how to populate the CMDB. Useful, reliable, contextualized reports can only be produced based on the quality of data you capture at the start of creating your CMDB.

 

Once you reach a satisfied perspective on the functionality and performance of your CMDB, keep in mind that the CMDB must be maintained to produce information of ongoing value. This should be in tandem with the evolution of your organization. You can follow our simple checklists to establish how to populate and maintain the CMDB.

 

Don’t be deterred by the level of planning required at the start, and indeed, throughout the CMDB lifecycle. Remember that configuration management implementation provides significant business value.

 

Finally, be guided by the following principles at each step of your CMDB journey:

 

1. Define clear objectives – plan for an iterative approach

2. Define the team, including owner and contributors

3. Identify data sources and data automation

4. Define metrics and plan for continuous improvement

5. Implement and repeat!

 

Case study: Discover how Lego built a scalable CMDB to reduce TCO

 

In order to further develop their asset management, a comprehensive, federated CMDB had to be put in place. The in-house CMDB that integrated with the LEGO Help Desk did not meet the scalable needs of the business and did not provide the required visibility of assets. Through implementing a consolidated CMDB, LEGO also planned to reduce asset support costs and improve financial planning.

 

Recommended reading

For more CMDB resources, check out the following whitepapers:

 

 

Interested in delivering more value from your Service Catalog? We recommend:

 

 

We’ve also produced how-to guides to help you build a business case for IT investment, successfully migrate to a new ITSM platform and learn how to integrate ITSM and ITAM.

 

If you’re looking for third-party analyst guidance on selecting a service management solution, download a complimentary copy of Info-Tech’s Service Desk Software Vendor Landscape and the 2015 Gartner Magic Quadrant for ITSSM Tools.

 

A full list of service management resources — including whitepapers, videos, presentations and case studies — is available in our ITSM resources library.

 

About us

Axios Systems
For more than 25 years, Axios Systems has been committed to innovation by providing rapid deployment of Service Management software. With an exclusive focus on Service Management, Axios is recognized as a world leader, by the leading analysts and their global client base.

 

Axios’s enterprise software, assyst, is purpose-built, designed to transform IT departments from technology-focused cost centers into profitable business-focused customer service teams. assyst adds tangible value to each client’s organization by building on the ITIL® framework to help solve their business challenges.

 

Axios is headquartered in the UK, with offices across Europe, the Americas, Middle East and Asia Pacific. For more information about Axios Systems, please visit us:

 

Top