How to See the Forest
and the Trees

To see the forest and the trees, you develop the capability to step back and see the big picture, while simultaneously being able to zoom in and observe the trees. This series of articles will teach some practical things that will help you to cultivate this skill.

In Part I we introduced the Context Diagram and the ICOMs that define any process boundary. In Part II we decomposed that context into an Activity Node Tree. In Part III we applied ICOMs to every node in the tree. In Part IV we added SIPOC — naming the suppliers and customers at the boundaries of the whole process.

We now have two frameworks. Each is powerful on its own. Neither is complete on its own.

ICOM tells us the structure of each activity: what flows in, what governs it, what produces it, and what enables it. It is a governance and structural framework.

SIPOC tells us the accountability at the boundaries: who provides the inputs and who depends on the outputs. It is an accountability framework.

The question we left open at the end of Part IV was this: what happens when you apply SIPOC not just at the top level — but at every activity node in the decomposition tree?

The answer is the model this entire series has been building toward.

Applying SIPOC at Every Node

In Part IV, we built a single SIPOC for the entire Baking Brownies process. It captured the Grocery Store Clerk and Baker as suppliers, and the Baker's Family and Guests as customers. It was accurate and useful, but it treated the process as a black box. The activities inside had no supplier-customer relationships of their own.

Now we open the box.

When we apply SIPOC at every activity node — the same way we applied ICOMs in Part III — we discover that every activity is its own mini-process with its own supplier and its own customer.

Every Supplier in this model is the person performing this activity, supplying their time, skill, and judgment to turn inputs into outputs. That is the service they provide. Materials suppliers (grocery stores, utility companies) appear alongside them because they provide the raw inputs, but the human doing the work is always named first.

Take A3 (Bake & Serve Brownies). Its Supplier is the Baker performing A3, the person executing the baking. The inputs they receive (brownie batter and greased pan) were produced by A2. The mechanism they depend on (a preheated oven) came from A1. Those prior deliveries show up in A3's Inputs and Mechanisms columns. That is where the upstream connections are captured.

And the Supplier of A2 (Mix Ingredients) is the Baker performing A2, the person doing the mixing. Their Customer is the Baker performing A3, who depends on receiving a properly prepared batter. If A2 delivers a poorly mixed batter, the model names exactly where the failure occurred and whose accountability it is.

In the brownie example, it is the same Baker at every step. In a real business process, those are different people or teams, and each handoff is an explicit accountability boundary. This is what is invisible at the L1 SIPOC level. It only becomes visible when you apply SIPOC at every node.

One more nuance: when an activity is fully automated — executed by a script, a programmed workflow, or an AI agent with no human intervention — the automation itself fills the Supplier role. It is simultaneously the performer and a Mechanism. This is an accommodation the method makes for fully automated steps: the automation is named as Supplier to preserve the accountability structure, even when no person is involved.

This is what combining SIPOC and ICOM at every node gives you: the ability to trace every input, output, control, and mechanism back to a specific person (or automation) and forward to a specific person, at every level of the process.

A Refinement When Combining IDEF0 with SIPOC

When you bring SIPOC and ICOM together at every activity node, something interesting happens to the Mechanisms category.

In Parts I through III, Mechanisms were defined as they are in standard IDEF0: the people, tools, and systems that enable an activity to execute. The baker is a Mechanism. The oven is a Mechanism. The mixing bowl is a Mechanism.

That definition is correct in a pure IDEF0 context, and Parts I through III were built on that foundation.

But once SIPOC is in the picture, leaving people in the Mechanisms category creates a conflict. SIPOC already has a specific place for people: Supplier (who provides the inputs and performs this activity) and Customer (who receives the outputs as well as the final customer this whole process is serving). If the baker appears as a Mechanism, they also implicitly appear as a Supplier and Customer in the SIPOC view. The same person is represented twice, in two different categories, for two different purposes.

The cleaner design, and the one this method adopts going forward, is this:

This is not a correction of Parts I through III. Those articles presented ICOMs faithfully as IDEF0 defines them. This is an intentional refinement that becomes possible and necessary once SIPOC is combined with ICOM. The frameworks reinforce each other, but only if each element has a single home.

Under this refinement, the baker is not a Mechanism. The baker is:

• A Supplier who provides their skill, time, and attention to the activity
• A Customer who receives the outputs of prior activities and depends on them being right

The oven, the mixing bowl, the timer, the cooling rack — these remain Mechanisms. They enable the activity but neither provide nor receive. They have no stake in the outcome. People do.

The Combined Model: A2 Mix Ingredients

Let's apply the full combined model — SIPOC + ICOM with the Mechanisms refinement — to A2 (Mix Ingredients). This activity has the richest set of elements in the brownie process, which makes it the clearest illustration of what the combined model reveals.

Supplier / Role: Baker + Grocery Store / Pantry

Who is supplying the inputs? Who is performing the activity?

The Supplier for any activity captures two things: who provides the inputs, and who performs the work.

The Grocery Store Clerk and Baker supply the physical ingredients — brownie mix, eggs, water, and pan. They deliver the raw materials that A2 will consume. If the grocery store is out of eggs, A2 cannot begin.

The Baker supplies the labor, skill, and judgment required to actually do the mixing. Ingredients alone do not produce batter. Someone has to combine them, in the right proportions, in the right sequence. That person — the one performing the activity — is also a Supplier.

Both are named. One delivers materials; the other delivers the service.

Inputs: Brownie Mix, Eggs, Water, Pan

What comes into this activity that is transformed or consumed?

These are the materials that A2 consumes and transforms. Same as the ICOM definition in Part III. SIPOC does not change what the inputs are — it adds who is responsible for delivering them.

Controls: Recipe, Customer Preference

What outside force constrains the process?

The recipe governs how much of each ingredient, in what order, combined in what way. Customer Preference governs variations — more chocolate, less sugar, brownies vs. blondies. Controls are not consumed; they govern. Neither the grocery store nor the baker's family provides a control arrow — controls come from standards, preferences, and operating norms.

Outputs: Brownie Batter, Trash, Greased Pan

What is the output from this activity? What does the supplier deliver?

A2 produces three outputs. The brownie batter is the primary output, the transformed result of combining all inputs. Trash (egg shells, packaging) is an incidental output that must be managed. The greased pan is a prepared output that flows directly to A3 alongside the batter. All three are real outputs and all three have a destination.

Mechanisms: Mixing Bowl & Spoon

What systems or tools are required to turn the inputs into outputs?

Under the combined model, only the tools and systems remain in Mechanisms. The mixing bowl and spoon enable the mixing to happen: they are not consumed, they are not the supplier, they are not the customer. The baker who uses them is the Supplier of labor and skill.

Customer: Baker (performing A3)

Who is the output delivered to? Who is the activity performed for?

The immediate customer of A2's output is the Baker who will execute A3 (Bake & Serve Brownies). They depend on A2 delivering a correctly prepared batter: the right consistency, right quantity, in a properly prepared pan. If A2 delivers poorly — wrong consistency, wrong amount, ungreased pan — A3 will fail even if everything else is perfect.

In the brownie example that is the same Baker throughout. In a real business process it is often a different person or team, and naming them makes the handoff explicit. That is an internal supplier-customer accountability that a standard L1 SIPOC cannot see.

The Full Model Across All Four Activities

With A2 fully mapped, here is how the combined SIPOC + ICOM model looks across all four activities:

Notice what just happened. Each activity now has a named Supplier (the person performing it), a named Customer (the person depending on its output), and a clear set of inputs, outputs, controls, and mechanisms. A4 (Cleanup) is a good example of something that often goes undocumented — it has real inputs, real outputs, real people responsible, and a real customer (the Baker who needs clean equipment for the next batch). When you leave activities like this off the model, you also leave off the accountability.

In this example it is the same Baker throughout — but the accountability at each handoff is distinct. If you are troubleshooting a bad batch of brownies, you now have a structured accountability map: which Supplier failed to deliver? Which input was wrong? Which control was violated? Which mechanism was unavailable?

That is diagnostic power. And it comes from combining two frameworks at every node.

The Spreadsheet: One Row Per Activity

The combined SIPOC + ICOM model is powerful — but it becomes operational when you put it in a spreadsheet.

Each row in the spreadsheet represents one activity. Each column captures one element of the model. The result is a single view of the entire process in which every activity, every dependency, and every accountability relationship is visible at once.

How Deep Do You Go?

Every process model should have at minimum three levels of decomposition:

• L0 — the Context Diagram: the entire process as a single box, with its external inputs, controls, outputs, and mechanisms
• L1 — the major activities inside that box (Preheat Oven, Mix Ingredients, Bake & Serve Brownies, Cleanup)
• L2 — the sub-activities within each L1 step (Secure Fuel, Check Oven, Ignite Oven…)

Whether you need L3 or deeper depends entirely on scope. For a discrete, localized process like baking brownies, L2 is sufficient. For end-to-end business processes spanning multiple departments, systems, or organizational handoffs, you will need L3 and sometimes L4 or beyond. The purpose of the model is to decompose down to the level where the work can actually be analyzed, assigned, and improved. That level is where the real problems live.

The spreadsheet handles this naturally. Activity IDs encode the level: A1 is L1, A1.1 is L2, A1.1.1 would be L3. Every row, at every level, carries the same nine columns. The hierarchy is visible in the ID; the model is consistent throughout.

The brownie process fully modeled at L1 and L2 looks like this:

The columns map directly to the combined model:

The KPIs and Problems / Pain Points columns are not part of the original IDEF0 or SIPOC frameworks. They are the natural next step: once you know what each activity produces and who depends on it, you can ask how well it performs and where it fails. Those are the columns that connect the structural model to the operational reality of the business.

This spreadsheet is not a diagram. It is not a swim lane chart. It is not a value stream map. It is a structured data table — and that means it can be filtered, sorted, analyzed, and extended. Every row is a work unit (an activity within a process, or a process step, within a particular context). Every column is a dimension of inquiry.

A process that lives in this spreadsheet can be diagnosed, discussed, and improved by any team, without requiring a Visio license, an IDEF0 tool, or a Lean Six Sigma certification (although, the Lean Six Sigma certification is a PLUS!).

Why This Matters

The traditional IDEF0 practitioner applies ICOMs at every node and produces a rich decomposition diagram. The traditional LSS practitioner builds a SIPOC and produces a stakeholder map. Both are useful. Both are incomplete.

The IDEF0 decomposition has no accountability — it can tell you that a brownie-mixing activity needs a recipe and a bowl, but it cannot tell you who is responsible for ensuring the recipe is current, or who gets called when the batter is wrong.

The SIPOC stakeholder map has no structure — it can tell you that the Grocery Store is a supplier and the Baker's Family is a customer, but it cannot tell you which activities inside the process are failing and why.

The combined model closes both gaps. Applied at every node, it produces a complete picture of any process: its structure, its governance, its accountability, and its performance potential — all visible in a single spreadsheet.

That is the model. In Part VI, we will add the final layer: quantifying it.

In Summary

Applying SIPOC at every activity node, not just at the top level, reveals internal supplier-customer relationships that the traditional L1 SIPOC cannot see. Combining it with ICOM at every node gives each activity a complete analytical profile: who provides, what flows in, what governs it, what produces it, what enables it, and who depends on the output.

The Mechanisms Redefinition — placing people in Supplier and Customer, leaving only tools and systems in Mechanisms — sharpens the model by ensuring every element has exactly one home.

The spreadsheet is not a visualization tool. It is the operational artifact — one row per activity at every level of decomposition, all fields in a single view, extensible with Critical KPIs and Problems. L1 gives you the high-level picture. L2 gives you the work. L3 and beyond give you the precision a large end-to-end process requires. It makes the model actionable for any team without requiring specialized software.

In Part VI, we will add the final dimension: Value Stream Analysis. Each activity can be quantified — cycle time, value-added time, wait time, defect rate. From those numbers we can calculate two derived metrics that tell you, objectively, how well the whole process performs and where the waste is hiding.

If you found this article informative, please like it and share it with your network. I'd like to hear from you in the comments and address any questions you might have.