In with the new, out with the old

Publish date:

Last month I was involved with a company which had implemented a new central application, based on an off-the-shelf package. It had been a difficult implementation on many levels: not used to pre-built applications meant tuning it to the company specifics was more difficult than in their home-grown application; old structures did not fit the […]

Last month I was involved with a company which had implemented a new central application, based on an off-the-shelf package.
It had been a difficult implementation on many levels: not used to pre-built applications meant tuning it to the company specifics was more difficult than in their home-grown application; old structures did not fit the new structure; old data was of such quality that the new application did not allow it in; the opportunity was taken to fundamentally restructure the client trees.
This last level, the restructuring of the customer tree, was a long-standing wish and finally they took the opportunity.
A good choice from the business perspective: better view on the Customer organisation and no more redundant copies of contracts on lower levels of the organisation.
Unfortunately, due to the complexity of the data-conversion, only those contracts that were still in use, were actually converted. This meant that the vast history was ‘left behind’ in the old system.
Goodbye customer history. Goodbye risk profiles. Goodbye loyalty profiles.
Granted, they had taken a final snapshot and moved that over as well, but a rolling 60 months of history on the customers needs, well, 60 months before that is fully active again. But sometimes you have to take drastic measures to move forward and get rid of the old data which is holding you back. And the guys and girls of the Data Warehouse can tie everything back together.
And that is indeed why I was called in: “make sure we get our history back but do not pollute our brand new system.”
Our challenge now is to get the information out of both systems, remove everything from the old system that has been converted (avoid duplication) and try to link the old customer tree to the new customer tree, the old contracts to the new contracts and the old events to the new contracts. Difficult but doable (at least for a good 90-95%), particularly because the new system has, in some places, link-files to the old keys.
In some places. It is our common feeling that had they known that the merging of the history was required, more link-files would have been created, which would have helped our effort further. But we might just have enough data for the majority of the data.
So, with a bit of luck and some more bits of hard work, we will be able to go from 2 client trees back to 1. And we are quite confident that we can do this.
Conclusion is that with a bit of forethought on how to preserve your history without polluting your brand new application, you can have the best of both worlds: a neat-n-clean brand new application and, on the side, a Data Warehouse with all your (on-going) history.
A very satisfying solution.

Related Posts

Financial Services

Who needs high-code developers? Citizen development is here for Financial Services

Date icon July 22, 2021

Why does IT let business wait for months to deliver low-hanging fruit process improvements if...

Insights and Data

Seven key lessons from data-sharing masters

Zhiwei Jiang
Date icon July 20, 2021

Three in five organizations only participate in low-collaboration data exchanges. But,...

Artificial Intelligence

Decoding trust and Ethics in AI for business outcomes

Anne-Laure Thieullent
Date icon July 19, 2021

From our AI and the Ethical Conundrum report, we know that 70% of customers expect...