Goal Orientation in ACM

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
Advertisements

About Max J. Pucher

I am the founder and Chief Technology Officer of ISIS Papyrus Software, a medium size software company specializing in communications and process management. I wrote several books and hold a number of patents. My quest is to bring common sense to IT, mostly by focusing in human quality issues rather than cost saving, outsourcing and automation. I am also Chief Architect at VIPorbit software which provides mobile relationship management.
This entry was posted in ACM and tagged , , , . Bookmark the permalink.