What is an “Important” process?


To paraphrase a recent question posed on bpm.com, “Which processes should you begin to define first?”, and as a consequence how does one identify these “important” processes. An important process in this context is a process of significant value to the organisation. The value is realized by considering these processes for definition/analysis and/or automation. For anyone involved in process design/automation this is not a new question, and for that reason being able to identify them is critical. An organisations response to this question may be that all of its processes are equally important, and which process to begin defining first is a matter of a coin toss. Such a response is also a cheat, since it abdicates any responsibility to analyse the organisations (sometimes necessarily complex) work practices and activities.

The incantation one wants to hear when confronted with this task is to look for “all those processes that are client facing”. This is not new, we have been talking about the importance of the client for a couple of decades now. To suggest that same applies to processes is not earth shattering. From you corner shop to your retail chain, they have long since extended their service provisions to more closely match the clients satisfaction point. This satisfaction point is not fixed, and therefore neither should the processes be laid in stone, but must be flexible to adopt and adjust to the changing client and market forces. Hence the need to be able to define/analyse the organisations important processes.

Process that have client interaction and/or integrates by extension with the clients processes are highly visible, and will contribute to a loss of client faith in the ability of the organisation to deliver on its promise be it goods or services. Delays in the process via unnecessary activities and/or badly defined activities will quickly become visible to the client. It is important to understand which activities in a process are being performed by implicit knowledge, rather than explicit practices by the knowledge worker. Implicit knowledge is very difficult to transfer, while documented organisational practices can be transferred and enforced. Defining processes may also weasel out the current practices, if there is to be any future opportunity to improve them.

It is precisely for all these reasons that claims and policy management processes have been defined/analysed/automated by most insurance companies. These processes are the most visible and delays in claims payment can be catastrophic for a policyholders with a small claims. Rule based and straight through processing have improved the relationship between the policyholder and the insurance organisation. Similarly outsourcing service providers that have defined/automated their on-boarding, hiring and billing processes are more likely to build a better relationship with their client.
In all this we have assumed that defining and analysing a processes go hand-in-hand, that definition is not an activity performed with no other aim in mind then to produce a pretty document. Further more these activities are followed in all but a few cases by either automation or optimisation.

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 process design, process engineering, process management. 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