PROCESS

Here is How to Build

Design

System

A company is many processes

Most of this book so far has looked closely at a single process. The Rules and the Exceptions studied one in detail (the communication around a fix), and Core turns next to the main process a company exists to run. But no company runs on one process. Behind every product sold and every customer served stand many processes at once: one that does the core business, others that keep it supplied with money, systems and people, and others that set where the company is going and check that it gets there. Each has its own work, its own result and its own owner. Together they are how the company actually works.

That set of processes is the system. It is not something anyone has to invent: every company that runs at all already has one, whether or not anyone has drawn it. Orders are taken, invoices are sent, people are hired, systems are kept running, plans are made. Each of those is a process, and each one depends on others. What a company often lacks is not the system but the sight of it: a single view in which every process can be seen at once, in its place, next to the processes it relies on.

This volume is about that view. It sits at the top of the zoom this book follows: the system first, then the core process within it, then the parts of that process, then the steps inside each part, and finally the guidance for doing a single step well. Each level shows something the one below cannot. A step cannot show its procedure, a procedure cannot show the process it serves, and no single process, however well designed, can show the system it belongs to.

The highest possible standard is to treat the company as a system of processes rather than as one process or a loose collection of tasks, to recognise that every process already belongs to a system whether it has been drawn or not, and to begin design at the top of the zoom, with the whole system in view, before turning to any single process within it.

Key Takeaway: No company runs on one process. Behind every customer served stand many processes at once: the core business, the processes that supply it with money, systems and people, and the processes that set direction and check progress. Together they are the system, and every company that runs already has one, drawn or not. What is often missing is the sight of it. This volume sits at the top of the book's zoom (system, core, sub-process, procedure, guide), because each level shows something the one below cannot.

A company is not one process but a system of processes; every company already has one, and design begins by seeing it whole.

MarvinPro · PROCESS · Here is How to Build · Design · System · Discipline 1: A System · Section: A company is many processes

MarvinPro | October 2026

marvinpro.com

See the whole before the part

Why start there? Because a process designed on its own can be designed well and still do harm. Tighten one process in isolation and its work often does not disappear; it moves. A check removed from one process lands in the next. A delay cut from one team's flow becomes a queue in someone else's. Two processes each do half of the same job, and a third piece of work belongs to neither and is done by whoever notices. Each process looks sound from inside. The trouble only shows from above, where you can see what passes between processes and what falls between them.

The system view is how you see it. Before you design or change any process, place it on the map: what it receives and from where, what it hands on and to whom, which processes it depends on and which depend on it. Then the choices change. You can see when a fix in one place is really a cost pushed somewhere else. You can see when a problem in your process is really born in another. And you can see where the company's effort is going, and whether it lands where the customer feels it.

Seeing the whole is not the same as designing the whole at once. The system view does not ask you to redraw every process before touching one. It asks you to know where the one you are touching sits, and to design it as a part of something larger. A process designed with its system in view can be judged by what it does for the whole. A process designed without it can only be judged by itself, and it can look perfect while it fails the company.

The highest possible standard is to place every process on the system map before designing or changing it, to know what it receives, what it hands on and which processes it depends on, and to judge any change by its effect on the whole system, so that an improvement in one place is never a cost quietly pushed to another.

Key Takeaway: A process designed alone can be designed well and still do harm: its work moves rather than disappears, landing in neighbouring processes as checks, queues, duplicated effort or work that belongs to no one. Each process looks sound from inside; the trouble only shows from above. So before designing or changing a process, place it on the map: what it receives, what it hands on, what it depends on and what depends on it. Seeing the whole does not mean redesigning everything at once; it means designing the one process as a part of something larger.

Place a process in its system before you change it; work tightened out of one process does not disappear, it moves.

MarvinPro · PROCESS · Here is How to Build · Design · System · Discipline 1: A System · Section: See the whole before the part

MarvinPro | October 2026

marvinpro.com

A system, not a list

A list of processes is not yet a system. Plenty of companies have a list: a page of process names, perhaps grouped by department, perhaps numbered. It tells you what exists. It does not tell you how any of it works together. A system is the processes and what connects them, and a view of it has to show more than names.

It has to show four things, and they are the four moves of this volume. First, the map: every process the company runs, named once, at the same level, on one page. Then the kind of each one: whether it does the core business, supports it or steers it, because each kind is designed and judged differently. Then the links: what flows from one process to another, so that every process can be read by what it receives and what it hands on. And finally, governance: an owner for every process, and someone who keeps the map itself true as the company changes.

Leave any one of these out and the view stops working. A map without kinds treats every process as equally central, and the core disappears among its supports. Kinds without links show a company of separate boxes, with nothing passing between them. Links without owners show where work flows but not who answers for it. And a map nobody keeps true is accurate for a while, and then misleading. With all four in place, the system becomes something you can read, design against and trust.

The highest possible standard is to build the system view as more than a list of processes: a single map on which every process is named at one level, sorted by kind, linked by what flows between it and its neighbours and governed by a named owner, with the map itself owned and kept true as the company changes.

Key Takeaway: A list of processes shows what exists, not how it works together. A system view shows four things, which are the four moves of this volume: the map (every process named once, at one level, on one page), the kind of each (core, support or steering), the links (what flows from one process to another) and governance (an owner for every process, and for the map itself). Leave one out and the view fails: without kinds the core disappears, without links the processes are separate boxes, without owners no one answers for the flow, and a map nobody keeps true turns misleading.

A system is not a list of processes: it is every process mapped, sorted, linked and owned, and kept true as the company changes.

MarvinPro · PROCESS · Here is How to Build · Design · System · Discipline 1: A System · Section: A system, not a list

MarvinPro | October 2026

marvinpro.com

A real example

Return to the software company you met in the Rules, and this time look at it from above. So far you have seen one of its processes closely: in the Rules and the Exceptions, the communication around a fix, which is how trouble is sorted, worked and told. From above, that process is one box among many.

At the centre sits the work the company exists to do: selling software by subscription, and keeping each customer subscribed, licensed and running. The next volume calls that the core and designs it. Around it sit the processes it cannot run without. Finance charges the customer, sends the invoice and collects what is due. IT keeps the systems the subscription depends on running. A people process hires and trains the teams who do the work. Communication (the process you already know) tells customers what is happening when something goes wrong. And above them all, planning decides which plans to sell and in which markets, and governance checks that every process does what it promises.

Now follow one ordinary event across the map. A customer's card payment fails at renewal. Finance tries to collect, and fails. The core, checking again and again whether the subscription is still active, finds that it is not and holds the software back. Communication tells the customer why, and how to put it right. That is one event crossing three processes, each sound on its own. But if finance keeps retrying for a week while the core holds the software back after a single day, the customer is cut off over a payment that would have gone through. Neither process is wrong inside. The fault is in how they meet, and it can only be seen on the map.

Seen from above, one failed renewal crosses finance, the core and communication; each process can be sound inside while the system fails where they meet.

MarvinPro · PROCESS · Here is How to Build · Design · System · Discipline 1: A System · A real example

MarvinPro | October 2026

marvinpro.com

A System

A company is not one process. It is a system of processes: one that does the core business, others that support it with money, systems and people, and others that set its direction and check its progress. Every company that runs already has one, drawn or not; what is often missing is the sight of it. This volume begins the book's zoom at the top, with the whole system, before the core, its parts, its steps and the guidance for a single step.

Seeing the whole comes first because a process designed alone can be designed well and still do harm. Its work moves rather than disappears, landing in neighbouring processes as checks, queues, duplication or work that belongs to no one. So before you design or change any process, place it on the map: what it receives, what it hands on, what it depends on and what depends on it. Then judge every change by what it does to the whole.

And a view of the system must be more than a list. It shows four things: every process on one map, the kind of each, the links between them, and an owner for every process and for the map itself. Leave one out and the view fails. Keep all four, and the system becomes something you can read, design against and trust: the ground every later volume of this book stands on.

A company is a system of processes: see it whole, on one map, sorted, linked and owned, before you design any process within it.

MarvinPro · PROCESS · Here is How to Build · Design · System · Discipline 1: A System · Chapter Outcome

MarvinPro | October 2026

marvinpro.com

Think Simple.