Why Complexity Matters

Einstein once said that everything should be made as simple as possible, but not simpler. And so it is with document automation. Everyone wants to make it as simple as possible. But anyone who tells you that it is simple (presumably by consuming whatever snake oil they are selling) is lying. Some document composition tasks are, by their very nature, highly complex, and some will make your head hurt. The challenge is to find the simplest and most effective way of dealing with them, so that you can fully reap the rewards of automation. Which begs two obvious question: what do we mean by complexity and does it affect your documents?

Yes, you do need to worry about complexity…

For present purposes, let’s break complexity into three buckets: low complexity; medium complexity; and high complexity.

If all you ever need to do is some kind of mail merge or field substitution, where you feed in some names, addresses, products or prices, then you are dealing with low complexity automation. This is the home turf of “customer communications management”, which, for the most part, means mass-mailing thousands of letters to thousands of customers, and making sure it says “Dear Bob” or “Dear Betty” at the top (this personal touch making Bob and Betty feel all warm and fuzzy). The documents might have some picky layout or branding, but the content is largely standardized and the variations are limited and controlled.

As you move from consumer (B2C) to business (B2B) transactions, where contracts are negotiated and paperwork is much less standard, you enter the world of medium complexity automation. In order to handle negotiated fall-back language in contracts, you need to support conditional logic, auto-numbering, dynamic cross-references, and page layouts that work no matter what combination of clauses ends up in the final draft. You also encounter repeating arrays of data, which is a fancy way of saying that lists of names, prices or products might need to contain 1, 2, 3 or 30 items. And because real people need to tailor each document to reflect the deals they negotiate, you have the added complexity of designing an intuitive, interactive, wizard (rather than simply pressing a button to run a batch process).

The final frontier is high complexity automation. We won’t attempt an exhaustive list of the joys that await, but we will give you a taste. You may need to assemble not one, but 20 different documents, or a subset of those 20 documents, all from a single questionnaire, without ever asking a redundant question. You may need to handle deeply nested conditional logic, where you include some special compliance-related clauses only if you are selling pink widgets, manufactured in the third world, sold by your US operating subsidiary, and bundled with consulting services in the State of Texas (everything’s bigger in Texas). You may need to generate documents that list repeating data (for example, a description of all the property you own and the value of each item), within other lists of repeating data (for example, all the locations where you do business). Or you may need to automate a set of documents that sometimes has two parties (a lender and a borrower) and sometimes has many different parties (4 lenders, 2 borrowers, and 3 guarantors). There’s a prize for anyone who comes up with a cool-sounding collective noun that covers borrowers and guarantors as a single class.

Now, before you say “most of my documents are low-medium complexity”, it’s important to remember that what matters is not average complexity, but peak complexity. For whatever package of documents you need to automate to get a new and improved business process, ask yourself what’s the most complex challenge in the most complex document. If this is a high complexity hurdle, then you will need to clear it to solve your business problem. This “peak complexity” is what really matters.


Which is not to say that you don’t have choices about how you deal with peak complexity.

For a one-off, tactical solution, you may choose a low-cost tool which can handle some of the automation out-of-the-box, and pay for custom-coding to solve the tricky bits. Or you could simply automate the easy bits and tell your users to use a manual work-around for the rest. But these approaches carry significant risks.

Custom-coding is a rabbit hole which can get deeper and deeper as you stumble into one unexpected surprise after another. It also leaves you dependent on the programmers who cut the code, which can make maintenance and enhancements slow, expensive and in some cases impossible (for example, when the only person who understands the code moves on to other things). And manual work-arounds can be just the excuse users need to reject a promising new solution. Plenty of people hate change, and if a change is clunky they will gleefully use that to justify a return to their bad old ways. Manual steps also threaten the compliance, cost and speed benefits the solution was supposed to deliver.

For enterprises looking beyond the tactical, to the full range of document-intensive processes that can benefit from automation, it’s important to make investment decisions with peak complexity in mind. There’s great value in document automation. But if you don’t have the tools to handle peak complexity, you may be leaving much of that value on the table.


Peter says:

Is “Obligor” cool-sounding enough?

Anonymous says:

Thanks for the excellent three-part-analysis of document complexity. I have build some document automation solutions using Word/VBA or Visual Basic 6 with Word, and there are solutions I have to update regularly, with another point: I'm still the programmer understanding the solution and the complexity (after 5 years), but in the business the responsible person has changed every year. Not

Write a Reply or Comment

Your email address will not be published. Required fields are marked *

Achieve 100% Contract Certainty™