ACM and BPM: A Battle of The Hemispheres?

Because there are already enough predictions on BPM for 2012, I will rather discuss how and why we try to predict things, including processes. This post also explains why my research into software systems focuses since 1997 on both entity modelling and pattern matching. Much what has been purely intuition then is now much better understood.

ACM versus BPM and BPM as part of ACM and …???

Many have tried to define and classify what BPM is and not and what thus the difference to ACM is. There is further ambiguity looming when we aren’t clear whether we talk about concepts and methodology or software and systems. I found that the core problem is a battle of mindsets and won’t thus be easily resolved. The two approaches are separated by how our our right and left brain hemispheres view the world. ‘Ah,’ you might think, ‘Here we go again with that boring discussion about the battle between our reasonable and emotional selves.’

Actually, that depiction of our brain is inaccurate. I will thus focus here on discussing the human mind and not technology as it provides important understanding. It may surprise you, but reason is not situated in the left hemisphere as humans possess no such ability. Emotion is not situated in our right brain hemisphere, but a central brain function associated with chemicals excreted by the amygdala gland. Reason and emotion are one and the same thing. Antonio Damasio discovered that it is not our rational ability that comes to decisions but our emotional center. It is not our ability to reason that searches our memory database with keywords, but emotional responses triggers memory patterns. To think, communicate and contemplate actually needs both brain hemispheres, and not just our left. Our abstract thinking just contemplates feelings, but it doesn’t really predict and it doesn’t decide on actions and goals. That a potential pattern for the future is a plausible one is not a rational prediction but an intuitive emotional weighting.

American Phrenological Journal

Why is the brain split in two hemispheres with different abilities?

We simply don’t know, but apparently evolution found it beneficial to keep them quite well separated. Yes, the left brain hemisphere harbors our language-oriented ability to formulate abstract concepts. We still can’t understand language or speak coherently without the sensory processing of our right hemisphere and additional motor skills. The left is our SERIAL thought processor but it doesn’t reason, it just models. It performs serial contemplation in abstract concepts but does not interact with reality. So where do these abstract models come from? They are received by our senses and processed in PARALLEL by our right hemisphere as repeatedly recognizable patterns and then linked to abstract model terms in the left. This illogical and non-reasoning pattern matching in the right is what we refer to as intuition. The abstract contemplation of the left is what we call imagination. The right hemisphere is about our sensory experience of now while the left presents scenarios of our past and enables us to imagine our potential future. It is necessary to link these two together to create our conscious self and it is the job of a tiny part in our oldest part of the brain called the medulla, sitting where the the spinal cord enters the brain. Besides vegetative functions such as heart beat and breathing, it also connects our bodily experiences to our feelings of now and to our abstract thoughts. If our medulla is damaged we fall into a coma. Our goal-orientation is not some logical plan but purely hormonal drives that we turn into abstract models. We do things to feel good. Always! Which does not mean we are selfish, because we also feel good when we make people happy.

By the way: Those who see humans as being distinct from animals through emotions and the conscious self should consider that most mammals have a similar medulla and amygdala as the human brain. We must assume that they feel conscious emotions the same way as we do, while most just can’t think abstractly about it. While that may be the much easier way to lead a life, I propose that most primates actually do abstract as well, as some could be taught up to 200 hand signs, including some for joy, fear and love.

The difference between motor automation and abstract plans.

Our intelligence is apparently related to our ability to predict things. Because we always expect things to happen from experience, the amount of processing we need to do something is reduced. But we must not oversimplify: There is a functional difference between motor skills, pattern recognition clusters and abstract predictions. Motor skills can be trained by approximately 60 repetitions to rewire the six neuron layers below the grey matter to automate a motor skill. Motor skills can be likened to manufacturing, where automation has an efficiency benefit. If we would have to consciously think about how to move our limbs we would not do much else and would be pretty clumsy. Human motor automation is a complex interaction between sensory input patterns and nerve responses. Because we cannot control our environment like a factory, what we do in real-life in the motor-cortex is very different to mental conveyor belts. In a neural representation of our limbs (homunculus) we build sets of sensation-response patterns from past experience that traverse action patterns based on feedback. A somewhat similar process happens related to pattern recognition for our sensory perceptions. A hierarchy of recognition clusters is trained to recognize repeated sensory patterns and memorizes them as a series of abstract scenarios. We are not conscious as to how our brain analyses retina patterns into abstract objects, but we can later recall these patterns through the trigger of the emotional context. Scenarios without emotional context we forget as irrelevant. Sensory input triggers another stored scenario and not in a predefined sequence. If an automated skill or stored pattern doesn’t succeed, we chemically switch to left-sided contemplation and trigger similar patterns that might be helpful.

What happens when we think about it …

The left hemisphere’s abstract world doesn’t do long-term planning in flows. We contemplate retroactively from desirable emotional states (goals). We contemplate possibilities and potentials in abstract concepts as a balance of feelings and orient (decide on) our actions weighing current desires versus long-term goals. Decisions are then made as to how we FEEL about both. Which is why good decision-making can’t be trained. It needs emotional experience. A person that inspires us will do much more than some how-to textbook. Neither can Big-Data, Predictive Analytics and process mining extract experience patterns for better planning. Microsoft’s market research produces the clumsy ‘Zune’, while Steve Jobs intuitively creates the iPod, iPhone and iPad. What happened does not tell us what grand plans will work in an ever-changing, adaptive world. Human knowledge is about which real-time process patterns are intuitively connected to which human actions. Our knowledge is segmented into independent pattern-action links and those can for example trained with the User-Trained Agent. We can however just assume what patterns the performer actually uses.

The skill of people motivation is based on understanding human emotions! Humans want to feel good and do things that they hope will take them there. We look for the feeling of success (dopamine) and not for lower cost. Our efficiency drive comes from being lazy and not from being rational about it. Our abstract thinking allows us to pull the potential of a positive feeling from the future into now and motivate us to do things that otherwise might be a strain, even unpleasant or against short-term desires. I.e.: I could eat the cookie now and end up fat (feels bad). I could exercise and look good to find a better partner (feels good). I need to hit my targets to get recognition (not money). Not surprisingly do negative thoughts lead to unpleasant emotions. Now code all that into flowcharts …

A human view of BPM-control versus ACM-guidance.

Well, I propose that BPM flowcharts are a left-brained serial illusion of how things ideally should be. It is a predictive, controlling approach to our world as represented by our left hemisphere models alone. Flowcharts replace our abstract model contemplation with a lesser, dumber function than our motor automation. Simple rules replace the complex pattern matching hierarchies that recognize our world. Rather than targeting goals we just follow procedures that ignore the complex adaptive world in which we cannot exert rational control beyond mechanical steps. Rather than opening our eyes we close them and follow procedure.

What sense does it make to create software that ignores the human perspective? Could we function as a human with just a right or a left hemisphere? Could we function if the two hemispheres were not connected at all? Clearly not, while people tend to favor one or the other, everyone must use BOTH. The same is true for ACM and BPM, because with just BPM we lose our connection to reality and just a Basic ACM will be a nice to have but it won’t transform your company. Just BPM will not provide a productive, humane work environment and stifles innovation. Just ACM will help to organize ad-hoc and knowledge work, but how would you know what your goals are? While we do not need BPMS flowcharting except for basic manufacturing, we need left-brained modeling in the sense of a Business Architecture to make ACM work. ACM creates a real-world perspective and transparency on what is actually happening related to our goals. This is why I see an ACMS as the software engine of an embedded, goal-oriented BPM methodology – hence Strategic ACM. Wikipedia defines BPM (recently updated) as “executing a series or network of value-added activities, performed by their relevant roles or collaborators, to purposefully achieve a common business goal.” Well, it seems that ANY way to organize a business is now simply renamed to BPM. Another way to end the discussion.

Conclusion: In our brain the connector between abstract-left and real-world-right hemispheres is our conscious, emotional self. The connector between ACM and BPM is the HUMAN!

References and further thoughts:

Rather than pointing you to scientific papers to understand my proposals better, I would suggest that you take the time to view these TED talks:

On the brain’s reality versus illusion from Jill Bolte, a brain researchers who suffered herself a stroke in her left brain hemisphere.

Iain McGilchrist explains how the brain is divided.

And the always factually cool but simply amazing Antonio Damasio on consciousness.

Jeff Hawkins argues that prediction is the key function of intelligence in his popular TED talk. He does however not discuss the well-known difference between abstract reasoning and motor functions.

PS: Do not flame me for minor errors or simplifications in regards to neurology. The post was already long enough …

Adaptive Case Management: Basic, Full, or Strategic?

I am all for a commonly agreed definition of ACM as long as it does not limit the necessary benefits for business. I propose that ACM has been pretty well-defined already, but because so many vendors – either BPM or otherwise – have differing functionalities, no written consensus has been reached. Quite understandable when the goal is to define a market fragment or product category that everyone wants to lead or that BPMS do ACM anyway. My intention was always different. I want to expand on today’s very limiting implementations of BPM and bring it out of the doldrums of existing BPMS relying on flowcharting. Yes, there is most probably a market for a basic ACM functionality, but that will move to the Cloud with the likes of Trello and AtTask.

Why is BPM my target for improvement?

I have been recently criticized for quoting Peter Drucker as an argument for ACM versus BPM. It is obvious that BPMS do not support knowledge work and don’t empower the user. I also quote W. Edwards Deming who proposed that it is essential to make the business system transparent to understand how it performs against the value goals. BPMS do not do that either, but only focus on reducing cost by standardizing procedure. Efficiency is however not about economies of scale. Toyota’s Taiichi Ohno proposed that efficiency will be achieved by ensuring uninterrupted flow (the Just-In-Time concept). Meaning that the system has to be ready when the flow comes in and therefore you actually need the idle resources that BPM or LEAN want to cut as waste. The fallacy of BPM is that standardization of work will reduce the cost and while that may be true in manufacturing it is not so for service work. UK management thinker John Seddon says that when you reduce the ability of a system to handle variety then you reduce the value delivery and increase the failure demand and both drive up cost. Hence, when you focus on cost reduction you drive it up, but only when you focus on delivering value then the cost will be lowered! ACM is the embodiment of such value-focused BPM methodology through business-friendly and low-bureaucracy technology empowerment.

A Functional Spectrum for ACM (and BPM)

I propose that ACM represents a spectrum of functionality that can be seen from different perspectives. In the following I created a first try of a matrix that maps ACM levels and styles. Look at it as a structured listing and not a hierarchy of dependencies. I use a business perspective to describe functionality and not technical implementation language. The functions are not aligned or co-dependent in row or column. I have used the term ‘Evolutionary’ to describe a complex-adaptive-system style of process management. For BPMS today most of the functionality listed in Dynamic, Adaptive and Evolutionary styles has to be handled by slow and expensive governance or by integration work with other software systems such as for rules and content. Don’t take the assignment of functions to styles as too literal. I was not easy to assign them and it is a matter of how the function has been implemented. From the feature matrix one can construct any kind of BPM, ACM or Collaboration system. Pick and chose to define the system you need or want to buy:

ACM Levels and Styles by Function

An ACM Manifesto?

Keith Swenson proposes the creation of an ACM Manifesto, which is one possible way to deal with the lack of agreement. I would very much like to create such a manifesto if it fulfills the usual purpose: A declaration of principles used by revolutionaries. In the literal sense it is however no more than a passenger or goods manifest of a vessel. But as it seems my goals are too high for my co-revolutionaries. They want to find consensus on a list of functions that would unambiguously make a product ACM and to this end rather reduce the functionality spectrum to exclude BPMS features. Additional capabilities are then to be seen as nice-to-have because lacking them would not reduce the ‘adaptiveness’ of the solution. The DCM Wave of Forrester Research just lists BPM vendors with case management functionality.

Keith Swenson proposed that simple definitions of teams, folders, goals, records, security, and communication will provide the ability to replace email as collaboration platform: ‘I would like to see ACM be a clear definition of the ability for a case manager to take on and complete goals, collaboratively, with history, and reuse of previous case patterns. Deployed not as a solution development platform for the IT department, but instead as an infrastructure that replaces email. An ACMS has to handle content. An ACM has to keep history, but process mining is an extra nice to have feature.’

He proposes that ACMS and BPMS require different skill sets and different people, which is correct if BPM is seen as a flowcharting design paradigm. BPM is for me the same ACM work activities guided by very strict rules and dependencies, which could thus be shown as flowcharts. Knowledge work is in difference to BPM guided by customer outcomes, goals, constraints, events and most of all user skills. ACM is the higher level capability and offers expanded process controls, more empowerment for the user and an embedded improvement paradigm. Keith suggests to call the combined ACMS/BPMS functionality APS or Adaptive Process, which I proposed as an option two years ago. At the time I wanted to make clear that an Adaptive paradigm offers much more opportunity than just runtime modifications by users.

Karl Walter Keirstead in difference proposes that ACM should possess BPM capabilities. He lists as a minimum feature set a repository (archive), a GUI to allow users to create work tasks (structured and ad-hoc) with resource and people allocation, background constraints and compliance checking, management dashboards and back-end data connectivity.

Do we focus on sales or on business needs?

I agree with both Keith and Karl Walter that all of their ACM features are necessary, I just take a much longer and more customer outcome oriented perspective. I interpret Keith’s stance as a ‘let’s-not-rock-the-boat’ attitude that is understandable from a typical marketing perspective while it could limit innovation! It is as if Steve Jobs would have said: Let’s NOT design a product that interferes with current markets for mobile phones, MP3 players, navigation systems, and handheld computers. Let’s carve out a niche that doesn’t overlap so we don’t have to compete!’ I have also been criticized for quoting Steve but like me, he focused on making things that already existed really easy to use. He simply removed the apparent complexity for the everyday user, but not by dumbing down what the user can do. Exactly the opposite. He put not less but MORE functions into the same device! I too want to put more functions for all business hierarchies into ACM and not less!

So how can ACM be further defined?

While I am working on a larger paper on the subject and also on a book, I have decided to post some of my thoughts to further the discussion and to invite feedback. This is not the final version and while I would have wanted to wait, it makes sense to collaborate on this as Keith requests. I propose however that we need to define the fullest functionality and then each vendor can define, which subset of features he wants to cover. I suspect that most vendors might not like this approach if they can’t have all the checkmarks. I nevertheless defined another perspective that segments functions into Model, Discover and Adapt requirements. I group features into three ACMS types: basic, full and strategic. Remember, this is a thought exercise only.

ACM Business Activities for Model, Discover and Adapt

The Model segment is functionality that is required to create the essential models that allow the business to define how it wants to describe its work. A Basic ACM system will have most of those pre-coded. If not, the models are created by architects. The Discover segment deals with functionality that business uses to create the actual processes. The Adapt segment is used by management to guide the knowledge workers. Some functions are overlapping and I put them where I see the most benefit. This is a very subjective definition of what I know about the market. I would make Change Management mandatory but not all products possess this and it is an IT management function. Remember, this is a first idea how to structure this.

What would be the business benefit of a lesser definition? If a business wants just a Basic ACM functionality then they know where to turn even if they know that there is more. If a business decides for a Strategic ACM solution then that does not mean they have to reorganize or change the company culture as has been suggested. Not all departments have to use all functionality. I have said many times that I don’t see that the software should restrict or force the business in any way. Exactly the opposite! The ACM platform must allow each business and department to work as they see fit to achieve customer outcomes and avoid the failure demand and increased costs that process standardization would cause.