The challenge

The cross-functional nature of business process management activities may make the task at hand not an easy climb, here are a few tips that may help though relativity and applicability will vary from organization to organization.

We need a process?

Often you will be receiving requests like these during your activities in BPM or Quality department. An important activity that needs to be done here is to find to find out those vital factors that are leading to this neede.g. delays, customer complaints, lack of information or incorrect information reaching a business unit. Often out of their customer oriented nature BPM and Quality department teams run on the way to develop processes without establishing a business context or a vital business need.

Its true that well established processes help organization achieve business objectives in a way that is sustainable and consistent, but developing a process is not always an answer to a business problem. 

Establish Process Ownership at Senior Level

Once a vital business need is established clearly, it is important to keep in view the ownership of process, process ownership can be defined along the way as its needs clarity on the influence process has on different areas in the organisation. Ideally process ownership must be set at a level that is most affected by the output of the process and has required authority to influence changes in the entire process.

Meet stakeholders individually before a Bing Bang stakeholder meeting

In cross-functional processes, it may be good to meet the key stakeholders individually and understand their issues and activities, it will help to rationalize inputs later in the discussion, since people have more important things on their schedule than participating in process related meetings. They expect the process team to be well versed with their issues and advocate their concerns with other functions, here skills related to time management, conflict management and positive relationships with stakeholders be deeply needed.

The world of exceptions

Meetings with stakeholders on process design often lead to the world of exceptions, such as what if this happens in the new process, what if that happens, and the discussion is dragged in to trying to find all process exceptions and introducing more and more controls to make it robust, but there is a bigger What If, i.e. What if this process is never completed and never implemented. 

Process Improvement is a long term journey, it does not happens instantly. Before entering the world of exceptions the world of regularity (business as usual) need to be explored which captures 80 to 90% of daily activities. 

A sweet flow needs to be captured and agreed upon before thinking about the exceptions, off course any legal implications or requirements implied by contractual agreements need not to be missed out. 

Exceptions should be defined as sub processes emerging from the ideal flow, in order to keep the business as usual process simple and user friendly.

Setting up the RACI Matrix

As human beings it’s a scary feeling to be responsible and accountable for activities, though almost everyone likes to be consulted & informed :), hence in absence of certain guidelines, discussion on RACI can be never ending and results in to escalations and top management involvement, leading to delays in process sign off and implementation. Following guidelines if set may help in cutting the discussion short:

Responsible: Doers are responsible for the activity. Outputs would normally fall under responsibility.

Accountable: Who approves or rejects an activity in a process is accountable. Outcomes would normally fall under accountability.

Consulted: Who will be affected by the outcome or output of activities.

Informed: It’s a heads up, who needs to take some steps earlier or later in the process as it progresses.

Alignment with Authorities set by top management

It’s an observed risk that lack of mapping approvals and rejections in processes as per the authorities set by top management can create audit issues and pose high risks to business e.g. Purchasing Order Approval Limits, who can approve to what amount of PO value. 

These approval limits should be mapped to the processes in addition to any legal implication or contractual requirements the organization subscribes to, as when a process user has to look in to more than one source of information for business activities, it results either in lack of compliance to process or to the specified authority framework or both.

Process team needs to have an alignment with the Legal and Governance Functions in the organization to be aware about any changes that may impact existing processes so that these can be updated as the change comes to in effect.