گلوگاه را با زمان‌سنج پیدا نکنید؛ ردِ کارهای برگشتی را بگیرید

When bottlenecks come up, many managers have a predictable first reaction: measure the time spent in every stage. Find out which person, team, or approval takes the longest. That is not useless, but it often leads us to the easiest answer rather than the right one.

A stage may genuinely take a long time and still deliver usable output every time. Meanwhile, a stage that appears fast can cripple the entire flow because its output is incomplete, unclear, or inconsistent, sending work back for correction. A stopwatch rarely captures that back-and-forth well.

A bottleneck is not only where work stops. Sometimes it is where work passes through, but does not pass through properly. Hours or days later, it returns because of a question, a defect, an incomplete file, or an undecided issue. That is the cost that disappears in stage-time reports.

In sales, operations, content production, customer service, or project delivery, this pattern appears often. One team says the information is insufficient. The previous team says the request was unclear. A manager steps in to resolve an exception. The work is revised and moves forward again. On paper, everyone is busy; in reality, the organization is doing the same work several times.

The problem is that rework is rarely recorded under its real name. It becomes “coordination,” “review,” “a minor revision,” “follow-up,” or “just one quick question.” Each label seems harmless on its own. Put them together, though, and you see that a meaningful share of the team’s capacity is not creating new output; it is repairing earlier output.

To see this problem, you do not need to begin with a complex dashboard, new software, or a data-analysis project. Choose one recurring workflow: one that regularly passes through several people or teams, and whose result matters to customers, revenue, quality, or delivery. The more repeatable the flow, the clearer the signals will be.

For example, choose the path from a customer request to a proposal, from order entry to delivery, or from task definition to final approval. You do not need to dissect the entire business at once. Choosing one bounded flow makes reality easier to see and makes pointless meetings less likely.

Then identify the handoff points. Do not just list department names; identify the moment when a person or team says, “My part is finished; now it is yours.” That moment must be visible. A form, ticket, file, logged message, or defined status in a work tool can be enough. For process management, a verbal handoff is not reliable memory.

For every item that crosses a handoff point, add just one question: was it accepted without a material change, or was it returned? If it was returned, where did it go back to, and what reason was given? The purpose here is not to put people on trial. It is to see the real path of work, not the path drawn in a flowchart.

Keep the record simple. The work item, handoff point, acceptance or return, reason for return, and the decision owner for the next step are usually enough. If the form is so detailed that nobody completes it, you have no data. If it is so vague that everything falls under “mistake,” you still learn nothing.

From the start, group the reasons for returns. Missing information, unclear criteria, execution errors, changed requests, missing decision authority, noncompliance with a standard, and off-path exceptions are useful initial categories. Your categories do not need to be perfect. They need to be clear enough that two people would place a similar event in roughly the same group.

You will quickly notice that not all returns have the same value. Some are natural, such as when a customer truly changes a request. Others reveal weak process design, such as when the next team must ask for the same basic information again or when every output moves back and forth between two people several times before approval.

This is where the key question changes. Instead of asking, “Who is slow?” ask, “What was missing from this output at the first handoff that made it unacceptable?” The question sounds simple, but it moves the conversation from individual blame to system improvement.

The answer is often found in the lack of a definition for “ready to hand off.” Many teams do not have a precise definition of what finished work means. Everyone considers the work done based on their own interpretation. One person says a file is ready because it has been prepared; another says it is not ready because a source, approval, or required information is missing. Both may be right from their own perspective.

A ready-for-handoff criterion does not need to be a heavy document full of legal-style clauses. A few clear conditions for each handoff are enough: what information must accompany the work, what decision must already be made, what must not remain unresolved, and who is allowed to accept an exception. A good criterion does not stop conversation; it stops guessing.

If an output keeps coming back, resist the urge to immediately add another person to the team, schedule more coordination meetings, or buy a new tool. These may sometimes be necessary, but they often only create more capacity to carry the same confusion. First, understand where the return loop closes and why it is triggered again and again.

Look at exceptions separately. A process that advances through many exceptions is not really a standard process; it is a collection of case-by-case decisions wearing the clothes of a process. If an exception repeats, it is no longer an exception. It should become a formal path, have its cause removed, or be deliberately stopped.

This perspective matters even more for automation and artificial intelligence. Recent discussions about organizational productivity keep circling back to the same point: adding a smart tool to an already messy workflow usually does not resolve the mess, it just speeds it up. When inputs are unclear, acceptance criteria are undefined, and work repeatedly returns, automation merely increases the speed of producing outputs that need correction. A tool may move work faster, but it cannot create agreement on what “acceptable output” means by itself.

Before automating any part, examine how often work returns at that point and why. If the cause is missing data or the absence of a decision rule, solve that first. If the cause is clear, repetitive work, then automation can help. The order of those two things is the difference between building leverage and building faster disorder.

After a few weeks of observation, do not look for a magic number. Look for patterns: which handoff has the most returns, which reason repeats, who has to absorb the most ambiguity, and which decision keeps being escalated to the manager. These usually offer a truer picture of the bottleneck than average task duration does.

Then choose just one loop and close it. Clarify the handoff criterion, delegate one decision to the right level, place needed information earlier in the flow, or define a path for a recurring exception. Do not attack every problem at once. Processes improve through small, observable changes, not through large plans that are soon forgotten.

Managing a bottleneck is not about hunting for one person to blame. The real work is reducing how often an output must travel backward before it becomes usable. When return loops decrease, time is released, tension drops, and real speed becomes visible. Then, if a bottleneck still remains, at least you are fixing the right place.