Build or Buy Capture Technology

By Chris Riley, ECMp, IOAp posted 05-31-2011 15:21


Document capture technology is rather unique.  I’m referring specifically to document imaging.  Unlike enterprise content management (ECM), it’s not generally worth the effort to even considering building your own capture solution from scratch.  If an organization were to build their own ECM solution, it’s usually just a combination of tables in a database, and a collection of settings.  However, to build capture, you have to understand scanning hardware, imaging, and document conversion technology, all of which are outside the realm of typical database driven software.

Despite this, I often run into organizations contemplating the idea of building their own capture solution.  Five years ago my response was a forehead smack, and then a reading of rights on why this cannot be.  Now that I’ve started to mature (insert laugh), I’ve started to ask questions instead.  The result has been, organizations don’t want to build the core of capture, what they are really saying is they can’t find the solution to solve their problem. 

We are accustomed to purchasing solutions that are complete, but in capture it’s often not the case.  So “build it” in this scenario most often refers to finding the best of breed technologies and making something great.  Taking the best scanning from here, the best imaging from there, and plopping on some nice document conversion.  This seems reasonable. 

Some of the best solutions I have ever seen, combine the best technologies vs. “off the shelf” product.  When I say best solution, I’m referring to one that not only satisfies the requirements, but extends them, and does so for a period of 6 or more months.  So really I don’t oppose this idea.  However, what I have also found is there are a few traps people fall into when they talk about “build it” capture.

1.)    Assuming all capture products are created equal:  At the low end of document capture is full-page capture.  This is the simplest form of capture where the scanner produces an image, and that image is converted to a searchable format such as PDF using OCR.  Most scanning hardware can do this out of the box, so in a “build it” scenario the only build part is connecting this with your backend.  This is substantially different from Data Capture, or Advanced Capture.  These later technologies are far more complex.  They are transaction based document capture, where the conversion step feeds some business process.  They require not only core technology, but proper configuration on your production documents.  Confusing full-page capture with advanced is very dangerous.

2.)    Assuming conversion technology is abundant and easy:  OCR takes approximately 50-man years to create.  So if you are thinking of writing an OCR engine, slap yourself.  For this reason, the core conversion engines are very limited in number.  Four engines dominate the market we see today. I call these commercial engines. There are several open source ( will talk about in a second ) engines that are really re-incarnations of the first ever engines, and several specialized engines.  If a vendor tells you they wrote their own OCR, be suspicious.  The top capture products out there licenses great OCR engines but do not create them.  In a “build it” scenario you could do the same, but thinking you will build your own OCR engine is futile.

3.)    Open source happy:  When the open source concept was started, it was a bunch of benevolent nerds, like myself, just wanting people to play with their technology.  Open source does not mean that anymore.  All the open source companies I interact with in the capture space are very much for profit.  Yeah they will pull you in with free technology, but in production implementations you will be paying support or some sort of usage fee.  Do not misunderstand their motives.  In addition to this Open Source OCR at its core is usually expired OCR technology, some bells and whistles, and a new name.  None of the OCR engines closely compare in accuracy to the top four commercial ones.  In a build it scenario open source usually benefits you in only one way, smaller entry barrier.  But in the end it will likely cost the same as, but take more effort than licensing commercial.  Where Open Source OCR is helpful is in testing, and sometimes much better support, when you pay of course.

For a tech head, building is always more fulfilling, and fun.  It’s sometimes hard to break loose from this, especially when most enterprise technologies are reasonable to consider building out.  Many companies take the long path to discover this.  I assure you; you are nine times out of 10 better to buy capture technology, then building.  The exceptions are: unique  document types, very concrete business processes where special accuracy is required, and service bureaus.

#ScanningandCapture #Capture #OCR