Backlog Scanning vs Today Forward Scanning – Should we treat them differently?

Most companies that are considering implementing document image scanning receive paper documents (such as application forms) every business day and consequently have both “current” documents (still to be processed) and “historical” documents (that have already been processed). The question often asked is whether to treat the two sets of documents the same or not? More particularly, should we be using the same paper scanning techniques and methods to process these documents?  

To answer the question we should really look at the two scenarios in more detail.

Processing historical backlogs is usually fairly simple – in most cases all we need to do is tie the document image back to an existing transaction (in the company’s ERP, CRM or similar system) and to then archive the document image in such a way that it can be retrieved as and when necessary. Generally this entails someone, at the time of processing the paper-based transaction, to physically write a transaction identifier (or sticking a pre-generated barcoded label) onto the front of the paper document, or if such foresight didn’t happen at the time, to search through an internal system for the corresponding transaction at the time of indexing. Although I say “simple”, to do this task accurately can be quite difficult, labour intensive and time consuming (which is why outsourcing the task to a professional scanning services company is usually the best approach). A good solution would probably have the capability of doing this search automatically through database “lookups”.

On the other hand, scanning current documents, such as application forms, on a daily basis requires another set of company policy decisions to be made. The simplest method is to process the transaction manually by capturing the relevant data off the paper document and, once the process is complete, to send the document to the scanning department to be scanned; attached to the transaction via an index; and archived. This is very similar approach to scanning historical documents, with the only difference being the timing involved. Because of the minimal changes required to the company’s procedures, this is often the approach taken, but is not necessarily the most productive or efficient one. However, because of the similarities to historical backlog scanning, it does mean that a centralised scanning department can be set up that can easily cope with both.

If you are considering taking this approach, I would recommend introducing the barcoded label approach into the process as soon as possible, as it would certainly make indexing a lot simpler and more accurate when you eventually do decide to implement scanning.

However, to make the best use of the benefits of document scanning, as discussed in my previous blog, it would make more sense to use the image of the document as the input into creating the transaction. In other words, capture the data off the image instead of off the paper document. Applying our minds to this, we should realise that this will entail some fairly drastic changes to the way you might have processed these documents in the past.

To name a few, there is the very real issue of handling the fear of change within staff members that have probably been working with paper in a specific manner for many years. This is an issue that shouldn’t be underestimated and you should budget to spend close to 25% of your project budget on handling change management correctly.

Then there is a good possibility that your current infrastructure wouldn’t be able to handle the traffic of moving electronic images around your network, nor would your existing computer monitors likely be of the quality or size to optimally view the document images.

To do things properly your clerks should be able to view the document image in the same dimensions, or bigger, as the original paper document. Given that they also need to capture the information off the document into the company’s systems, it typically means that their screen size should also be large enough to display the capture screen at the same time. Many companies provide their data capture clerks with two monitors configured to work side by side, where they display the document image on the one and the capture screen on the other.

This brings us to the automated data capture tools which “reads” the document image and transfers the appropriate text directly into the data capture screen without human intervention. There are a number of technologies involved in this type of technique and will be the subject of another topic later in my blog series, given the advances that have happened in this area over the last few years. It is certainly worth considering these technologies, given the benefits to productivity and efficiency that can be obtained through minimising the amount of human interactions involved. However, for the sake of this discussion, I will treat them as a “black box”, where you simply provide them with a document image and they return a set of completed fields in your ERP or CRM system, from which you can kick off a transaction.

As you might expect, this is the domain of specialised software techniques and products, which are generally more expensive than your run of the mill scanning product and become significantly more expensive as you add the “bells and whistles”. More importantly, the vendors of these products generally charge for each document that is processed through their software. This actually makes sense because companies that process applications on a daily basis typically have calculated an average cost for processing an individual document and if the software can improve the speed and accuracy in capturing the document, it will reduce the company’s costs and generally improve the customer service it can deliver. Importantly, this could result in the company winning more business than their competitors if they can respond more quickly. Based on this, many companies can gain significant competitive benefits by implementing such solutions and are willing to pay to do so.

Now if you decide to go this route in order to process your Today Forward documents, can you use the same solutions to process your backlog?

The answer, in theory, is yes, but unfortunately the practical situation seems to be different. Theoretically, these solutions use the same scanning and indexing techniques as their cheaper counterparts and should therefore be able to process backlogs, but the problem lies in their licensing procedures. As discussed above, because they charge per document scanned, it becomes prohibitively expensive to use these solutions to tackle vast numbers of documents where all you want to do is to scan, index and archive them, which is typically the situation with backlogs.

So, the solution seems to be to consider the two situations as two separate projects and to evaluate exactly what you want to achieve with each. In many situations you could use the same solution, either separately for each project or simply to use the same infrastructure for backlog scanning as and when there are opportunities to do so, but in other cases two separate solutions might be more financially feasible. This is especially true if you consider using an outsourcing service provider, as suggested previously.