First Step in Workflow: Moving from Unstructured to Managed Processes

This post defines KAMM stage one and stage two processes; the benefits of redesigning stage one processes; and the requirements for making this transition. As we’ve noted in the Kinetic Data Maturity Model (KAMM), redesigning business processes to go from manual to fully automated is a multi-step undertaking. Fortunately, moving through each phase can provide big savings in time and costs.

The first step is transitioning unstructured, unmanaged manual processes to workflow procedures that have some structure and management behind them. This accelerates fulfillment while eliminating wasteful, frustrating back-and-forth communications.

This post defines Stage 1 — along with their frustrations — and Stage 2 processes:

1. the benefits of redesigning Stage 1 processes; and
2. the requirements for making this transition.

What is Stage 1 of KAMM?

Stage 1 is where most new processes begin. In startup companies, virtually every business process is at Stage 1 initially. In established companies, Stage 1 processes often emerge when there are changes in the enterprise: a new product or service launch, a merger or acquisition, a new strategic partnership, a change in the organizational structure, or other such moves.

Stage 1 provides a basic framework for fulfilling some type of request: a new hire, a new piece of equipment, new software, some type of internal services, or something else.

Typically, an organization will create a simple web-based form or perhaps even just a generic email box. An employee (or a customer, or a supplier…) types a description of their issue into an email message or the web form, hits “Submit” and then waits for someone to (and hopes someone will) deal with it.

What the organization has, in effect, is a wide open funnel through which they can take requests. For example, an employee who requested some computer hardware may report that an item was damaged when they received it, or there were items missing, or they received the wrong items (e.g., a monitor and a keyboard, when they wanted two monitors). Any variety of issues may be reported.

Frustrations of Stage 1 Processes

Though Stage 1 processes can “get the job done,” they typically result in a number of frustrations for both requesters and fulfillers, as well as wasting time and money for the organization.

One common frustration is excessive communication. To use one of the examples above, an employee may request two large-screen monitors to connect to their laptop but instead receive a monitor and a keyboard. They type the details of their issue into an online form; the submitted information gets sent to an email inbox; and then the person assigned the issue may have to respond by asking for the order number.

The employee then responds to that email with what they believe to be the order number…but it’s actually the shipping number. So there is another round of messages sent back and forth. The entire sequence of communications may take a couple of days. Often, people get annoyed, and decide “Forget it; too much energy.”

But those back-and-forth messages about clarification of what data is required in order to resolve the issue happen over and over again. That becomes a frustration for the fullfillers, because this is what they do all day long. It’s not an ideal experience for either the requester or the fulfiller — but it is typical.

A second problem with Stage 1 processes is that experienced fulfillers typically have these processes memorized. They know they need to match the complaint to the order number, validate the issue, send the requester an RMA number along with instructions, etc. At a minimum, these fulfillment steps should be written down so that any employee on the fulfillment team can resolve this type of issue. But for Stage 1 processes, there’s frequently not even formal documentation.

A third frustration of Stage 1 processes is their lack of visibility. The requester has no idea who is working on the issue; if anyone is actually working on the issue; or when their issue may be resolved. Management has no visibility into how frequently this type of issue occurs, or how long it typically takes to resolve such problems.

A final difficulty with Stage 1 processes is dropped issues, or confusion during handoffs. If there is more than one person involved in the fulfillment of a request, that can be a recipe for trouble. Whose responsibility is it to tell the requester that the issue has been resolved—the person who received the original request, or the individual it gets handed off to? This situation is even more challenging when there are multiple functions involved in fulfillment (e.g., IT and finance) rather than just departmental coworkers.

Stage 1 processes mean pain for the requester, the fulfiller, and the broader organization.

Why Organizations Have Stage 1 Processes

There are many reasons why a business enterprise, government agency, or educational institution may have some Stage 1 processes in place. In some cases, it even makes sense to keep these at Stage 1. In many more situations, however, there are significant benefits to moving such processes to Stage 2. Here are several reasons why Stage 1 processes may exist.

• New processes: As noted above, virtually all processes start out at Stage 1. It’s helpful to develop some experience and standards around Stage 1 processes before attempting to move them forward.
• Legacy operations: An organization that makes efforts to optimize and automate common business processes may still have some Stage 1 processes in place for supporting older, legacy products. The volume isn’t high enough or the potential return substantial enough to justify modifying those workflows.
• Non-core focus: Procedures that are necessary but infrequent and not part of core operations are often manual, Stage 1 processes. For example, the IRS has automated systems in place for processing tax returns and sending out refunds because those are core parts of its mission. But the organization likely used many Stage 1 processes for managing the distribution of COVID-19 relief payments, because those were an unusual occurrence.
• Technology laggards: Some organizations simply aren’t aggressive about adopting automation technology, particularly if there’s no competitive market pressure to do so. They may take an “if it isn’t broke, don’t try to fix it” approach to certain operational procedures.
• Low volume: For items and services with low, intermittent demand, automation may be seen as not worth the effort. For example, an auto parts distributor may have highly automated processes in place for common parts, but still use Stage 1 one processes for rare special orders, such as a tail light assembly for a 1957 Studebaker Golden Hawk.
• Exceptions and customizations: An organization may have automated processes in place for shipping standard products but still use Stage 1 processes when the requester wants something modified or out of the ordinary.
• Non-time-sensitive issues: Processes may be left at Stage 1 if they are related to “no rush” types of requests where the requester has low expectations and is perfectly satisfied with not getting an answer back quickly.

What is Stage 2 of KAMM?

At Stage 2, some degree of management and structure is applied to processes. Instead of simply presenting the requester 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.

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

Returning to the example of an employee receiving a monitor and a keyboard when they had requested two monitors, the web form may offer “Incorrect order” as one issue option. If the employee checks that box, the form will then ask for information such as the order number, what was expected, and what was actually received.

So, when the form responses are sent to the fulfiller, that person now at least has the right order number, what the person expected, and what actually happened — eliminating several back-and-forth emails.

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).

Having complete and correct information right away helps the fulfillment person to be more efficient, and have a better work experience. It also enables the organization to develop SLAs around these common services: an incorrect order will be resolved within three days, billing errors within four hours, etc.

Benefits of Moving from Stage 1 to Stage 2

For common processes, there are several benefits for moving from Stage 1 to Stage 2. Depending upon the frequency and value of the process, these benefits can be quite significant. Among these benefits are:

• Improved visibility: In a Stage 1 process, the requester sends an email or submits a form, and then…waits. They have no idea if their issue being worked, who is working it, or what the status is. At Stage 2, requesters have visibility into the process, and managers gain visibility into the frequency of each type of request, typical resolution time, requester satisfaction scores, and other performance metrics.
• Greater reliability: With Stage 1 processes, there is always some risk of a request being “dropped.” It may not have reached the right person. It may have been set aside to work later, then forgotten about. It may have required multiple individuals to fulfill it, and gotten dropped during a handoff. The requester has no idea this has happened until a week, or two, or three goes by…and there’s still no resolution. By contrast, at Stage 2, the problem is assigned a ticket number, an SLA, and the requester can check on progress at any time.
• More accurate ticket assignment: Because issues are predefined rather than wide open (and open to interpretation), tickets get routed to the right team, with the right information, the first time. This makes problem resolution faster and more accurate.
• Improved user experience: Less typing, fewer back-and-forth emails, faster and more accurate problem resolution, and increased visibility add up to a better experience for requesters.
• Improved fulfiller experience: Getting accurate, complete information right away, combined with receiving work that matches their skill set, improves life for those on the fulfillment end. There’s less frustration and confusion, less stopping and starting, and more consistent, predictable work. Network experts don’t get assigned mainframe questions, or vice versa. They have happier customers, so they receive higher performance scores.
• Increased efficiency: Issues get resolved faster and more accurately, reducing wasted time on back-and-forth communications or worse, avoidable downtime. Management has visibility into process metrics, enabling them to prioritize improving the right processes and eliminating bottlenecks.
• Modernized, rationalized processes: Managing and structuring processes enables them to be improved, eliminating wasted steps. Rationalizing processes means they are performed uniformly and consistently; there are no longer multiple methods being used by different people to resolve the same type of problem. Confusion is reduced or removed.
• Time savings: Back-and-forth communications are eliminated. Fulfillers can resolve problems or fulfill requests more quickly. Requesters spend less time waiting for issues to be resolved. Processes are accelerated, enabling everyone involved to be more productive.
• Cost savings: In the Kinetic Automation Maturity Model (KAMM^SM), the average fulfillment cost at Stage 2 is half that at Stage 1. But depending on the nature of the process, the ROI can be much greater: 4X, 6X, even 10X, with hundreds of hours saved per month. Reducing costs frees up budget dollars to be spent elsewhere.
• Higher confidence: When issues are resolved accurately, quickly, and consistently, users have greater confidence in the system. They are more likely to use the request system as designed rather than trying to work around it, causing disruption.

In conclusion

A Stage 1 process is unstructured and unmanaged. Requests may be submitted through a simple web form, an email address, or a paper form. This is where virtually all new processes start, and where some will remain if they are unusual, low-volume, or have intermittent and unpredictable demand.

Moving processes from Stage 1 to Stage 2 can provide significant time and cost savings, as well as improving the reliability of and visibility into process workflows. Even this first level of automation improves the experience for both those making requests and those fulfilling them, as well as benefiting the organization.

Processes are solid candidates for transitioning from Stage 1 to Stage 2 if they have reasonably high volumes or if there are legal or compliance considerations involved.

Making the transition from Stage 1 processes to Stage 2 requires some knowledge of their characteristics as well as defined fulfillment steps. The final piece is technology that provides client-side logic to assure the information submitted is valid.

Moving from Stage 1 to Stage 2 is just the first step in the KAMM framework for process automation. But this first step alone can provide valuable benefits and significant ROI.

This all sounds great, but exactly how does one transition a process from Stage 1 to Stage 2? Find out in our next post!