A Process by any other name…

…would still confuse as much.

  (with apologies to Shakespeare)


    The average person see a process as they would see a forest, essentially without the details of the trees. The fact that a process is only a moniker, for a collection of activities is completely lost in this perspective. This is unfortunate, since these activities are like the trees of the forest, that give the process its shape and structure. They help to explain how the organisation does its business, or attains its business goals. It is particularly important that process designers pay heed to this fact. A good process design is dependent upon knowing the inner workings of the target organisation.

   An organisations interest in a process is only incidental, its real interest is in certain events that the process generates. Event-driven organisation have their processes fired  off when a trigger event happens.

   For example, a claim request from a policy holder will trigger the Insurers claim process.

   The activities of the claim process will generate many events, not all of them are of business value to the Insurer. Many of the events generated by the activities are useful for the correct execution of the process. Some of them are trigger events for financial processes of the Insurer, for example, a claim payment to the insured. It is obvious from this that an inside-out view is more important than a simple outside view of the process.

   Process, beside being a moniker, should properly be used as bench marks. A claim for the insured is the most stressful time, and delays at this stage are one of the best example of bad customer service. Processes are useful for comparing cross company practices and performance. But, for any individual Insurer, it is always the latency of each activity that sums to the performance of the process as a whole.

   As mentioned in another article, it is important to differentiate the language of the technologist from that of the business user. The technologists language is driven by the need to standardise computer design tools and execution engines for processes. These standardisation make it easier for the technologists to compare vendor tools and machine performance. These standardisation eases the job of the technologists for implementation of business process for machine execution, and also communications with other technologist. A business process common language for machines and technologists. It is undeniable that there is a need for such a common language for technologists and machines. There is also need for a standardisation effort to provide industry wide vendor comparison. But, there is no need for the business user, or the business process designer to learn or communicate in this, what is after all a foreign language to him.

   It is suggested that the visualisation of the process as boxes and arrows provides a sense of the flow, while presumably the attached XML document provides the details. This is perhaps true for a technologist, but not for a business user. It is really unfortunate that the word “flow” has ever entered the lexicon of process language. It is the consequence of our need to believe that automation (with digitisation) will reduce all process latency to Planck time. We want to believeThat the earth is flat, at least, in the economic sense. The need to make everything uniform and reproducible in the millions leads us to use all avenues to ensure it is so. It would have been far better to use  “follow” instead “flow”, an activity follows another activity, instead of an activity flowing into another activity.

   These tools (that help to draw the boxes and arrows) are meant for interactive use, which also suggests that the business user must be well adept at using it to navigate the process.

   The business user community already has a language, the language of the organisation at which he is very adept. He has the knowledge to deduce which collection of activities organisation-demo-example-1complete a process of interest to the organisation. He also has the language of business events, the organisational analytics that they give rise to. The only thing lacking is an ontology that brings all this together for him to be able to design processes. 

    The ontology must have a small set of symbols, a small amount of grammar, but it must enable a very large and rich set processes. This is not unlike chess, a few pieces, a small set of valid moves, but generating an infinite variety of games. Of course, there is always place for some small syntactic sugar for the handling of business rules and such additions.

   The motivation for the business user/analyst is to own and design the process with the optimum use of the organisation structure. The only thing that constraints his design are the limits of his understanding, and the boundaries of the organisation structure. But, a technologist is also constrained by the tools, the standards, and his far more limited knowledge of the organisation structure.

Posted in business analysis, DEMO, process design, process improvement | Leave a comment

Offshoring, Distributed Teams, and Risk


   We cannot with any honesty call the offshoring that has been in existence for the past three decades a distributed development model. One of the primary condition of distributed development is that every one of the distributed teams must function in an autonomous manner. Please note that autonomous in this context is never full autonomy for the distributed team, their decisions are always bounded by the clients bigger product vision and direction. There is no benefit in the early stages of a startup, to hand over autonomy to remote distributed teams. This will change as the product matures and team dynamics improve.

   The current offshoring model use of the term distributed is mostly a marketing ploy. The model is more representative of distributed as in, divide up. The necessary work is divided up (by the client or his representative role) and then handed over to the remote teams. This chunking allows the work to be quantified in terms of effort, and hence also converted to monetary terms. This working model also explains why the transition to agile teams was (and still is) so difficult for offshoring.

   The financial risk was a known or at most calculable in the old model.

   In the agile development context, learning went hand-in-hand with the idea of fast fail and iteration speed. This combination increases the required competency level of the team members. Agile, instead of alleviating the clients risk, made its monetary quantification more complex. 

   Although, the idea of a long term relationship between the client and the service provider, and its supposed (not so conclusive) benefits, it is difficult to quantify the reduction in risk this brings to the client. One would expect the combination of agile, devOps and continuous delivery would reduce the risk to the client. But, as usual “knowing of” and “knowing” are two entirely different things. Exploiting these techniques requires a qualitative leap in the team structure and dynamic. Exploitation is not only     about choosing the right technologies. It is about the empowered team to stand up and take ownership and responsibilities, it is this dynamic that is also the most fragile.

   For the startup (client) that offshore its work, the experience of managing the dynamics of team structure, the domain and technology complexities, may turn out to be a total catastrophe. Distributed teams failures can also have a monetary charge on other teams that are successful, by increasing their wait time. Such failures disturb the working dynamics of the teams and increases the long term relationships, the onset of the blame games.


   As long as the offshore service provider has an option to just transfer resource from a lost client to a fresh client, the risk for failure is solely carried by the client.

   What is required is a risk transference mechanism that will change the working relationship of client and service provider to one of carrying a shared risk. Such a shared risk is necessary for the clients to accept the service providers offering of distributed autonomous teams.

   Having a penalty clause in the contract is not the same thing as risk sharing, it is more a contingency plan for the client. More importantly, the penalty is a reputation risk cover for the service provider. This can easily be indemnified against, and the larger the organisation the more ineffective. Since the client faces many different types of failures each with a different chance of occurring, and different amount of loss, a single number such as a penalty is unsuitable.

   From the service providers perspective the risk transference must lead to an incentive to differentiate and improve his service provisioning. Without such a motivation the service game will only follow the old rules with very little hope of long term sustainability of the service model.

   There is a body of study that suggests that financial options are a suitable contract for such a risk transference. But, in practice this is an unknown quantity in the offshoring sector.   

Posted in Distributed Teams, outsourcing/offshoring, Risk | Leave a comment