Managing Dependencies and Invisible Friction in Business Operations

No real business runs smoothly. Orders wait for approvals, invoices wait for delivery notes, deliveries wait for a driver who is waiting for a phone call. Each of those waits is a business process dependency: one step that cannot happen until another person, document, tool or decision is ready. Most of them are harmless. A few of them quietly decide how fast the whole business can grow, and almost none of them are written down.

This note is about making those dependencies visible. I explain what I mean by a business process dependency, how it differs from a constraint or from friction, how I map them in a real operation, and what to do once they are on paper. It builds on the second step of the five-step method I described last week: Structure.

Key points

• A business process dependency is any step that cannot start until something else is ready.
• Friction is the cost of dependencies that are slow, unreliable or invisible.
• Map dependencies by following real work and asking one question: what are you waiting for?
• Once visible, each dependency can be removed, buffered, duplicated, documented or monitored.

Why friction stays invisible

Friction in a business rarely announces itself. It appears as small delays that everyone has learned to live with: the manager who approves purchases only on Thursdays, the accountant who needs the delivery notes before closing the month, the one salesperson who knows the real price list. Each delay seems reasonable on its own, and each one hides a business process dependency. Together, they set the pace of the company.

Three things keep friction hidden.

• It is spread out. No single person sees the whole flow. Each one sees their own wait and assumes it is normal.
• It is absorbed by people. Experienced staff work around problems so naturally that the problems disappear from view. The cost reappears when those people are absent or leave.
• It is not measured. Businesses count sales, costs and stock. Almost none count waiting time, rework or the number of times a document is chased.

I grew up around quarry operations, where friction is easier to see. When a crusher waits for a loader, a queue of trucks forms at the gate and everyone notices. In an office, the queue is a pile of emails, and nobody notices until a customer complains.

What a business process dependency is

A business process dependency is a relationship in which one activity cannot start, continue or finish until something else is available. That something can be a person, a piece of information, a physical resource, a decision, a tool or an outside party.

Dependencies are not a defect. A business is a set of connected activities, and connections create dependencies. The problem is never that dependencies exist. The problem is when they are unknown, unreliable or concentrated on a single point.

The most common types I meet are these.

Type	What the step waits for	Example
Sequence	Another step to finish	Invoicing waits for the signed delivery note
Information	Data held somewhere else	Quoting waits for the current supplier price
Person	One specific individual	Discounts wait for the owner’s approval
Shared resource	Equipment or capacity used by several flows	Two production orders wait for the same machine
Outside party	A supplier, bank, carrier or authority	Shipping waits for the transporter to confirm a truck
Rule	A legal or internal control	Payment waits for a second signature above a threshold

Each type fails differently. A sequence dependency fails when the first step is late. An information dependency fails when the data is wrong or out of date. A person dependency fails when that person is absent, busy or gone. Mapping a business process dependency means knowing its type, because the type tells you how it will break.

Constraints, dependencies and friction

These three words are often used interchangeably. I find it useful to keep them apart.

• A constraint is a limit on the whole system: capacity, budget, time, regulation, skills. A crusher can process only so many tonnes per hour. A team can answer only so many calls per day.
• A dependency is a link between two parts of the system. It says that one part needs another.
• Friction is the cost created when dependencies are slow, unreliable or invisible: waiting, chasing, rework, errors and frustration.

The theory of constraints teaches that a system can only move as fast as its tightest constraint. Dependencies explain why the constraint is where it is. Friction is what you feel day to day. When I map a business, I look at all three together, but I start with dependencies, because they are the easiest to observe and the most often ignored.

How I map each business process dependency

I do not map dependencies in a meeting room. I map them where the work happens, by following real cases. The method is simple enough to run in a few days on a single flow.

1. Choose one flow. Order to cash, purchase to payment, enquiry to quote. One flow at a time.
2. Follow one real case from start to finish. A real order, with its real documents and real messages, through every hand it passes.
3. At every step, ask one question: what are you waiting for? The answer names the dependency. Write down who or what, how long the wait usually is, and what happens when it is longer.
4. Mark single points. Any dependency that rests on one person, one file, one machine or one supplier gets a mark. These are the points that stop everything when they fail.
5. Estimate frequency and impact. How often does this dependency cause a delay, and how much does the delay cost? Rough numbers are enough.

The question “what are you waiting for?” is the most useful tool I know for this work. People rarely describe their job in terms of dependencies, but they always know what they are waiting for.

The dependency register

The output of the mapping is a short table I call a dependency register. It is not a complex document. On a typical flow it has between ten and thirty lines.

Field	What it records
Step	The activity that waits
Depends on	The person, data, resource, party or rule it waits for
Type	Sequence, information, person, shared resource, outside party, rule
Single point	Yes or no
Usual wait	Typical delay in hours or days
Failure frequency	How often the wait becomes a problem
Impact	What a failure costs: time, money, customer trust
Owner	Who is responsible for keeping this dependency healthy

The last column matters most. A business process dependency without an owner is a dependency nobody will fix.

Human variables

Spreadsheets and process maps tend to treat people as reliable components. They are not, and that is not a criticism. People get ill, take holidays, change jobs, forget, misread and get tired. A realistic map includes those variables.

Software teams use the term bus factor for the number of people who would have to disappear before a project stalls. Many small and medium businesses have a bus factor of one on their most important flows: one person who holds the supplier relationships, the passwords, the price logic or the customer history.

When I map human dependencies, I ask four questions:

• Availability. What happens on the days this person is not here?
• Knowledge. Is what they know written anywhere, or only in their head?
• Load. Are they a dependency for so many flows that they have become the constraint?
• Handover. If they left tomorrow, how long would it take someone else to do their part?

None of this is about blaming individuals. A person who has become a single point of failure usually got there by being reliable and helpful. The fix is to share the load and the knowledge, not to replace the person.

Bottlenecks and queues

Where dependencies meet a constraint, queues form. A queue is the clearest physical sign of friction: work waiting in front of a step that cannot keep up.

Little’s law gives a simple relationship between three quantities: the average amount of work in progress equals the arrival rate multiplied by the average time each item spends in the system. In practical terms, if work keeps arriving at the same rate and a dependency slows down, the pile of waiting work grows, and so does the time every customer waits.

This is why the bottleneck deserves attention before anything else. Speeding up a step that is not the bottleneck only makes the queue in front of the bottleneck longer. In a quarry, it means more trucks waiting at the crusher. In an office, it means more files waiting on one desk.

Evidence over assumptions

Every manager has an opinion about where the business is slow. In my experience, those opinions are right about half the time. The other half, the real friction sits somewhere less visible, often in a business process dependency between two departments that nobody owns.

So I measure before I conclude. Three measures are enough to start:

• Waiting time. How long does work sit between steps? It is often longer than the time spent working on it.
• Rework. How often is something done twice: a quote recalculated, an invoice corrected, a delivery re-sent?
• Chasing. How many messages, calls or visits are spent asking for something that should have arrived on its own?

These numbers do not need to be precise, and they do not need to cover every business process dependency at once. A week of tally marks on paper is often enough to show where the friction concentrates, and they settle arguments that opinion alone cannot.

An illustration: the month-end close

The following example is an illustration, built from patterns that are common in trading and distribution businesses. It does not describe a specific company.

A trading business closes its accounts each month. The close always takes ten days, and the owner believes the accountant is slow.

Following one month-end from start to finish shows something else. The accountant is waiting for three things: the signed delivery notes from the warehouse, the supplier invoices from the purchasing assistant, and the cash receipts from the drivers. The delivery notes arrive in a folder once a week. The supplier invoices sit in an email inbox until someone has time. The cash receipts depend on drivers coming back to the office, which they do irregularly.

The dependency register makes the picture clear. The close is not slow because of the accountant. It is slow because three information dependencies have no owner and no deadline. The fix is not a new accounting tool. It is three small rules: delivery notes scanned daily, supplier invoices forwarded on receipt, cash receipts recorded at the end of each round. The close shortens because the waits shorten, without changing the person or the software.

What to do once a dependency is visible

A mapped dependency can be handled in one of five ways. The choice depends on its type, frequency and impact.

Action	When to use it	Example
Remove	The dependency is a habit, not a need	Approval no longer needed below a set amount
Buffer	The dependency is necessary but unreliable	A small safety stock of a critical part
Duplicate	A single person or tool holds everything	A second person trained on supplier pricing
Document	Knowledge lives only in someone’s head	The price logic written down and shared
Monitor	The dependency is healthy but critical	A weekly check that a key supplier is on time

Software can help with several of these. A shared database removes information dependencies between departments. Automatic reminders monitor deadlines. Permissions and audit trails make controls cheaper. But software helps only after the business process dependency is understood. Automating a dependency nobody has mapped simply makes the problem faster.

Some friction is useful

Not every dependency should disappear. Some friction protects the business. A second signature on large payments, a quality check before shipping, a pause before a price change: these are deliberate dependencies, and removing them to save time can be expensive.

Before removing a dependency, I ask why it was created. If nobody knows, I try to find out before deleting it. Rules often exist because of a problem that happened years ago and that would happen again without them. The goal is not a frictionless business. It is a business where every business process dependency is known, owned and worth its cost.

Common mistakes

• Mapping from the org chart. Reporting lines say who manages whom, not who waits for whom.
• Ignoring outside parties. Suppliers, carriers, banks and authorities are often the least reliable dependencies, and the least visible.
• Treating every business process dependency as permanent. Many were created for a reason that no longer exists.
• Treating people as machines. Plans that assume everyone is always present and always right will fail on the first ordinary week.
• Fixing the loudest delay. The delay people complain about is not always the one that sets the pace.
• Automating before mapping. Software built on an unmapped business process dependency spreads the friction instead of removing it.
• Removing controls for speed. Some dependencies exist to prevent costly mistakes. Understand them before you cut them.

How this shapes the way I build

This way of looking at dependencies comes from operations, not from software. It applies to a quarry, an online store or a clinic in the same way. When I build software through MeskikCode, the dependency register is one of the first things I want to see, because it shows which links the system must make reliable and which ones it should leave alone. The same thinking applies to the other ventures I am involved in.

Questions about business process dependency

Next

Next week I go back to where this way of thinking started for me: the quarry and crushing operations I grew up around. Meanwhile, you can read about my background or write to me if you are untangling dependencies in your own business.