Complex, multi-team processes in transactional operations can often be almost invisible in operation and execution – until, that is, something goes wrong. Transactional process failures are common: failed online transactions, payments not made on time, double bookings and lost orders are frequently encountered errors. These processes often involve manual tasks and multiple unconnected systems, are typically only known from start to finish by a few, and do not have the oversight and ownership of an end-to-end owner. With limited visibility of the tasks and plenty of scope for non-standardized methods, the transactional process can be a challenge to manage.

In a medium-size company, a business process management (BPM) workflow product was developed from scratch to manage complex transactional changes, building on the organization’s background of delivering Lean Six Sigma process excellence projects. The process involved the management of supplier product offerings into and across a distribution network. The setup can be configured both by the supplier and the network owner. Changes to the supplier setup could range from a price and service package change to access restrictions and accounting changes.

Here are six main lessons from a BPM build in a transactional operation.

1. Identify Business Processes

The reasons why a task is being done a particular way can become lost in complex transactional processes with multiple teams managing small parts of the whole. This is magnified by the ability to extract data from databases into multiple other products, meaning data ownership is not clear. This is especially a risk when teams have no visibility on the end product and are removed from both the process trigger and the customer. Teams are focused on their parts of the process, meaning they do not have a view of the overall process. The name used locally to describe the task is not always going to be same when looking at it from the big picture.

A key start point is to define a full list of all the processes that need to be included in the scope of the project. The high-level business process list gives structure to the process discovery that follows and also becomes a reference point when deciding what level to define the process at.

With the business processes identified, decisions can be made as to what will be the actual process start point in the BPM product. This structure also creates the opportunity to define the reusable steps that can be used multiple times to manage the process. This could be reusable subprocesses, operations or tasks depending on how granular the process is being defined.

The minimum requirement is to define the business processes before moving to Step 2.

2. Build a Business Process Summary

While many practioners are familiar with SIPOC (suppliers, inputs, process, outputs, customers) or SIPOC variants at a process level, the tool also features in the business process summary template. The business process summary defines a range of key attributes of the process, which then acts as a document for ongoing management.

In one master document, key aspects of a process are defined and questioned – and gaps are uncovered. The feedback loops (or lack thereof) from process to suppliers or customer to the process are areas to focus on. The customer feedback loop may be familiar (for internal processes, even this may be weak or nonexistent) but the process to supplier loop is likely to be limited in transactional areas.

After completing the summary with process members, the business process summary becomes a living document to build and add to as the level of process management increases.

At the top of the document is a space for a process owner, which leads to Step 3.

3. Find a Process Owner

Identify a process owner who can look at the end-to-end management of the process rather than managing vertically. Process owners can reach across the teams, highlighting the overall customer experience or the final customer experience, and close the gaps back with the teams who are involved far upstream from the final customer. They also become key assets for the BPM process discovery and deployment as they care about the overall picture rather than suboptimizing elements in the process. The process owner becomes a key point of contact for the process discovery and deployment teams as work progresses.

A process owner’s responsibilities may include:

• Governing the overall delivery of the changes.
• Understand the overall information architecture, where data is mastered and kept.
• Championing best practices for the benefit of the overall process.
• Identifying potential new processes arising from new capabilities or business changes.

4. Find Subject Matter Experts (SMEs)

Deploying a BPM workflow product across manual processes requires a high level of support. SMEs are central to explaining how they complete the process, from reviewing diagram accuracy to testing the workflow product as the activities transfer from a diagram to on-screen tasks. Securing SME support for the long term with clearly defined roles is a core pillar of a workflow product.

SME role requirements might include:

• Providing detailed information on team tasks and interactions in each process.
• Reviewing and signing off on the process diagram for their process lane.
• Being involved in a walk through of the process diagram to ensure all steps are included.
• Providing requirements for the tools that will be used by the team.
• Being actively involved in user testing for each process.
• Assisting in the rollout of defined process in the product.

5. Define the Level at Which to Start Process Discovery

A lot of time and effort can be spent revising process diagrams if there is doubt about what level to define the process at, especially if the dreaded words “it depends” are muttered in a discovery session. Once the urge to run away has passed, the session can continue and the team can learn to understand how the process operates, even if the process is not ultimately modeled at the operational/task level. Defined too closely and there is no time for the end user to show tasks have been completed in the workflow product before they have completed the next one. If a task triggers other processes or interactions with other teams this is when the detail should be exposed in the process diagram to make sure any process complexity is captured. Being clear on the level at which to define the process saves a lot of rework.

6. Define Reusable Subprocess Diagrams

Building and displaying a complex process in one diagram has a number of initial attractions: it is visually appealing, easier to start with and often combined with a “wow” factor when shown to unsuspecting stakeholders. Development teams, however, are likely to prefer deploying and then managing a number of smaller diagrams, rather than getting to grips with a single multi-lane, multi-gateway diagram. If the defined process (Step 1) has been the BPM deployment start point, a list of reusable BPM building blocks should start to appear. These smaller operational, or subprocess, diagrams are easier to maintain, manage and deploy faster as the project progresses. Although opening a number of BPM files and switching between them in stakeholder discussions will be less fluid, the advantages of modeling with small diagrams are numerous.

Summary

Defining, building and deploying a BPM workflow application in a transactional operation produces many opportunities to take a manual process toward a standardized, integrated repeatable process. The key elements of this type of workflow include:

• Define the high-level processes being managed.
• Complete the business process summary for each high-level process.
• Find a process owner.
• Identify and build a team of SMEs.
• Map at the suitable level.
• Keep process diagrams small as well as reusable and interchangeable.

If these steps are followed and established, a solid platform is built for a successful BPM deployment.