Murmuration of Tasks

“Drawing” is the root of the word “Design”. So at its most narrow understanding “to design” would be “to draw”, and it is not surprising how often this particular interpretation of “design” is used in business process implementation. The aim of the tool is to allow for the implementation of a production artifact, that is, an object that will be embedded in a BPM engine. Along the way it may provide simulation to ensure that the “flow” of the process is accurate, and that implementation will be clear of run-time errors. But, most of the tools do not encourage a proper participation of the business user or the end user, since the language is of the technical variety it is alien to both these type of users. This does not encourage any learning within the organisation, there is no reusable knowledge for the business, and more emphatically there is no rate of increase in the learning from design or conceptual alternatives.

From the perspective of the tool a task is a drag-and-drop box with an attachment of properties, form or an interface method. Really, this is what the business user understands! A task is catgorised by some of the following:

  • Context, part of a goal that fits into the larger business need of the organisation.
  • Owner performer of the task could be internal to the organisation or an external proxy owner.
  • Inputs, these are all the required information of the case (of which this task is an integral part) that is necessary to complete the task.
  • Output, these are additions to the knowledge artifacts of the case (of which this task is an integral part) that will eventually be completed (this could be either a success or failure of the case).

There is no mention of interfaces or other technical language here; it is the business language describing the task. The task has to be seen as part of the whole, that is, the business goal that has to be achieved. This is not to suggest that all tasks will be executed for all instances of the case occurrence, but the as-is analysis must identify all the tasks with their associated rules, this is the whole picture without which you cannot optimise or have an optimal implementation. This is an all-inclusive analysis; it pulls all existing participants involved in achieving the business goal. It encourages tacit type of knowledge to be made explicit, thus adding to the organisational learning.

starling-FinalTasks only make sense for the organisation at the business goal level locally and the business need level globally. They should be seen as a choreographed whole, not unlike the murmuration of starlings, no matter how confused the parts may look locally. It is believed that each starling maintains a “behavioural zone” to manoeuvre and together the swarm create a mesmeric image. Unlike a “metric distance” (in the language of the article sited in the link) which would connect a task to its prior and post tasks, what is required of a business process is an identification of its tasks and their individual behavioural zones. These zones would cross both organisational structure boundaries and case boundaries.

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 Adaptive Case Management, BPM. Bookmark the permalink.

Leave a Reply

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

You are commenting using your 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