⏱ 22 min read
I’ve seen this mistake more times than I care to count.
A healthcare program team spends weeks refining what looks like a very solid patient discharge diagram. Operations is happy. Nursing leadership signs off. Product says it is clear. The flow looks clean: physician clears discharge, pharmacy reviews meds, nurse completes discharge education, transport is arranged, patient leaves, follow-up instructions are sent.
In the workshop, it looks excellent.
Then delivery begins, and the diagram starts letting everyone down.
Engineering reads “send discharge instructions” as a single system event coming out of the EHR. Integration assumes it includes outbound messages to the patient portal, PCP notification, and home health referral where needed. Compliance asks where medication reconciliation ownership is captured and how exceptions are handled when the attending physician signs late. Nursing asks who is actually on the hook when transport authorization is missing and the patient is medically ready but cannot leave. Nobody has a confident answer, because the diagram never made any of that explicit.
A month later, the symptoms start showing up in production planning. Duplicate notifications. Two teams each building their own trigger for patient communications. Ambiguity around medication reconciliation. No visible exception path for missing transport authorization. Audit trail gaps because the process diagram never separated manual completion from system-generated updates. Everyone says some version of the same thing: “But we aligned on the process.”
Maybe.
But not on the same process.
That’s the point.
The issue was not that the diagram was sloppy. It was actually a pretty good flowchart. The problem was that the team chose the wrong modeling language for an enterprise problem. They used a notation that is good at showing sequence and weak at showing accountability, events, timing, system boundaries, and exception handling.
That difference matters more than many teams realize.
Flowcharts are useful. Often faster. Sometimes exactly the right tool. I still use them constantly in early discovery because they help people talk, and getting people to talk is the first real job. But once a process crosses roles, systems, time boundaries, compliance obligations, and external parties, the conversation changes. At that point, the model has to do more than tell a coherent story. It has to define what must happen, by whom, and under what conditions.
That is where BPMN earns its reputation—when it actually deserves one.
Most teams are not really arguing about notation
They think they are.
What they are usually arguing about is operating precision.
Business stakeholders typically want speed, readability, and something they can react to in a workshop without needing a legend or a mini training session. Architects want traceability and explicit boundaries. Delivery teams want process semantics that can be tested, and ideally reused in automation design. Compliance wants evidence. Integration teams want to know where one participant stops and another starts. Security wants to understand who is acting under what authority, and whether IAM roles or service principals are actually represented in the model or simply implied and hand-waved away.
So the BPMN vs flowchart debate becomes a proxy war for all of that.
In enterprise settings, notation becomes governance by stealth. People ask for “just a simple process view” when what they really want is to postpone decisions about ownership, control points, exception rules, or system orchestration. Or they ask for BPMN because it sounds rigorous, when in reality what they need first is a rough current-state sketch and a difficult conversation about scope. BPMN training
I’ll say it plainly: a lot of “simple process diagrams” are unresolved architecture decisions wearing friendly shapes.
Healthcare makes this painfully obvious. Patient access, referrals, prior auth, discharge, claims, care coordination, consent management, lab escalation—these are not merely sequences of work. They are socio-technical processes. They involve humans, systems, timing windows, regulatory obligations, external organizations, and failure paths that are not edge cases at all. In many clinical and administrative workflows, the exceptions are the process. TOGAF training
That is why the notation choice matters. It shapes what the team is forced to clarify.
What each notation is actually good at
Let’s strip away the mythology for a minute.
Flowchart, without the romance
Flowcharts are great for rough ideation, local SOP visualization, onboarding aids, simple decision logic, and whiteboard alignment in early discovery. They are familiar. Fast. Nobody needs a training course to draw one. In a workshop with twenty people, a flowchart lowers the social barrier to participation. That is not a minor advantage. In my experience, it is often the difference between a useful discussion and a room full of polite silence.
I’m not anti-flowchart. Not even close.
A good flowchart can unlock process understanding faster than a formally correct BPMN model ever will in the first two sessions. BPMN and UML together
But flowcharts start to wobble when the team needs more than broad sequence. Roles are often implied rather than explicit. Event handling is informal. Asynchronous behavior gets flattened into simple arrows. Message exchange across systems or organizations turns into lines that look precise but really are not. The same symbol might represent a user action in one step, a policy decision in another, and a system event in the next.
That is usually when interpretation drift begins.
BPMN, minus the consultant gloss
BPMN is useful for cross-functional business processes, orchestration across teams and systems, exception-rich regulated workflows, automation handoff, and operational control design. Not because it is “fancier,” and not because enterprise architecture needs more notation for its own sake. It matters because BPMN gives semantics to participants, tasks, events, gateways, timing, and message exchange. free Sparx EA maturity assessment
That is the real difference.
A timer event is not just a note saying “follow up in 48 hours.” A message flow is not just an arrow crossing a page. A boundary event is not decorative notation. Those constructs force the team to answer practical questions: who is waiting, what starts the wait, what interrupts it, who receives what, which participant owns the next action, what happens if nothing arrives.
Teams resist BPMN for understandable reasons. It can feel heavy. Many people have seen over-modeled monstrosities—giant wall posters covered in gateways and tiny labels that nobody can read without zooming to 300%. Some architects treat BPMN like a purity sport. That has done real damage over the years. It makes business teams think BPMN itself is the problem, when often the real issue is poor modeling discipline.
A bad BPMN model is definitely worse than a good flowchart.
But a flowchart asked to carry enterprise-grade semantics is worse in a quieter way. It creates confidence without precision.
That’s dangerous.
A comparison table teams can actually use
Here’s the practical version.
The wrong choice is often not flowchart or BPMN.
It is pretending one artifact can serve every audience equally well.
That fantasy burns a lot of time.
In healthcare, the exceptions are the process
Take prior authorization. Almost every healthcare organization has some version of the same high-level flowchart:
- receive order
- submit authorization
- approve or deny
- schedule procedure
That is fine for a first conversation. It is not fine for architecture.
Because enterprise reality shows up immediately. Payer response is often asynchronous. Additional clinical documentation may be requested. Authorization can expire before the patient is scheduled. The patient may reschedule, which can affect validity windows. The service category may change, forcing resubmission. Urgent requests follow different timing rules. Different systems are involved: EHR, utilization management, scheduling, payer connectivity services, contact center CRM, maybe a document management platform for attachments. Identity matters too—who is acting as the submitting provider, what delegated permissions exist, which staff can amend the request, which messages are attributable for audit.
A flowchart usually collapses all of that into a couple of arrows and a denial branch.
But that simplification comes at a cost. It hides the real architecture problem.
BPMN helps because it can represent timer events for payer response windows, message flows between provider organization and payer, and explicit roles across utilization review nurse, scheduling coordinator, physician office, and integration services. It can show what happens when a request for additional documentation interrupts the original path. It can make expiration visible. It can show that “schedule procedure” is not one step but a conditional transition based on authorization state, service type, and date validity.
Here’s a deliberately simplified sketch:
That is usually where a flowchart stops.
The enterprise version needs to distinguish provider, payer, scheduling, patient communication, and system events. It needs to account for response timers, resubmission triggers, and exception ownership. In BPMN, those are not side notes. They are part of the process definition.
And in my experience, if your process has to survive reality rather than merely explain intent, BPMN usually earns its keep.
The audience question changes everything
This is where architects get themselves into trouble.
We fall in love with the “right” model and forget the “right for whom” question.
A discovery workshop artifact is not the same thing as an executive communication artifact. A control design artifact is different from a delivery handoff artifact. An automation-ready model is different again. Training material has its own needs entirely.
I’ve seen teams burn weeks perfecting BPMN before they even agreed on scope. That is one kind of waste.
I’ve also seen organizations keep polishing the same swimlane flowchart long after it was obvious the process involved external events, asynchronous integration, exception handling, and compliance controls. That waste is more expensive because it often makes it all the way into implementation.
My default pattern is simple:
Start rough.
Use plain language.
Get the story out.
Then identify actors, triggers, events, failure cases, and system boundaries.
Only promote to BPMN when the process needs shared precision.
That threshold comes sooner than many teams expect.
Flowcharts hide accountability at exactly the wrong time
Consider emergency department to inpatient admission handoff. ArchiMate in TOGAF
The typical flowchart is deceptively clean:
- patient assessed
- admit decision made
- bed requested
- patient transferred
Everyone nods.
But the architecture questions are where delivery actually lives. Who triggers bed management? Which system is the source of truth for admission status—the EHR, ADT platform, bed management system, or some package-specific workflow module? What event starts transport orchestration? What happens if there is no bed assignment within the SLA? Who reconciles clinical handoff completeness? How do alerts propagate across care team systems, secure messaging, and operational dashboards? What happens during downtime procedures when one system is unavailable? If Kafka is used as the event backbone, which service owns the admission-confirmed event and what is the idempotency strategy when downstream consumers receive duplicates?
A plain flowchart does not naturally force those answers.
BPMN does a better job because it separates participants clearly. It distinguishes user tasks, service tasks, and message events. It supports escalation and timeout logic. You can show, for example, that bed assignment delay triggers an escalation event to the house supervisor after a timer threshold. You can make the handoff completion criteria explicit rather than assumed.
That matters because unresolved ownership does not stay on the page. It becomes operational friction. Nurses chase bed status. The contact center gets inconsistent updates. Reporting shows transfer delays but nobody agrees on where they started. Integration teams create compensating logic in interfaces because process accountability was never clarified upstream.
The ambiguity migrates into operations.
It always does.
The mistakes teams repeat constantly
Some of these are almost industry traditions at this point.
Common BPMN mistakes
The biggest one is over-modeling. Teams capture every micro-step, every click, every tiny branch, and produce unreadable wall posters. Nobody uses them except the architect who made them, and even they stop looking after a month.
Another is treating BPMN as a compliance artifact only. That misses the point. BPMN should support understanding, design, and execution thinking, not just audit evidence. I also see models with formally correct notation and terrible naming. “Process request” is not a useful task name. Neither is “Handle exception.” If the labels are vague, the semantics will not save you.
A subtle but damaging mistake is ignoring message flows and collapsing all actors into one lane because “it’s easier to read.” It may be easier to read in the moment, but it erases the interaction boundaries that matter most in enterprise delivery. And then there is the classic happy-path model that pretends exceptions are edge cases. In healthcare, they often are not. Prior auth, claims denial, lab escalation, discharge, referral triage—the difficult cases are common enough to define the process.
Also, don’t let tooling dictate design. If your BPM platform or process repository makes one pattern easier to draw, that does not mean the business process actually works that way.
Common flowchart mistakes
Flowcharts fail in more casual ways. Teams mix business steps, system behavior, and policy decisions at the same level. Arrows imply responsibility without naming it. There is no distinction between synchronous and asynchronous actions. Endless diamonds conceal rules complexity that should be stated somewhere else. Swimlanes are used and someone says, “This is basically BPMN.”
No, it isn’t.
Swimlanes help. They do not add event semantics, message semantics, or execution clarity by themselves.
The most expensive flowchart mistake is publishing a discovery diagram as if it were implementation-ready. That is how hidden assumptions become code.
Here’s the smell I watch for: if two delivery teams can read the same diagram and build different solutions, the model is under-specified for its purpose.
That test is brutally effective.
The integration angle most articles miss
Enterprises run on handoffs, not boxes.
That is especially true in healthcare. The process lives across EHR, portal, CRM/contact center, integration engine, payer connectivity services, scheduling platform, document management, IAM, analytics, and whatever legacy scheduling or order management tool nobody was allowed to retire.
Flowcharts struggle once the process crosses system boundaries because they do not naturally distinguish between control flow inside one participant and message exchange across participants. Everything becomes an arrow. But architecturally, those arrows are very different things.
A control flow says what happens next inside a participant context. A message flow says one participant informs or requests action from another. If you blur those, you blur ownership, retry behavior, observability, and failure handling.
Take a discharge scenario. The discharge summary is completed in the EHR. A message is sent to the primary care provider. Patient instructions are published to the portal. A home health referral is triggered. If no PCP acknowledgment is received within a window, a follow-up task is created for care coordination.
That is not one arrow chain.
It is event ownership, message exchange, and timeout logic across systems and organizations. If Kafka is in the mix, now we care about event publication responsibility, schema contracts, replay behavior, duplicate message handling, and consumer lag. If IAM is well-designed, service-to-service authorization and user-attributed actions should align with process ownership. If they do not, your audit trail becomes a reconstruction exercise after the fact.
This is why I’m opinionated here: once systems start talking asynchronously, a plain flowchart becomes a polite lie.
Useful at first. Misleading soon after.
A practical decision guide
Not a framework. Just a guide.
Use a flowchart when
You are in early discovery.
The process is local to one team.
You need simple training material.
It is a temporary workshop artifact.
The risk is low, exceptions are few, and system interaction is minimal.
Use BPMN when
The process spans multiple roles.
It is regulated.
Timers, events, or asynchronous behavior matter.
It crosses organizational boundaries.
It is a candidate for automation.
Exception handling is non-trivial.
Auditability, controls, or SLAs are part of the design.
Use both when
You need stakeholder onboarding and delivery precision. In practice, this is common and healthy. Use a flowchart or simplified operational view to bring people in. Use BPMN for architecture and delivery precision. Keep them intentionally separate, and define which one is authoritative for which decision.
That last part matters. If the flowchart is for orientation and the BPMN model is the delivery reference, say so explicitly.
Otherwise people will cherry-pick the simpler artifact when things get uncomfortable.
The transition from operations sketch to executable logic is where programs stumble
Outpatient referrals are a classic example.
The intake team often begins with a reasonable flowchart for triage: referral received, review completeness, prioritize urgency, schedule or request more information. Fine.
Then the operating model scales. Referrals arrive by fax, portal, EHR, and partner clinics. Urgency categories vary. Incomplete referrals need follow-up. Specialist capacity matters. No-show history influences pathing. Insurance constraints affect scheduling options. Patient communication preferences matter. Different clinics have different intake rules. The reporting team needs status categories that line up with actual operational states.
What usually happens in delivery is predictable. Developers encode hidden rules from workshops. Operations assumes some manual exceptions remain in scope. Product thinks the workflow engine will “mostly follow the diagram.” Reporting cannot reconcile statuses because the process steps in the flowchart were not semantically defined.
Then the blame starts.
BPMN would not magically fix bad governance, but it would improve the handoff. You can model gateways for referral completeness and urgency, message events for external requests, timer events for follow-up windows, and clear lane ownership between intake, specialty clinic, scheduling, and patient communications. You can tie process states to measurable events. You can define what is waiting, what is escalated, and what is considered complete.
A simple illustration:
Again, good enough for conversation. Not enough for delivery if the process is becoming operationally critical.
The lesson is blunt: if implementation teams must infer process semantics, they will invent them.
And once invented, those semantics become expensive to unwind.
Not everything should become BPMN
A useful counterweight.
Some architects reach for BPMN because it feels rigorous, not because the problem requires it. I’ve done this myself earlier in my career. It is an easy trap, especially when you want to show discipline in a messy environment.
But BPMN is overkill for team-level desktop procedures, simple support triage with no automation ambition, executive narrative decks, and one-time transformation workshops where the goal is alignment rather than operational precision. In those cases, forcing BPMN slows momentum, intimidates stakeholders, and can create false confidence. A technically correct model that has not been operationally validated is still a bad artifact.
Proportionality matters.
The model should fit the risk carried by the process.
How I’d handle this in an enterprise architecture engagement
I don’t start with notation. I start with failure.
What goes wrong today? Where are the delays, the rework loops, the ownership disputes, the missed communications, the audit issues, the patient harm or operational risk points? That gives the process model a reason to exist.
Then I capture current-state flow in plain language. Not polished. Just enough to expose the path.
Next I identify actors, systems, triggers, business outcomes, and control points. In healthcare I also check for clinical safety implications, regulatory obligations, patient communication timing, and downtime/manual fallback procedures. A process that works beautifully in the happy path and collapses during downtime is not an enterprise design. It is a demo.
Before future-state modeling, I pull out exception scenarios. Missing consent. Duplicate referral. Payer timeout. Home health agency rejects referral. Lab result not acknowledged. Transport unavailable. Identity mismatch in portal. These should come before the polished design, not after.
Then I decide whether the process needs BPMN precision. Sometimes it doesn’t. When it does, I create layered views:
- an executive summary view
- an operational BPMN view
- an integration and event view
- linkage to capability maps, ownership, and backlog items
That layered approach matters. One diagram should not be asked to do every job.
And I validate the model against real cases, not workshop optimism. We walk through actual scenarios. Friday evening discharge. Expired authorization. PCP not in directory. Kafka consumer down. IAM token expired for a service account. Contact center opens a case while the nurse is still in progress. If the model breaks under those cases, the problem is usually not the notation. It is the process design.
Governance implications
This is not just a preference about diagrams.
The process model choice affects solution scope clarity, vendor package evaluation, workflow automation feasibility, control design, integration contracts, test case completeness, KPI design, and operational ownership. If you model a cross-functional regulated process as a simple flowchart, you may still get through architecture review, but you are pushing ambiguity downstream into delivery and operations.
My recommendation is straightforward: define a modeling standard by use case, not as a universal mandate.
For example:
- flowcharts allowed for ideation, discovery, and local SOPs
- BPMN required for cross-functional regulated workflows and automation-target processes
That policy is a lot healthier than demanding BPMN everywhere. I’ve watched architecture review boards do exactly that, then never read the BPMN artifacts they requested. That is governance theater, and people can smell it.
Why business teams say BPMN is too complicated
Sometimes they are right.
Sometimes they have only seen terrible BPMN.
And sometimes the process itself is complicated, and BPMN is merely revealing that fact. That can be uncomfortable because a simple diagram is often emotionally reassuring. It makes the organization feel more coherent than it really is.
Clarity is not the same as simplicity.
A few tactics help. Limit the symbol palette. Use naming conventions. Separate overview from detail. Model only decision-relevant detail. Review using real scenarios instead of notation lectures. In most organizations, business stakeholders do not need to become BPMN experts. They need enough familiarity to challenge the model intelligently.
That is a much lower bar.
A few healthcare field notes
Medication refill approval: flowcharts help explain the broad sequence to clinicians and pharmacy operations. BPMN becomes useful when refill eligibility, provider delegation, formulary checks, patient outreach, and escalation for controlled substances need explicit handling.
Lab result escalation: a flowchart is enough to show normal review flow. BPMN becomes necessary when critical values, acknowledgment windows, on-call routing, message retries, and escalation timers come into play.
Claims denial rework: flowcharts help train revenue cycle teams on common paths. BPMN is better when denial categories trigger different rework routes, document requests, payer interactions, and aging thresholds.
Care transition to post-acute providers: a flowchart can explain the high-level handoff. BPMN matters when referral acceptance, bed availability, discharge timing, transportation, acknowledgment, and patient-family communication span multiple organizations.
Consent management across channels: flowchart for basic education. BPMN when consent capture occurs in portal, registration, contact center, and bedside workflows with revocation events and policy-driven downstream impact.
Telehealth appointment exception handling: flowchart for standard booking. BPMN when device readiness, identity verification, payer eligibility, no-show logic, interpreter coordination, and fallback to phone visit must be orchestrated.
The pattern is consistent. Flowcharts help teams think. BPMN helps enterprises agree, build, govern, and improve.
Final thought
The real question is not which notation is better.
It is how much ambiguity the process can safely tolerate.
For low-risk, local, mostly linear work, flowcharts are often the right answer. They are fast, democratic, and useful. But in regulated, multi-system, patient-impacting workflows, ambiguity is rarely cheap. It shows up later as duplicated integrations, unresolved ownership, missing controls, weak observability, test gaps, and operational friction that nobody can quite trace back to the original diagram.
I’ve seen enough of these programs now to be fairly firm on this: if the process crosses roles, systems, time boundaries, and compliance obligations, a flowchart may start the conversation, but BPMN usually finishes it.
FAQ
Is BPMN only useful if we plan to automate the process?
No. Automation is one reason, but not the only one. BPMN is also useful when you need shared precision across teams, explicit control points, clear ownership, and better handling of exceptions and timing. Even if the process remains mostly manual, the semantics can still reduce ambiguity.
Are swimlane flowcharts enough for most enterprise processes?
For some, yes. For many, no. Swimlanes improve visibility of roles, but they do not give you the event, message, and exception semantics that BPMN does. They are often a good intermediate artifact, not a full substitute.
How much BPMN should business stakeholders really learn?
Usually not much. Standardize on a small subset: start/end events, tasks, gateways, lanes, message flows, timer events, and maybe boundary events. That is enough for many enterprise process discussions without turning every workshop into notation training.
Can one process have both a flowchart and a BPMN model without creating confusion?
Absolutely. In fact, that is often the best approach. Just define purpose clearly. One artifact for orientation and communication. Another for authoritative design and delivery precision.
What is the minimum BPMN subset a healthcare architecture team should standardize on?
I’d keep it tight: pools, lanes, start/end events, user tasks, service tasks, exclusive gateways, timer events, message flows, and a small number of escalation or error patterns. More important than breadth is consistency. A limited, disciplined BPMN style beats a comprehensive but chaotic one every time.
Frequently Asked Questions
What is BPMN used for?
BPMN (Business Process Model and Notation) is used to document and communicate business processes. It provides a standardised visual notation for process flows, decisions, events, and roles — used by both business analysts and systems architects.
What are the most important BPMN elements to learn first?
Start with: Tasks (what happens), Gateways (decisions and parallelism), Events (start, intermediate, end), Sequence Flows (order), and Pools/Lanes (responsibility boundaries). These cover 90% of real-world process models.
How does BPMN relate to ArchiMate?
BPMN models the detail of individual business processes; ArchiMate models the broader enterprise context — capabilities, applications supporting processes, and technology infrastructure. In Sparx EA, BPMN processes can be linked to ArchiMate elements for full traceability.