Brave New World of Capture

clip_image002Hopefully the salesmen who have tried to sell me Capture solutions over the years aren’t reading this blog; if any are, I’m sorry. I have been telling those guys for years that:

We don’t use forms and we really don’t have a need for hardware or software to scan into SharePoint.”

I lied. OK, I really didn’t lie, I just couldn’t properly imagine the truth – we do have a need for a scan-to-SharePoint. Well, actually we don’t but we will for a while.

Sorry for the confusing lead-up to this post, but it has been very confusing for us as well. Despite the fact that we are an insurance company, we really don’t use hardly any forms in our business process. What we do need a scanning solution for is backfilling some important document libraries. We could simply take the approach of having a network scanner, or even desktop scanners  (since we have so few insureds) but I don’t think that will work. What makes me say that? Well we’ve had desktop scanners and high-speed Multi-function copies on our network for the entire time that we’ve had SharePoint but very little content has been added to SharePoint via those devices. The reason for that result is something that Marc Anderson mentioned recently and Steve Weissman has been saying forever – simply having the technology scanners or SharePoint) in place is not enough.

If technology is not the answer, then why am I excited about the arrival of these MFC’s and the configuration of the scan-to-SharePoint options next week? The answer is technology is only part of the answer this time. This time, we are going to attempt to address the business process side of the equation and the human side of the business process.

The copiers that we just replaced were “capable” of scanning to SharePoint, but only if you gave the copier Full Control the SharePoint sites that you wanted to scan to. That meant that people could scan documents into libraries that they couldn’t actually reach from their desktop. We trust our employees, but that’s dumb. The dumbest part of that would occur when someone accidentally scanned a document to the wrong library – then they couldn’t even delete it. In addition, the copiers needed to be on the Internet so the vendor could access the copier for maintenance and meter readings. Call me silly, but that sounds like a potential security risk. With that feature never activated, we were left scanning to a network drive and getting documents in the form of “Scan_20080616121254.PDF” – very helpful. Of course, there were better capture options around when we bought those MFC’s but we didn’t need them; remember? We also couldn’t afford them – we still can’t.

What we can afford is the following combination of hardware, software, workflows, training and administrivia:

The MFC’s communicate with server-based software that can map user rights and privileges back to the menu system of the copier.

The MFC’s are capable of rendering the scanned documents as PDF or PDF/A into the desired library and they are capable of producing metadata from barcodes or other scanned artifacts.

We are capable of creating SharePoint Designer workflows to process the scanned documents upon arrival in the library. In some cases, we may have the scanner deliver documents to a staging library so that the workflow can perform other operations first. For example: our policies are what are known as “continuous form” policies, meaning that we renew by endorsement. In non-insurance speak, that means that each year, we have to add 10-12 pages to an existing document / PDF. These MFC’s in conjunction with software from HarePoint and Muhimbi can stitch the incoming PDFs onto the back or front of an existing PDF.

Once we can demonstrate these capabilities, we can ask department managers to accept the assignment, on behalf of their staff, to make backfilling a requirement during the lease-term of these copiers. If our Policy Management software can be made to print to PDF in those libraries, we can eliminate the need for the scan-to-SharePoint option with the next generation MFC’s (see, I didn’t lie).

By the way, just to prove that “we get it,” rather than make people login at the copier using an on-screen keyboard, we paid extra for a reader that can accept the proximity badges we use for our security system as input – how cool is that?

The copiers just arrived. The software has not been configured. The workflows haven’t been written and the people haven’t been trained. But we have engaged a training partner to help us get our coworkers up-to-speed and we are starting with “Content Management Fundamentals” – We are going to start at the beginning, cover all the bases and build solutions that will help us treat “Backfilling” like the important business process that it is in real life.

The Other Side of Capture

Last week, I mentioned the importance of the tight integration between Office and SharePoint. It is one thing to say that most of the documents we have to upload to our SharePoint library were created in Microsoft Office. It’s quite another thing when we realize that we began creating these using Office 97 and these documents are currently in a number of different locations. In most cases, this comes down to a “you know the drill” moment. In this particular case, we found a Rosetta stone of sorts. One of our employees had an Excel spreadsheet that linked to the documents in their various locations. The spreadsheet also included numerous columns of information about the documents, some of which matched our metadata requirements exactly. Unfortunately, the spreadsheet had been poorly maintained and also included a few errors. With the help of a temporary list, a few VBA scripts and a few disposable workflows, we were able to update and correct the spreadsheet, and then upload it to a SharePoint list. Once in SharePoint, we ran a workflow that used the list values to update the document library metadata. It wasn’t pretty, but it worked, it saved time and it helped ensure accuracy. I realize there are products that can perform tasks like this, but when you only need to do this once, buying something doesn’t make sense.

Moving on to the opposite end of the Capture portion of the roadmap, we find one interesting on-ramp lane, Application Created Information. We have quite a bit of this content in our organization and even some in this particular project. The important thing to understand about this content is that it is already being created by the most efficient process we can imagine. In other words, this does not represent a problem we want SharePoint to solve. Instead, we are extending the reach of our applications to include SharePoint, by taking advantage of the powerful, albeit poorly documented web services interface that Microsoft provides. This represents an expensive proposition for us, but unlike a highly focused add-on product, this is a broad based solution that we can use in multiple applications. We are building this capability gradually; our first version can handle basic list and library operations. That means that our applications that create reports can also file them. While we can’t yet initiate a workflow, we can rely on SharePoint to handle that task until we finish v2.0 of our development effort.

In addition to the expense associated with building the interface library for our software development environment, will be buying some products too. We are currently evaluating Muhimbi’s PDF Converter for SharePoint, to create PDFs on SharePoint and inside workflows. We are also planning to integrate PDF manipulation capabilities into our in-house applications in 2011. That capability will enable us to automatically update PDFs stored in SharePoint. These two solutions will help us to bring content into SharePoint through non-traditional pathways. We may be driving on the shoulder of the on-ramp, but I think that still counts as capture.