The quote above comes from The People Are the Company by John Seely Brown and Estee Solomon Gray.  It is a great quote highlighting where business process tooling seems to fail - in handling human interactions and their approaches to processes and problem solving. 

This is the subject of a book (written in 2005) by Keith Harrison-Broninski, Human Interactions, The Heart and Soul of Business Process Management. The information is also overviewed in a paper by Harrison-Broninski at http://human-interaction-management.info/A%20Role-Based%20Approach%20To%20Business%20Process%20Management.doc. The paper and book describes the mismatch between human-driven and machine-driven processes, and that most processes are the former, while most tooling supports the latter. 

The mismatch with human processes is that:

• People evolve and adapt a process depending on various factors (such as what they learned in another process or iteration)
• Therefore the process canNOT be prescriptive but should be "supportive"
• People work multiple roles and/or processes simultaneously and may bring knowledge from one role or process into another
• Who a person is, what they do and what they know make a difference to the outcome
• People turn information into knowledge and incorporate that knowledge into the outcome
• Information and knowledge are not static
• People jump around in a process trying to be as efficient and effective as possible
• Again, the process canNOT be prescriptive but should define a typical/best practice approach

So, where do we go with this?  The author suggests using and modifying Role Activity Diagrams (RADs).  Before reading this book, I had only a passing acquaintance with these diagrams (since there is almost no tool support for them). RAD was conceived quite some time ago - it was proposed in 1983 by Holt, Ramsey and Grimes in Electrical Communication. Although not widely implemented, the concepts are quite valuable and should be used to inform BPMN and other high-level process modeling work.

OK, then, what are the main concepts in RADs? These are defined as:

• Roles (divisions of responsibilities)
• Users (specific humans, organizations/groups, machines, etc. assigned to/placed in roles)
• Resources (any process object and/or information)
• Activities (one or more tasks that manipulate resources)
• Interactions between roles
• States of a process (logical conditions that control execution and validation of activities)

You can probably see the corrollaries and differences vis-a-vis BPMN (Business Process Modeling Notation, http://www.bpmn.org).

And, what modifications are needed? These are discussed in Chapter 3 (a "New Theory of Roles") of the Human Interactions book as:

• Adding attributes to roles and users (more on this below)
• Use of a role to start, stop or manage processes - which means that anything can be a resource/trigger and can be shared with another role or user
• Ability to track that multiple copies of information exist as a normal part of the process 
• Allowing jumps from one activity to another, along with repeating and interleaving activities as necessary 
• This directly relates to the fact that a process is informational, and not prescriptive, and that each activity should have pre/post-conditions to define when it can occur
• Activities are not atomic (just as BPMN processes are not atomic) but can be further defined/refined 
• Interactions are not synchronous - there are multiple channels for sending and receiving resources/information

These thoughts really resonated with my experiences, and suggested areas to work to better capture business process information.

I did want to expand on what Role and User attributes were deemed valuable (I mentioned this in the list directly above).  For Roles, these are:

• Goals (terminating conditions)
• Responsibilities and requirements ("always true" conditions)
• Necessary data/information
• References to other roles (to get more information)
• Capabilities
• Process authority

And for Users, these are:

• Identity
• Physical and virtual location
• Private information (beyond what is provided in the Role)
• Relationships (at the instance level)
• Behavioral tendencies
• Capabilities
• Organizational authority

Pretty interesting!  More on this in later posts.

Andrea