What Actually Happens When a Document is Automated?

In a recent post we covered a few strategies and toolsets for keeping document automation projects manageable. Here we look at the objectives and outcomes of these projects, and what happens within.

Somewhere in your business, a new or existing document-generating process needs attention. New processes may be candidates for automation. Existing manual processes may be candidates for automation. Existing automated processes may be candidates for new technology.

The rationale for giving attention to such processes is that they, and/or the documents they generate, are of sufficient value to the business to justify the attention.

The value proposition may be positive – contracts, agreements, sales proposals, employment contracts, and other documents that bring benefits to the business – or it may indeed be negative – resources better used elsewhere, or documents that simply carry too much risk for the bottom line or the business itself if they are not right.

It should come as no surprise that many documents and processes fall in both camps, but that only enhances the rationale.

The rationale drives the objectives: better document processes and better documents. The project gets the nod. The outcomes will depend on what happens next.

Document generation relies on institutional knowledge which is in turn built on institutional logic.

The logic derives from how the business must work, and is predictable. Sales proposals follow leads. Invoices follow sales. Offer letters follow candidate selections. Reports follow evaluations. But what is the knowledge?

Institutional knowledge speaks to the details: what is the source of the customer / employee / product / service data that populates a given document? How does content change from one customer / business area / sales type / job offer, to the next? What allowance applies to adjustment of standard pricing or other attributes? What aspect of a document determines whether or not it needs approval? Email or print for this customer? Which logo / page header / style applies to which business area?

Without automation, the knowledge may well be codified already into manual processes as written procedures, detailed instructions embedded in the text of documents, hand-me-down know-how, or even ‘everyone knows that’.

Knowledge codified this way is not easily updated and not guaranteed to be current, reliable, or even persistently applied.

When a document is automated, the institutional logic and knowledge is formally codified into an automated process.

This may happen within the templates that generate the documents, within the processes that deploy the templates, and anywhere else in the process.

Retained in this way, the codified knowledge can be easily updated, and is always current, reliable, and consistently applied.

The effectiveness of automation, and therefore the outcome for any automation project, relies on the capabilities of the people – and the tools – involved.

You bring your people to the project for their institutional knowledge. Subject matter experts, business analysts, and database and app specialists; together they know their business and how its documents fit with it. They know or can identify the prime candidates for the automation process. They can define in detail the content, business rules and information sources that will elevate templates and processes from mundane to cutting-edge drivers of quality and competitiveness. They can develop and execute proper testing plans to ensure fitness for purpose.

The toolset will largely determine whether or not the people and their skills, and therefore the project, are effective. On this topic, we’re less interested in what’s used for project management and communication. We are interested in the tools used for the core automation activities, and specifically in a couple of key characteristics of these tools: features, and usability.

Features are a large part of what drives purchasing of products and services. To pick one example – which we will explore in more detail in a future discussion – consider the feature that underpins most of the functionality and features: the markers used to embed automation in templates.

ActiveDocs tools – our products – are built on the use of sophisticated markers that facilitate and maximize all of the capabilities outlined above, running end-to-end, from template design through to document workflow and delivery. Yes, they matter; simplistic markers make for simplistic feature sets.

A tool’s usability – or lack of it – can stop a project in its tracks. If the tool’s interface is difficult to use, if it doesn’t allow you to identify dependencies or help you to avoid breaking them, if every change to a data source means revisiting all of your templates, if every new or changed data item requires a new or changed bookmark in the documents and then you must link that on another form to a placeholder field… your team might just spend more energy fighting the tool than improving the business.

Our products are built for enterprise-grade deployment. We are dedicated to their development and we build on our industry awareness, our own experience and the experiences of our global multi-vertical customer base to inform that development.

Given this deep and wide investment we are confident that our products can meet your challenges and we are unashamedly focussed on our products being part of enterprise projects for large organizations.

ActiveDocs brings its services expertise to the project, indirectly by training your people, from template designers to administrators, and directly by providing both kick-start and long-term template design services and other consultancy when we are needed. As with our product development we invest in great people as well, and as with our product development we are completely confident that our people and your people can do great things.