As-is process

An as-is process is the way a process works today, before improvements, automation, redesign, or new documentation are introduced. It captures the real steps, handoffs, tools, delays, exceptions, and workarounds people use in practice. ¹

The phrase shows up in process improvement, operations, business analysis, and systems implementation work. The point is to describe reality before prescribing a better future. If a team skips the as-is process and jumps straight to the ideal workflow, it often solves the wrong problem.

Most process problems hide in the gap between the official procedure and what people actually do. ²

An as-is process map makes that gap visible. It may show that a manager approves requests in email even though the system has an approval feature. It may show that a support team copies customer details between three tools because an integration is missing. It may show that a "simple" onboarding step depends on one experienced teammate remembering to send a message at the right time.

The useful discipline is restraint. Before you simplify, automate, delegate, or document a process, you need to know which parts are formal work, which parts are informal survival tactics, and which parts compensate for broken systems.

The as-is process describes the current state. The to-be process describes the desired future state. Keep them separate long enough to understand the gap. ³

A strong improvement project usually needs both. The as-is process explains what is happening. The to-be process explains what should change. The gap between them becomes the work plan.

Start by watching the work or walking through a recent real example. Ask people to show the tools, messages, spreadsheets, approvals, and decisions they actually use. Do not start with the policy document unless the goal is specifically to test whether reality matches the policy.

The best questions are concrete:

• What triggers this process?
• Who touches the work before it is done?
• Which system is treated as the source of truth?
• Where do people wait, re-enter data, ask for clarification, or create side notes?
• What happens when the normal path does not work?

The last question is usually where the process gets interesting. Exceptions reveal how the team handles ambiguity, missing information, unavailable approvers, edge-case customers, broken tools, and unclear ownership.

Documenting the polite version instead of the real version. People often describe the process they think they are supposed to follow. Ask for a recent example and follow the evidence. The goal is to understand the system people are operating inside.

Stopping at the visible steps. A process map that only shows obvious tasks misses much of the cost. Approval waits, rework loops, duplicate entry, handoff confusion, and exception handling should be visible if they affect the outcome.

Treating every workaround as bad. Some workarounds are symptoms of a broken process. Others are practical knowledge worth preserving. The as-is process should separate fragile hacks from experienced judgment.

Turning the map into the improvement plan too soon. Once a pain point is visible, it is tempting to jump into fixes. Hold that urge long enough to understand frequency, impact, owner, and constraints. Otherwise the team may optimize a rare annoyance while leaving the main bottleneck untouched.

An as-is process is a strong starting point for SOPs, training guides, onboarding materials, and system-change plans. It should not always be copied directly into documentation.

First decide whether the current process is acceptable. If it is the process the team wants people to follow, turn it into clear step-by-step documentation. If it contains known issues, use it as source material for a to-be process or improvement backlog.

A practical rule: document the current process when consistency is the main problem. Redesign the process when the current process itself is the problem. Teams get into trouble when they polish a broken process into a beautiful SOP.

Trails helps teams capture the as-is process as someone performs the work. Instead of reconstructing steps from memory, a team can record the workflow, turn it into a polished step-by-step guide, and create an AI-narrated video version for training or sharing. That makes it easier to compare the current process with the future process and decide what should be documented, improved, or removed.

Is an as-is process the same as a current-state process?

Yes. "As-is process" and "current-state process" usually refer to the same idea: how work happens today before improvement or redesign.

Should an as-is process include problems and workarounds?

Yes. Problems, delays, rework, and workarounds are often the most valuable part of the as-is view. They show where the process differs from the official version and where improvement may be needed.

When should you create an as-is process map?

Create one before redesigning a workflow, implementing a new tool, writing a major SOP, training a team on a changed process, or investigating why a process produces inconsistent outcomes.

Can an as-is process become an SOP?

Sometimes. If the current process is effective and the main need is consistency, it can become an SOP. If the current process is broken, use the as-is map to design a better to-be process first.