Adaptive Process and Goal Orientation

While all this discussion is going on whether ACM is BPM, and BPM is part of SOA or whether it is rather just a management practice, I contemplated a bit more of what we are trying to achieve with the adaptive process/case paradigm. Before I start let me present the following graph to illustrate how I see ECM, CRM, BPM and ACM (Adaptive Case Management) in relationship. Adaptive Process is provided by a system that can support all these processes and applications, like our ISIS Papyrus Platform.



The only reason to execute processes is to achieve certain outcomes and GOAL ORIENTATION is therefore essential.
Linking those outcomes to rigid execution from the beginning is a key problem of current BPM implementations, because these processes are not simple, repeatable manufacturing steps. Measuring KPIs  rather than outcomes is the next fallacy. KPIs are typically disconnected from the process and when they wander off, there is no causal link to their improvement. If process outcomes are goals defined by means of business rules as part of the process, then we have the causal link  to innovating processes. Any number of goals can be linked to become a structure of pre- and co-requisite, dependent outcomes, milestones and achievements that in total represent an end-to-end business process. Goals should be real-world, simple-to-observe-and-report achievements. It is important to observe as close to the outcome as possible to avoid distortion. For example, rather ask a customer directly if he is satisfied than trying to extrapolate that from some statistical customer information.

Modeling processes without a business architecture – a capability map, process owners, team roles and the related data entity models – lacks the power to create causal business goals/outcomes. While it can be interesting to model the departmental hierarchy as is, it is more important to define the process owners and their teams that will span departmental boundaries. Within the process teams, role/policy authority controls access and execution rights, as well as delegation and substitution must be provided. The process owners must observe and interpret and act upon goal deviations immediately. Goals can be set for process optimization to ensure that SLA Service Level Agreements are met or that the cheapest form of execution of a process is recommended by default to the business user.

We need to map the tasks and todos into the above organizational structure to make them easily understood. The five core elements of data, content, goals, rules and interaction form the process templates. Outcomes are linked (by means of state/event/rule definitions) user to-dos, process activities, BPMN fragments or planned sequences that can be expressed as either task lists or BPMN flowcharts. There is no rigid execution of predefined flows, but agents or business users or both will drive the process execution forward as per the goal definitions. External events can be received by a variety of means to change process element states  A process is completed when the goal rules are fulfilled for whatever reason and not when all activities have been executed. Execution is therefore totally dynamic.

Usually wall-filling process maps are needed to create an overview of elaborate end-to-end processes.  One of the best ways to express a dynamically changing process map is by means of a Gantt chart as used in project management.

In today’s businesses, users expect nothing but the best from an application in terms of user interface presentation. It truly is the make or break issue. That does not mean a lot of unnecessary bells and whistles that consume CPU and graphic power, but intuitive, easy-to-use and more than else personalized user interfaces. Ease of use can also be achieved by dumbing down the user interaction to simple page-by-page HTML forms, but that leaves the business user lacking in terms of the most effective presentation of the process data and content. The full power of a graphic GUI must be available to the business user without the need for complex programming, while deploying the same GUI to Windows, Mac or Linux desktops and obviously also to the portal and browser. We clearly must not forget the mobile world and be able to access cases and processes from a mobile device.

I hope this sums up the needs of ADAPTIVE AND GOALS:

  • ‘Agile’ process flowcharting is no longer the state of the art
  • Processes are defined through their outcomes and not through rigid execution
  • Manage all process elements: data, goals, rules, content, GUI
  • ‘Design by Doing’ with iterative goal-based modeling
  • Create and reuse manageable milestone/activity lists rather than flowcharts
  • Fast deployment and adaptation to needs during enactment with a model preserving strategy
  • Eliminate exceptions with adaptive process execution
  • Adapt and improve processes in real-time by the business user
  • Uses events to react to external events and messages (SOA)
  • Agent technology chooses the optimal execution path based on goal fulfilment

How the Papyrus Platform provides all of the above, you will find on my Papyrus Architecture blog.

6 Comments on “Adaptive Process and Goal Orientation

  1. Pingback: With an EYE on Goals « Papyrus Platform Architecture

  2. Pingback: Links for May 8 « Thoughts on Collaborative Planning

  3. Pingback: Column 2 : links for 2010-05-25

    • Sandra, thanks for referencing my posts and finding them usefull despite mentioning my products. As I pointed out on your website, I made full disclosure about my role and no one is suprised that I put my money where my mouth is and developed a solution according to my convictions and vision, despite being far off mainstream in 1997. Allow me a little gloating, please. It’s just a tiny pleasure for me. On the other hand, I want to point out that you are allowed to sell your expertise as a consultant and analyst by showing off your knowledge posting, so why should I not show off my skills and have the reward through my products? Are you not in this business to make a living? Thanks again and keep up the good work!

      Like

  4. Hm, why is ECM more predictable than CRM and BPM? Most of our customer don´t use our workflow because they are better able to work adhoc on the dossier view (Berman: Aktensicht), creating new documents and changing status fields if necessary.

    Like

  5. Martin, I would agree with you. I was referring to how the systems are most commonly used. Most ECM solutions use a very well defined inbound (scanning/capture) workflows. For case- or collaboration enabled ECM solutions, compared to an older CRM it might be turned around. Good observation. Might require some market study to actually ascertain what the average status is today. I will make some enquiries with our customers and if necessary update it. Thanks.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: