Life after merger: data better together or apart?
As companies expand they restructure, start new initiatives, acquire competitors, and in times of hardship they ditch unprofitable business lines and cut staff.
But change is an inevitable part of business, with an equally inevitable impact on IT systems – especially when two departments or organisations join forces.
Mergers most often aim to achieve efficiencies, for example to reach a broader customer base without doubling the size of the organisation. Just as there may be duplication of roles between the companies (and painful redundancy programmes), it may be equally inefficient to run two human resources systems or customer databases or accounting packages.
How easy is it to merge two sets of data? Plenty of obstacles can get in the way, including subtle differences in how terms are defined.
In sales for example, one organisation’s “lead” can be another’s “opportunity”, and one customer database may be more realistic than the other. Merging the two would mean diluting one and over-egging the other.
Data quality can also be a challenge. Data can be incorrectly entered, with words misspelt and fields poorly linked. Many organisations rely on their own shorthand to reflect domain knowledge – not entering full address information for local customers, for example, or using secret codes to indicate a bad payer or a handle-with-care client.
And the primary tenet of good software design – to separate the data logic from the business logic – is frequently ignored.
From simple code that validates address fields to fully fledged escalation workflows or critical event flagging, all can happen within the data layer, but such extensions can add a great deal of work to the merge.
In merging two systems, you will need to assess the approach you wish to take. You may be looking at two databases that share the same data definitions and front-ends and have a minimum of customisation.
If both organisations have been using the same commercial package or online service and followed the manual to the letter, you are in the enviable position of simply having to import one set of data into the other.
Even in this case, however, you should take care to avoid risks. It is a good idea to set up a test version of the database, via cloning or export, rather than just going for it with a live system. (Who’d be so stupid? Well, seen it, been there.)
The chances are you will find customisations that have more impact than you would expect, for example an obscure yet important extra field created in one system but not in the other.
Running a trial is essential. If it reveals complications, such as data quality issues or domain-specific extensions, then you will need to cost the approach you decide to take. The cost of merging two systems may well exceed the overheads incurred by running them in parallel.
Where a big-bang transition seems prohibitive, it may be better to keep both systems running
There are no hard and fast rules about how, or indeed whether, to merge two systems. You may be able to devise an interface, or use one system for current customers, suppliers and products, say, and keep the other as an archive, or build a new front end which draws information from both.
Where a big-bang transition seems prohibitive, it may be better to keep both systems running, migrating subsets of the data over time. Not ideal, but it all comes down to numbers.
On the upside, a merger of two systems may provide an opportunity to realign business processes and working practices. Organisations and the people in them might like to believe they are unique, but there is usually room for alignment with what is considered best practice. A new IT system can act as a lever that gets people working more efficiently.
Whatever the chosen approach, most people will see it as working with a new application. From small changes in terminology and tweaks to processes to learning about whole new capabilities or practices that are no longer acceptable, users will require training.
If a company is only as good as the data it manages, it is the people involved who have the biggest influence on that data. ®