No single source usually tells the whole truth about a business process. The SOP describes the approved procedure, the spreadsheet contains operational fields and routing codes, and interviews reveal what people actually do. Building a Visio swimlane from only one of them creates a partial—and sometimes misleading—picture.
The better approach is evidence reconciliation: extract process elements from every source, record where they agree or conflict, resolve material gaps, and only then generate the diagram.
What each source contributes
| Source | Usually strongest for | Common weakness |
|---|---|---|
| SOP or policy | Approved sequence, controls, formal roles | May be outdated or too high-level |
| Excel/CSV | IDs, statuses, routing rules, system fields | Context and exceptions may be missing |
| Interview or meeting | Actual behavior, workarounds, tacit knowledge | Memory can be incomplete or subjective |
Treating one source as automatically correct wastes the value of the other two. Instead, declare which source is authoritative for each type of fact.
Build a source-of-truth policy
Before diagramming, define resolution rules such as:
- the SOP controls mandatory approvals and compliance steps;
- the system export controls valid status values and routing codes;
- process owners confirm current responsibility and undocumented exceptions;
- unresolved conflicts remain visible and are not silently guessed.
This policy makes review consistent. It also explains why a diagram differs from one of its inputs.
A multi-source diagram workflow
1. Normalize names and identifiers
Map alternate names to canonical terms: “Ops,” “Operations,” and “Back Office” may refer to the same team. Match spreadsheet step IDs to document headings when possible. Preserve source-specific names in notes for traceability.
2. Extract evidence independently
Do not merge the sources immediately. First create separate lists of steps, owners, decisions, inputs, outputs, exceptions, and systems. This prevents a dominant source from hiding useful differences.
3. Create a conflict table
| Process element | SOP says | Spreadsheet says | Interview says | Resolution |
|---|---|---|---|---|
| Approval owner | Manager | Role code M2 | Team lead | Confirm with process owner |
| Rejection route | Return to requester | Status = CLOSED | Rework occurs | Update policy or diagram note |
Prioritize conflicts that change sequence, control ownership, or risk. Cosmetic naming differences can be normalized later.
4. Review a unified plan
Upload the sources to VSDXAI and ask for a consolidated, evidence-linked plan before generating the swimlane.
Build a current-state cross-functional process from the attached SOP, spreadsheet, and interview transcript. Extract each source separately, then reconcile them using this priority: SOP for mandatory controls, spreadsheet for valid fields and codes, interview for current execution and exceptions. For every step, record its supporting source. Flag conflicts, missing owners, and unsupported transitions. Do not invent a resolution. Generate the swimlane only after the consolidated plan is approved.
5. Generate the VSDX and maintain lineage
Use one lane per accountable role—not one lane per speaker or system. Add systems as annotations or dedicated lanes only when system behavior is a real participant in the process. Export an editable .vsdx and retain the source set, review decisions, and version date.
VSDXAI is useful here because the workflow can preserve an evidence graph and reviewable plan instead of collapsing all inputs into an unexplained picture.
How to handle unresolved discrepancies
Not every conflict can be settled in one workshop. Use one of three treatments:
- Block publication: for compliance controls, financial approval, safety, or legal obligations.
- Mark as provisional: for an owner or threshold awaiting confirmation.
- Show a variant: when two regions or customer types legitimately use different paths.
Never choose the most convenient version simply to make the diagram cleaner.
Review checklist
- [ ] Authority rules are defined by fact type.
- [ ] Names and role synonyms are normalized.
- [ ] Each important step has a source reference.
- [ ] Conflicts affecting sequence or control are resolved or flagged.
- [ ] Current practice is distinguished from approved policy.
- [ ] Variants are shown intentionally, not merged accidentally.
- [ ] The swimlane owner represents accountability.
- [ ] The native VSDX is editable and versioned.
FAQ
Which source should win when the SOP and interview disagree?
That is a governance decision, not an AI decision. The SOP may be authoritative for what must happen, while the interview reveals a control gap in what does happen. Often both belong in an as-is/to-be comparison.
How many inputs can one diagram use?
Use as many as needed for the defined process scope, but keep a source register. If several files repeat the same type of evidence, identify the latest approved version before extraction.
Should systems have their own swimlanes?
Only when the system performs autonomous steps or its behavior must be distinguished from human work. Otherwise, attach the system name to the activity to avoid excessive lanes.
When the sources disagree, the goal is not to hide the disagreement—it is to turn it into a reviewable decision. Build your next evidence-backed Visio swimlane at VSDXAI.
Top comments (0)