The Infosys Labs research blog tracks trends in technology with a focus on applied research in Information and Communication Technology (ICT)

« July 2011 | Main | November 2011 »

August 10, 2011

How important and critical is to capture Events in business process modeling?

Let us take a simple process: Process Name: Issue Visitor Pass for Entry into the Organization Campus; Goal of the process: To check the authenticity and issue the pass for the visitor (from the Security Officer Perspective). Event that triggers this process: "Arrival of Visitor to the Campus"; Function or Tasks followed are: Gather details about the visitor, purpose of visit and contact details in a specified form, Check whether the contact person is an existing employee in the company in the system, connect with the Employee to cross check about the visitor information and get an oral permission, update the visitor information (name, reason for visit etc) into the system, issue an bar code based card with the validity of the card mentioned. Result: Visitor Entry Completed and Visitor allowed entering campus (successful result). From a high level perspective, the arrival of the visitor is an occurrence (and it is also information sensed if one can argue) that someone enters and says I need to visit the campus. But the real information is gathered after this occurrence that someone wants to enter the campus; so the trigger is the occurrence or the state wherein someone needs access to the campus (from the Security Officer Perspective). The business resources used here during the process are a paper based Visitor Form filled by the Visitor, the application which has the employee details (which the security officer checks), telephone (to call the employee), a bar code based security card and a magnetic card reader to pass on the information of the card holder to the card with access permissions to restricted/non restricted areas within the campus. There may be other checks related to restriction of gadgets/materials that are allowed inside the campus for which the Security Officer will cross check with the visitor and ensures to his better knowledge that the visitor is a safe bet to enter into the premises of the company. So many business resources are used in this simple process. Now we are clear on the "trigger", "process" and "result". This is a simple trigger/event and a simple result - the process is a stand alone process - we need not worry what happens once the result or state change of "Visitor Allowed To Enter Campus". But we can be of sure of one thing that the trigger event "Arrival of Visitor" and the result "Visitor Allowed To Enter Campus" are not "action items" per se. These are state changes that either triggers something to happen - a process or a service or other logical information instantiation.

But a complex event or result might trigger multiple processes and leads to state changes that further triggers downstream processes. Another example can be a process wherein the customer wants to purchase a book online. The event is an external event for the system wherein "customer has a need to purchase a book" - then the process wherein the customer fills information online and places the order - state change - "Order for book placed". This result triggers subsequent processes in which different Role acts upon - 1) Verify Inventory for the availability of book 2) Initiate Invoice Process 3) Initiate Shipping Process 4) Initiate inventory of the book if the book total falls below a certain limit. These tasks can happen parallel and can be performed by various roles/departments. Order Manager identifies the book and pass it to the shipping department which then couriers the book; meanwhile the accounting team initiates the invoice process. "Order for book placed" triggers all these downstream process and the same result is to be used in all these processes to appreciate process integration through event/result combination. This way one enable horizontal process integration as per the initial discussion started here.

In more complex event situations, the "annual budget cycle" - which is a trigger event, initiates multiple processes - business planning, resource planning, market plans, target definition, product development and technology planning. Here comes the problem, here these are all high level business processes and further broken down to various levels. It becomes a huge task to first identify the relevant events and the associated processes and make sure integration of processes exist both vertically and horizontally. This will be like boiling the ocean when one tries to cascade and capture everywhere the same event and result when there are multiple levels of abstractions of business processes (for which one can use the tree, branch, and leaves analogy in the discussion - top down or functional decomposition).

From practical business process modeling perspective, it is real difficult to elicit the right trigger event information - it is usually a generic understanding of what triggers what. One cannot make a great sense out of the events/results expect in cases where one can try to horizontally integrate - this is also left to modeler's interpretation in most cases. But if the purpose is for system development, then make sure the right event/result or pre-condition/post-condition is elicited and documented completely.

To summarize, process architecture definition is crucial, while event architecture definition is an add-on or nice to have!