Porter’s value chain

Michael E. Porter · 1985

Break the business into the activities it actually performs, and ask which of them the customer is paying for.

Its place in the frameworkBusiness Core›Operational Systems

What it does

Primary activities — bringing things in, making them, getting them out, selling them, supporting them — run across the middle, with procurement, technology, people and infrastructure supporting all of them. The point is not the diagram but the question it forces at every box: does this activity add value the customer would pay for, does it cost less than a competitor’s, and if neither, why is it here?

Reach for it when: When looking for where margin actually comes from, and when deciding what to keep, improve or hand to someone else.
Where it stops: It was drawn for manufacturing and fits a linear flow best. Service and software businesses often have to redraw it before it says anything useful.

Michael E. Porter, Competitive Advantage, Free Press, 1985.

Why it sits at Operational Systems

How the work actually gets done — the processes, tools and standards that turn intention into output without requiring a decision every time.

A model is only useful when you reach for it at the right moment. This one answers a question that arises here — so it is filed here, and nowhere else. These are the working areas it serves:

Process designProcess mapping and value stream analysis, which distinguish steps that add value from steps that merely add time.
ToolingWork on the fit between technology and process, and the recurring finding that implementing a system without redesigning the process encodes the old inefficiency.
Standards and qualityStandard work in lean practice, and quality management’s distinction between inspecting defects out and designing them out.
Continuous improvementDeming’s plan-do-check-act cycle, and kaizen practice on small changes made by the people doing the work.

All of Operational Systems

What it touches elsewhere

Nothing in a business is decided on its own. A conclusion reached with this model at Operational Systems lands in these other cores, whether or not anyone follows it there.

Goal CoreMost tactical goals land on an operational system, whether or not they say so.
Omni CoreWhat the customer experiences is produced by these systems, not by intentions about service.
Data CoreProcess measures are what tell you whether a system is working before customers do.
Business CoreSystems, people and assets are the three things every operation runs on.

Filed at the same place

These answer questions that arise at Operational Systems too. Where they disagree with this one, the disagreement is the useful part.

The theory of constraintsEvery system has one bottleneck at a time, and improving anything else changes nothing.
Lean thinkingDefine value from the customer’s side, then remove everything in the flow that does not create it.
The McKinsey 7S frameworkSeven things that have to agree with one another for an organisation to work: strategy, structure, systems, shared values, style, staff and skills.

Elsewhere in Business Core

These are other people’s models, named here so you can go to the source and use them properly. The Omnigoal is not affiliated with their authors and is not endorsed by them; nothing of theirs is reproduced here — no canvas, no diagram, no wording. Each is described in our own words, with the originator credited, because the framework is a place to put thinking, not a replacement for the people who did it. Model names and trademarks belong to their respective owners and are used here only to refer to the work itself.

All 125 models