Avoiding Project Data TraumaBy Katrina Burke, Head of Consulting – Enterprise Solutions on
So, what should a customer do to avoid those pitfalls? And, what role if any should a customer’s system integrator play in the data conversion process?
As a customer, the golden rule to abide by is: plan early and get going as soon as possible. It is a cruel truism that data conversion is often an afterthought in any implementation project. Too often organisations are mesmerized by their desire to start using their shiny new software toys and adopt a “we will worry about that later” attitude to data conversion. But the reality is that without a smooth data conversion process the build phase will be plagued by delays. A successful go-live depends on an organisation ensuring its data can be consolidated, exported and mapped into the new system.
Ideally, the responsibility for data conversion should be clearly articulated in the tender document. A customer should outline exactly what it anticipates doing itself and what it expects the system integrator to take on. Deciding who does what is vital, because if there is no clear understanding up front the system integrator will assume the customer is responsible for the extract and cleansing of the data from all legacy systems. When it’s time to begin loading, the system integrator will expect the customer to provide it with a single file ready for upload and reconciliation. If it can’t do that successfully problems begin to mount quickly. Imagine the time and cost implications of a 70% error rate on the first data load. Very shortly the system integrator will be asking for more time – and more money, to iron out the data kinks on subsequent loads.
To avoid that scenario – ideally before the tender document hits the market – a customer should take a deep breath and assess the current quality of its data. There is a good chance that it is in a poor state, because typically, it is one of the underlying reasons for implementing a new system in the first place. If the legacy system(s) suffers from poor user uptake or no longer lets the organisation undertake the processes it needs to do, it is more than likely that the data that resides in the system is not up-to-date. Yes, a new system will help the organisation realise new business efficiencies and streamline procedures for end users, but it needs reliable data to drive those activities.
Understanding the gaps in the data and identifying a plan to rectify them is key because the cleaner the master data, the smoother the data conversion process will be. Customers should build this essential activity into their plan and appoint a data lead that owns the process of extracting and cleansing the data. Typically, the data will be living in a variety of disconnected locations – such as in separate systems and on personal hard drives – and it takes a coordinated effort to bring it all together.
I have often said that the implementation of an SAP solution has huge change implications because it will change a process driven organisation into a data driven organisation. You will find that if the data you enter up front in an SAP process is complete and correct, the processe ‘just happens’. No longer is there a need for manual check points and decision making because the data was collected early to drive the process end to end. This places even greater emphasis on the data conversion activity.
In summary, never assume the system integrator will own the data conversion. It’s your data and only you know how to collect and correct it accurately. If their help is needed make sure that is stipulated in the tender document. The system integrator will create the tools to load the data into the new system, but without prior agreement they will assume the data will be given to them in the format requested by the project team – all nicely consolidated into a single file. Getting the data to that state takes time and cannot be done by magic – it is a process that requires planning and, more often than not, a great deal of hard work.