by Bernard Chester, Infonomics
06-06-2009
Most of us have encountered the problem created by multiple silos of information. Information may be under control, but it very likely the contents of one repository are not linked or coordinated with any of the others. Maintenance and support costs are duplicated. Does this happen with data capture?
I’ve seen similar problems occur when capture solutions are implemented. Often this is a side effect of focusing on the source format and/or the technologies required for capturing the data, rather than the business problem.
Here is a real-world example (1) of this: An institution was implementing imaging and enterprise content management (ECM) to handle paper enrollment applications. But paper was only one of the ways one could apply. In order to adequately serve potential clients, a number of alternatives were provided. While there was a standard paper form, there was also a “look alike” smart form that someone could download and fill out, and a Web application. The paper would arrive via US mail, fax, or scanned email attachment or on electronic media. The smart form might be printed and handled as though it was a paper form; or it could be delivered as an email attachment, downloaded to the website, or sent back on electronic media. The Web application filled in an ERP database table. In all cases, a completed application needed to be validated for consistency or completeness, entered into the educational MIS, and then would initiate a review workflow. All in all, a typical situation, that one might see with any application or claim process.
Initially, no matter the source, the application was printed and data was manually entered into screens. During the spring surge, temporary staffing was brought in to handle the data entry load. The goal was to eliminate that manual work, and by doing so, eliminate entry errors, delays, and lost files.
The original development plan was complex, expensive, and looked to take several years to complete. Because of the different delivery schemes, different technology teams – imaging, electronic forms, and Web – would handle the tasks for their respective source. Each looked at implementing unique data validation and transaction storage approaches. For example, the image team would process the paper stream into the ECM system, but the other teams took the approach since they were only dealing with digital data, there was no need to store the input stream.
The concept of Unified Capture (UC) attempts to avoid duplication of effort and variations in the complete business process. Capture is viewed as a systemic need, not individual technology issues. All of the potential streams and formats of information are merged and common logic is used where possible.
UC is not an easy solution to obtain. It requires more up front design work, demands that a number of technology experts put their heads together and their attitudes aside (2), and can produce development schedules with multiple critical tasks. My recommendation is that the design effort be guided by a business process analyst, but you may be challenged to find one who also understands the technologies involved enough arbitrate differences. The reality is that implementing future changes (e.g., new required fields) are going to be more interdependent than point solutions.
For my client, an alternate UC design was developed that reduced the development work and simplified the new business process. (See attached diagram). The basic principles of the new design were:
1. All submissions will go into the ECM system, so they are available as records and may be used by application processors and process auditing. Non-image information is converted: electronic forms become PDF files and data records are extracted as XML using database tools and formatted using a standard style sheet.
2. A rules engine will be implemented to validate all applications. The rules were segmented into sets, so they could be used as components of multiple solutions. (Note: the sets tended to match Web screens, to ensure that interactive users could correct entry errors before moving to the next screen).
3. Create a uniform scheme for responding to applications, independent of the submission technology.
The resulting project was completed in about 16 months. Some of that time was invested in adding the rules engine to the internal toolset. Now all applications are processed in less time, with a guarantee of identical handling and validation. A side benefit of the new system was the ability to provide tracking on applications in the early stages of processing, to both staff and submitters (“did you receive it?” questions).
1. Significantly disguised as a courtesy to the client.
2. For example, assuming that paper submissions are going to disappear!
Download: Full PDF Article