Business Process for Information Workers

Being responsible for BPM at Siebel, I began to come to the realization that traditional BPM does not address the process requirements for information workers. Some of the requirements such as collaboration and pervasive analytics are now well understood and being addressed. However, some other requirements, as I saw them, do not get attention. In this post, I summarize some such requirements. It is based on a presentation I made to my management – David Bernstein and Peter Lim – about 1.5 years back.

Defining the Problem

As is commonly said, Information Workers drive the business processes instead of being driven by the processes. What that means, for example, is that no company, in its right mind, will force a stringent step-by-step selling process on its sales people. More technically speaking, the Information Worker business processes are too non-linear to be orchestrated.

This is commonly interpreted to mean that BPM for information workers, means collaboration, especially of the ad-hoc kind, and pockets of BPM automation. For example, in the Sales process, the Quote generation process, which is a small piece of the overall process, may be implemented as a BPM process.

However, I think there is an opportunity to do better. Let’s start by defining the objectives of BPM for Information Workers (excluding those that are addressed by today’s solutions):

1. Guide users to the most valuable activities, that is activities that maximize objectives, leveraging organizational best practices and learned insights.
2. Enforce policies and constraints.
3. Enable loosely coupled interactions between stake holders (sort of implicit collaboration). For example, if the Sales Rep schedules a meeting with the customer executive, the Sales Engineer is automatically steered towards closing out all outstanding questions from the executive’s reports.

The Process from User Perspective

To explain my proposed solution, let me start by painting the picture from a end user perspective. Following is a mock up of an Opportunity application (to be accurate the side bar is a mock up overlaid on screen shot of the Nexus application):

In the above picture, pay attention to the Activities in the sidebar. The Sales Rep’s view of the process is essentially a list of activities along with their recommended values (the bar with green boxes). This list and the recommendations are not static. Some activities that have prerequisites are not shown until the prerequisites are satisfied. For example, Create Quote activity may become available only after Perform Discovery activity is complete. Also, the recommendations change as various events happen. For example, if the Customer Browsed the web site for a demo, the Schedule Demo activity may become a highly recommended activity.

In summary, as a Sales Rep, I am not constrained by the process; however, I am not flying blind either.

The Process from Implementation Perspective

From an implementation perspective, the business process, like most other business processes, is a collection of Tasks. However, these Tasks are not sequenced; instead, each Task is associated with rules which specify when it becomes available, when and whether it is required, and when it becomes unavailable.

Also, associated with each Task are rules to determine its value at any point of time.

From a BPM technology perspective, it requires:

• A good event framework to tie every thing together. Events trigger activation, deactivation, and other state changes of the Tasks.
• Business Rules to capture the constraints and policies associated with the Task state changes
• A recommendation engine; preferably, one based on Bayesian models (for example, Sigma Dynamics that Siebel OEMed and Oracle acquired)

Summary

While pockets of automation, collaboration, and analytics provide value to Information Worker business processes, there is a potential for BPM to do more. BPM can become the Information Worker’s friend, guiding them without constraining them. In this quest, Events, Rules, and Bayesian model based predictive engines, may be more important technologies than traditional process orchestration.