Output Management
Plotting the landscape
I have to admit: Although I understand the concept very well, I’m not an export on Output Generation; the process of creating business output by merging data and templates followed by print preparation, printing and distribution.
It’s the world where you find solutions based upon e.g. StreamServe, Doc1, ISIS Papyrus and more recently Adobe.
It’s a world that is part of ECM. Enterprise Content Management does cover the capture, management, storage, preservation and delivery of content and documents related to organizational processes. This is however not a guarantee that it is treated that way.
CMS Watch recently published the 2008 Content Technology Vendor Map in the form of a subway map.
As you can see for yourself, it’s a great refreshing idea. They have divided the ECM metropolis into several neighborhoods, which makes it easy to travel around from e.g. the City Center to Archivia and stop with your favorite vendor along the way.
But guess what. I can’t travel to Printurbia! You know, the neighborhood with the lovely sites I already mentioned: StreamServe, Doc1, Adobe and ISIS Papyrus. The neighborhood that takes care of Output Management.
It’s characteristic for the way Output Management is often treated: as a separate city without connections to the Big City. And is that good for Printurbia? Or for Archivia or the City Center? No, it’s not!
ECM and Output Management in the real world
The least we’ll do with generated business output is to preserve it. Whatever is produced by the output management solution, most likely in AFP or PDF these days, is more or less dumped into an ECM solution. For instance within the financial world, Mobius is a common solution for archiving that output and making it findable.
Does this mean that ECM experts are called in, at the beginning of the output management project, to share their knowledge in order to make the two work together? No. But unfortunately that is the traditional way.
More and more companies start building and enhancing their electronic dossiers. Due to the nature of businesses, a client dossier is not uncommon. There is a lot of business communication between the company and its clients. Storing the business output in the client dossier is thus a no-brainer for the average business user. And they’re right. If you do have an electronic dossier and open the dossier of a particular client, you do expect all business output – call it correspondence if you like – to be there in a usable format.
In the real world this requirement can introduce some headaches. This is in particular the case when the ECM experts were not invited to help building the design for the output management solution. That’s why the traditional way, is the wrong way.
Including the perspective that ECM experts will bring to the table it the proper way.
Pitfalls for Output Management from an ECM perspective
The first and foremost question to be answered is: does the output management solution need to support output archiving, dossier creation or both? Not choosing ‘both’ implies that you will leave particular business requirements out, which are specific to either one of the options. This is not bad per se if you make this decision conscious. If you just forget one of the two, it will be a matter of time before you will regret it.
Let’s assume you settle for both and with that in mind look at some of the considerations you have to make.
What is the retrieval profile? Although you just said that you need both archiving and dossiers, you need to become more specific on how the stored output will be used. Only when you know how the user will search or browse for the output you’ll be able to pass the proper metadata from the sources, that are used for output generation, on to the archive and dossiers. If you don’t know the end user will regularly search for documents based upon e.g. a contract end-date then why would that date be passed on from the source? And guess what, it is more likely that you can live without if you focus on just output archival. It’s easy to provide numerous other examples. There’s also another side of this coin. If certain documents are never needed in the dossier you may consider to optimize the output for archival only.
What is the storage format? Will it e.g. be AFP or PDF? Since you want to support both archiving and dossiers, let’s say you choose PDF for the simple reason that browsing through your dossier and viewing documents in general is easier when the documents are in PDF format. This choice does lead to some interesting follow up considerations.
What PDF format will be used? PDF/A is the ISO standard (19005 to be precise) for archiving and as such a good choice for just archiving and dossiers inside a controlled environment. PDF/A e.g. does not allow security to be applied at the PDF file itself and this makes it less applicable for sharing outside a controlled environment. For this, additional measures can be taken. This does not mean moving away from PDF/A at all because that’s even worse. If security is a concern and you still don’t want to consider PDF/A be warned that not every PDF standard is practical. Older versions may not have important functionality like access security, watermarks/overlay and content tagging. On the other hand, downscaling a PDF in the 1.7 format (Acrobat 
to PDF/A may cause a loss of interaction functionality.
What is the granularity of output generation? For a dossier it’s obvious that each document needs its own PDF file. For archiving this may not be the case. If one business process produces a set of documents (e.g. a contract, a product description and terms & conditions) you me want to be able to reproduce this set. One way of doing that is by combining them into one PDF. But beware. Your records and compliance manger may require you to delete part of the PDF on an earlier data than other parts. And your user will complain when they look for that one particular document from a multi-document PDF. Search (both on metadata and full text) will return more hits than needed. Reading the document requires them to browse inside the PDF to the actual document. Printing requires them to restrict the number of pages to be printed.
Maybe your terms & conditions are standard for thousands of contracts. You now are storing them as many times as you have contracts in stead of once.
Tracking which documents belong together from an output perspective is useful but can be done in other ways.
How do we handle stationery? The generated output typically doesn’t include the stationery. For reprints from your archive or dossier, this can cause a problem when the stationery physically no longer exists. It assumes that you still know which version of the physical stationery was used. But if you don’t actively start storing this information, you won’t know. And can on line viewers understand e.g. the invoice now that it lacks the look and feel of the stationery? Including the stationery as a background layer does increase the storage size and requires reprint to be done on blank paper on a color printer.
How do we handle the outbound – inbound loop? Part of the business output will be returned for valid business reasons: the contract is signed, the form is completed, and the requested copy of the ID has been provided. Do we match the returned and probably scanned document with the output? The signed contract should ideally be a new version of the document that was send. Including recognizable marks on the output could make your live so much easier than without them.
Is the timing right for both? Output tends to be archived in batches. But do you need and can you handle on demand generation and storage of the output? Or go even a step further. For some business documents it might be useful to have the document already in the dossier even if the output hasn’t been printed and distributed. You may find this odd but wouldn’t it be nice of the account manager can see which business output sits in the pipeline when the client gives him a call? Wouldn’t it be nice if this predictability of the output distribution can help increase customer satisfaction? If so, you may want to have output in the dossier long before it is printed. And yes, to control this you need a closed-loop solution that can set flag to differentiate between output that has been send and which has not.
Maybe there is much more to say. Maybe I will do so in a later post. This one is long enough already. I know I’m not complete on this. That is intended. See this as a wake-up call. An eye-opener if you like.
Note 1: The AIIM definition of ECM can be found here: http://www.aiim.org/about-ecm.asp
Note 2: More about this CMS Watch publication can be found here: http://www.cmswatch.com/vendormap/
