By ,
October 16, 2011 - 5:37 PM
I always get a kick when someone outside the ECM space ends up finding me. The conversations that arise are always interesting, probably more for me then for them. For them it usually ends in disappointment, this post is about why.
This connection happens 7 or 8 times a year, not counting organized events, and it happened again just last week. AIIM expert blogger Bud Porter-Roth referred to me a very interesting capture case. The ECM novice was an Israeli analyst firm. Their customer, even more novice, was an Israeli bank. Their project was to help the bank identify a solution for check processing.
I find myself saying “I do not want to discourage, but I want to make sure you are on the right path” and “so many projects fail, not because of technology, but because of expectations” a lot. It’s a catch 22, do you let a company run down a bad path, or try to help the course correct? This case was no different. The expectation was that it’s possible to purchase check scanners that cannot just produce an image, but recognize all data on the check, not just machine print, even hand writing. Those of you in the know are already slapping your forehead. This is such a dangerous belief.
Why do they believe it?
1.) They are not a part of the ECM/Capture club
2.) The vendors let them believe it
Maybe indirectly, our industry fosters these poor expectations. We do it first by downplaying how important planning is, and second by not making education the most important first step. I know why we do it. SIs need a job, ISVs want fast sales cycles and love selling professional services. To me this seems counter intuitive. We want them to buy our stuff and be successful, but not until they go through the proper initiation process. Yes sales process would be longer in my world, but ultimately projects more successful, customers more happy, more upsell possibilities.
Similar to my post on IT vs. End-User. Is it the ECM club vs. Everyone else? Are we putting too much focus on our exclusivity? I take a different perspective. The more people we bring in the better. The more we work with customers through the process the better.
The conversation ended with some disappointment on their end, once they realized they need to prepare their customer to accept the reality that handwriting recognition accuracy is very low relative to OCR, that a boxed product is not going to cut it, and that scanners are not bundled with a genie.
The consumerization of enterprise technology WILL, and already is, forcing these high pride business models to change. It’s very refreshing. But if we don’t embrace it, it will swallow us. For me, I want more and more members to join the club sooner. What I’m finding is that if they fail, they are more likely to give up on capture all together, and focus on born digital.
----------------------------
Below is a re-cap of the Q&A from my several conversations with the Israeli Analyst Firm / Bank. It’s interesting to observe the tension between what they want to believe and what I’m trying to educate them on.
Q: What are the best resources for check processing?
A: First I would recommend understanding capture in general. For that I recommend AIIM’s OCR Checklist, Capture Guide, and Community on capture. There used to be an organization that specifically focused on Check processing, it has been sense integrated into a larger financial transaction’s organization. This is another good source. Unfortunately there is no one stop shop or prescribed answers.
Q: What are the best products?
A: You first need to understand the difference between a boxed capture product and an engine. Boxed products provide the fastest path to deployment, but limit the flexibility in fine-tuning. While an engine gives the most flexibility and ultimately the highest accuracy, but requires a developer with experience and longer integration time. With that said you need to establish clearly your expectations in terms of cost, time to production, accuracy etc. These will help form which direction you go. On the engine side you can count three leaders, on the boxed product side there are many, but all the ones I am aware of have specific fine-tuning for US checks and focus on OCR and MICR recognition. Bottom line is not all solutions are created equal in the capture market. Knowing what you want first is key, but be willing to adapt.
Q: What's the basic difference between an engine and an application (usually named by the vendors as a "software solution")? Is an application based on an engine+ API? If it does, why did you claim that: "An application will not give you the same amount of control that an engine will. An engine will allow you to very tightly control accuracy and process" (is it because an application already adapted to a specific engine)?
A: Very different. In one case you control the source code, thus control ALL the recognition settings, in the application method you are accepting the settings the software vendor choose. But more specifically I’m pointing out pre-configured applications for check recognition, versus a general recognition engine.
Q: A boxed product is less accurate than purchasing an engine though it’s easier to implement. Also an application is required if we buy an engine (not sure if it was referred to an engine or boxed product since in the article you sent me it was written: "Check scanners today are very fast, but also pretty pricey. Second, they need an application that assist and tracks the sending of the images and data to banks via a secure connection").
A: The quote and what we were talking about are two different things. Separate the process of producing an image from recognition. Many organizations are ONLY imaging checks, not recognizing them, however the bulk of our conversation has been about recognition not scanning. Check scanners are not bundled with check reading except for MICR, so for what you are trying to do you will need a second stage recognition application. There are a few boxed ones, but all the ones I know are US only. Then there is the process of creating your own using an engine and it’s API. For this you need a developer with imaging experience. An application will not give you the same amount of control that an engine will. An engine will allow you to very tightly control accuracy and process.
Q: How should we scan the checks?
A: There are several variables here. The first is volume and process. Teller scanning and ATM scanning will be very different. The thing that you want to shoot for is scanning at 300 DPI Tiff Group 4. This is ideal, however most check scanners max out at 200 dpi. Other consideration that has to be made is archival, and document prep. A good image is the first step in success.
Q: I've read that many companies supply hardware solution which is the scanner+ recognition application. Did you mean boxed product are actually the hardware solution (the scanners + applications)?
A: “Recognition” can mean everything from Full-Page OCR to Intelligent Data Capture IDR ( Also called data capture ) which is what you need in check processing. IDR is field level recognition. The complexity different between full page recognition and IDR is night and day. I suspect the check scanners you look at include recognition of MICR only, full-page OCR. I did not say they were US only. What I said was that the only products I know of that can read CAR, LAR are on US checks only. It’s possible there are products outside the US that I am not aware of. In the US we have regulation called Check 21 which very specifically defines how images of checks can be processed as original checks. There are several vendors that wrote boxed products at the teller level to try to leverage this opportunity. The biggest banks in the US who are doing recognition at the ATM are relying on the integration of several OCR engines done by the ATM manufacture. While at the teller using boxed products. The point I’m illustrating is that when you find a boxed product it’s clearly going to have to have regional settings in addition to Hebrew recognition.
Q: What are core recognition technologies and what is the difference between them and recognition processes?
A: The core technologies are OCR/OMR/ICR/MICR/Barcode while IDR/IWR/LAR/CAR/BCR are process technologies that combine the core technology with document classification, field identification, recognition, dictionaries, and data types.
Q: What is Voting, and why is it better? A lot of products I investigate promote voting.
A: The process of voting is taking independent results from three or more engines or configurations and comparing the results to get final accuracy. To do voting you need three engines or three configurations. Voting three separate engines does not really work because the way each engine reports character confidence level is different so there will always be a bias to one engine if it’s most accurate or not. Some claim they overcome this bias, but because the modern engines change their confidence reporting on a document level it’s nearly impossible. Voting the same engine three times with three different settings is possible, but the accuracy boost will seldom exceed 2%. Usually far less. Most the time this makes it cost prohibitive. The term voting is really just a marketing term.
Q: You said OCR accuracy is 98% while IWR (I'm not sure if it was IWR or ICR) is like 20%!?
A: Accuracy is SOLEY dependent on the quality of documents. So when I was talking about percent they were purely ranges you can expect. There is an accuracy first of identifying the document (0% or 100%), accuracy of finding the fields ( 0%-100% ), accuracy of recognition ( 0%-100%), accuracy after data types and dictionaries ( 0%-100%). These combine to make the total accuracy on a character level, and are cumulative. For example if you never ID a document, you never recognize it. With that said, a GOOD deployment of check processing on printed checks you can expect 98% before verification. A GOOD deployment of check processing on hand printed checks you can expect 65% before verification. IWR is purely the reading of the hand written text, the average accuracy of such a field is 20-30% unless you have existing databases to back up the data. What I was trying to illustrate is, usually you’re better off to ignore hand written checks and focus first on printed checks. You move to hand written check processing when the volumes of checks justify even sub 50% read rates.
Q: Branch/ teller/ ATM capture are basically the same software (it's just that the pricing is different)?
A: The primary reason the price is different is because of page volume. Most capture products are priced by number of pages a month they process. ATMs process a much higher volume, and carry a higher premium. Not only that much more fine tuning. It also has to do with process. In ATM precision is far more important. So in this case they have spent much more effort on tuning the solution. Getting to 80% read rate on typographic documents is easy. Getting from that 80% incrementally to the 98% is where the most money and effort is put in.
A: Is it not possible to recognize hand writing?
Q: Correct, don’t let anyone tell you otherwise. But be clear this is very different than IWR. No one has the core recognition of hand writing without the support of dictionaries and data types. The primary reason for this is handwriting is not even consistent for a particular user. You cannot rely that someone will always write the same way. Handwriting changes based on time of day, mood, and individual doing the writing. With the support of dictionaries accuracy can jump substantially. In the case of check processing this is called CAR and LAR. So for example, can you expect to read the memo, or signature on a check, no, but you can expect to read the written amount as it can be cross referenced with the printed numerical value.
Q: OMR- is capable of recognizing any scribble that seems like a signature but it can’t confirm it's actually a signature. Besides, signature is changed every time so it's impossible to validate it's the signature of the person who wrote the check.
A: Correct you can very accurately determine the presence of a signature using OMR thus validating that it IS signed, but not WHO’s signature it is. I have seen this done before but only in extremely contained scenarios with a small subset of options. Banks tend to have too many customers to make this successful.
Rate Post
You need to log in to rate blog posts.
Click here to login.
This post and comment(s) reflect the personal perspectives of community members, and not necessarily those of their employers or of AIIM International
