I have been thinking some more about Human Process Management, especially how it differs from Business Process Management. Certainly one key difference is whether the process is structured or not - i.e. whether you can prescribe the execution of the process based on some model of the business.

It is clear that there are a number of mainstream business processes that lend themselves to such a model (e.g. ERP,CRM), but I claim that most processes in an organization are human2human (or people2people) processes and the tend to be ad-hoc and dynamic. It turns out that even structured processes have a large number of exceptions - that tend to be handled in relatively ad-hoc, case-by-case manner.

I was reading an old blog post by Pravin Indurkar where he looked at B2B EDI purchase order transactions at a small business and found that though there was one standard process -there were 65(!) different variations depending on the nature of the order. While it would be possible to model all the possible process paths - it certainly would be time consuming and expensive. My guess is as soon as you model the 65 different possibility there will be a 66th and 67th that are used to take into account variation and business conditions - so the way these are handled is usually through an unmanaged human exception process. These human processes are either exclusively human to human process (collaboration) or human processes that invoke various systems as part of the process (or what Barry Briggs calls human-down processes).

These types of Human Process are far too fluid and dynamic to be made part of an Enterprise BPM system - and tend to handled through email - yet another cause of email Information Overload…

I have been thinking about documents and their usage context in organizations. Knowing how a document is used is just as important as knowing the content, though today’s document repositories don’t really know the usage context for the documents they store. At best they and let user try make up the gap with tagging and descriptions. Most human centric organizational processes entail the use of various documents as a natural part of the process - either as input to the process (e.g. research or background) or output (e.g. a findings report).  So the link between documents and their process context is a natural one, and critical if you really want to understand the document.

So it is surprising to me that this hasn’t come up more as an issue in document management systems - the need to really connect documents and the flow of the human centric process that uses them - even if the process is an ad-hoc one executed (as most are) over email.

You could decide to implement all processes as a workflow in a document mangement system - but for many processes that would be overkill (especially the ad-hoc kind), would just take too long and require to many IT resources - not to mention that it would require the users learning a new way to do things. If you decide to keep the documents in a standard repository - then you lose the connection between the process that used or generated the documents - which means that you really can’t understand how the document is actually used in an organizational context…