Collaborating in structured business processes - Part II

In the last post Collaborating in structured business processes - Part I I talked about the need for the true collaboration capabilities offered by collaborative software at certain points within a structured business process. The challenge is that collaboration software typically does not extend itself to external processes, people or systems.

I used the new account opening use case as an example of the need for collaboration within structured business processes, especially at the point where complex exception handling is required within the process.

Bruce Silver has pointed me towards some of the vendors that provide this type of capability, in his comments on my first post. This post follows on from the first to describe how I envision that a standard BPMS could be extended to enable collaborative features if they are not already part of the architecture.

I would love to know what other use cases could benefit from this type of capability, and even better any examples of where it has been deployed in reality.

Collaboration as a service

Rather than treating collaboration as a pure user application we need to treat it as a service. This provides us an approach for BPM to orchestrate a complete process including touchpoints that interact with a collaborative environment. At specific steps in the process, BPM can call out to the collaboration service, allowing the ad-hoc work to be completed before carrying on with its structured duties.



Imagine that BPM requests the operation "collaborate around customer money-laundering risk" from the service. Under the covers the collaboration service might do the following:

• Create a new collaborative workspace from a predefined template, to contain all of the research documentation and discussions
• Assign values to a set of attributes directly from the BPM new account application, describing the basis of the exception to be handled to the collaborative users
• Create links to any documents referenced by the account application within a "background" folder in the workspace, enabling users easy access to them
• Provide links to customer information held in CRM or accounting systems
  
• Email a predefined group of users that a new exception requires processing in the collaborative environment

At this point BPM has successfully passed control of the process to the collaboration service. It can now sit back and wait. The collaboration application can now go back to being a user driven application, what it does best.

If well thought out, the collaborative users processing the exception may never need to touch the BPM system to perform (or be informed of) their tasks, centering their attention on their primary collaboration application and research tools.

Handing back control

Completion of the exception handling process happens when the collaborative users decide that they have completed their investigations, making a go/no-go decision. Several things should happen at this point: working documents should be stored to a records repository; the workspace should be locked down; BPM should be informed that it can resume the case, being handed a minimal amount of information to enable it to route the it appropriately, based on the collaborative users' decision. Of course, a reference would be available to easily get back at the collaborative workspace and all of the information it contains, if required by a user at a later stage.

Handling of timeouts, where collaborative processes exceed those configured for the business process need to be handled, through further interaction with the users through standard collaborative means like entries in group discussions, or by escalation to a manager.

Records

Storing records of the collaborative workspace is essential in many regulated or potentially litigious environments, and selecting an appropriate collaborative tool that supports integration with a records management system is key. It is also important that the collaborative tool has the flexibility to enable continuous access to these records through the collaborative UI in a completely unchangeable manner. This is essential so that audits can reveal the underlying work in context, and litigation is supported.

SOA

Although I use the word 'service' to illustrate a set of defined interactions of a BPMS with a collaborative tool, this type of integration does not require a full SOA for it to be useful. Of course, if the organization has deployed SOA, demonstrating the value of collaboration as a reusable service across the enterprise could be accelerated by deploying defined use cases for BPMS processes and collaboration.

Outcome

In this example the BPMS has successfully orchestrated the process across its own human interactions while managing data interchange with partners and business systems. By treating the collaborative application as a service that can be called from a workflow at predefined steps, BPMS can handle collaborative requirements as seamlessly as any other interaction with an external system. Now tasks like complex exception handling can be performed as well, in an environment that is most effective for the users, without them ever needing to become familiar with the BPMS controlling the process.

Technorati tags: Financial Services Technology New Account Opening BPMS collaboration SOA