What is Document Generation and Why do I need it?

Document Generation is the process of generating documents dynamically. That is, the content of the document is customized for the intended recipient. Simplistically, it may be thought of as 'Mail-merge on steroids'. For example everybody's bank statement is different – that is, each bank statement is generated for specifically for the recipient.

All organisations do this in one form or another, and most do it very poorly.

Typically, document generation falls into the following categories:

1. On-Demand – "I am generating the document and want to look at it now, please". Common examples of this include generation of documents by mainframes (Figure 1), by an application server (Figure 2), or through the use of Word Templates with the possible addition of some VBA macros (Figure 3). Note that typically Word document generation requires the use of a distiller (such as Acrobat Distiller) to produce an electronic file copy.
2. Interactive – "I am generating the document, but want to interact with it before I produce it". E.g. I want to choose the paragraphs to include. Maybe I would like to include a custom salutation. This typically involves some sort of approval process, or work flow.
3. Batch – "I am generating 10,000 of these, and want them all printed off and delivered". This is typically done after hours.

Various Enterprise Document Generation Systems

Most enterprises have many different document generation systems. Here are some typical use cases:

Generation of Documents by Mainframe (Figure 1)

In this example documents are generated directly by the mainframe. These are often fulfilled by mailhouses who print the (text output) directly on to pre-printed stationery (shells).

Generation of Document by Application Server (Figure 2)

This is a typical example for a web based application, where the web server uses a library such as iText, or a report writer (such as Crystal reports) to format and generate the output.

Production of Document using Microsoft Word (Figure 3)

In this example, text is merged with Microsoft Word templates. Sometimes this is done in a server application with mixed results.

Manual Document Generation

This example shows a typical interaction that you might see in a call center. i.e.

• The customer phones a call center operator.
• The operator uses internal Standards and Procedures to determine the type of document to produce.
• They then use a boilerplate document, and add information from core systems.
• This often needs to be approved by some sort of workflow.
• A copy of the correspendence is kept - sometimes as a physical copy, sometimes in an imaging repository.

Mailhouse Print Re-Engineering

In this example, a mainframe generated document is passed over to a mailhouse who re-engineer it by:

• Repositioning the text.
• Removing content.
• Add postal and insertion control barcodes.
• Print onto pre-printed stationery or shells.
• They may also do things like completely regenerate the document after extracting the data, or adding additional text or targeted marketing messages to the document.

So what is wrong with these approaches?

• Complicated
  • Too many pieces involved.
  • Difficult to integrate.
• Inefficient
  • Many people, systems and processes are involved. This leads to duplication and multiple handling.
  • Often times, it leads to multiple customer communications rather than integrated customer communications.
• Slow to Change
  • Systems are difficult to change, and slow to deploy leading to lost opportunity costs.
  • Non standard systems mean that staff must be specifically trained, and so it is difficult to resource when workloads increase.
  • Driver for change can often be external such as legislative (e.g. Sarbanes-Oxley)
• Expensive
  • Duplication, inefficiency, complexity all lead to high maintenance costs.

So what should a good solution look like?

• It should have a sophisticated templating environment, suitable for use by a wide variety of users.
• Data and presentation should be separated, so that the presentation (e.g. how the document looks) should be able to be changed independently from the system(s) that produces the data – i.e. you should be able to change the content and styling of a produced document, without modifying the core system.
• Changes should be able to be made quickly and with confidence.
• Content should be re-usable across the enterprise.
• The solution should be standards based.
• The solution should have an open architecture.
• The solution should provide services suitable for consumption in an SOA.
• The solution should be performant enough to support the enterprise.
• The solution should be architected in such a way that it can be easily integrated into existing processes, data providers, and workflows.
• It should be capable of providing a large number of output formats.
• The content should be secure.

The following diagram illustrates a best-of-breed approach using the Scriptura product set.

It is important to note the following:

• More than one calling application uses the same document generation service. Note that in this case the interface to Scriptura, is via web-services.
• The templating tool is the same for each calling application, allowing for the duplication and centralization of templating resources.
• The server can produce multiple output formats.

For more information please contact us.