Conducting a Gap Analysis: Bridging the Old and the New
“We’ve mapped the old process and the new one — now what?” That’s the most common question I hear in the early stages of BPR. It’s not a bad question. But it’s often the sign that teams have skipped the most critical step: the real work of comparing those two models to uncover where the actual friction lies.
Too many teams treat the as-is and to-be models as separate documents. But the power lies not in their existence — it’s in their confrontation. That’s where BPR gap analysis begins.
As someone who’s guided over 60 process re-engineering initiatives across finance, healthcare, and logistics, I’ve learned this: the real transformation happens in the space between what is and what could be. That’s the gap — and it’s where you’ll find the root of inefficiencies, outdated dependencies, and hidden risks.
In this chapter, you’ll learn how to conduct a rigorous gap analysis that goes beyond surface-level differences. You’ll see how to identify missing tasks, redundant steps, and broken system integrations using structured comparison techniques. And you’ll learn how to visualize and prioritize these gaps in a way that’s actionable for your implementation team.
Why BPR Gap Analysis Matters
Without a proper gap analysis, your to-be model becomes a wish list, not a plan.
Even the most elegant redesign fails if it doesn’t account for real-world constraints — legacy systems that won’t be replaced overnight, teams resistant to change, or critical handoffs that weren’t captured in the as-is model.
BPR gap analysis is your diagnostic tool. It answers: What’s missing? What’s duplicated? What’s broken? And most importantly: What must change before we can implement the new process?
Think of it like a structural inspection of your process blueprint. You don’t just check if the roof is intact — you look for cracks, weak supports, and signs of water damage. The same applies to workflows.
The Core of As-Is vs To-Be Comparison
The as-is model reflects reality — warts and all. The to-be model reflects vision — clean, streamlined, efficient. But between them lies a chasm of expectations, assumptions, and unverified changes.
Comparing the two isn’t about spotting differences. It’s about analyzing their impact.
Ask yourself: Does every step in the to-be process have a corresponding trigger or input in the as-is model? Are critical decision points missing? Is there a handoff that no longer exists in the new flow?
These are the red flags a structured gap analysis uncovers.
Key Areas to Evaluate in Your Gap Analysis
Not all gaps are created equal. Focus on these four key dimensions when conducting your as-is vs to-be comparison:
- Task Gap Identification: Are any steps missing in the to-be model? Are there tasks in the as-is that no longer serve a purpose?
- Performance Gap: Are cycle times, error rates, or resource usage still inconsistent with the new design?
- System Dependency Gap: Are there systems in the as-is model that no longer align with the to-be flow? Are outdated integrations still in place?
- Stakeholder Alignment Gap: Are roles or responsibilities missing? Are key decision-makers or support teams unaccounted for in the new model?
Each gap must be evaluated for severity and risk. A missing approval step might be a minor oversight. A missing system integration could derail the entire rollout.
Practical Methods for Conducting BPR Gap Analysis
There’s no single way to conduct a gap analysis. But these four proven approaches work across industries and complexity levels.
1. Side-by-Side Visual Comparison
Place your as-is and to-be models side by side in your modeling tool. Use color-coding to highlight:
- Green: Items present in both models — unchanged.
- Red: Items present in as-is but missing in to-be — potential gap.
- Blue: Items present in to-be but absent in as-is — potential innovation.
- Orange: Items with modified logic or sequence — requires review.
This method is fast and visual. It’s ideal for small to medium processes. For larger workflows, use the next approach.
2. Matrix-Based Gap Grid
Create a table that maps every process step in the as-is model against the to-be model. List each step and mark its status:
| As-Is Step | To-Be Step | Gap Status | Notes |
|---|---|---|---|
| Submit invoice | Auto-generate invoice | Red (missing in to-be) | Auto-generation requires new system integration |
| Approve by finance | Approve by system | Orange (logic changed) | Approval now automated; manual override needed |
Use this to track gaps by type, urgency, and responsible team. It’s especially useful when presenting findings to leadership or cross-functional teams.
3. Decision Table Modeling for Complex Logic
When your process involves conditional decisions (e.g., “If invoice amount > $10k, require dual approval”), use a decision table to compare logic between models.
Here’s a real-world example from a finance team I worked with:
| Condition | As-Is Action | To-Be Action | Gap? |
|---|---|---|---|
| Amount ≤ $5k | Single approval | Single approval | No |
| $5k < Amount ≤ $10k | Double approval | Single approval | Yes — risks oversight |
| Amount > $10k | Double approval | Auto-escalate to CFO | Yes — logic change not fully validated |
This exposed a major risk: the new model reduced oversight for mid-tier invoices. We added a conditional review step to mitigate it.
4. Stakeholder Impact Mapping
Not all gaps are procedural. Some are human. Map how each gap affects stakeholders:
- Who will be affected? Is it a new role? A changed workload?
- What’s the impact? Increased workload? Loss of control? New skill requirement?
- How can it be mitigated? Training? Temporary support? Role clarification?
Example: In a hospital BPR project, the to-be model removed the nurse’s manual chart update step. But the gap analysis revealed that nurses would lose visibility into patient status changes. We added a dashboard notification feature instead.
Turning Gaps into Actionable Items
Identifying a gap is only half the battle. The real work is turning it into a project task.
Use this simple framework to convert each gap into a project item:
- Describe the gap: “The to-be model lacks a step for system validation after data migration.”
- Assign severity: High (could break process upon rollout).
- Define the fix: Add a validation step in the to-be model.
- Assign ownership: IT team lead, process owner.
- Set deadline: 10 days before pilot.
Integrate this into your Work Breakdown Structure (WBS) — the next step in your BPR journey.
Common Pitfalls in Gap Analysis
Even experienced teams make these mistakes. Avoid them:
- Overlooking implicit dependencies: Not every handoff is explicit. A decision might rely on a report that no longer exists.
- Assuming change is only procedural: People, roles, and systems often need change too.
- Ignoring the ‘why’ behind changes: Why was a step removed? Was it truly inefficient, or was it a shortcut to avoid a bottleneck?
- Treating gaps as problems to fix, not opportunities to optimize: Some gaps reveal better ways to design the process — not just fix the old one.
Remember: The goal isn’t to eliminate every difference. It’s to understand them — and decide which ones are acceptable.
Frequently Asked Questions
How do I handle gaps that require system changes not in scope?
If a gap points to a system upgrade or integration beyond the current project scope, flag it as a dependency. Document it clearly and escalate to IT leadership. Include it in the roadmap, but don’t let it block the to-be model.
Should I conduct gap analysis before or after finalizing the to-be model?
Always conduct it after the to-be model is stable. But don’t wait until the end. Run preliminary comparisons during design to catch issues early.
What if the as-is and to-be models are very different?
That’s expected. The entire point of BPR is to disrupt old patterns. But use the gap analysis to ensure the new design isn’t just “different” — it’s better. Ask: Does it reduce risk? Improve speed? Increase accuracy?
How do I prioritize which gap to fix first?
Use a risk-impact matrix. Score each gap on two axes: business impact (high, medium, low) and implementation difficulty. High impact + low difficulty = top priority.
Can I skip gap analysis if the to-be model is simple?
No. Even simple processes hide complexity. A small gap in a high-volume workflow can cause massive delays. Always validate — never assume.
Summary
Conducting a BPR gap analysis isn’t an afterthought. It’s the bridge between vision and execution.
By systematically comparing the as-is and to-be models, you uncover hidden risks, redundant steps, and system dependencies that could derail your initiative.
Use visual comparison, decision tables, and stakeholder mapping to turn every gap into a clear, actionable task.
Remember: Efficiency isn’t just about design. It’s about knowing where your process truly stands — and having the courage to fix it.
Now you’re ready to move into the next stage: turning these insights into a real project plan. The work has only just begun.
