The BPM adjective war proliferates once more. I already commented on it in 2009 in ‘Agile-, AdHoc-, Dynamic-, Social-, or Adaptive BPM’ Since then more and more adjectives are being added to describe variants of process functionality in simplistic terms. Too often they do not have any sensible meaning such as ‘Smart’. Jim Sinur coined one of the more sensible definitions for adaptive processes with ‘Design by Doing’.
Forrester Research has recently added another populist term like ‘Apps’ and published a report on ‘Smart Process Apps’, which looks like an exercise for BPM vendors to sell to businesses who are now demanding less effort for process analysis and governance. Forrester guesses that smart process apps will be ‘an emerging $34 billion software category designed to support people-intensive, highly variable, and loosely structured business processes. Smart process apps will package enterprise social platforms, mobility, and dynamic case management (DCM) to serve goals of innovation, collaboration, and workforce productivity and to connect to core business processes.’
So let’s call a spade a spade: ‘With SPA we package a whole bunch of old software and sell it to you as innovation.’ IBM did the same for years by renaming all products under the WebSphere brand. The odd part is that our competitors and vendors do not admit that ISIS was first to offer consolidated process and inbound/outbound content applications in 2001. They go as far to claim that ISIS must have old software because we have been doing it for so long. I would call that mature and having the most experience! When we announced it at the time analysts could not see it in the market place as it was REALLY NEW. Now that everyone has copied it, it is innovation? Strange, but more on analysts in another post …
In the SPA report, vendors and Forrester are describing a subset of what we have been offering as truly consolidated ACM functionality since 2009. Especially the integration with ECM functionality, particularly document capture and outbound content generation, has been always a key differentiator to BPM in my definitions of ACM. Many SPA offerings do not even cover content beyond MS-Office.
SPAs just offers the reusable process of ACM which in difference is user created and not pre-hard-coded. It would be frightening if SPA would be a new $34b category that ties businesses into legacy products. Now that ACM, adaptive, goal-orientation and content integration are becoming accepted – suddenly everyone innovates by applying the tag to everything. Businesses do not need a short-sighted shortcut that immediately becomes a legacy problem. There is the principle benefit that some vertical business knowledge is embedded in the SPA. Like with SAP you can now change your business to work like the software … (hey, its an anagram!).
Would I look at SPA differently had Forrester Research invited us to take part (damn, we don’t pay them anymore)? I don’t think so. We were included in DCM studies and I still said what I thought was wrong with its half-hearted definition. I would have still said that the SPA approach is nowhere near enough.
Why do businesses need ACM for processes and not Smart Apps?
The reason that I agreed to the term ‘Adaptive Case Management’ with the WfMC was the necessity of providing content functionality to the process performer. Case management was originally about providing a central folder service for all content of a case — plus work does not follow a flow. Adaptive is further not just a synonym for dynamic, flexible, intelligent, ad-hoc or smart. In biology, adaptation refers to both the current state of being adapted and to the dynamic evolutionary process that leads to the adaptation. Yes, SPA functionality is PRE-CODED and they do not support the evolutionary permanent change.
The first question is how can adaptive process functionality be described and second, how would a business know how to apply those functions? Or what language do we use and what do we describe with it? What you want to describe actually defines the language to use. These elements must be managed seamlessly and homogeneously in the process/content platform. Disconnected products like in SPA will make this a management nightmare.
Look at this chart from a recent Gartner Group paper. It actually does a pretty good job of analyzing and positioning the various process types in this graph. It is another form of the linear graph that I have first used as the process spectrum from transactions to social.
This graph refers to process run-time adaptation but what makes a system adaptive are the process-life cycle aspects. Process life-cycle describes what happens before and after a process is being performed. In orthodox BPM that is purely a governance bureaucracy issue. ACM facilitates all life-cycle changes particularly in the sense of performer creation, reusable processes, case fragments and goal-orientation that allow a business-driven creation of service goals.
My definition of ACM adaptive processes in 2009 already included the dynamic orchestration, rules, constraints (boundary rules), goal-orientation, business events and social. This is the spectrum of the business needs – all the way implemented in the Papyrus Platform and not in different products! Being focused on processes, the Gartner analysis passes on content functionality. In their iBPM report however, Gartner named the ability to capture inbound and drive content from within the process platform’ advanced functionality’.
How to achieve a better process outcome next time?
Ad-hoc, social, dynamic, process fragments, event-driven changes, and user decisions are all runtime modifications that do not by default translate to a better process next time. And better does not mean cheaper but achieving more if its well-defined goals and outcomes. Turning past executions into new processes and having the system learn to make recommendations on what actions improve process outcomes — THAT IS ADAPTIVE. Adaptive processes are therefore not about being chaotic, creative, un-structured or non-compliant but about using the dynamics of that to create a process that fulfills all goals, follows all compliance rules and can change at the drop of a hat — and can be reused for a better outcome NEXT TIME. That process or any parts of it might turnout to be quite rigid for one reason or the other. Performers can be restricted from modifying it. Adaptive is more about how the process is created than how much people can change it.
What are the definitions that make up an adaptive process:
- goals (business view)
- outcomes (customer view)
- skill or resources (capability view)
- work (task types, dependencies, checklists)
- data (forms and silo interface view)
- rules (for data and content, resources, work)
- content (inbound, outbound, social, email, rules)
Orthodox BPM flow diagrams, BPMN or even the CMMN case management notation describe at best 20% of that. I have said so for more than a decade. If there is one good thing about SPA it is the admission that a process is not just a flow diagram. SPA is sold as an ‘improvement’ and a ‘NEW NEED’ while it has always been the same. In orthodox BPM the other 80% were hardcoded. Because SPA is built on orthodox BPM and ECM engines the 80% are still hardcoded. But now they are packaged as a murky app that will be hard to maintain. An encoded process (in SPA) is no more than an assumption of a happy path that hardly ever makes anyone happy, but is at best the cheapest way to achieve average outcomes. The ad-hoc elements and the social component are supposed to fill the cracks.
The business user must have the facility to create and modify all the above elements of a process given the right authority. All such changes must be logged and audited. The prime goal is to make it so easy that all actions are being performed inside the ACM functionally and there is no need to step outside to email or MS-Office. Clearly, not all business users will have the skill or the time to continuously make some changes. Humans tend to do things the way they were done before. The fear that people will continuously make changes is irrational. People are lazy. If you let them they will do things with the least amount of effort (=cost). That is the reason that the process must have goal and outcome definitions. But there must be the opportunity to improve on the fly and save it for the future.
The unpredictable drivers of business process change:
- customer expectations
- people interactions
- business events
- resource dependencies
- data dependencies
- market competition
Once modifications have been made because of the list above how will the business know of these are just one-time changes or if they should continue into a more permanent change for future performances of the process? Often these decisions are not made by the performer but by a process owner or a process coach (if you must in a Center of Excellence). As you gather process knowledge from the actual process instance there is no need for complex process mining or external customer satisfaction surveys.
What functions are needed for evolutionary process adaptation:
- saving case/process instances as templates
- monitor related business targets
- skill availability
- resource monitoring
- service level agreements
- reuse of process fragments
- discovering process patterns for events
- chosing templates for best outcomes
- customer rating of outcomes
- performer ratings of templates
Can you ignore any of these and still assume that a process will deliver what the customer expects? No. Will simply providing all this information in a flashy dashboard be enough? Absolutely not. It is quite difficult to provide a user interface that will be seen as easy to use and intuitive. It is new functionality for the business so they find it difficult in any case. But if we can configure user interaction to match their understanding of what their job is, there is a huge opportunity for empowering the business. Don’t expect a single UI to be perfect for everyone. Does improvement have to be handled through a Center of Excellence? Absolutely not, but feel free to call it what you will.
Ad-hoc, social, dynamic, process fragments, event driven changes, and user decisions are all runtime modifications that do not by default translate to a better process next time. And better does not mean cheaper but achieving more of its well defined goals and outcomes. Turning past executions into new processes and having the system learn to make recommendations on what actions improve process outcomes — THAT IS ADAPTIVE. Adaptive processes are therefore not about being chaotic, creative, un-structured or non-compliant but about using the real-world dynamics of work to create a process that fulfills all goals, follows all compliance rules and can change at the drop of a hat to be better NEXT TIME.
From my experience the claim that processes have to be rigid because of compliance and regulations is simply an excuse. There are usually just a few checkpoints where the performer’s work has to be constrained, verified or the customer’s outcome be reduced. That can easily be done by rules. To work towards a process outcome does not have to and should not be one homogenous structure, but each department (capability and process owner) defines and maintains their own. Adaptive processes are created by linking to work goals of other departments without caring how they actually do what they do. If you want me to perform a work task for your process, you link a goal that I created in my library into the case. It will automatically be assigned to my team. Some like to call this Process As A Service …
Anyone who puts however processes, collaboration, content, rules, social, interfacing and more into separate software engines as in the SPA proposal and proposes to make them work together sensibly and allow an ADAPTIVE evolution of the resulting fragmented process definitions … is naive like ‘The Sorcerer’s Apprentice’ (J.W. Goethe).
PS: In case you disagree — take it easy! This is just my personal opinion differing with Forrester Research.