Metrics That Drive Action, Story 2 — Finding The Hidden Bottleneck

In print production, bottlenecks don't just slow one machine or production step—they set the pace for the entire plant. When one work center becomes the constraint (a press, a cutter, a folding line, even prepress), everything upstream piles up as WIP and everything downstream starves, which shows up as expediting, overtime, missed dates, and "busy" people who still can't ship on time. That's the take-home message from The Goal: the system's output is limited by its constraint, so local efficiency (keeping every department busy) is not the same as global performance (shipping more jobs on time). With that lens, the story below isn't just about software; it's about making the constraint and its queue visible enough to manage it, instead of arguing about where the bottleneck "must be" based on feel.

This is the second story is a conglomerate of several print operations to illustrate a common problem and how to fix it. (read the first story here)

The next breakthrough came when Julie admitted a second truth: even with better job tickets, the print shop still couldn't manage what it couldn't see—queues, routing decisions, and device-level status. Jobs would "disappear" into print queues, priorities would churn, and utilization arguments devolved into "my team is slammed" versus "your team is the bottleneck." Julie realized the KPI cockpit couldn't drive action if the shop lacked real-time visibility into what was waiting, what was running, and why it was not moving.

Julie implemented RSA's QDirect specifically to turn production output into captured, analyzable events. Because the software consolidates and routes jobs from multiple sources, jobs stopped getting stranded in disconnected pipelines, and "mystery work" (files sitting on someone's desktop, jobs stuck in a device queue, tickets that didn't match the file) began to disappear. The practical recommendation is to force a single release point for all production devices—one place where jobs enter the output pipeline—so every job has a traceable start, a traceable queue position, and a traceable owner. If you don't standardize the entry point, you can't manage queue time; you're just hoping.

More importantly for measurement, QDirect provided monitoring of printer status and job progress, so the shop had an objective timeline of what was running, what was waiting, and what was stuck. Julie made this actionable by creating three simple, shop-friendly states that map directly to interventions: RUNNING (leave it alone), WAITING (it needs a decision), and BLOCKED (it needs help). Then she set thresholds: if a job sits in WAITING beyond X minutes in front of the constraint, it is automatically reviewed in the next huddle; if it is BLOCKED, the supervisor must assign a root cause (material missing, approvals, downstream capacity, device down, file issue) before moving on. This is where many operations fail—they see a queue, but they don't operationalize the queue into rules.

That monitoring became the data foundation for the metrics that actually move performance. Julie used the software's job batching and load balancing to reduce priority thrash and make queue time predictable instead of chaotic. The practical recommendation is to define batching rules that reduce changeovers without breaking due dates—for example, batch by stock and finishing requirements, but limit batch size by a maximum "time window" so urgent jobs aren't buried. Julie also added a rule that protects the constraint: don't release work to the constraint unless upstream is complete and downstream has capacity. That one discipline alone reduces the most common form of false utilization—running jobs that later stall due to finishing capacity or missing parts.

Julie standardized ticketing changes using the software's job ticketing, so reroutes, splits, and batch decisions were logged as part of the production record rather than hidden in someone's email thread. The practical recommendation here is to treat every reroute as data: require a reason code (capacity, device capability, downtime, expedite, quality issue), because reroute volume is often the first sign your routing logic or schedule discipline is broken. When reroutes rise, the fix is usually not "more flexibility"—it's more discipline: better eligibility rules, better pre-staging, or better release sequencing.

She finally got "constraint utilization" out of the realm of guessing because the software made it obvious when the constraint was running, idle, starved, or blocked, and why. Julie turned this into an operations habit: at the start of each shift, the supervisor confirms (1) what the constraint is today, (2) what work is staged to feed it, (3) what two issues could starve/block it, and (4) who owns preventing those issues. This is a practical, low-drama way to use utilization as a decision tool rather than an argument.

In practice, QDirect turned the "invisible queue" into actionable data. When queue time rose, Julie could see where it accumulated and whether batching rules, device routing, approvals, material staging, or upstream starvation caused it. When on-time delivery dipped, she could trace the earliest driver—queue growth at the constraint, load imbalance, or constraint downtime—without waiting for end-of-month reports. The cockpit dashboard didn't get more complex; it got more potent because the software supplied the missing operational truth: what's in the queue, where it is, and what it's waiting on.