Barry Talks! : Common Sense for Uncommon Times

Friday, January 28, 2005

Processes and Documents

Here's a provocative statement: every business document is an artifact of a business process -- but we have yet to build a product that treats them that way.
As we enter the Decade of Process, it's increasingly evident that documents -- forms, Word documents, spreadsheets -- are renditions of the state of some larger process. It's the process, not the document, which is the overarching concept.
When you renew your driver's licence, or submit a purchase request for a new computer, or build an SEC disclosure, or edit a performance appraisal, all these forms and documents are really projections of the process.
Let's think about this for a second in more detail. Say you want to buy some pencils. You fill out a form. You hand it to your manager. The manager signs it. You fill out a purchase order. You mail it. You get your pencils. You get an invoice. Your manager signs it. You send it to accounts payable. They fill out another form. It goes to the bank which has its own forms, and ultimately the pencils are paid for.

Now, step back for a few moments. In this process there's a lot of context, shared across all these documents: there's you, the customer; the pencils; your manager; the vendor; the A/P department; and so on. What if there were a process that knew all this, and emitted the right documents at the right time?
In our example above, say the process "knows" that this purchase is at the 'needs-manager-approval' state, and therefore on the manager's desktop appears a just-in-time form populated by this process context to which he or she can attach a digital signature.
Indeed, everything about the document is conditioned by the process. Who the document goes to; what the fields contain (here, your pencils); who originated the request (you); what fields are available for editing (approval, and/or the edit box saying why you can't have them); and maybe even a list of recommended vendors populated from the corporate procurement database.
And once the manager approves, the "document" is no more. The state is recorded in the process which goes to the next step (and perhaps the approval is also noted in a database for auditing purposes). The forms program here is an editor for the process. The document itself is merely a transient rendition of process state.
When it's time to generate a purchase order, that same context can be used to instantiate the right kind of document formatted in the way the vendor wants to see it; and similarly with the invoice. All these are views on the context and state of the process.
Now, none of this is intended to diminish the importance of these editors, for how else would we humans be able to interact with automated processes? Rather, we seek to reposition documents in the spectrum of computing assets: they are the user interface into business processes.
Process has driven business for millenia -- that's reality. Documents, be they carved in stone tablets, typewritten, or word-prcessed, have always been projections of process. What's changed is that with the approaching ubiquity of process engines and the existence of a common metaformat for process context (XML) we can now model and deploy business processes in a way much closer to the way business works than ever before.
For decades we've said that usability means getting the tool out of the way of the task. We're one step closer.

Comment (0) #