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.

About KM Mukku

Kick-start, build and manage teams in product development (particularly in the financial domain), and enjoy all in adaptive case management, business process design and business process improvement. Currently holding the position of CTO at coMakeIT.
This entry was posted in business analysis, DEMO, process design, process improvement. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s