Gone are the days of implementing a single Integrated System (a.k.a. ERP) to support all business processes. Instead, organisations are opting for the use of multiple systems (from multiple vendors), following the premise of best-of-breed for each application area.
Regardless, of the selected approach for choosing the various systems in an organisation, all of these systems should be implemented according to two fundamental principles for Data Management:
- All of these systems work with data following the workflow of Capture + Process + Store + Report. Where Reporting is a must, always.
- In an organisation, these systems are always part of a bigger ecosystem; therefore they do not exist in isolation. At some stage, these systems will need to work together with other systems.
Unfortunately, these principles are not always followed, and the post-launch implementation of the missing features becomes a project by itself requiring the investment of additional time and money.
5 Common Issues of Implementing Best of Breed Systems
The following are some of the common issues found by end-users post project implementation. These problems reflect the lack of one or even both of the principles described previously:
- The system has been implemented, but it doesn’t provide all the reports we need to run the operation.
- We have access to the system’s database, but we cannot make sense of it. Tables and columns use names we cannot understand, and they don’t reflect the terms used in our business.
- We don’t have access to the database, the only way to extract data from the system is by running a report and then exporting the report’s data into a CSV or Excel file.
- We want to use a back-end process to integrate this system with another one so that we can avoid duplication of effort for manual entry.
- The system has the reports we need, but we would like to use the datasets of those reports to visualise them in a different format.
How to Avoid or Solve These Common Issues?
How easy or difficult it is to resolve post implementation issues depends mainly on how big the system is, on the underlying technologies used to store the data and the level of customisation used to implement such system in your organisation.
Like it or not, there is always some dependency on the system’s vendor expertise when wanting to access the database and giving meaning to the data store in it.
Here are a few tips on how to address the problem of accessing the data and making it available for other uses:
- Ask the system’s vendor to make the data accessible in the shape of a Reporting Database. This database should be well documented and easy to use when data is needed for reporting or for any other downstream systems.
- Use third party tools or middleware to abstract the system’s data structures into a metadata layer that reflects your business processes. Use these tools to extract the data into a reporting database and create the reports yourself.
- An extension to asking the vendor for a Reporting Database is to ask them also to build the reports.
- Ask the vendor for API’s or Webservices you can use to integrate this system with any other internal or external system. These Webservices, as well as the Reporting Database, must use names that reflect the terms used in your business.
- Involve your internal resources during and post project implementation. Working with the vendor will allow your team to learn how to interact with the system’s back-end and where to look next time there is a need for a new piece of data.
- The best advice is always prevention, and to achieve this, it is always a good idea reviewing the overall Enterprise Architecture and how the new system will interact with other systems in the organisation. Also, the precise definition of requirements for data capture, processing and reporting will make sure there are no surprises by the end of the project.
