Taking control of your ERP data is more than just a lofty ideal. It's a real-life business problem, but one that can be solved with a well implemented, well managed ERP solution. Admittedly, I have a tendency towards obsessive compulsiveness. Compounding the situation, I am predominantly surrounded by others who also share this malady (accountants, other consultants, etc…). This condition leaves me disproportionately worried about data consistency, data structures and data in general. For anyone wandering onto this blog that doesn’t understand (I’m not just picking on sales and marketing here), just take my word for it that this kind of stuff can actually keep a generally functional person up at night.
Data Can be Beautiful
In theory, data is quite beautiful with full uniformity, forward-looking structures that anticipate unforeseeable changes in the business, and authors (users) who all think alike and never make mistakes. The reality, however, is that data quickly gets messy and needs to be managed.
It needs to be managed because ultimately your ERP solution must provide information that helps you run your business. At best, if the information you are trying to get out of the solution requires you to work “around” your data, you are wasting resources that could be better directed elsewhere. At worst, your ERP data challenges are providing misinformation that could be leading to poor management decisions.
To better convey the idea of controlling your data, let’s consider just four types of inefficiency that are keeping you from it.
4 Types of ERP Data Inefficiency:
- Inconsistent data entry. Example: Some vendors are numbered V.XXXXX and others are numbered VEND.XXXXX, while the addresses have been entered in all upper case for some and in proper case for others.
- Duplicate data. Example: Customer ABC Inc has been entered into the system five different times, each with slightly different naming/numbering conventions or address formatting. Typically, all five of those customers now also have associated posted history.
- Orphaned transactional data. Example: A multitude of old purchase orders are “stuck” in history, dating back years, because they cannot be deleted or posted in their current state.
- Reports or queries with hard-coded rules. Example: A sales performance report exists where the third character in the item number drives an alternate treatment of the margin calculation, but only in odd-numbered months that start on a weekday.
While all of these issues could theoretically be avoided with more predictive designs and dedicated “gate-keepers” signing off on every entry made in the application, that is not normally practical (as an aside, I would cite item creation as a possible exception). On the bright side, each of these situations preventing you from taking control of your ERP data can typically be addressed through a brief review of data and reporting and a little cleanup work - either coded or manual.
Quick Tools & Black Boxes
Quick tools can often be defined or written to renumber or cleanse data (ex: numbering and address uniformity across all vendors), merge records (ex: combining five customer histories) and address orphaned data (ex: systematic purge and cleanup of purchase orders and contingent data).
A bigger challenge in the effort to control your ERP data, and one requiring a bit more reflection, is the situation where reports or functions in your solution have been written with hard-coded rules based on attributes not controllable or transparent to the user. This issue often compounds over time and can become a more expensive endeavor. I often refer to these as “black-boxes”. Just as they require a bit more time to properly identify and solve, they also provide the biggest potential for savings down the road.
Upgrades & Data Review
Upgrades certainly provide an opportunity to perform these data reviews and often give an organization a reasonable excuse to “table” these issues until such a project is approved. In truth, the data review and cleanup exercise is usually no less expensive during an upgrade project than it would be separately. The only advantage an upgrade provides is that everyone is forced to think about the solution during the course of the project. Re-implementations are the exception, where data may be left behind or remapped.
If the examples above resonated with you, then your application may be a candidate for a data review. Rest assured, this is often not due to poor original design or bad business practices, but is more often the result of shifting company focus, new internal processes, or ever-evolving business rules (and possibly disproportionately low budgets when new reporting is needed). Regardless, the return on investment for taking control of your ERP data is almost always justified in these cases - even if you don’t personally share my affliction.
by Stoneridge Software