A dashboard is a presentation layer. It renders whatever the underlying systems agree to give it. If those systems don't agree on what an entity is, what state it's in, who owns it, or what depends on it, no amount of dashboard design fixes that — it just displays the disagreement faster and in more colors.
This shows up clearly in pharmaceutical supply chains, where operational data typically lives across an ERP, a planning system, a QMS, sometimes a LIMS, a CDMO or CMO portal, warehouse and inventory systems, logistics data, commercial demand feeds, a BI/reporting layer, and realistically a handful of spreadsheets filling the gaps. Not every organization runs all of these, but most run enough of them that integration is a real architecture problem, not a reporting problem.
The core issue is that an ERP can hold perfectly accurate transaction records while the organization still lacks enough context to make a timely decision. Those are two different capabilities, and conflating them is where a lot of "we need better visibility" initiatives go sideways.
Transaction data versus decision context
Consider a transaction record:
Batch: B2147
Status: Manufacturing
That's accurate, and it's also close to useless for a supply decision on its own. Making a decision about that batch requires assembling additional context: which product and site or CDMO it belongs to, the expected and originally committed completion dates, the current milestone and its variance from plan, any open material dependency, any unresolved quality exception, whether release depends on something still pending, what inventory position it affects, which demand commitment is exposed if it slips, who owns the next action, and what that action actually is.
None of that lives in the transaction record. It has to be assembled from multiple sources and linked to the batch as a specific entity. This is the gap most "visibility" projects actually need to close, and it's a modeling problem before it's a UI problem.
A conceptual entity model
A workable domain model for this space needs entities that map to real operational concepts, not just database tables mirroring each source system:
- Product — what is being manufactured
- Batch — a specific production run of a product
- Site / External Manufacturer — where the batch is being made
- Demand Requirement — what commercial or clinical need this batch is meant to satisfy
- Supply Commitment — the planned fulfillment of that requirement
- Inventory Position — current and projected stock, tied to product and site
- Milestone — a specific point in the batch's production lifecycle
- Quality Status — release-readiness state, tied to batch
- Exception — a deviation from plan that requires attention
- Decision — a specific choice made in response to an exception
- Owner — the person or role accountable for a decision
The relationships matter more than the list. A Batch has many Milestones. A Milestone variance can trigger an Exception. An Exception is linked to whichever Supply Commitment and Inventory Position it threatens. A Decision resolves an Exception and is tied to an Owner. Modeling it this way means a query like "what open exceptions threaten Q3 supply commitments for Product X" is a traversal of the graph, not a manual cross-reference across five spreadsheets.
State modeling beats a generic status field
A single status field tends to get overloaded fast — "Manufacturing" might mean on schedule, might mean stalled waiting on a material, might mean past its committed date with nobody flagging it. A more useful model separates the current state from whether that state is on track.
An illustrative state sequence, not an industry standard:
*Planned → Scheduled → In Execution → Awaiting Dependency → Completed → Released
*
Pairing state with a variance flag and a dependency reference (what it's waiting on, and since when) turns "Manufacturing" into something queryable: how long has this batch actually been in this state relative to plan, and what is it blocked on, if anything.
Event-driven propagation
A useful way to think about how a change should ripple through the system:
CDMO milestone changes
→ supply commitment recalculated
→ projected inventory position updated
→ exception created if impact exceeds threshold
→ owner notified
→ human decision recorded
This can be implemented with an event bus, a scheduled synchronization job, a workflow engine, or plain API polling the pattern matters more than the specific stack. What matters architecturally is that a milestone change is treated as an event with downstream consequences to propagate, rather than a value that just gets overwritten in place with no record of what it affected.
Exception architecture, not alert-everything
Not every data change deserves an alert. A milestone shifting by a day inside normal variance is different from a shift that pushes a batch past a committed release date with an inventory impact. Useful exception logic needs thresholds and business rules (how much variance actually matters, and for which entity types), severity and ownership (who is notified, and how urgently), and suppression or deduplication (so the same underlying issue doesn't generate five alerts from five source systems). Skipping this design step is how teams end up with alert volume high enough that people stop reading them.
An illustrative exception payload:
{
"batchId": "B2147",
"milestone": "manufacturing",
"committedDate": "2026-08-20",
"currentEstimate": "2026-08-29",
"varianceDays": 9,
"inventoryImpact": "Region-2 projected below policy on 2026-08-27",
"exceptionOwner": "supply-planning-lead",
"decisionRequired": true
}
Values here are illustrative. The structure is the point: variance, impact, and an assigned owner sitting alongside the raw status, so a reviewer isn't reconstructing that context by hand.
Dashboard design follows from the model, not the other way around
Once entities, state, and exceptions are modeled properly, dashboard design gets simpler: prioritize exceptions, variance, consequence, owner, and required action over a wall of KPIs. A dashboard showing twelve charts and no clear "what needs a decision today" view is usually a symptom of skipping the modeling work above, not a design failure on its own.
Where human control stays explicit
Automation can assemble context, calculate downstream impact, and route an exception to the right owner. That's a meaningfully different scope than automatically executing a decision particularly for regulated batch release, quality dispositions, or supply commitments with financial or compliance implications, where the architecture should route to a person rather than resolve the exception itself. Where this system design touches quality or regulatory-adjacent state, treat that boundary as a hard line in the architecture, not a configuration option.
Teams working through this kind of integration are often solving two different problems at once: figuring out what the operating model should actually be, and building the technical implementation for it. Gyan Solutions is a Detroit-area operations and implementation firm that works on both sides sometimes starting with Pharma Supply Chain Consulting to work out planning, CDMO coordination, and inventory visibility before touching a system, and sometimes starting directly on the technical build when that requirement is already defined. Neither one assumes the other comes first.
Before building another dashboard, define the decision it must support, the entities and state required to make that decision, the exceptions that matter, and who remains responsible for acting on them.
