Effective use of Exception Reporting in ERP implementation

In many of my ERP implementations, I am surprised to see the kind of customizations that I have been asked to incorporate to ensure that the 'User do not make any mistakes'. Simple ones include, 'Ensuring that the Employee code is numeric', 'The customer name is All Caps' etc. The complex ones include 'Ensuring that XYZ user enters the price correctly', 'The ABC user should enter only a particular type of Purchase Order' or that the 'DEF user raises sales order only for Channel customers'. I invariably end up customizing the application to meet the above requirements since standard applications have a limited capability in meeting some of the above requirements.

When I ask the organization why these customizations are required, after much hemming and hawing, the true reason comes out 'We do not trust our employees to be responsible. They will always make mistakes.....'

We are a theory X organization.

What is common to all the above requirements? As I see it, almost all of it tries to prevent user from entering an incorrect data. Most of the time the user enters incorrect data for two reasons. One, he doesn't know that he should enter the data in a particular format (Using All caps, Numbers etc). This is simply a process documentation/ training issue. Two, she has access to areas where they are not authorized to enter. This is an access control issue.

Or, finally there may be a fundamental problem in the organization that encourages employees to enter wrong data in the system.

One of the very powerful ways to identify the root issues is the use of exception reports. Once the control requirements are identified, these are very simple and logical and easy to design. There are two key benefits to use of exception reports. One, they help identify the root cause. If a user enters wrong data consistently, this may a simple case of giving her a training. And two, they ensure that some of the major issues come out in the open very early so that they can be identified and resolved. They also address the key issue with customizations in that they do not have any impact on future application upgrades.

Given the benefits of exception reporting, why do most organizations not go for that? There are many reasons. One, the implementation consultants themselves are not aware of the utility / benefits of exception reporting. Two, organizations are scared that employees will make mistakes and thereby their control systems will prove to be ineffective. The way to handle this is to have a combination of exception reports and control systems working together. And thirdly, generation of new exception report may be expensive to the organization. Finally, since exception reports are custom based reports, the customer is not able to see them in action at the requirement gathering stage and hence they decide on the customized controls.

I feel that it is the duty of the consultant to educate the customer on the benefits of exception reporting. It is my experience that many of the customers requirements are related to accurate data entry and minimizing errors and in this, the paradigm of exception reports can provide a lot of long term benefits to the organization.

What do you think? Have you 'sold' exception reporting to the customer in your implementations? What were the problems / issues that you faced? What was the result? Is it beneficial?