I have copied here a message I sent to a BPM Guru regarding the origins of the Civerex ACM/BPM workflow management methodology and software.
“Peter… I like your notion of ‘ … start from scratch and come up with a concept derived from first principles’.
We spent a lot of time analyzing shortcomings of our own approach to workflow management over a period of 20 years.
We proceeded otherwise – our results had their origins with Critical Path Method (invented in 1957 with antecedents going back to the early 1900’s). I spent 9 years at one time researching CPM/PERT and building large systems for General Electric Company and the Bechtel Corporation. The notion of tasks having precedence/succession relationships is pretty general so long as you accommodate a degenerate implementation comprising standalone tasks.
Whereas CPM always had a predictive focus (time of arrival at milestones, resource leveling/balancing, and virtually nothing at all in the area of quality of work), we started in medicine where it is difficult to predict timings (either for walk in clinic appointments or surgical interventions).
Our origins with CPM led us to graphic representations of tasks and their interconnections. We invented constructs not in CPM (rule-based branching, loopbacks, hidden ‘gatekeeper’ tasks executed only by robots).
A key point in our work was to develop a complier for our flowgraphs/workflows.
We always had trouble with unstructured tasks until we read “Mastering the Unpredictable” – this had a eureka effect on us and led to a very simple and effective concept of a ‘revolving door’ where you can at any time generate an instance that is a workflow of one step at a menu of all possible services that an organization is able to perform. The ‘menu’ approach allowed us to list all services performed at an organization plus all workflows.
There is more to this, of course – with 200 workflows, one cannot rely on users to decide which one to engage next so the generation of instances had to be automated (i.e. patient has these symptoms, the decision support system posts candidate diseases, the doctor picks one or more, the system then engages disease-specific processing).
The final element (probably the most important) was configuration of the User Interface.
Realizing that all work for any day is composed of fixed time pre-commitments plus ‘to-do’ lists, we made the interface somewhat like Outlook. This greatly reduced resistance at the user level (anyone who knows how to use Outlook or even a paper agenda book immediately is at ease with the system). The significance of our Orders InTray (to-do list plus calendar) was to allow us to go from 200 screens to 1 screen.
I have noticed several times in your posts a focus on ‘collaboration’ – this is not workflows, not ad hoc tasks, but rather a highly subjective initiative on the part of an individual to reach out to someone else. One person may do this to perform a task, another person performing the same task may not need / want to reach out. So it is totally unpredictable with no apparent consistency across individuals, and no apparent consistency with any one specific individual (e.g. today I may do a task and have some uncertainty so I reach out, another day I may do a task that requires the same skill set and I may decide to do the task and not bother to get a ‘second opinion’). We invented something we call ‘collaborative consultations’ to address this need. Collaborative consultations greatly reduce medical and administrative errors during the processing of instances.
No system can these days stand alone, so we made our ‘ACM/BPM’ software suite open-ended – anyone who uses our software can become a publisher and carry out bi-directional data exchange with any number of subscribers and publishers for subsets of available data. And, each publisher/subscriber is free to give whatever names they wish to data elements. I can publish ‘abc’ and one subscriber will read this as ‘def’ and another as ‘ghi’. The only caveat is that if you want to subscribe to my ‘abc’ data and the data values happen to be 50 characters in length, then if you set up ‘def’ with a capacity of 30 characters you will see truncation. Otherwise there are no restrictions (strings, integers, Boolean, date, time sound, video)”.