<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=6766292&amp;fmt=gif">
Skip to content

Business Process Automation: How to Move from Stage Two to Stage Three

Business process automation is a journey of several steps, not a single leap. Let's define stage two and outline stage three.

Published on

May 25, 2022

Business process automation is a journey of several steps — not a single leap. Let’s define stage two, and outline stage three.

A Quick Refresher

Business process automation is a journey of several steps — not a single leap. Workflow automation is the process of transforming manual processes to fully automated workflows and requires transitioning them through six stages, as explained in the Kinetic Automation Maturity Model (KAMMsm).

The first step is to move processes from open-ended, manual task flows (Stage 1) to structured and managed processes. At Stage 2, fulfillment processes are still manual, but SLAs are applied. At stage three, specific steps start to be mapped out, taking fulfillment processes out of the “brain of the fulfiller” and enabling some steps to be automated.

Here’s a quick refresher:

  • The definition of Stage 2 processes
  • What Stage 3 processes look like
  • When and why you’d want to move processes from stage two to three
  • How to accomplish that transition

What is Stage 2 of the Kinetic Automation Maturity Model?

At Stage 1, processes are undefined and open-ended. The requester types their request into an email message or free-text field on a web form, and someone on the other end figures out how to fulfill it.

Stage 2 adds structure and a system. In the first step of a workflow, some degree of management and structure is applied to processes in Stage 2. Instead of simply presenting a person making a request with an open text field on a web form, the fulfilling organization may ask the requester to select from a list of five, 10, or some number of predefined services.

Stage 2

For each service, the form will then ask the user to provide specific information needed for that request.

At Stage 2, common types of requests are predefined rather than wide open. The system asks for the right information up front, with validation (e.g., order numbers must begin with an “N” and be seven characters long; any other type of input will be flagged as an error).

Frustrations of Stage 2 Processes

Though there is now a system in place, at Stage 2, all of the steps required for processing of fulfillment are stored in the brain of the fulfiller. They know what the process is. The human is acting like an engine.

That works, but it requires a high level of training for an organization. If you want to modify your processes, you have to communicate to all the fulfillers.

That makes changing processes hard, and training new people to do fulfillment hard. It also creates significant risk; if a fulfiller leaves the organization, a great deal of valuable knowledge will walk out the door.

In addition, while Stage 2 processes provide more visibility than Stage 1, that visibility is still limited. It’s difficult to see where steps may be missed, where errors may occur, and where bottlenecks are slowing process completion.

Why Organizations Have Stage 2 Processes

Organizations commonly have a lot of Stage 2 processes that should be moved to Stage 3. It’s the Pareto Principle: (roughly) 20% of all the different types of requests are repetitive tasks that account for 80% of all requests submitted. These are the prime candidates for further workflow automation.

On the other hand, it makes sense to keep low-volume types of requests that don’t have compliance impacts at Stage 2. It may not be worth the effort to optimize and automate workflows that just don’t happen very often. It’s a fair amount of work to migrate the knowledge from someone’s brain into a process definition, so if a task only gets done a couple of times each month, it probably doesn’t make sense to move it.

What is Stage 3 of KAMM?

While the major advance in taking processes from Stage 1 to Stage 2 is moving from unstructured workflows to a framework, the big change in Stage 3 is to migrate process definitions from human brains to software systems. It’s systematizing the human brain. It’s no longer the case that some human knows what to do, but rather that the system knows what to do.

At Stage 3, you start breaking down the end-to-end fulfillment process into a series of discrete steps. This enables you to optimize fulfillment for the task at hand. Fulfillment is still done by humans, but the system assists them by 1) guiding them through the process step-by-step, and 2) providing the human fulfiller, at each step, with only the information needed to complete that specific task.

For example, to begin the process of fulfilling an order for a new iPhone, the fulfiller may need to know who approved the request and when it was approved. At the second step, the fulfiller may need to know what color and model of iPhone to take from inventory, but doesn’t need the approval details. At the third step, the fulfiller needs to know what software to pre-install on the phone, but doesn’t need the detail for the first two steps.

Benefits of Moving from Stage 2 to Stage 3

As noted above, in Stage 2, a human is both managing and performing all fulfillment tasks. At Stage 3, though humans are still performing the tasks, a system is now managing the overall process. That provides a number of compelling benefits. Moving processes from Stage 2 to Stage 3:

  1. Reduces costs
    Per the KAMM framework, this transition typically cuts fulfillment costs by about a third, mainly due to reducing manual steps and improving consistency.
  2. Enables process optimization
    At Stage 3, fulfillment processes are broken down into discrete steps, which uncovers opportunities to eliminate, combine, or redesign tasks in order to reduce the overall time and effort required.
  3. Improves visibility
    Identifying and “systematizing” fulfillment tasks provides greater visibility to spot bottlenecks, reduce or eliminate errors, and measure performance on a more granular level.
  4. Simplifies training
    In Stage 3, the fulfillment steps get well defined. That guidance can be used to optimize tasks, reduce time, simplify training, and increase flexibility. It’s easier to change process definitions, and new fulfillment employees can be onboarded more quickly.
  5. Reduces errors
    There’s a much higher likelihood of getting the process done properly the first time once it’s at Stage 3 of the KAMM framework. At Stage 2, fulfillment is still relying entirely on a human brain. No matter how knowledgeable, talented, and conscientious employees may be, they can still forget things or make mistakes. But at Stage 3, the system is managing the task flow, which reduces the need to resubmit requests or correct fulfillment errors.
  6. Improves employee satisfaction
    When employees get their requests fulfilled more quickly and with greater accuracy, their job satisfaction increases. They are able to be more productive and have less disruption to their workflow. And by simplifying fulfillment tasks and reducing rework, it increases job satisfaction for those doing the fulfillment work as well.
  7. Improves scalability
    Moving processes to Stage 3 improves utilization of resources within an organization, which cuts costs while increasing capacity. It enables the enterprise to handle the same number of requests with fewer people, or a larger number of requests with the same staff level.

How to Move Processes from Stage Two to Stage Three

Again, this migration is about taking the fulfillment process out of the brains of humans and moving it into a system that can manage, guide, and enforce the steps. It makes sense to undertake this move for high-volume requests as well as for lower-volume requests that have legal or regulatory compliance implications.

The transition from Stage 2 to Stage 3 involves a lot of whiteboard time. After identifying which processes to migrate, you’ll need to carefully examine the Stage 2 tickets for each request type. What did the fulfillers do? What notes did they make? Get the process owners involved. Break down each complete fulfillment workflow into discrete steps. Build out the steps and look for opportunities to improve the process.

In addition to a whiteboard, you’ll need software that lets you do something with that information: an orchestration back end that can guide fulfillers through the process and provide them with the information needed at each stage.

As human fulfillers progress through each step, it’s important that the system only passes through the information needed to complete that specific step. This is key to reducing errors. If fulfillers are overloaded with extraneous information that isn’t required for the task at hand, then they need to search and sift to find what they need — and that can cause errors. Orchestration is vital.

A Stage Two to Stage Three Example: Ordering an iPhone

At Stage Two, when an employee requests a new or replacement iPhone, the request gets routed to someone in IT to take an iPhone out of inventory, preload it with the required software, and deliver it to the employee. But the first step that the fulfiller takes is to check and make sure the request has been approved.

Process owners may look and see that they are getting 20, or 100, or some significant number of iPhone requests each month, and decide to improve this process. The first step in transitioning that process from Stage 2 to Stage 3 is to go to a whiteboard and map out all of the steps required for fulfillment.

Noticing that fulfillers can’t begin their work until they check to see if the request has been approved, the first bit of process improvement can be applied: route the request to the appropriate manager for approval before it goes to IT for fulfillment. It’s a small improvement, but will save time for IT on every iPhone request going forward.

In Stage 2, the requester would have been presented with some very basic options, such as model, after selecting iPhone as their request type. In Stage 3, they would see a full list of options in drop-down menus, so that this information can be passed to the fulfiller at the appropriate step: model, carrier, color, type of case and perhaps choices of specific apps.

Parts of the process may start to be automated at Stage Three. For example, at Stage Two, the fulfiller may know that when they get down to five or fewer iPhones in stock, it’s time to manually place an order for 10 (or some number) more, to replenish their stock on hand.

Seeing this part of the process in the whiteboard exercise, the team may automate this, having the system automatically order more phones once the inventory drops to a preset level. Again, it’s a small improvement that saves a lot of manual effort over time.

Summing things up

Moving processes from Stage 2 to Stage 3 starts with looking at recent tickets to identify the best candidates. Any processes that are either high-volume or have compliance implications can be improved by transitioning them to Stage 3.

The migration starts with a whiteboard exercise. A big part of the move to Stage 3 is to take knowledge out of the heads of fulfillers and map all of the fulfillment steps in orchestration software. This enables the system to manage the process, and provide fulfillers with the precise information they need at each step.

Some sort of orchestration software is required to make the move to Stage 3. But the system won’t do anything for you until you sit down with your process owners in front of a whiteboard and break down the process.

This transformation provides a number of benefits, from cutting fulfillment costs by one-third on average, to reducing errors, increasing visibility and improving employee satisfaction.

Latest Articles

Unlocking Developer Efficiency with the Right Tools
Complex Workflow   |   Aug 20, 2024

Unlocking Developer Efficiency with the Right Tools

Choosing the perfect Integrated IDE can streamline workflows and boo...

React’s useContext vs Redux: Global State Cage Match
Complex Workflow   |   Aug 13, 2024

React’s useContext vs Redux: Global State Cage Match

This post explores the critical distinctions between React’s useCont...

A Wonderful Front-end Training Experience in Beautiful Baltimore
Complex Workflow   |   Jul 30, 2024

A Wonderful Front-end Training Experience in Beautiful Baltimore

We recently had the pleasure of hosting a special onsite front-end t...