What processes have to change when the oil price increases by 20%? How do we react to an upcoming hurricane in Louisiana? What impact does the strike of one of our main suppliers have on our process landscape? While process modelling is increasingly popular, most organisations design their business processes in complete isolation of such changes in their environment. Providing a link from process models to such contextual changes with the ultimate aim to reduce the time to adaptation is the objective of context-aware process modelling.
A large insurance company and active ARIS user receives approx. 9,000 phone calls as part of its so-called teleclaims process every week. The process is well documented with a precise understanding of the call centre customer interaction protocol related to the lodgement of a claim via phone. However, if a storm hits town the call volume will quickly go up from 9,000 to approx. 20,000 phone calls per week. In such a scenario, a rapid lodgement including fewer questions to the customer is used to accelerate the process. Furthermore, additional casual call center agents are hired.
This simple example shows how a change in the environment of a process, here a change of the weather, demands a change of a process. We call these context-dependent processes. The appropriate execution of context-dependent processes relies on external variables such as weather, time, location, competitive environment, national interest rates, resource prices, etc.
The typical modelling of processes does not consider such relevant context variables. Instead we model a process in isolation from its environment and if at all might specify relevant context factors as textual model attributes. Other solutions will include the explicit inclusion of context in the control flow of a process in the form of an XOR-split (“Check if it rains”). Such an inclusion is very disturbing as it extends the size of the model, makes it more complex, increases as a consequence the likelihood of a modelling mistake and leads to reduced model acceptance by the end users.
A more elegant solution would be to make process models context-aware. This requires similar to knowledge- or risk-aware process models a dedicated approach to context modelling. The relevant context variables and their relationships with each other (e.g. storm leads to damage leads to claims) have to be captured in such context models. The process models themselves would be contextualised, i.e. each elements of the model has to be related to relevant context. An end user would then either select a specfic context ("How do we work on sunny Sundays in Italy?") or the context would be selected automatically as the tool could easily know where the user is, what day of the week it is and if it rains.
We are still a bit away from such context-aware models but the number of enquiries for such advanced modelling capabilities increases quickly. Context-aware models would have further countless benefits such as support for variant management, scenario analysis, configurable reference models or business continuity planning.
Yes, classical approach might be applied but in a higher level for reducing space of context elements, so it might reduce storing constraints. Once you have key elements for different business scenarios, let say, patterns or reference models for context-rules as flexible as possible, easier impact analyzes might be conducted.
I’d refer to Context-rules regarding to a specific business scenario as those which allow to define from strategic level those elements (key contextual elements) affecting current business process execution.
Best regards,
Ricardo Seguel P.
TU/e, Netherlands.
