Lots of interesting content this afternoon; I had my eye on integrating BPM and Kofax Capture, but ended up at the session on turning MFPs (multi-function printers, aka MFDs or multi-function devices) for point of origination document capture using Kofax Front Office Server (KFS). Rather than collecting documents at remote offices or branches and shipping them to central locations, KFS puts scanning capabilities on the MFP that already exists in many offices to get the documents captured hours or days earlier, and eliminate some of the paper movement and handling. This isn’t just about scanning, however: it’s necessary to extract metadata from the documents in order to make them actionable.
They presented several scenarios, starting with the first simple touchless pattern:
- Branch user authenticates at MFP using login, which can be synchronized with Active Directory
- Branch user scans batch of documents using a button on the panel corresponding to the workflow that these documents belong to; these buttons are configured on Kofax Front Office Server to correspond to specific scan batch classes
- VRS and KTM process the documents, doing image correction and auto-indexing if possible
- The documents are committed to a content repository
- The user can receive a confirmation email when the batch is created, or a link to the document in the repository after completion
Different buttons/options can be presented on the MFP panel for different users, depending on which shortcuts that are set up for them during KFS configuration; this means that the MFP panel doesn’t have to be filled up with a bunch of buttons that are used by only a few users, but is effectively tailored for each user role. There are also global shortcuts that can be seen on the MFP panel before login, and are available to all logged-in users.
A more complex scenario had them scan at the MFD, then return to their computer and use a web client to do validation and correction required before committing to the repository; this is the thin client version of the KTM validation rather than a function of KFS, I believe. This has the advantage of not requiring any software to be installed at the desktop clients, but this is still fundamentally a data entry functionality, not something that you want a lot of branch users to be doing regardless of how slick the interface is.
The speaker stated that KFS is designed for ad hoc capture, not batch capture, so there are definite limitations on the volume passing through a single KFS server. In particular, it does not appear to be suitable (or optimized) for large batches, but really for scanning a small set of documents quickly, such as a handful of documents related to a particular customer file. Also, the images need to pass to KFS in color or greyscale mode for processing, then are thresholded by VRS to pure black and white before passing on to KTM, so it may be better to locate KFS at the branches where there are multiple MFPs in order to reduce bandwidth requirements. Fundamentally, KFS is a glorified scanning module; it doesn’t do any of the recognition or auto-indexing, although you can use it to capture manual index values at the MFD.
It’s also possible to do some controlled ad hoc scanning: instead of just uncontrolled scan to email (which many of the MFPs support natively, but ends up being turned off by organizations who are nervous about that), you can scan to an email, with the advantage that KFS can convert the document to searchable PDF rather than just an image format. However, it’s not clear that you can restrict the recipients – only the originators, since the user has to have this function in their profile – so organizations that don’t currently allow scan to email (if that function exists on the MFP) may not enable this either.
There is also a KFS web client for managing documents after MFP scanning before they go to Capture and KTM, which allows for pages to be reviewed, (permanently) redacted, reordered, documents split and merged, burn text notes into the document, and other functions. Since this allows for document editing – changing the actual images before committal to the content management system – you couldn’t enable this functionality in scenarios that are concerned with legal admissibility of the documents. The web client has some additional functions, such as generating a cover page that you pre-fill (on the screen) with the batch index fields, then print and use as a batch cover page that will be recognized by KTM. It also supports thin client scanning with a desktop scanner, which is pretty cool – as long as Windows recognizes the scanner (TWAIN), the web client can control it.
As he pointed out, all of the documentation is available online without having to register – you can find the latest KFS documentation here and support notes here. I wish all vendors did this.
They finished up with some configuration information; there appears to be two different configuration options that correspond to some of their scenarios:
- The “Capture to Process” scenario, where you’re using the MFP as just another scanner for your existing capture process, has KFS, VRS and KC on the KFS server. KTM, KTM add-ons and Kofax Monitor are on the centralized server where presumably dedicated KC workstations also feed into it.
- Touchless Processing scenario moves KTM from the centralized server to the KFS server, so that the images are completely processed by the time that they leave that server. I think.
I need to get a bit more clarity on configuration alternatives, but one key point for distributed capture via MFP is that documents scanned in greyscale/color at the MFP move to KFS in that resolution (hence much larger images); the VRS module that is co-located with KFS does the image enhancement and thresholding to a binary image. That means that you want to ensure fast/cheap connectivity between the MFP and the KFS server, but that the bandwidth can be considerably lower for the link from KFS to KTM.