One of the difficulties in advising a client on an implementation project is trying to bring awareness to situations that a consultant has seen time and time again, yet a client has never seen because they haven’t been through an implementation project. How do you convey that something is important to concentrate on when a client “doesn’t know what they don’t know” as the old saying goes. The very definition of “you don’t know what you don’t know” means that you don’t know how to plan accordingly. You can’t monitor progress; you can’t measure for accuracy. It’s in these situations that it is even more critical for the consultant to communicate the need to understand and conceptualize difficult topics.
In that vein, today’s topic is Data. Data is the foundation of any business. It’s often easy to tell when a company is struggling with data in their current system. Physical documents have notes scribbled on them. There’s paperwork with new instructions attached at various points in the process. Users often repeat the same adjustments time and time again at a transaction level, rather than correcting it at the master data level. Or they simply don’t know where the information is stored in the first place.
But when implementing a new system, converting existing data into items that make sense in the new system is integral. Oh so often, the business owners of the implementation are wearing many hats - still trying to do their day-to-day jobs while learning about the new system and explaining business processes to the consulting team. Data seems like it has a small part to play when the overall project is considered, however there are thousands of fields of data in any system stored in hundreds of tables. The importance of spending the time to map fields from the old system to the new system seems tedious and overwhelming, so the task often gets swept under a rug after a few introductory workshops. Assumptions are made both by consultants about how data is used in the current system and by the users thinking “oh the consultants have seen it all, they know what to do for me.”
Yet the easiest and often most dangerous way to fail at Go-live is to not have spent enough time on data conversion. When a steering committee asks us what is the biggest risk to the project that can be minimized, we often answer “There’s five! Data, data, data’s sister data, her boyfriend data, oh and did I mention data?”
A few key examples of data that can be incorrectly converted without a proper understanding of the old system and the new are things like: units of measure, pricing tables, and quantity conversions. Other considerations are more technical in nature. The same data point can have different data types in one system to the next which would require an additional conversion step. Another example, field lengths are not standard, so the way that the data is presented to users could change.
Tips for the Day:
- Lean on your consultant’s knowledge of their system to make a smooth transition.
- Point out critical data points during process blueprinting in order to have breakout sessions.
- Data areas of extra concern are where manual calculations and adjustments are made. Focus on having in-depth conversations with your consultants regarding these data points.
- Provide concrete examples in the current system of common errors made by users.
- Request a copy of a data conversion timeline from your consultant so that everyone can stay informed and on track.
As you can see data conversion plays a crucial role in any implementation. However, it is a completely manageable one, if treated with the time and effort that is needed. Your Go-live will improve significantly if the effort is put forth.
