I have been involved in document capture for 26 years - since well before it was even called "capture." I am often asked about how I came to found Datacap. So taking advantage of my impending exit from the stage (read on for more!), I thought I would share some background on the founding of Datacap as the first true document capture software company.

The microprocessor revolution was in full swing in the mid-1980s when I joined a hospital information systems startup. We concentrated on data collection in operating rooms using what was then cutting edge: IBM PCs networked directly together with TCP/IP. We got sterilized computers into the operating rooms... but we struggled to get nurses to use them.

Turns out that not only was the nursing staff more comfortable working with pen and paper (usually on a clipboard), but they resented having to literally turn their backs on the patient - particularly when they were being asked to enter what was essentially inventory data for billing purposes (the materials and instruments being used during the course of the operation). We also had a back up system in case the PCs or the network didn't work (which was often). It used... paper.

It was in this context that I was struck down with a very nasty virus: chicken pox. You may think of chicken pox as a childhood disease with some discomfort - or even as a great opportunity to play hooky from school - but adult chicken pox, as I quickly learned, is an entirely different beast. I ran a high fever, and for several days I literally could not raise my head off the pillow.

At times I became delirious. And it was in a delirium that Datacap was born. I had visions of paper forms filled in by nurses in the OR dancing around... but, more interestingly, of the data on the pages coming unstuck from the paper and floating off. I saw individual characters very clearly and how they could be segmented to be understood by the computer as data.

Once the fever had burned itself out, I got back to work. One day not long after, a guy I had brought in to help us with some of our tougher user interface challenges showed off an early document scanner. He was building a driver to run the scanner from a Mac for another client of his. It seemed an amazing piece of equipment... and it struck me right there that if we could scan the nurses' sheets, then we could segment the characters and turn paper into data!

Once the wheels started spinning, there was no turning back. Along with Noel Kropf, the guy with the scanner, we founded Datacap and we set to work building our first product, Paper Keyboard, releasing it in 1989. It all seems so inevitable now, but at the time there were nothing but hurdles to overcome: porting to Windows 3.0, adding machine-print OCR, tying multiple machines together to distribute the work, etc., etc.. It kept a growing team of developers busy for the next two and a half decades.

And, of course, we faced increasing competition as the "forms processing" business became a recognized speciality in the quickly gowing document imaging industry. Some vendors edged into scanning and data entry automation from related areas like manual data entry (Textware, later Captiva), while some started the long transition from hardware to software (Kofax).

Eventually, Datacap became part of IBM in 2010, giving us the opportunity to put down a global footprint. What started off literally as a “vision” in a fever, has become a global reality, used by customers worldwide to ingest millions of pages each day. In some ways, for me, that fever never passed. It has energized me for years – and I like to think I have “infected” a few others. If so, then maybe my job is done. I can let a new generation of visionaries take what we have done with IBM Datacap to a new level. That's part of the reason why I decided to step aside from my current role into retirement at the end of this month, not long after I push the "Publish" button on this blog.

I still have a vision for the future of document capture, one that is increasingly mobile and distributed, and one that will make the steady transition from "on-premise" to SaaS for many customers. But I'm sharing it with you now so that you can help make it a reality while I spend some more time on my bike and doing the many things that I haven't had the opportunity to do since I first caught the Datacap bug!

Whatever I’ve done, I’d like to thank the hundreds, and probably thousands of individuals that have made the document capture space a thriving business arena. Whether you were with Datacap, with IBM, with one of our many partners, or even with a competitor (ha, I know you are reading this!), without all of you, we would not have such a vibrant and successful capture community!

An intuitive user-interface is essential to facilitate distributed capture. Typically, the people receiving documents are customer-facing, not dedicated and trained capture operators. The solution should provide a clear and simple series of steps to that assure a legible document image…

Can it be “Read?”

A poor image quality or, worse, partially-captured document, will quickly undermine the benefits of distributed capture, especially downstream when it comes time to extract data with optical character recognition (OCR). This is where most mobile telephone cameras struggle to create high enough quality images to avoid laborious manual effort later in the process. For a step up in quality, select a portable scanner – some are no larger than a thick ruler – that attaches to a laptop or mobile device.

What document is it?

The first, most important, piece of information about any scan, is the identity of the document itself. Is it an application, a claim, a change-of-address, etc? That question might be answered by manual input from the person who scanned or took the picture of the document, but it also might be automated through automatic document classification. Remember, your mobile and distributed workforce are not trained capture professionals, so take a belt and suspenders strategy on this one…

Is it Accurate?

Determining the accuracy of content extracted from a document is of prime importance. Whether the extraction is manual, or automated with OCR, you need a set of checks and balances to assure users that the solution can be relied upon. For example, if the software is uncertain, how does it notify a user, and which user is it that gets notified?

Is it Safe?

The security of data is essential to consider, especially when handling customer or other sensitive data. Distributed capture must be considered moving capture into high-risk environments. Make sure you understand what the risk exposure is if a mobile device is lost or stolen in the field.

Is it Faster?

The speed at which the captured document is transferred from the mobile device to your repository or LOB system determines the speed at which it can be processed by the application. The old saying, “a chain is only as strong as its weakest link,” comes into play here. If there is, in fact, a bandwidth limitation for remote users, then the advantages of capturing remotely may be lost in the transfer.

Is it Capable of Handling Anything a User Throws at it?

There are always exceptions and how you manage them is the test of a capture system. Can you add attachments? Can you add a new document you weren’t expecting? Can you annotate a document or route it to a supervisor for review? The closer you are to the customer, the more exceptions you will encounter, so make sure you have the flexibility to handle the unexpected.

Will it work for me?

In most cases, a mobile capture solution will both archive the document images, and route them into a line of business system – as fast as possible for customer satisfaction. For example, an invoice, resume, or contract will be sent to the ERP system. An insurance claim will be forwarded for adjudication. A loan application may link to a case management system, where underwriters will review. A medical document will be appended to the patient’s electronic health record. Make sure your distributed capture system can connect to your business systems and deliver image and data seamlessly.

After all these years in the capture business, I thought things had settled down. People have been saying that document capture is a “mature” technology. And, of course, it is, but the world is changing around us, creating new opportunities. So don’t be shy: if you see a way to shorten the cycles, to deliver better customer service, to improve vendor relations, or to change just about any existing process by capturing documents sooner at distributed/remote locations, then take advantage of the opportunity. Just ask the right questions - and get credible answers – as you navigate to a successful implementation.

I'm just back from a trip to India. Until fairly recently, I would never have imagined significant opportunity for document capture in the very place where outsourcing of data entry has been most successful. That's relevant to the document capture business because when a document is "captured" two things happen:

- the paper document is digitized (usually scanned, but sometimes an already electronic document is converted to a standard format), and

- data is extracted from the document - either manually or using OCR - so the document can be filed, and sometimes to populate a line-of-business application.

Call it what you will - indexing, verification, keying - it is a data entry requirement that allows a document that has been digitized to be sent to locations around the world where labor is less expensive. It is exactly in this type of work that India has excelled. A vast, trained workforce has taken on the tedious task of manually extracting information from documents. Even compared to "automated," OCR-assisted data entry that requires relatively expensive labor in North America or Europe, a very competitive alternative has been to take advantage of the much lower-cost labor pool in India (and other countries) to manually enter data, without the help of automation at all.

So why was I in India? To some extent, you can say that the success and breadth of outsourcing initiatives over the last 20 years have changed the underlying economics. Although labor continues to significantly less expensive in markets such as India, China, Philippines - the usual suspects - costs have gone up substantially. They have gone up enough that it is no longer a given that throwing more manpower at a problem, such as manual data entry, is going to be less expensive than investing in automation technologies to help assist in the effort. Many organizations are coming to the same conclusion.

Even banks with far-flung operations and massive workforces are exploring ways to automate aspects of the document capture process: the volumes of documents to be captured are staggering once a bank wades into the world of branch capture. (My thoughts on how branch capture is technically something new in document capture: http://ibm.co/13i74bl.) Automation not only reduces costs, but speeds up the process, ultimately helping improve customer services… and most importantly, customer satisfaction. (And if you are skeptical that customer satisfaction is the underlying benefit of document capture, let me try to convince you: http://ibm.co/10bwmsJ.)

Put another way, in large-scale document capture operations, there is a premium on reducing complexity, including the number of people involved. Globally, the Holy Grail is to grow the number of documents being captured, while meeting that growing need with existing staff.

From my perspective, document capture has come of age when it is being adopted globally, even in markets traditionally noted for the low cost of labor.

To continue the conversation, connect with me on Twitter @captureguru.

4 Non-Trivial Questions to Ask before Committing to Production Document Capture

In late 2009 and I got a call from the brother of a good friend. He was a researcher at IBM's Watson Labs - soon to became famous for the "Watson" artificial intelligence engine that spectacularly beat the top humans on the trivia game-show, Jeopardy!

My friend was trying to solve a problem and thought that my company, Datacap (the acquisition of Datacap by IBM was not even on the horizon at this point), could help, since we specialized in optical character recognition (OCR) and related document capture technologies.

I said, "great, let me ask you 3 or 4 questions about what you are trying to do:

1) What is the volume of documents/pages/images you need to process per day, week, month, or year?

2) What data do you need to extract from those pages, any special considerations to take into account?

3) Are the pages consistent in format, variable, something in between?"

He said he had 5000 pages. Clearly to him that was a big number, but he was a bit deflated when I asked, "is that per day?" In the production document capture business, it is definitely common that a volume like that may be literally processed "before breakfast."

But 5000 pages were all he had. Not every day or week, or even every month, just once. I was a little skeptical, but I wanted to learn more.

He needed to extract information from an English language pronunciation guide. He wanted to read the word to be pronounced, and then the linguistically precise definition of the pronunciation, including diacritical marks (accents) commonly used in those definitions. In other words, this was not just straight English language OCR. My skepticism increased.

I wasn't surprised when I next learned that the pages were not at all consistent, that the definitions for a specific word could wrap from one page to the next, or that the pages to be scanned were in bound books...

That was it. Did he really expect to use a production capture product to process - one time - 5000 pages with specialized text and words on them and no fixed format? Well, yes, he did. He had a real challenge and his expectation was not unreasonable... it just is not what production document capture is about.

Those three questions can help anyone quickly assess a document capture problem. In this case, the answer was simple, but perhaps wrong. I advised him that it would not be economically feasible for him to invest in production document capture, but in giving that answer I missed a great opportunity.

Turns out I should have asked a 4th question, "why do you need to read a pronunciation guide?"

I learned later that my friend was working on a major artificial intelligence project, one that would need a computer capable of blurting out words under extreme time pressure. He was, in fact, working on giving "Watson" a voice. It was that voice, having been trained to enunciate thousands of words, that went on prime time to beat the best human players at a live game of Jeopardy!

He eventually used a desktop OCR program and a lot of patience to translate the pronunciation guide from paper to something Watson could understand. Although my 3 questions helped me quickly assess the value of the opportunity, by skipping the 4th question, I missed the opportunity to brag how Datacap helped to give Watson a voice!

Is production document capture and imaging right for you? Click here to learn more on using capture solutions.