innovation starts with i

There's a trend in IT to prefix terms with an i in a mistaken belief it automatically builds a culture that the organisation wants. If you really want to change the culture of IT, all you need to do is be innovative, it already starts with i.

I remember the story of an IT organisation where ITIL was already in place but they hadn't gone further and implemented Constant Service Improvement. Services were seen as reliable, but costly and no longer responding to customer requirements. Rather than talking to customers and staff, the new CIO followed the usual runbook and started reimplementing ITIL fundamentals again.

This was in an industry with high touch customers, so reinforcing metrics like call closure rates and further centralising IT just frustrated staff and further infuriated customers. Furthermore having IT staff close to the customers had provided the flexibility that the processes lacked. Installing more bureaucracy in an environment where bureaucracy was seen as part of the problem further compounded the issue.

A better approach would have be to understand this and improve this customer engagement capability rather than roll it back by centralising IT. In addition to this, in an attempt to build a new culture IT was rebranded and banners were hung from the ceiling of the IT call centre. On the side facing the customer there was a word prefixed with i, on the side facing the staff they were blank. The outward image wasn't one that matched the internal one.

From this example we can see that building culture isn't simply a matter of prefixing a word with i. You need to understand your current organisation, your staff and your customers. Many organisations already have a framework like ITIL in place that is delivering the base IT services well, but customers are finding those services don't have the level of flexibility they require.

The obvious thing to do here isn't to install yet more bureaucracy, but understand the problem. Understanding the problem would have led to the realisation that this was like many ITIL implementations where the basic processes and metrics had been implemented but a culture of Constant Service Improvement hadn't been. 

As we know IT changes rapidly, and processes need to be able to change in response to changing requirements. Putting a program of Constant Service Improvement in place, and allowing processes to be modified to meet changing requirements will help build an innovative culture. This requires leadership to drive a culture that sees ITIL as a framework rather than a doctrine, and sees customer satisfaction metrics as more important that call closure rates.

Obviously we still need metrics like call closure rates, but if processes are not delivering what customers require and there isn't a program of Constant Service Improvement in place, then both staff and customers are going to be increasingly frustrated. If the process isn't delivering what customers require in the timeframes they require, forcing staff to close calls to meet metrics is just ludicrous.

Rather than working on resolving the issue staff bounce the call between teams or more ridiculously close the call and ask the customer to reopen the call simply to meet some arbitrary metrics. It's no wonder customer satisfaction metric weren't being taken.

We've all experienced dealing with organisations where this happens. It's incredibly frustrating. Running an organisation by these kind of metrics alienates both staff and customers. It also reinforces bad organisational culture. The Service Manager should be using customer satisfaction metrics and customer engagement to be constantly improving the service being delivered. Services should be tailored to customer requirements.

Changing IT culture takes genuine leadership from the top, not prefixing a word with an i. It requires a genuine desire to change the organisational culture for the better. It means talking to your customers and staff to understand where the current processes work and where they don't, not installing more bureaucracy.

To cope with the increasing rate of change we need to create a culture that is agile and flexible at the point of customer engagement, and rock solid where it needs to be. It means enabling and empowering staff to get things done. It means building teams where staff understand their value to the business and are able to contribute in ways that improve the business.

In order to do this you need to understand what is and isn't working in your current organisation. If you don't have a baseline for the organisation how can you measure your improvement. While there are many frameworks available like ITIL, implementing them without understanding your organisation can leave staff focused on metrics like call closure rates rather than customer satisfaction. 

Contact us to discuss how we can help your organisation to be innovative, and increase your agility, flexibility, and profitability.  

Configuration Measurement Database

Configuration Measurement Database: From Monolith, to Management, to Measurement, and beyond...

 

As we know the M in the abbreviation CMDB is an abbreviation for Management. In reality, in a lot of cases we'd argue the M is actually an abbreviation for Monolith, rather than Management. We'd additionally argue that in order for a business to gain true value and insight out of it's CMDB, M should be an abbreviation for Measurement. 

Without regular measurement there cannot be improvement. Without improvement there cannot be increases in customer satisfaction. Without increases in customer satisfaction there cannot be increases in revenue.

Firstly lets get started by discussing what do we mean when we refer to the M in CMDB as being an abbreviation Monolith.

In a lot of traditional ITIL implementations of CMDB we see the CMDB referred to as the authoritative source of information, yet there is no easy mechanism for updating this data. If there is no easy mechanism for updating this data then there is only one time it will ever be correct, that is when it is being entered. Five seconds after entering that data it is out of date. It can be argued having no data is better than having incorrect data. Incorrect data leads to incorrect assumptions. Incorrect assumption lead to poor planning and poor budgeting.

It doesn't matter how good your Configuration Management process is, if it isn't automated, then invariably it's going to be skipped, or fail at some point. Whether it's due to human error, or insufficient time, the data in the CMDB is going to be out of date. As the number of items you are managing scales up, the impact of this can be catastrophic to the business, especially where security is concerned.

For example, lets take the recent OpenSSL Heartbleed vulnerability into account. While this was a very well communicated issue by software supplier, in many cases the communication about the level of exposure by organisations using the software to their customers wasn't. If your CMDB isn't up to date how do you have any chance of ascertaining your level of exposure? 

More importantly how do you determine the impact to your customers? If your CMDB isn't kept up to date you don't have the capability to respond in this manner. You additionally don't have the capability of assessing the cost and impact to the organisation. Therefore, if the CMDB updates are not automated, it becomes a monolith, or monolithic in nature. It rarely, if ever gets updated as the process to do so is to onerous. 

Here's a few questions to ask yourself:

  • Can you quickly/automatically report on your license exposure for a specific product?
  • Can you quickly/automatically report on the versions of software you have deployed?
  • Can you quickly/automatically report on the firmware versions you have deployed?

These are common questions that come up again and again in relation to IT management, especially around budgeting or auditing time. If the answer to any of these questions is no, then you don't know the true cost of delivery of your infrastructure. In an era of increasing competition and dwindling margins, not knowing this kind of information can have a large impact to an organisations profitability. 

Secondly, lets conclude this discussion by examining what we think the M in CMDB should actually be an abbreviation for Measurement, rather than Management. Maybe you've got beyond the monolith stage and your updates are automated. The next question to ask yourself is what are you doing with this data? Are you just managing it? Or are you measuring it? 

If your CMDB reporting isn't automated, then you are not doing regular measurement of your configuration management. You are only doing adhoc baselining. So what do we mean by measurement? Here are a few simple questions to ask yourself to determine whether you are using your CMDB for measurement rather than management.

Ask yourself:

  • Can you report on the number of configuration changes that happened to a system outside of a change window?
  • Can you report how long it takes for a configuration change to be rolled out to a set of systems?
  • Can you report how many configuration changes needed to be rolled back?
  • Can you report on the number of configuration that were successfully or unsuccessfully applied?
  • Can you report on the number of systems deployed that met the baseline configuration?

If the answer to any of these is no, then you are not measuring. These common questions relate to common task which consume time, and if not resolved lead to outages. If you are not measuring these then you don't really know the true cost of delivering your service. You similarly can't quantify the impact they are having on your organisation in order to develop and correctly cost a plan to resolve them.

Would you like to the M in your CMDB to be an abbreviation for Measurement?

Contact us to discuss how we can help you leverage your CMDB to allow your organisation to be innovative, and increase your agility, flexibility, and profitability.