The term business process reengineering first emerged in the 1990s. Its purpose was to focus on the business and process flows within an organization, with the twin goals of making them more effective and efficient.
Since systems are integrally woven into nearly every business process, reengineering those processes often comes down to the orchestration of systems and applications that functional areas of the business use.
IT meets with end business users to reengineer and improve business processes. The focus is on what types of data and applications these processes need, and not so much on elements such as ease of use.
Unfortunately, not addressing ease of use can be a catastrophic oversight. I witnessed this firsthand some years ago when I was working as a systems analyst.
My assignment was to get an internal system working that users refused to use. This system was a dairy feed ration system. It configured a mix of ingredients for animals with a specific herd profile. The system was written by an extremely talented scientist and software developer. It gave the company a nutritional and cost-savings advantage over ration formulation systems that competitors were using.
The problem was that users throughout the company wouldn’t use the system! Instead, they preferred to use the same commercially available software that the company's competitors were using.
I soon discovered why. For all his brilliance, the system developer had never considered that a user-friendly interface would be important.
We set to work to reduce what had been layers and layers of drill-down menus into more streamlined, single-page entry screens that could accomplish everything the users needed to do. After six months of work, we had moved 25 remote field offices onto the new system.
Human Usability Is Still a Problem Today
Too often, software developers with limited knowledge of how humans and machines interact are tasked with developing processes and systems. Users react by resisting the business process or system change. Worse yet they may refuse to use a new process or system at all.
What can IT do to improve the reengineering of systems and business processes?
1. Include human factors engineering in system and process design testing
No one knows the plusses and minuses of how business process flows, and systems operate better than the end users themselves.
A user in finance, for example, already knows all the bottlenecks he or she needs to work around. This is exactly the person who should be front and center in any business process or system redesign.
Users who already know the business process flows should be integrally involved in a business process reengineering project from start to finish. Also, human usability should be a key element in QA testing and checkout.
2. Perform a complete system and business process integration
The reengineering of a business process or system should never create downstream issues for other processes or systems. If a given process or system interacts with other processes, steps or systems, the needs for total process and system integration should be carefully documented, and the reengineering deployment plan should address them all.
There is nothing more frustrating for users (or customers) than to encounter a new system or process that is only “half done.”
A prime example is when a customer calls a company with an account problem. The phone system automation passes the customer from point to point or even from person to person. Each time the customer is passed to a new point or person, he or she is asked again for an account number or other identifier.
The customer gets frustrated from having to repeat an account number because systems and processes aren’t integrated. Meanwhile, the users who are helping customer get frustrated because they have to hear about the issue repeatedly from multiple customers. Bottom line: In a well-integrated system and business process, that customer should only have to give an account number once.
3. Adopt a process that recognizes software as malleable
The goal of a business process reengineering project should be to make the new process simple and seamless. For this to happen, any software, whether it is developed internally or purchased commercially, must be subordinate to the requirements of the business process.
Here is where companies get caught: They purchase or develop a piece of software. The software doesn’t quite match up with the new business process, so they make the users adjust to the software instead of making the software adjust to the business.
A business process should never be “hard coded” to how the software has to work.
4. Always plan for business process overrides
There always will be circumstances in any business process when it becomes necessary for someone in authority to override the normal flow of a business process.
For example, this happens in retail, when a customer is supposed to get a discount on an item, the system isn't programmed to automatically provide the discount, and someone must override the system to get the transaction done.
Adding manual overrides at appropriate points in any business or system flow should be an integral part of any business process or system reengineering effort. Your users and customers will thank you for it.
What to Read Next:
Reinventing the Customer Experience, One Process at a Time
