In this day and age, the phrase Enterprise Resource Planning (ERP) seems almost anachronistic. After all, with the rise of the cloud and service oriented architectures, the ERP gets no media love and often inspires scorn due to the solution's perceived inflexibility and monolithic approach to service.
The cold, hard truth, though, is that many an organization still runs on this stalwart technology platform. In higher education, for example, enrollment/admissions, student life, financials, grades and even fundraising all operate by virtual of these tightly integrated platforms. Moreover, that doesn't appear to be changing anytime soon. The ERP does and will have a significant presence in the organization for a very long time.
That doesn't mean that, once the ERP is implemented, that all innovation and progress simply stops until the next major upgrade or replacement takes place! Rather, the ERP has become the center of a whole, with any number of third party services linked to it. Further, not every organization will stay on a single ERP forever. As an organization grows and evolves, a new ERP may become necessary.
In today's fast-moving and IT-centric environment, there are a number of ERP rules that should be observed. Which rules apply will depend on the situation at hand; not every rule will be applicable 100% of the time.
Rule 1: Don't migrate to a new platform with dirty data
Unfortunately, "dirty data" is and will probably remain a problem for a long time. Dirty data happens when people ignore data entry standards, when there are no data entry standards, when data is entered inconsistently and when codes and data standards "drift" over time. Of course, these are just some of the ways that data gets dirty. However it happens, though, it happens.
In some cases, organizations take a "blame the ERP" approach. Rather than correct processes that may have led to inconsistent data, they lay the blame at the ERP vendor's doorstep and decide that the only way to clean up is to move to a new ERP. Yes... this really happens.
In these cases, there are a couple of ways that a migration can take place:
- The data can be cleaned in the legacy system and then migrated to the new system.
- The data can be cleaned on the way over to the new system through the development of data transformation matrices.
I've seen both methods done. No matter what, data translation matrices will almost certainly have to be created for an ERP migration, so the thinking is that a few more won't hurt anything.
But, there's a huge downside. There's no really good way to quickly and 100% accurately "fact check" dirty data that's been run through a ringer. Rather, when possible, clean the data in the legacy system before moving it. This way, existing processes and reports can be tested with the newly cleaned data in a known way.
Sometimes, time constraints will prevent this from taking place, but be aware that migrating dirty data and cleaning up on the way or at the end is a major risk that needs to be considered.
Rule 2: Migrate for the right reasons
Previously, I mentioned that some organizations make the decision to migrate to a new ERP for the simple fact that their data is dirty and, as a result, reporting is a mess and automated processes simply break. Further, too often, organizations do a great job getting people trained when an ERP is implemented but then end the training programs.
Before you decide to move to a new system, ask yourself a few questions:
- Would clean data solve your problems? It's much less expensive to clean data than it is to move to a new system.
- What kind of continuous training program do you have in place? None? Get one! Get your people trained up on the current version and its capabilities before you leap.
- Do your people take some responsibility for their own training? If the answer is no, you have a bigger problem. The end user must be an active participant in the training solution, not a passive viewer.
- Is IT viewed as the training department? That's not IT's job and if that's the expectation, it's probably not going to be successful.
Rule 3: Engage your ERP vendor
If the last time you talked to your vendor was when you signed your ERP contract, you're doing it wrong. You probably pay a hefty annual fee for ERP support. Engage the vendor! They see the same problems you're seeing in a multitude of environments and may be able to help.
In one organization at which I worked, staff perceived the ERP as poor software primarily due to training issues. The ERP vendor offered to perform a free assessment of the situation that could be presented for action. Yes, they had a vested interest, but it was enough to loosen the purse strings for access to training and conference funds.
Rule 4: Integration is king
The rise of the cloud presented particular challenges for the ERP. By their very nature, ERPs are not all things to all people. They are most things to most people. Third party solutions-sometimes cloud-based and sometimes not-will fill the gap.
Any third party solutions that are deployed should be a part of the whole and not just tacked on. If a solution requires major rekeying of data on a constant basis, it's a non-starter. If a solution can't sync data back and forth, it's a not starter. There are too many god solutions out there that can integrated into your software to choose one that's going to make life miserable for your staff and mess up your data.
Although cloud has become a great buzzword, many companies still run on the tried and true ERP. By following a few simple rules related to either maintenance or migration of an ERP, you can maintain insanity around these process workhorses.
Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive with CampusWorks, Inc. Scott is available for consulting, writing, and speaking engagements and can be reached at firstname.lastname@example.org.