Deep Structures of Business Processes

In May of 2006 Jan L.G. Dietz wrote an article for the Communications of the ACM entitled “The Deep Structure of Business Processes.”  Someone recently sent me a copy of the article and asked a number of questions about it.  Obviously the title derives from the work of structuralists, like Chomsky, who posit a “deep structure” for natural language — a kind of hardwired grammar that the structuralists believe limits what the mind can do.  I doubt that Dietz intended us the take the analogy too seriously, but the idea is intriguing:  Is there some deep structure that lies beneath the surface and defines the essential structure of business processes?

The article, it turns out, is a recapitulation of arguments made by Terry Winograd and Fernando Flores, who wrote a popular, if nearly mystical book, Understanding Computers and Cognition in 1986.  Specifically, it focuses on Flores' language-action theory that interactions between participants involve communications in which actors exchange “requests”, “promises”, commitments” or “declines.”  It's an interesting idea, and if you are dealing with interactions between customers and employees, or negotiations between business entities, it can be very useful.  Still, bottom line, it doesn't form a deep structure for all processes.  Some processes are automated and don't involve any human interaction. Some process simply involve people and robots working on an assembly line.  Still other processes invoke designers working along to create a new model.

For most of us, developing a picture of a business process using a workflow modeling language like BPMN, with boxes and arrows, and perhaps some swim lanes, is the most useful way to capture the basics of a process.

If you really want to think about “deep structures” that might lie below the boxes and arrows of a flow diagram, let me suggest some other possible “deep structures.”

1) A model that shows how information is passed from one activity to another, picturing who has or lacks access to what information at what point in the workflow.  I'm using “information” rather broadly in this case — to refer not so much to data, as to insight and awareness.  Who in an organization knows what's going on and can really answer customer questions, for example, and who is just following a rote prescription and lacks real understanding.  Why do some items always get referred to specific people who seem able to solve problems that others can't.

2) A model that shows how feedback is passed backward “up” a workflow chain to assure that people earlier in the chain know the consequences of their actions.  This usually involves passing information about results to supervisors who then communicate it to workers.  For certain tasks, its very important that workers know if their outputs are well received and appropriate for subsequent activities.

3) A model that shows how people are reinforced or rewarded for actions.  Obviously their are salaries, but who gets bonuses, and who gets recognition?  What kind of rewards are given and how frequently.  One can ultimately think of an organization as a who network of people getting praise or blame and the resulting “economy” goes a long way towards explaining why some processes run smoothly and others do not.

4) A model that shows how data is input and accesses from information systems (databases, applications) used by a given process.  IT people worry a lot about this, since who updates what determines the accuracy and usability of data.

Like, the structure of communication interactions, all of these different types of “flows” can be critical to understanding why a given business process is or isn't working as it should.  At one time or another I have played around with ways to diagram each of these different types of flows.  (Data flow diagrams have been well defined by IT people, for example.) All are irrelevant is some circumstances, but very important in others.  Hence, they aren't “deep structures” so much as they are details that we need to understand as we drill down in some cases and can ignore in others.

It was interesting to review, again, the ideas of Winograd and Flores.   It is a good reminder of how many people have worked, over the years,  on one or another aspect involved in understanding why some business processes are excellent and others just don't work as they should.  We all need a wide variety of different tools when we set out to understand and improve processes in a large organization.

FacebookTwitterGoogle+Share

Speak Your Mind

*