Process Thinking with Promises

the-full-transaction-1

  More than a decade of talking about the need for non-technical business people to take on the task of mapping out the business processes, we are still in the wrong place. Business processes define how the business people do things, achieve their business goals. But, the business process design is done by members of the IT department.

  It is increasingly evident that a process designer is required to be an expert in the symbols of the process language, including those thrust by the design tools. It seems at times as though emphasis on the process design ignores the Organisation and its  structure.

osp-1

  Consider figure on the right, it is a recruitment business process of an offshore service provider. It is purely for illustrative purposes and is thus incomplete. The tool used in this case does not support partner organisations. It is not possible for a business person to understand this except as a superficial chain of activities. There are too many symbols with embedded meaning to fathom all the intricacies of the process. Each symbol in the diagram tells a story, and not knowing this means there is no proper critique of the process from the business person. It is only in its execution that a business person understand the consequences of the design. 

  How Organisations get things done is often found embedded in its business processes. One could even say that an Organisation is just the sum of its processes. Organisational structure plays a large part in influencing and is also influenced by its business processes. The Organisations structure acts as a constraint on its processes, and vice versa. Business process should be designed around the Organisations structure, and the structure should evolve in time as new business practices and external factors come into play.

request_promise_transaction

  How do we make the process designing conceptually more  non-technical business person friendly? We can start by simplifying the language used in process design. The DEMO ontology provides an enterprise wide notion of a transaction, figure on the right.

In this sense a business activity should be seen as a transaction (in the DEMO sense). An activity thus consists of the following, a triggering request, promise, execution, statement, and acceptance.

  • Actor (A1) in the figure is the request raiser; he may be external or internal to the organisation.
  • Actor (A2) is the promissory for the execution of the activity, and the promise is backed by the Organisation. The actor is the owner of the activity from the promise, to the execution, to the statement.
  • Actor (A1) at the end has the option to accept or decline the result, he will accept if it his desired result.

the-whole-request_promise_transaction

  These concepts can be used to redo the illustrative process, to transform the process as set of  linked transactions, see figure on the right. We have the exact same process, but with a lot more clarity for the business person. It is thus possible with a minimum number of language constructs to design all business process, by and for business persons. As a set of linked transactions it is easy to verify that the business goal is achieved, or should be achievable within the constraints of the Organisations structure. We are not aware of any formal verification process.

  Even when the process crosses boundaries into other Organisations, the language used to depict the activity is the same. Thus Partnership relations can be also clear in the diagram.

  A promise in the transaction is not a mere statement with some ethical connotations, but it is akin to contract backed by the organisation. It is also a precursor to trust between the parties in the promise. There are no restrictions that the actors in the transaction have to be human. It is possible (and true) for an actor to be a machine, rule engine, etc. Neither is there any restriction of atomicity on the execution part of the promise. It is indeed possible that the execution may consist of multiple actions by the actor offering the promise to the requestor.   

CONCLUSION

This little snippet of a writeup can not do justice to showing just what DEMO can contribute to business process design. Nor can it begin to stress the importance of DEMO to enterprise architecture. DEMO provides a much tighter and controlled feedback with the Organisations enterprise architecture, both from an informational and process perspective. Process design is for the business people to own, not some tool mastering technical IT person.

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 BPM, DEMO, process design. 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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s