Developing a Customer Data Integration (CDI) toolFrederik De Win
In 2014, one of our clients (leading provider of packaging worldwide) sought a solution to bring structure to their customer base. They reached out to Keyrus who designed and developed the Customer Data Integration (CDI) tool.
CDI was built using the master data management (MDM) software Semarchy xDM. It reads customer data from over 100 ERP systems, allowing users (data stewards) to match and group customers that are the same. This process is known as de-duplication. I was working at this client for a while as a developer on other BI systems when I learned some of the basics of Semarchy xDM.
When I was asked if I wanted to perform the CDI upgrade I didn’t have to think twice: it was a nice opportunity to expand my knowledge on MDM and gain experience in analysis/development. After all, this was not just a simple upgrade. We wanted to make use of this project to involve the business and the data stewards. Let me take you through the process.
In order to get a better understanding of the current state, we started interviews with the various stakeholders. Their input was vital to the success of the upgrade. These stakeholders were of course the data stewards but also the finance and sales department. These departments rely on correct customer information and are therefore very dependent on CDI. Naturally we could not talk to each stakeholder, there’s 40 data stewards already. So we created a team of 5 dedicated key data stewards, supplemented by 2 people from finance and sales, to provide us with their insights and feedback. This was the first time I had to do interviews and it was something I really enjoyed doing. You gain a much better picture of the current state of the solution, what is good and what could be improved. Working with people is something I really like and this factor played a big role in starting a career as BI consultant. You don’t rely on machines and coding alone. You are part of a team and work with people from different departments of the client.
After analysing the various interviews we came up with the following high-level requirements:
- Simplify the navigation and layout
- Simplify customer de-duplication
- Make the tool visually more appealing
- Add a few extra features
- Ensure the system performance improves or at least stays the same
Some of the requested features were already built in the tool, for example a search function that scans the whole system. These are of course easy to set up. Other features needed to be developed by myself and this is something I really like about our job: we are professional problem solvers! Always looking for ways to translate the client’s needs into solutions that add value.
The next logical step was to plan the development cycle. Which requirements get priority, what are the milestones, when will testing take place etc. It is easier to work if you know what to and when to do it. With a planning in place I could start developing. I will not go into too much detail here as this is fairly technical. Some of the steps included:
- Cleaning the system of obsolete data
- Simplifying the various user actions/the layout
- Developing the additional features
- Preparing user acceptance tests and giving training
I must say that this is a period in which I learned a lot about the software but also about sense checking your own work. You build a solution and expect a certain behavior from your end-users. Unfortunately these end-users are usually highly skilled in changing the rules and breaking the solution :-). This was very insightful to me. A more senior colleague helped by reviewing my work, testing my logic and ensuring the solution meets the requirements.
The last important steps were the user acceptance and integration tests. We asked our key data stewards to run through an extensive list of scenarios. This was to ensure the upgrade covered all of the requirements and to check if we needed some final tuning on the solution. Since CDI is a hub for all the customer information, several systems rely on it. They read from it and we needed to ensure they could still do so after the upgrade.
With all of these steps finalised, we were ready to perform the upgrade and roll out the solution. I tested this extensively on our acceptance environment so I was well prepared… Having said that, there was still some part of me that felt stressed! I kept thinking of some worst case scenarios corrupting the database, killing the servers or worse having to rollback and postpone the upgrade. I would describe this feeling as a healthy dose of stress. After all, this is the moment you have been working to. You want this to go as smooth as possible. It felt a bit like taking an exam but I can say that we passed with flying colours!
We’re a few months post launch now. During this time I stayed at the client, ready to tackle any issues that could occur. Based on the feedback we gathered from the various stakeholders the upgrade was successful. The data stewards are very positive about the new layout, the improved simplicity of the tool and the performance. Finance and sales are satisfied with the added features. They now have an easier time to do their reporting.
The project is over now but that doesn’t mean I am no longer fully involved. Some minor change requests were gathered and sized and will be implemented by myself in the near future. Overall I can say that I learned a lot about the life cycle of a project and I hope you did too!
Any questions? Don’t hesitate to contact me: email@example.com