The Story

After getting involved in some business process modeling/improvement projects (in varying sizes and in different customers), some years ago we came to realize that indeed our own (small consultancy) company was facing some difficulties in managing its processes. 

At some point in the past, our "central" process design/improvement team consisting of some "process experts" designed "cutting-edge" processes (based on their own expertise, view, and the business climate then). But as time passed, we have started deviating from the documented processes due to various reasons. Some of our process definitions had to be simplified, some had to be extended in some way to adapt to new conditions, projects, etc.

Despite the fact that the actual execution was somehow changed and performed one way or another, the process descriptions stayed as-is, and thus became out-dated. There were few reasons for that and perhaps the key one was the fact that there was an ambiguity about who should actually initiate and perform these updates (as the processes cut across functions, people, etc.). Should it be performed by our famous central group or by the performers of that process? In fact there was also a (change) process to improve the processes but never enacted as -itself - was bureaucratic.

The changes were quite important in essence, and the company should not continue missing these opportunities of integrating them into its processes. These changes started becoming tacit - embedded in people’s head. This couldn't go on like this.

We also had to get rid of this central way of modeling and maintaining our processes, as it was proven ineffective for us. We shouldn’t expect anyone else to model our processes and maintain/improve it on our behalf (even someone from inside).  We had to find a method that would allow us to collaboratively model our processes, yet control and maintain our own way of doing individual work (in a decentralized way) - we were experts on what we do after all.  

We were triggered with the idea that the organizations are structured in some entities (people, role, dept., branch, ...) who offer their services to others (internal or external to the organization) and processes are nothing but a collection of these service calls and running services that are called. (For those familiar with the concept: this is analogous to the idea of object-oriented software composed of classes performing/offering some operations in the software system. They call each other to perform a piece of functionality –a process in our case).  These entities (people mainly) perform their tasks (i.e. offer services) through the roles they act for.  

So, we thought maybe we should let each one of us to define what he/she offers to the organization and give the full control over the internal workings of his/her service (again, they were experts on what they do at the end of the day).

It was easier said than done. This was a complete mind shift. The current BP notations, tools, and methods were assuming (implicitly or explicitly) a central power controlling the modeling and improvement process.  Letting everyone to model would lead a chaotic environment (definitions) with full of inconsistencies and conflicts among individual models. But we were also convinced that these inconsistencies/conflicts should be surfaced as there lied the chances for improvement; chances to make tacit explicit. 

We had to come up with a new notation (extend a commonly used one), a tool and more importantly a method that would guide us with our adventure.  The key point here was asking our people to define the services they provide AND the inputs (documents, information, messages, etc) they require to offer that service and the outputs they generate at the end. IN ADDITION to this, they are asked to define FROM WHERE they expect to acquire the inputs and TO WHERE they forward their outputs.

For example: Suppose I am playing the Role T and I need message A to come from Role R to offer my service S. This request should be reflected in one of the service description of Role R (by stating that Role R forwards message A to me – Role T). If there is a conflict we need to communicate and solve.

Fig. 1: Role A specifies what it does (as Service/Operation OPR1), what it requires and produces*  

When all services are defined and inconsistencies are resolved, the organization had a repository, which - in fact - had a tremendous amount of information. Because based on these individual service models, we were able to (automatically) generate the entire model for a process at any time (see Fig. 2 below), or models that show the inner-workings or dependencies from various perspectives (who gets what from whom, etc.)  (see Fig. 3 below).  

Each model was nothing but a query to the process-base that visualizes a portion of the processes from a specific perspective. A generated model was valid until a change was made to its underlying individual service model. When a change was performed, the model had to be regenerated in order to reflect the change.  

By encapsulation, information about the internal workings of a role service is hidden to outside world, yet its interface (what it needs and what it provides back) is visible as expectations. Any change of behavior that alters its interface is visible instantly and must be solved by the individual acting for this role and might require further changes to other service descriptions.

You will find the details of our endeavor: findings, challenges, limitations, etc. here:
http://www.sciencedirect.com/science/article/pii/S0378720611000541

Those interested with the paper and with further discussions, please send me an email: o.turetken@gmail.com.  

Fig. 2: A Generated Process Model (for a Review process) from individual role operations *

Fig. 3: A generated role dependency diagram for the review process*

* Figures from: Turetken, O., Demirors, O. (2011). Plural: A Decentralized Business Process Modeling Method, Information & Management, Vol.48, Iss.6, Pages 235-247.