Mapping the As-Is Process (BPD): Seeing Reality Clearly

Never assume your team is aligned on how work actually gets done. The single greatest threat to successful re-engineering isn’t complexity—it’s the illusion of understanding. I’ve seen teams skip documenting the as-is process only to redesign a flow that never existed in reality. That’s how re-engineering fails before it begins.

As-is process mapping isn’t about updating paperwork. It’s about capturing the actual, lived workflow—every handoff, delay, and bypass. The goal is clarity, not perfection. You’re not building a report. You’re constructing a foundation. If your model doesn’t reflect how work flows in practice, every decision downstream is based on fiction.

When I lead BPR initiatives, I start with a simple rule: every process must be validated by the people who perform it. Not by the manager who assumes it. Not by a consultant who reverse-engineers a flowchart. The real work happens in the room with the front-line staff. This chapter walks you through how to gather that reality, document it with BPMN, and confirm it’s accurate before you even consider change.

Why the As-Is Model Is Your Most Important Artifact

Before you can redesign anything, you must see it clearly. The as-is process diagram is not a formality. It’s the diagnostic tool that reveals where time is lost, where bottlenecks hide, and where people are improvising.

It’s the only way to distinguish between the process as imagined and the process as practiced. Too many organizations skip this step and jump straight to “improvement.” That’s like prescribing medicine before diagnosing the illness.

Visualizing the as-is process with BPMN provides a standardized, universally understood language. It’s not about aesthetics—it’s about precision. Every decision, every condition, every delay must be accounted for.

Here’s what happens when you skip this:

• Redesign decisions are based on assumptions, not reality
• Teams reject the new model because it doesn’t match their daily work
• Improvements fail because they were built on a flawed foundation
• Time and money are wasted on a re-engineering effort that never lands

Step-by-Step: Documenting the Existing Process

1. Identify the Process Boundary

Start by defining the start and end of the process. What triggers it? What marks completion? Be specific. A customer order is not “started” when a sales rep writes a quote—it’s when the order is confirmed and approved.

Ask: What are the input and output? Who owns the process? What system data is involved? These answers form your process boundary.

2. Gather Existing Documentation and Interviews

Collect every piece of evidence: forms, emails, system logs, policy manuals. Then schedule interviews with 4–6 team members who touch the process—front-line staff, supervisors, support teams.

Ask: “Walk me through what happens when a customer places an order.” Don’t ask, “Do you follow the procedure?” You want workflow, not compliance.

3. Use BPMN to Model the As-Is Flow

Build the diagram using BPMN in Visual Paradigm. Start with the event, then swimlanes for roles, and connect every task with sequence flows.

Use standard symbols:

• Start event: Circle with a dot (trigger)
• Task: Rounded rectangle (work unit)
• Gateway: Diamond (decision point)
• End event: Circle with a dot inside (completion)

Don’t rush to make it pretty. Make it accurate. If a task is done manually via email, represent it. If a decision is made informally, show it. The model must reflect reality, not idealized flow.

4. Validate with the Team

Share the draft BPMN as-is model in a workshop. Don’t present it as a finished product. Say: “This is what we heard from your team. Does this match how you actually work?”

Be ready for corrections. People will say: “That’s not how it happens.” That’s not a failure—it’s data. Update the model. Repeat until no one objects.

5. Flag Redundancies, Delays, and Gaps

Now, analyze the process. Use the model to identify:

• Tasks repeated across departments
• Manual handoffs that cause delays
• Decision loops with no clear owner
• Unplanned rework due to poor input quality

These are not just inefficiencies—they are signals. The process is not broken; it’s *designed* to be inefficient.

Common Pitfalls in As-Is Mapping

Here are the errors I see most often—and how to avoid them.

Mistake	Why It Breaks	Solution
Only interviewing managers	Managers see the process as it should be, not as it is.	Interview front-line workers first.
Using vague labels like “approve” or “review”	Creates ambiguity and untraceable decisions.	Specify: Who? What? By when? With what criteria?
Ignoring informal workarounds	Bypasses in the process hide the real inefficiencies.	Ask: “What happens if the system is down?”
Skipping validation with the team	Model becomes a compliance artifact, not a living document.	Host a workshop. Use whiteboards. Let people draw.

Real-World Example: Order Fulfillment in a Retail Firm

Let’s walk through a real example from a mid-sized e-commerce company.

They believed their order fulfillment process took 24 hours. The as-is BPMN model revealed:

• 3 separate approvals needed: Sales → Finance → Logistics
• Each approval took 4–8 hours due to email dependency
• Finance often requested missing data, causing rework
• 12% of orders were delayed due to missing contact info

When we mapped the as-is process, we found the real cycle time was 72 hours—not 24. The “as-is” model exposed a hidden bottleneck: no standardized data collection form. The fix wasn’t automation—it was data governance.

When You’re Done: The Power of the BPMN As-Is Model

The as-is model is not a deliverable. It’s a catalyst. It’s where you discover that:

• Work isn’t flowing—it’s being held up
• People are doing the same task twice
• Decisions are made in the dark

This is where re-engineering begins. You don’t fix processes based on how they should be. You fix them based on how they are.

Once the as-is model is validated, you have a shared truth. You can now ask: “How can we eliminate this step?” “Can we automate this handoff?” “Can we merge these approvals?”

The model becomes the common language. When you move to the to-be design, you’re not guessing. You’re solving real problems.

Frequently Asked Questions

Why should I use BPMN instead of a simple flowchart?

BPMN provides a standardized, unambiguous way to document processes. It includes semantics for events, tasks, gateways, and data flows that prevent misinterpretation. It’s easier for stakeholders across IT, operations, and compliance to understand and validate.

How do I ensure the as-is model reflects actual behavior, not idealized process?

Interview people who perform the work—not just supervisors. Observe workflows in real time. Ask, “What usually happens?” and “What do you do when the system fails?” Use the model to capture exceptions, not just the expected path.

Can I use Visual Paradigm to document existing process without prior BPMN training?

Yes. Visual Paradigm has a guided BPMN modeling interface with templates, drag-and-drop tools, and real-time validation. It enforces syntax rules and helps you avoid common modeling errors. The learning curve is shallow—most teams produce a usable as-is model in one workshop.

How many interviews should I conduct for accurate as-is mapping?

Start with 4–6 key stakeholders who touch the process. You don’t need a large sample—just enough to capture the full journey. If multiple roles are involved, include one representative per swimlane. Revisit the model after initial feedback.

What if the team disagrees on how the process works?

That’s normal. Use the model as a discussion tool. Present the draft and say: “We’re trying to capture how work really happens. Where does this not match your experience?” Document all variations. The goal is to show the actual workflow—not force consensus.

How do I handle processes that are documented but never followed?

That’s a red flag. If the process is outdated or ignored, the as-is model must show the actual steps—even if they’re informal. Use dashed lines or annotations to mark deviations: “This step is done via email because the system is down.” The model should reflect reality, not policy.

Understanding the as-is process isn’t about compliance. It’s about truth. And truth is the only foundation for real change.