Adapter Initial
2010
Agile-, Adhoc-, Dynamic-, Social-, Or Adaptive Bpm
I am pleased to inform you that we have just published ‘Mastering the Unpredictable’ with the substantial support of Keith Swenson, and it is not too soon. The subject of adaptive processes is heating up as you might have read. In the book I discussed the differences between BPM types. Forrester groups products into Integration-, Document-, or Human Centric, which is not very helpful to figure out what you actually need. Vendors position their solutions as such: agile, dynamic (aka flexible), and ad-hoc (often also called human). I started to use the term “adaptive” for process requirements a few years ago. It has been used before but as a substitute for agile. A recent arrival is Social BPM. What does it all mean?
Agile Process — arrived with more powerful design tools and BPMS functionality that gave a business analyst a faster way to design flowcharts. The agile BPM concept requires the complete analysis, modeling, implementation, simulation, monitoring, and optimization lifecycle. Therefore it is laden with bureaucracy, overhead and long implementation lead times. Processes are mostly laid out in intricate detail, encoded with business rule engines, linked to complex SOA backend orchestration, more complex data and user interface mappings, and in most cases sees content as an afterthought — except for document-centric capture solutions.
Dynamic Process — has been around for a few years now in various incarnations. It is a variant of agile process and enables the business user to make changes to the process execution on the fly, by for example selecting a different sub-process, but requiring predefined exit points. User changes do not change the defined process template, and a change is seen as either an exception or an unforeseen variant. That hits the limitations of most BPM systems, because users do not have access to the metadata definitions of process and business variables and therefore these dynamic user changes fall through the monitoring grid.
However, most users who taste Dynamic BPM blood report that they love the flexibility as a new kind of freedom. Such processes can proliferate and if the system isn’t really capable of handling it, a lack of transparency can be the consequence. That is not the problem of the dynamic process but the limitation of the BPM system. I question the need for process standardization as a reaction to the limitations of orthodox BPM systems. If dynamic processes are the cause of distress in your BPM bureaucracy or system they most probably ought to be executed as adaptive processes and not be forced back into rigidity.
Ad-Hoc Process — those are typically simple processes with a couple of steps relating to content state. The most commonly used ad-hoc process environment today is Microsoft SharePoint. There are however substantial problems to be considered. User-created SharePoint processes and content are a Wild-Bunch mix of Word/Excel/Access pieces interspersed with macros. That makes them neither easily manageable nor reasonably upward compatible to the next releases of MS-Office and SharePoint. But too many business managers are looking for quick-fixes rather than sustainability. When I talked to IT managers in terms of process management with SharePoint the general response was negative, despite users being reasonably happy with the ease-of-use.
I propose that these ad-hoc processes also ought to be managed through adaptive processes, which provides them with the business metadata definitions, the standardized backend interfaces, business rules, and easy-to-use content and user interface creation and adaptation.
Social BPM — For me, process management is about people communication, therefore I always saw the link to ECM and CRM and most obviously to social networking, despite the realization that it can’t be enforced. Social networkers are collaborative t-shirts with backpacks who love what they do because it is their own free choice. BPM proponents believe in upfront design and people control. And in that gap — so some believe — may lie salvation through Social BPM, but in which lifecycle phase could social be of benefit? Design, modeling, implementation, simulation, optimization, deployment, execution, monitoring, or tuning? No clear definition …
Open collaborative effort on the creation of process flowcharts covers at most 20% of the complete process functionality to be designed. Once the flowchart is encoded with the other BPM elements it stops to be social, agile and will never be adaptive. That is not the same as empowerment, which provides authorization and access to resources. A business hierarchy is most effective when the process teams can each focus on their own things. There is little need for an open social collaborative community to DESIGN processes. Surely, two process owners need to discuss their handovers. If the process tools are web-enabled they are automatically ‘social’. Social communication is not enough, because the business needs a central repository to manage and deploy all the process and business metadata.
Adaptive Process — sidelines Business Process Design and Management as a strategic initiative. Process design must rather map the business strategy into a business architecture with capability maps, use cases and process teams. It is however quite impossible to sensibly derive detailed business processes from a strategy without bottom-up participation. Social BPM could help but the result would still be rigid. The process owning team alone must create and maintain the (secondary) service processes, while the management defines the goals in a capability map that links the service processes and the support processes together. That has to be communicated in an easy-to-use business architecture for the process teams directly in a metadata repository. The infrastructure provides the necessary transparency for management to define goals and outcomes and to monitor their achievement, while business users still retain their ad-hoc freedom. These processes can be enhanced to stricter definition and more complexity any time.
So what does adaptive mean? It refers to internal changes caused by outside conditions that become permanent and make the entity more fitting to those new conditions. Those changes are performed by means of the entity itself and not by some external force. So if you need consultants to design or change your processes it may be agile but not adaptive. With Adaptive Process, endusers do not just collaborate in flowchart design, but they actually create the real-world process on the fly. Not just a simple ad-hoc activity, but with substantial complexity using metadata models from the repository and business rules in natural language for well defined goals. Being adaptive is not about predicting how a process WILL work or to agree on all possible mutations. Adaptive means that real-time knowledge from the last process execution can influence the execution of the next.
Misconceptions — Adaptive process is empowerment, but that does not mean decision-making authority for anyone about everything. Authorized users can however add business rules to a process during runtime. Centrally managed business rules can make an adaptive process as flexible or rigid as needed without ever touching a flowchart. Process adherence in BPM too often forces users to do the wrong thing right. A process adherence culture is thus not a valuable business trait. It requires complex process exception handling to be analyzed, implemented and executed. Give up the rigid process and gone are the exceptions. There is no need to evaluate to see if processes are dynamic, because that is the norm anyway. Rigid processes are the odd and rare ones.
Strict role/policy security must control who is allowed to make what changes to a process. Everything that actors want for a customer is a good thing for the business. Actors do not always know the consequences of that and that’s where transparency comes into play. Adaptive Process is not just a more flexible kind of BPM, where users can make more choices during execution! That is Dynamic or Ad-Hoc BPM. Adaptive Process is about DOING AWAY with the flowcharting process and allow business users to interact with all above process artifacts in real-time and create those processes WITH ANY CONTROL, SEQUENCE AND STRUCTURE NEEDED interactively — without needing further implementation work. I don’t see much of a danger. The difference is that it happens in real-time, by the real people, and for or with the real customers. Therefore there is no need for simulation, as you just adapt over time the process controls to the minimum amount necessary.
For many organizations this power is new and strange, but users love the freedom when they get it. The management loves the transparency and immediate control over processes. Changes can happen more or less immediately. The ones that are the most cautious about using adaptive processes are BPM analysts, IT architects, and IT production managers. This might change once they see it is a fantastic chance to put a well defined process and business architecture in place.
So the risk of Adaptive Process is not in the implementation or in business users resisting process adherence. The question is whether management or IT are willing to hand that much power to the business users, because Adaptive Process enables them to also create protected processes in agile, ad-hoc, dynamic and social BPM style.
About the Author
Max J. Pucher is the founder and current Chief Architect of ISIS Papyrus Software, a globally operating company that specializes in Artificial Intelligence for business process and communication. He has written several books, frequently speaks and writes on IT and holds several patents.
Magic Flight Launch Box Power Adapter Initial Impressions
