IT shouldn’t limit corporate agility
This summer’s Harvard Business Review focused on companies’ ability to adapt. Agility is high on every successful company’s agenda. Key to this success is the ability to execute. An unlikely bottleneck is appearing in the one department that should be bringing agility and speed. And it’s not even their fault! The IT department is victim of its own success. Indeed, in three decades, businesses have evolved to relying on IT for supporting most of their activities. Three decades may seem long but think of it: early nineties IT was limited to replacing typewriters and ledgers. A short period of point solutions was followed by a major effort to implement centralise IT around a single technology and, often, vendor. This was the golden age of ERP. We’re not saying ERP is dead but it seems the monolithic approach to IT is being questioned. Reasons often quoted are “ERP is expensive”, “one doesn’t fit all”, “we’re too dependant on one vendor”, etc. They’re all valid arguments. And we’re seeing more and more hybrid IT landscapes indeed where the core ERP is completed by functionality through adding best-of-breed solutions for instance. Also, M&A activity has given rise to companies running on multiple ERP’s. At best it’s the same vendor but often it’s not. As everybody knows, (IT) integration efforts are long and expensive. And the impact of having to change puts extra weight on people, especially in the case of an already stressful takeover. Instead of starting harmonisation efforts right away, businesses take a more strategic, long term approach.
The whole thing, whichever approach one takes is confrontational though. In a previous life, we sold a best-of-breed solution to a multinational that had ERP from a single vendor. But they ran two separate instances; one for each half of the globe. We focused on implementing our tool on the instance of the headquarters. This was a very complex integration and we were up and running in six months. After going live, our client would then do the same with the second ERP instance. This took them about a whole year. First question is why that second integration took so long. Shouldn’t it actually be shorter than the first one? The whole functional analysis was done and we knew after the first integration where to find and how to connect to the data. Unfortunately that’s not how things went. First, it seemed that the ‘other half of the world’ needed to be convinced of the initial functional analysis. Luckily, the ended subscribing to the original thesis but it took some convincing. Second, and that’s the big one, the second ERP instance was configured totally differently than the first one. Remember: same technology! Because they were separate implementations, not all data was the same in both systems and, even more difficult to resolve: not all data meant the same thing. So you’d find a data point “size” and it’d be different to the one in the other ERP. Reconciling metrics (i.e. centimeters and inches) takes work but it isn’t complex. Knowing that one SIZE measure refers to size of the pallet whereas the other refers to the size of the actual item is harder to discover. So the whole integration process meant they had to go through each data point and consult people from the business in order to get the correct interpretation.
The example above is real and it’s not a lone example. I’ve seen this happen many times. The cost to these enterprises is very high: longer implementations often involves paying external consultants, it takes internal teams off of their day job and it delays putting the solution into production. Lost savings or lost income from that delay is often forgotten from cost calculations! We’ve also noticed in several cases that people when questioned about the meaning of their data answer “they’ve asked me the same question for that other IT project”. This means that knowledge exists but is not managed efficiently. What’s worse than investing in something that goes unused?
The key message for IT departments is twofold:
- it can be avoided
- it can be solved beforehand
Set up a central, easily accessible repository for all your data. And don’t just record what you have, but include the where, how it’s defined (across systems if it exists in multiple locations) and what it means. Make this repository accessible to not just the IT department but ideally include the whole organisation. Besides being easily accessible, it should also be easily searchable. This avoids people wasting time having to ask others and waiting for answers. Such a repository avoids having to ‘find out’ on the job and avoids a lot of the time wasted on the integration project. At the same time, it also allows the hybrid landscape to be efficient.
The time dimension is the most undervalued one in business strategy. If anything, when decisions and actions are taken is more important that what is done. Some products are released only to flop only to become hits when another vendor brings it to market a few years later. Is the success due to that vendor’s genius or did timing play a bigger role? In our case, implementing that central repository should not be done when the need arises. Instead, it should be core to any company’s IT strategy. Setting up and maintaining a central catalog, dictionary and glossary for all your data allows for a smoother roll-out and maintaining of systems integration. And, done well, it can relieve IT of most support calls pertaining to data as business users find their own way through the maze of IT systems, whether they be single- or multi-vendor.
Maintaining such a central repository is like basic hygiene for IT and data departments. The more agility is demanded from companies in order to maintain relevance and competitiveness, the more attention should be put paid towards basic hygiene. It allows your workforce to act and react more swiftly and to the point whereby instead of resisting, they may embrace change.
