RedStack

Today, we are witnessing a significant change in the way that businesses use Information Technology to support their needs for agility and flexibility.  Part of this is the shift from monolithic applications and Enterprise Application Integration, to Service Orientation and loose coupling.

A significant challenge in adopting a service oriented approach is the need to refocus on business processes as the key requirements of IT.  In this post, we will discuss what it means to become process oriented.  Subsequent posts will explore in detail how this is actually achieved, using Oracle software.

What is a business process?

There are many different definitions of “business process.”  For the purposes of this series of posts, we present the following definition:

“A collection of related, structured activities – a chain of events – that produce a specific product or service.”

Importantly, business processes exist at many levels in an organisation, from the high level “macro” business processes (often referred to as Level 0, Level 1, etc.) which refer to large business processes, through to low level, operational processes.  Some examples of high level business processes are “hire to retire,” “order to cash,” and “procure to pay.”  An example of an operational process is “invoice matching.”  We will explore these in later posts.

Business processes may be automated or manual.  Often, they are “coded into” application systems.  This could be as a result of acquisition of an “off the shelf” application package, which includes its own predefined business processes.  Alternatively, it may be as the result of custom development based on requirements stated at some point in time in the past.

Importantly, business processes cross organisational and systems boundaries.  This leads to a common problem of identifying process owners, and reluctance on the part of business people to own processes that are not completely contained within their own area of responsibility.  Some business processes also tend to change quite often, as a result of external and internal factors, e.g. change in regulation, a response to a competitor’s action, change of strategy, merger or acquisition, etc.

What is a Process Oriented Organisation?

There are several characteristics that distinguish a process oriented organisation.  Most importantly, they attach value to business processes, i.e. they know how much value is created by a process, and how much it costs (in time, resources, etc.) to operate that process.

They have process owners, and these people are usually in “the business,” as opposed to IT.  Many of these organisations are introducing a position in their organisation for a process manager, sometimes called a Chief Process Officer (CPO).

These organisations derive their business processes from their strategy, they understand that business processes cross organisational and system boundaries, and they seek to constantly measure and improve the performance of their business processes.

Continuous Improvement

A key aim of process oriented organisations is to continuously improve the efficiency of their business processes.  This means they need to be able to objectively measure the performance of processes using business metrics, which they can attach a value to.  These metrics could be things like “average time to process an order,” “number of employees required to process 1000 orders per day,” etc.

It is important to understand that not all processes would be focussed on for improvement.  It is normal to identify which processes have scope for signifcant improvement, and the realisable value of making such imrpovements, and then focussing efforts on those processes which provide the opportunity with the highest potential realisable value.

The cycle of continuous improvement would normally be carried out as described below:

• Business Analysts speak to process owners, workers and other stakeholders to understand the business process,
• Business Analysts create a model of the business process and review this with the stakeholders to ensure accuracy and agreement,
• Business Analysts validate the model, usually using standard Operations Research methods, to ensure that it does behave like the real world process and that it can be used to make decisions about the real world process,
• Business Analysts model various potential changes to the process, e.g. reording the process flow, adjusting resource levels, automation of some steps, etc., and test these to understand what the impact on the process woule be, e.g. in terms of cost, time, throughput, resource requirements, etc.,
• Business Analysts produce a business case for implementation of a change to the process, based on the information produced from the modelling and simulation activities,
• A business case approval and funding process takes place,
• Requirements are released to IT (where appropriate) to implement the changes to the business process,
• The performance of the business process is then monitored against the established performance indicators, to validate that the proposed value has been realised, and finally
• We return to the beginning and do another iteration.

Finally

To wrap up this first post in this series on business processes, let us consider also that process oriented organisations tend to have higher levels of accountability and visibility within their organisations.  That is, they have a much clearer view of how their business processes are performing, often in “real” time, and they are able to hold people accountable for their performance.

Many organisations today use project based funding, i.e. funding is allocated on a project by project basis.  This can create a challenge for service and process oriented approaches, because we often see that no one project is willing to assume the extra cost of establishing infrastructure, when they will not be realising all of the value themselves.  Process modelling and orientation provide a very good mechanism for clearly demonstrating mathematically defensible business value, which can help to obtain support for “infrastructure” style business cases.

In the next post in this series, we will discuss process modelling – what it is, how we do it, and what the value of modelling is.