Structure is in the Eye of the Beholder

Michael Poulin made an excellent post called “Why business process is always structured?” which delves into the question of why people believe that work is predictable when often it is not.  He compares ACM and BPM and the illusion that makes them appear the same.

Michael says “enthusiasts of process management believe that ‘process is everything we do’“.  So true.   It is this belief in that a process must exist, that drives the existence of the process, not the other way around.

He says “But, wait a minute, do we know what/why we do things? Do we really know the logic of our actions?”   Truth is, we do things, and then later rationalize why we did them.  However, it is not clear that that rationale is in fact the cause of the actions.

Actually, this post is so right on, I am tempted to quote every paragraph here in entirety, but that seems pointless when you can read the original.  Let me however quote his conclusion for emphasis:

Presented observation leads to simple conclusion – Adaptive Case Management and Business Process Management have only one common thing – business management. ACM is not about process management due to the absence of the process, it is rather about a management of consequences of unpredicted events, which itself is very important business task.

I could not have said it better.  He says we find ourselves in this position because both sides “use term ‘process’ inappropriately.”   That is precisely it.  ACM is not simply process management with no process.

The Illusion

I describe it as an illusion.  When an art student first attempts to draw an outdoor scene involving a tree, they commonly will start by drawing a line around the tree.  That line does not exist in reality, but it is a construct of the mind which automatically classifying what you are seeing.  The tree “looks” separate from the surrounding, because we understand that the tree is a separate entity from the mountain behind it.  The art student must “unlearn” this habit of drawing in the borders between conceptual things.  Such unlearning is not trivial.

A very similar thing happens when people attempt to describe workplace activity.  In reality activity is continuous and without distinct boundaries.  It is the mind that interprets the activity, and draws in the boundaries between different activities.  Without drawing these boundaries, it would be impossible to talk about what it being done, yet we should not forget that they are merely the result of analytical reasoning about the activity.  I wrote a bit about this a year ago in “It is All Taylor’s Fault.”

The Blindness of Hindsight

There is another source of illusion, and that is the belief that “hindsight is 20/20”.  Consider this:

Learning a subject involves the act of forgetting that you don’t know it.

This trite phrase reminds us that when you learn something, it is very hard to remember what it was like to not know that.  When a case manager works through a case, continually assessing the situation, making decisions that define the course of the work.  After it is completed, the case manager knows all the facts of the case, and all the key decisions that were correctly, or incorrectly, made.  It is easy to think that the whole “process” could have been set up in advance.

If you have followed this far….

We are taught from early years to explain how things have been done, and how they should be done again.  But these process diagrams are often “cartoons to the tapestry of life”.  When I say that business processes are cartoon, I don’t mean to belittle their need or usefulness.  In cases where the process is well known and repeatable, such cartoons are very useful indeed.  We should not, however, confuse those cartoons with reality which is much more complex, and much harder to talk about.  Our minds naturally put form on what would otherwise be undescribable, and we are fooled by 20/20 hindsight into believe that it all could have been drawn up in advance.  We vastly underestimate the variability of action that could have occurred.  We vastly underestimate the amount and nature of exceptions that occur.  Most of all we vastly under-appreciate how well intelligent people can use experience to smooth out the small bumps and make the whole activity appear uniform.

Wishing you a very Happy, if Unpredictable, New Year.

7 thoughts on “Structure is in the Eye of the Beholder

  1. Keith, great pointer and analysis. I am obviously in full agreement in principle with Michael, because you and me have been writing about this for years.

    The comparison of ACM with BPM is dangerous, because BPM does not require technology. ACM is a technology driven solution. We can compare ACM with BPMS!

    But I am not totally happy with the very narrow definition of process, because that is not how it is being used in the market. If process only means FLOWCHART then Michael is right, but if processes are focused on reaching goals without nailing down exactly how to reach them then it is still BPM. Processes define also a structure outcomes, skills, objectives, targets and goals and for that we need ACM, because BPMS have no functional support for that.

    What is even more important is the reiteration that process management must support working towards goals while constantly dealing with disruptive events.

    More on this here: http://isismjpucher.wordpress.com/2010/11/15/can-bpmn-and-rules-handle-complex-events-no/

    And yes, as I just wrote in my most recent post: The SKILL of the performer achieves the process goal and is the leverage point to the outcome as per the value proposition.

  2. Folks, thank you for your kind words.

    I am approaching BPM and ACM from Service Orientation perspective (in OASIS SOA semantics, which is not about Web Services). My general motto is that the most things we do are services; we serve each other inside the company and across its boundaries.

    I am promoting the view, which might be quite disagree, that a business or ‘technical’ process in an implementation of the business or technical service, and there may be many alternative implementations performed in different ways, by different people with different skills BUT all of them result in the execution of the same business functionality and deliver the same result – Real World Effect (RWE).

    Recall that for services particular implementation is immaterial. So, one service differs from another services by its business functionality and RWE. For the process, all attributes mentioned by Max are important but one process differs from another process only by its process business logic, i.e. HOW we reaching the RWE. Moreover, the process is agnostic to its sub-processes or actions – the only important things about actions are: their results in full and on time (SLA) and interaction interfaces. This is what IBM, e.g., used for their Dynamic Process Edition.

    In other words, process to me is very concrete thing that realises the tasks (business functionality) and delivers RWE utilising certain resources. Besides process logic, the resources affect the quality of the process results. In SOA, there is a notion of Execution Context – set of rules, regulations, policies and resources – where particular service operates. This Execution Context effects not only the quality of the services results but also the results themselves. I believe this concept of Execution Context is equally applicable to the business processes (this is why the same processes – the same business logic – may have different results).

    Overall, service-process-service-process-… chain is how we work and how an enterprise is supposed to be constructed (while it is not so far).

    I hope, this explains my view; I would happy if I can find people who think the same way but slight discrepancies are only healthy for the progress.

  3. Pingback: Новогоднее сражение ACM vs. BPM « Архитектура информационных систем

  4. Pingback: Process, Structure, and the Illusion of Hindsight vs. Foresight » Process for the Enterprise

  5. Pingback: What Could Cause Adaptive Case Management to Fail in 2011 « Jacob Ukelson's Blog

Leave a comment