How many times have you heard the argument that customizing ERP is a sure road to disaster? The typical scenario cited to support this point of view will involve an older ERP system with multiple code changes implemented by the user. The vendor supplying the original product will not be able to support the modified product, because they have no clue what specifically has been changed within the code.
Now vendors are proclaiming all sorts of alternative ways of approaching this. Some will suggest software that facilitates customization without code change. Cincom Control offers extreme flexibility in terms of customizing the user experience through role tailoring. It’s a great approach and it does preserve the integrity of the product without forcing the user to totally adapt to the needs of the product.
But, before we go too far down that road of complete flexibility, let’s talk about the underlying assumption that drives this dilemma.
Software vs. User
Ask almost anyone involved if the software should adapt itself to the user or, should the user adapt to the software and the resounding answer will always be the former. Somehow, we have decided that we are always right and the software is always wrong. Perhaps this is an outgrowth of the customer is always right.
Think about it for a minute. Your company is going to spend a million dollars on ERP software. Your systems and processes are in such lousy shape that you are going to embark on a huge project that will ultimately touch almost everyone within your organization. The risk to your organization is so great that it is cost justifiable to drop all of that cash, burn up all of that employee time, effort and inconvenience to mitigate that risk.
Now, having accepted all of that you want to insist that you know better when it comes to certain requirements or methodologies built into your ERP solution? Seriously?
That strikes me as a kind of a non sequitur. That sounds like you’re paying to go to the Mayo Clinic and then arguing with the doctor about what the cure should be.
Okay, I’ll admit my example might be a bit simplistic. I’ll even own up to the fact that off-the-shelf software may not have everything built-in that you need. There may be processes or methodologies built into some products that aren’t really applicable to the business you are in.
But, I still think there are frequently changes made that just might deserve a bit more consideration.
The software required methodology might just be the kind of change needed to really improve the organization.
I would submit that sometimes, the organization should change, the customer should adapt. The software required methodology might just be the kind of change needed to really improve the organization.
Here’s a small example.
I know of a product sold to local government entities. It’s designed to be an off-the-shelf system that runs the day-to-day affairs of municipal governments. This package was for the most part concentrated on the financial aspects of local government operations.
Most, if not all of these systems have built-in financial controls to prevent unscrupulous employees from helping themselves to taxpayer provided funds. They will typically not allow a single individual to authorize, execute and record expenditures. They also do not allow folks handling expenditures to also handle receipts. These are typical financial controls that any auditor would look for during an annual audit.
But what about smaller entities that simply don’t have the headcount required to cover the distribution of authority?
The easy solution is to modify the code by eliminating the checks and balances built into it. The result is a one-person finance department that has no regular, day-to-day oversight. The same person handling receipts is also handling payments.
This creates a situation that is very efficient but is also ripe for abuse. Would it not make some sense to have some kind of check-off? Surely, another department head or perhaps an elected official could provide periodic cross checks.
It’s a small but graphic example of what happens when you unplug processes that are built around industry standards. It’s easy to see why careful consideration must be given to modifying software to “make life easier” for the end user. It may well be that those changes are opening the door to big headaches down the road.
Obviously, some customization is inevitable for many implementations. The best systems are designed to keep the customization restricted to the application layer of the technology stack. The application itself is designed to be tweaked to fit the end users needs.
Just be sure that the customization is working for your best interest and not because it’s easier to change the code than to redesign the process.