The danger of optimizing one part of the company and making the entire system worse

A sales team automates the preparation of proposals and goes from sending twenty a day to sixty. The local metric improves: less time per proposal and faster response speed. Two weeks later, operations has more poorly defined projects, administration spends more time correcting hiring data, and management receives more escalations because exceptions have increased.

None of these consequences prove that automation is bad. Prove something else: the unit of analysis was too small. A stage was optimized and that stage was measured, when the result that mattered depended on an entire chain.

A company does not win when a department works faster. You win when the entire system produces a better result with less overall friction.

This problem appears with technology, but it is not born from technology. It also occurs when hiring, centralizing, decentralizing, changing incentives, imposing controls, reducing inventory, accelerating sales, or removing an approval. Any intervention that modifies the behavior of one part alters the conditions of the connected parts.

1. Local optimization is rational and can still be bad for the business

Departments need objectives. Sales looks at conversion and speed; operations looks at capacity and compliance; finance looks at margin, collection and risk; attention look at resolution and experience. The problem appears when each area improves its indicator without understanding what variable it transfers to the rest.

A local optimization usually follows correct logic within its boundary:

• reduce time per case;
• increase processed volume;
• reduce cost per unit;
• eliminate manual steps;
• increase the utilization of a team;
• reduce inventory or own backlog.

But the department boundary rarely coincides with the business outcome boundary. An order doesn't just belong to sales; It goes through validation, availability, delivery, billing, collection and, if something goes wrong, service. A file does not end when a team “completes” it; It ends when it produces the result that justified opening it.

That's why one metric can improve and the system can get worse. There is no contradiction: we are simply observing two different scales.

The boundary error

we will call boundary error to evaluate an intervention within an organizational limit that is narrower than the actual path of its consequences. The more connected an activity is to other areas, the less reliable an exclusively local assessment is.

2. Distinguish first-order and second-order effects

First-order effects are what we look for directly. If we automate request classification, we expect fewer human minutes per request. If we remove an approval, we expect a shorter wait. If we add an integration, we expect less double entry.

Second-order effects appear because the system reacts to the improvement.

Hypothetical example: A company automates the capture and initial qualification of leads.

1. First order: the sales team processes more contacts per hour.
2. Second order: more opportunities enter the pipeline.
3. Third operational effect: Pre-sale receives more estimate requests.
4. Consequence: the queue of complex proposals increases.
5. Human response: Pre-sale simplifies analysis to keep pace.
6. Later consequence: operations receives more ambiguous scope and rework increases.

Initial automation can still be valuable. But to capture that value you may have to change qualification criteria, pre-sales capacity, handoff format or commercial limits. If we only look at the time saved in acquisition, we will declare success before we have seen the system.

Business systems respond

A spreadsheet doesn't complain when it receives ten times as many rows. A team does change its behavior. Prioritize, create shortcuts, postpone tasks, increase batches, reduce review depth or escalate more decisions. These responses are part of the system.

That is why second-order analysis must include not only data flows and tasks, but also human capacity, incentives and decisions under pressure.

3. Map five types of dependency between areas

Not all dependencies are visible in a process diagram. To analyze the complete system it is advisable to distinguish at least five.

1. Volume dependence

One stage produces units that another must absorb. If A doubles throughput and B maintains capacity, a queue appears even though A is more efficient.

2. Quality dependence

B's work depends on A providing correct, complete or sufficiently structured information. A can save time by skipping checks and transfer the cost as rework.

3. Decision dependence

An improvement can generate more exceptions that end up being escalated to the same person or committee. Automation speeds up the normal flow but concentrates the decisional bottleneck even more.

4. Information dependence

Two areas can share the same customer, order or project, but work with different statuses. Automating an undefined source of truth can increase the speed at which a contradiction spreads.

5. Economic dependence

One area can reduce its cost by increasing another: discounts that increase sales but erode margin; large lots that lower unit cost but increase inventory; Eliminated controls that save minutes but increase subsequent incidents.

These dependencies turn the “department process” into a simplification. In reality there is a network for exchanging work, information, decisions, risk and capacity.

4. An eliminated bottleneck usually reveals the next

Removing a bottleneck does not mean that the system becomes unconstrained. It means that another part becomes the dominant limitation. This is normal.

The mistake is designing the project as if the goal were to maximize utilization of the improved stage. If a machine, piece of equipment, or agent can produce 1,000 units and the next stage can absorb 400, operating the first at 1,000 does not create 1,000 units of value. Create 600 queue units.

In intellectual work, this queue takes on less visible forms: inboxes, unreviewed tickets, pending decisions, documents awaiting signature, unvalidated proposals or clients to whom no one can respond in time.

That is why an essential question after any improvement is:

If this intervention works exactly as we expect, which part of the system will receive more work, more decisions, or more risk?

5. Framework ProjectCore: Impact → Transfer → Response → Result

Before implementing a local improvement, it can be analyzed with four layers.

I. Direct impact

What changes in the intervened stage: time, volume, error, cost, capacity, autonomy or decision frequency.

II. Transfer

What variable leaves that stage to another. It may be more cases, less context, faster information, more exceptions, advanced decisions or displaced risk.

III. System response

How the receiving areas react. Do they have capacity? Will priorities change? Would you create a manual control? Will scales increase? Will quality be reduced to maintain volume?

IV. Final result

What happens with the metric that really matters to the business: total time, total cost, margin, compliance, conversion, satisfaction, errors, cash flow or growth capacity.

6. Don't confuse resource efficiency with flow efficiency

An organization can try to keep each team as busy as possible and, paradoxically, slow down the entire outcome. If each area works in large batches to “be efficient,” work waits longer between stages. If no one retains exception capability, an urgent incident disrupts the entire system.

Resource efficiency asks how much we use each capacity. Flow efficiency asks how long it takes a unit of work to traverse the system and how much total effort it consumes.

Both matter, but they are not equivalent. A company can accept some apparent idle capacity at a critical point if that reserve reduces queues, protects SLA or allows it to absorb variability.

7. Three patterns of false improvement

Pattern A: Savings that reappear as an exception

The standard case is automated and the local team saves hours. The exceptions, however, reach another area without context. Time doesn't disappear: it changes ownership and becomes more expensive because it requires research.

Pattern B: speed that deteriorates downstream quality

An initial validation is reduced to speed up entry. Later, a specialized stage detects errors that have already contaminated documents, inventory or communications. The cost of correcting late exceeds that of validating early.

Pattern C: productivity that creates internal demand

A tool allows you to generate reports, campaigns, analyzes or requests at almost no cost. By lowering the friction of production, the quantity produced increases. If reviewing, approving, or executing is still expensive, the system becomes overwhelmed on that second activity.

8. Measure a chain, not a point

A major intervention should have at least one local metric, one flow metric, and one or two guardrail metrics.

• Location: human time per case in the changed stage.
• Flow: total time from input to result.
• Quality guardrail: error, rework or return at later stages.
• Guardrail capacity: backlog or queue age at the receiver.
• Economic: total cost per unit or margin when relevant.

Hypothetical example: If invoicing automates invoice creation, “hourly invoices” can improve dramatically. But real success may depend on time to collection, percentage of corrected invoices, incidents of incorrect data, and total manual work of the order-to-cash cycle.

A local improvement becomes credible when the final result improves without damaging relevant guardrails.

9. Test the intervention under conditions of success, not just failure

Pilots often test whether the technology fails. You also have to test what happens if it works very well.

This test avoids a common paradox: that technical success causes operational failure.

10. When optimizing locally does make sense

Not everything requires redesigning the entire company. A local improvement is reasonable when its interfaces are clear, the downstream capability is understood, the output has verifiable quality, and the final metrics do not depend on many hidden consequences.

It may also be correct to improve a specific constraint even if we know that another one will appear. The important thing is to do it consciously and prepare the next movement.

The rule is not “never optimize a department.” It is:

Optimize locally, but decide systemically.

11. Relationship with automation: the problem is not the tool

In how to know if a process needs automation We explain that automation can move the bottleneck. Here the point is broader: any intervention must be seen as part of a network of dependencies.

Automation amplifies this phenomenon because it can change throughput abruptly. But it can also be used to solve it: coordinate handoffs, make capacity visible, enrich context, apply limits and detect queues before they become incidents.

12. Design ownership for the transversal result

If sales only responds for “earned,” operations only for “delivered,” and management only for “invoiced,” no one necessarily owns the entire journey from promise to collection. Cross-border problems become “another department” problems.

For critical processes, it is advisable that there be transversal ownership of the result, although each stage maintains its functional manager. That owner does not have to execute everything. You must be able to observe flow, call for changes between areas, and resolve conflicting metrics.

13. Practical Systemic Optimization Audit

1. Select a recent or planned improvement.
2. Write the local metric you intend to improve.
3. Draw what output the stage produces and who receives it.
4. It marks dependencies on volume, quality, decision, information and economy.
5. Identifies the first restriction that would appear if the buff doubled its effect.
6. Define two plausible second-order consequences.
7. Choose a complete flow metric.
8. Add downstream guardrails.
9. Try a real sample before expanding.
10. Review the system after the new behavior stabilizes.

Conclusion

Companies are made of dependencies. When one part changes, the others do not remain motionless. They absorb more volume, receive less context, modify priorities, create controls, accumulate queues or change the way they decide.

That is why an improvement should not be judged solely by the productivity of the intervened point. The whole question is whether the system delivers a better result with lower total cost, less waiting, less error and a sustainable load.

Optimizing one part may be exactly what the company needs. But the border of the decision must reach where its consequences reach.

ProjectCore analyzes processes and dependencies before proposing technology. You can see the focus on how we work.