Business Process Automation and How it Relates to OCR
Business Process Automation (BPA), also known as office automation, is the field concerned with identifying applications in a business that can be automated, then designing and implementing a solution. Unlike other areas in business, it is usually easy to make a business case for business process automation as any successful installment of such a system will reduce a Company's manpower costs. Thus, with BPA it should not be difficult to show a return on investment (ROI) in some reasonable time.
So if the challenge in office automation is not justifying the installation of an automated system from an ROI perspective, where do the difficulties lie?
There are at least 3 issues that typically get in the way of a company deploying an application-specific automated system (ASAS):
- engineering-specific obstacles to overcome
- integration into existing workflow
- modification of existing processes
Let's review each of these issues briefly.
Office Automation is generally not trivial and out-of-the-box solutions usually do not work. It is easy to get frustrated when your IT department can't get the problem solved. Fact is that most automation solutions are complex, push the envelope with respect to current technology, and need to be engineered by experts.
Q: But if the automation venture has a strong upside but involves some risk, how do you minimize your Company's exposure and come out on top?
A: Have the specifications for the working, automated system very precisely defined before approving the project. This way there is no ambiguity as to how the system will operate. If the system operates to specifications, then the Company's IT department is sure the system will end up going online, and paying for itself. In addition, the Company should leave most of the risk with the automation engineering company, so that there is very little financial exposure until the system is up and running. On the other hand, the automation company (e.g., CVISION) will take the job only if it's sure it can get the job done to spec. In addition, there needs to be a significant upside for automation company once the system is operational for taking the risk in design, development, and implementation of the automation system.
Integration into existing workflows
Of the 3 issues listed above, this one is probably the easiest to overcome. In most companies, an automated system would replace some system already in place. As a result, it must be integrated into an existing workflow. This is usually straightforward engineering, with no research component and little risk, if any. Thus, if the automated system will show a clear ROI to the Company once operational, the integration component should not get in the way of making the project viable.
Modification of existing processes
Many automation projects require some aspect of redesign in order to satisfy some of the specifications for the project to be feasible.
Sometimes, in order for an automation application to be successful, certain processes within the application need to be redesigned. In our check deposit example, this was true for many Banks. For example, a financial institution had to redesign their check deposit forms to support automation by requiring that the deposit total amount be entered twice. Similarly, many automation projects require some aspect of redesign in order to satisfy some of the specifications for the project to be feasible. This part of an automation project is a little tricky since often more than just one group of the Company may need to get involved once issues like form redesign come up.
The relevant decision factor here is, and should be, return on investment. If someone at the Company is convinced that the automation project will yield the Company significant ROI long term, and the specs have been carefully put together, then process re-engineering should not get in the way. In particular, no re-engineering (other than on a prototype basis) should be done until the automation group produces a running system that is shown to satisfy the system specifications. Once this prototype has been developed, such that the risk factors have been eliminated (or greatly reduced), then it is time to re-engineer the process workflow as needed for the system to go into production.