The distributed document capture market, despite having been discussed for a very long time, is still very immature. This is my conclusion after doing quite a bit of research on this market over the past couple months. Is there a best practices for distributed capture? I haven't found anything definitive published on the topic.
So, first off, what is distributed capture? Well, it's basically truncating-or electronifying paper documents as far up the workflow chain as possible. This means that if loan applications, for example, are filled out at a branch office of a bank, they are going to be scanned there and sent digitally to loan processing center for approval and archiving. The advantages are that
1. distributed capture can reduce the time it takes to get the paper forms to the loan processing center,
2. it can save money on courier charges if the paper forms were being overnighted,
3. it can reduce the number of documents lost in transit as well as increase security around the transfer of the documents,
4. and it can put data entry related to the loans into the hands of the customer service rep at the branch, who is going to be more invested in the loan than a data entry operator at loan processing center.
Yes, all of these can be advantages, but there are some disadvantages too. For example, do you want your mid-level salaried knowledge workers, like loan officers, doing scanning and data entry when they could be producing more loans?
I guess the reason I haven't really seen a definitive best practices on distributed document capture is because there are so many diverse approaches to it, and to me, this is the sign of an immature market. I think I talked with four vendors in the past two weeks, all of which are promoting and selling distributed capture, but all who are doing it very different ways. Daybreak ICS, for example, uses a client server approach with a universal client for document scanners and customized release scripts from its server into ECM applications. eCopy also has customized release scripts, or "Connectors," as well as a universal interface, but its interface is primarily used on MFPs. Oracle, which acquired Web capture pioneer Captovation in the the spring, has a Web-based client with dedicated release scripts. ImageTag picks up images from a watched folder and files them based on data assigned to a bar-coded tag applied to the document before it's scanned.
All these different approaches lead to different workflows associated with distributed capture. All these vendors have had success, of course, but perhaps one reason the market has not caught fire the way many people are projecting, is because there is no standardized best practices. In other words, there's too much solutions providing/customization going on in the distributed capture space and not enough product sales.
I think some sort of flow-chart/questionnaire for end users with multiple sites is in order.
Any thoughts on this?
Subscribe to:
Post Comments (Atom)
7 comments:
Ralph,
You get to a great point, and that is the fact that there is yet to be a unified opinion on distributed capture. Something very interesting we have seen over the years is yet another workflow and that is distributed "image" capture, but centralized "data capture". A big drive for this workflow is cost. But other things follow such as administration is easier as data capture tends to be the most complex component of the whole deal, and having it centralized allows for great accuracy and easier administration, overall a tighter control of the entire process. This is often a workflow we recommend, but have also done implementations where the whole story, image and data capture, happens at the sites local machine. This was the case with WorldVision. But at some point this data is getting back to a centralized database. So no matter how distributed you try to make it you always have to look at the path to the end location. It seems to me that a big drive for the type of workflow is often mandated by how an organization does business today. This will force vendors to become adaptable and not dictate workflows but rather, fit in. Great post!
This is a great subject, one that should be discussed more often. The most important issue in your post is the question: should knowledge workers be capturing documents?
The answer is yes! To make my point, I'd like you to consider another technology example. Consider word processing software.
In the first 5 years, word processing was used only by trained word processors and NOT by knowledge workers. Knowledge workers sent their hand written documents to word processors to be typed.
Then technology got easier, providing all the capabilities through a UI that could be used by virtually any knowledge worker. As a result, everyone started word processing. Many more documents were created via word processing software. Productivity soared.
Document imaging software is evolving the same way. It is moving from the point where only trained experts could use it to the point where every knowledge worker can. There will always be applications where you will need a trained operator, but with "easier-to-use" software, documents that had never been scanned will be captured and included in business software.
Bill & Chris:
You both make interesting points. Chris, I absolutely agree that I have seen an increasing number of distributed document capture/centralized data capture implementations recently. And in an emerging market, such as distributed capture, I think flexibility in how you can deploy a solution is helpful.
Bill, you also make a good point about the potential wave of the future. Yes, centralized data capture is very much an established way of doing business, but, then again, so were secretary pools for typing letters. I'm not sure how long it will take centralized data entry operators to go the way of dedicated word processors, but you're right, user interface may be the only thing standing in the way. Probably, not coincidentally, eCopy does one of the best jobs with user interface in the distributed capture market.
Bottom line is that for now, and at least two to five years out, I think the flexible distributed document with the option of centralized data capture will continue to be very attractive, but after that, who knows? Everyone knows how to make copies, right?
Ralph
Hi Ralph,
I'm a longtime document scanner solutions guy and very familiar with the challenges we still face on the Distributed side of it. Couple thoughts on your good post.
1) 'Distributed Capture' is not in and of itself a business solution, and it's not a standalone market despite creative vendor and analyst efforts to create the illusion of one. It is a hardware/software technology that is useful only when embedded in a business process such the loan app you described. I agree with Chris that it's irrevelant how much or how little 'capture stuff' is done at the point of origin, because the end result is a workflow and that's where the business value is.
2) I also work for a company whose capture product line includes an overlooked distributed method: fax. Based on your definition of distributed capture, would you include fax servers too? Or did you mean to cover only document scanners and MFPs as input devices? I bring it up because if we included fax servers then we could argue there is a mature distributed capture segment with several vertical uses. Certainly not a solution for every document type, as we all know the limitations of fax as imaging, but it does have its place in the world.
Enjoy the rest of the summer on the Lake!
Dan:
I'll agree that the fax server market is mature, but I would say that the integration of fax servers with BPM is still finding its legs. As far as fax goes for an onramp for distributed capture, yes, it works, and there are millions of fax machines out there, but how many new fax machines are being sold each year? It would seem to me that analog communication has a limited lifespan going forward.
Any thoughts on this?
Thanks.
Great topic Ralph and one that continues to be refined and defined by different parameters. I am moderating a distributed capture panel at the upcoming TAWPI conference and if any of the contributers to this thread or other readers want to suggest questions that I can present to our panelists (Datacap, Visioneer, Fujitsu and Kodak), I will be happy to add them to my list and will try to include as many as possible during the hour long session.
Just few of my thoughts on this topic after few years of experience in implementing distributed capture projects (or rather part of end to end workflow projects) for financial companies esp insurance:
1. Most companies prefer to have data entry centralized for the sake of better use of human resources, or just outsourced the whole data entry process to 3rd party vendor.
2. Scan capture is usually an additional step added to the new workflow so it cannot be a bottleneck to the new workflow. Also, branch users are usually customer facing, and the customer experience cannot be compromised (i.e., you cannot ask the customer to wait for you to do scanning).
3. So far, for all projects that I did or seen, scanning are never be done by knowledge workers. In fact, I do see a trend where scanning is being outsourced too, even in the branch.
4. Distributed capture can go beyond branch offices. We have implemented projects where scan capture is done at the agency offices (which technically does not belong to the insurance company).
5. Fax capture is an easy and quick way to get external parties (like agents or agency offices) to be integrated with your workflow, but it does have its limitation. After considering the cost (long run, not upfront), quality, and constraints of the fax machine (e.g., no double sided, at least for the common fax machines, not the higher end ones), most companies prefers to adopt low-end distributed capture over the Internet.
Just few thoughts to share.
Post a Comment