Blogs

Mobile capture is different from centralized capture in two ways: an easy way and a challenging way. The easy way is that mobile capture is very similar to capture with MFP devices, in that both are radically distributed capture. Radically distributed capture, as opposed to moderately distributed workgroup capture, has been around for 10 years. We (collectively) know how to do it really well – we’ve got it completely nailed. But unfortunately many folks are making the same mistakes with mobile capture that were solved many years ago with MFP radically distributed capture. This post is going to explain what those mistakes are so we can stop making them with mobile capture. Then we can use this victory as the baseline on which to stand – as we focus on what’s really challenging and interesting about mobile capture.

Mobile capture is the second wave in distributed capture. The first started around 2002 with the adoption of MFPs and radically distributed capture as a viable enterprise input channel. Best and worst practices soon emerged, and it quickly became easy to design the right kind of capture configuration that incorporated the new distributed possibilities -- whether radically distributed, completely centralized, or some hybrid of the two.

Mobile capture as the second wave in distributed capture has a lot of the same characteristics as the first wave. In a later post I’ll talk more specifically about how it’s different. But in a nutshell, it’s obviously different quantitatively, in that everything in this wave is happening faster than the first. But more important, it’s different qualitatively – and this is the most exciting part about mobile capture. It’s one of the changes that are ending the era of ECM and bringing in the era of “content intensive applications” or whatever term most of us will settle on in a year. But what I’m focusing on here is how mobile capture is similar to MFP capture, and how folks are making many of the same mistakes they did ten years ago.

For example, we learned years ago exactly how very different the highly distributed capture of checks, business cards, and receipts, is from the distributed capture of loan applications. They differ in business objectives, scale, and complexity. You can’t get from one to the other by quantitatively “scaling up” – they are qualitatively different. I know I’m repeating myself but – since we learned this around 2003, why are folks (both vendors and organizations) still making the same mistakes?

THERE ARE 4 TYPES OF DISTRIBUTED CAPTURE APPLICATIONS

Let’s start from the top. First, we can segment capture applications into centralized and decentralized. (I’m going to use decentralized and distributed interchangeably.) There are different types of decentralized applications, and it’s important to understand the differences. They may differ in the following three ways:

1. By primary business objectives: reducing costs (of shipping paper) or increasing business process efficiency (primarily reducing cycle time of workflow – and thereby e.g. making customers happy).
2. By application complexity: simple or complex. Basically if you want to reduce costs, you can get by with simple distributed capture. But if you want to improve process efficiency, it’s going to be complex – with tight coupling, QA, better document management, workflow, and integration.
3. By deployment size (# of contributors): small or big. If you get big, you’re going to have to scale up – and that’s often a qualitative rather than quantitative change. You need sampling for QA, automated rather than manual indexing, a formalized training program, etc.

From these three factors, you get four basic types of distributed capture scenarios (and note that business objectives and complexity are linked):

1. Small Simple
2. Small Complex
3. Big Simple
4. Big Complex

1.  The first is Small Simple Distributed capture. So what does this type look like? Recall that the driver is reducing paper and the manual processing of mail, shipping, or fax. You will have distributed contributors (people doing the capture), each capturing low volumes. And there will be minimal indexing or incorporation into downstream processes. Some good examples are anywhere you can capture to file systems, email folders, or a repository for simple search. So this means administrative applications like employee expense receipt and report processing. I know this isn’t sexy line of business stuff, but administrative applications are often the best way to start because the consequences of messing up are less than if you mess up a customer-facing application. There are plenty of opportunities – but don’t hinder your ability to get Big or Complex. You can get started almost right away if you have MFPs, scanners, and fax solutions – or smartphones and tablets with capture capabilities.

2.  The second type is Small Complex Distributed capture. The driver here is to quickly incorporate critical information into complex high value business applications. It requires significant processing and incorporation into downstream business processes. It therefore typically requires manual indexing by experts, visual QA, filtering to designated workflows, and notification or confirmation upon delivery of images to downstream systems. Examples include customer service, customer enrollment, and mortgage loan processing at branch offices -- anytime you have a customer sitting across from an agent or rep at a branch desk. Or the customer’s at home. Regarding opportunities, fewer firms are executing this successfully. I think both organizations and hardware-centric vendors underestimate the complexity of the applications. We see the best success when companies extend their existing centralized capture and ECM approaches into a decentralized model.

3.  The third type is Big Simple Distributed capture. Since it’s simple, the key driver is reducing paper and manual processing of mail, shipping, or fax. But since it’s big, the other key factor is volume – scaling infrastructure and components. Fewer firms are undertaking Big Simple Decentralized. The applications are not high value, but have infrastructure and support requirements and costs requirements of high volume capture applications. The most typical examples are capture to file systems, email folders, or a repository for simple search and retrieval for compliance and customer service. Regarding opportunities, beware of both hardware-centric vendors (with capture software) and advanced capture platforms. The hardware-centric vendors may not scale. And the advanced capture platforms may scale but be too expensive for simple applications driven by cost reduction. Finally, ECM-type systems are overkill – you don’t need an ECM system across the enterprise for everyone’s expense receipts.

4.  The final and fourth type is Big Complex Distributed capture. Here, you focus on quickly getting information into complex high value business applications like loan processing or new customer enrollment. Because it’s complex, it requires significant indexing and incorporation into downstream business processes. It may also include mixed configurations of decentralized and centralized capture. So you are mixing your centralized capture center with lots of branch scanners, MFPs – and now smartphones and tablets. Many of these applications look like small complex applications (application, enrollment, mortgage loan processing) -- but differ significantly in scale and complexity. They are often BIG because they are applications where documents originate from external senders and are captured by them – or delivered to large numbers of field offices or agents, who then capture them. So since the customers are capturing or sending in documents, be prepared not only for increased scale but also lots more QA, error correction, etc. Today it’s growing but in the early days few firms were executing it successfully. Just beware of its complexity.

SUMMARY

Let me now summarize what I’ve said so far about distributed capture in 5 points:

1. Gain consensus on the purpose of the distributed capture initiative (cost reduction or improve process cycle time)
2. Prepare for increased investment in centralized capture -- particularly if it’s Big or Complex. You will probably want to use your centralized crew to help with indexing, QA, error correction, and release.
3. Plan for significant integration efforts -- if it’s Complex.
4. Prepare for significant user training efforts to ensure participation and indexing accuracy -- particularly if it’s Big or Complex.
5. Don’t box yourself in with a simple small solution that can’t scale Big or get Complex if you want to develop in that direction. Implement to enable future extensibility and scalability (to get Big and Complex)

These 5 recommendations have been solid for MFP-based distributed capture and are a minimal set of recommendations for mobile-based distributed capture. Your mobile capture initiative will be a non-starter if it violates these six. Mobile capture comes with a whole host of other complexities and requirements which I’ll address another time.