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.
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