Imagine assembling a 747.
The aircraft is extraordinarily complex. Construction requires many parts, precise tolerances, specialist skills, and extensive coordination. It is also difficult, expensive, and time-consuming.
Now suppose you have complete, correct schematics, verified assembly procedures, exact interface specifications, and clear tests at each stage. You also have the equipment and expertise needed to follow them.
Engineers have already resolved much of the systemic structure and encoded that understanding in the instructions. You still face an enormous task, but you have a dependable account of what to do and how the parts must function together.
Now remove the warehouse indexing system. The instructions identify the parts needed for the next operation, but finding them takes hours. The task becomes much more difficult without a corresponding increase in uncertainty about how to assemble the aircraft.
Finally, remove the schematics and verified procedures. You have the same parts and the same objective, but must discover which arrangements work, which interfaces are compatible, which sequences are viable, and how to determine whether the assembled system will perform safely.
You must now reconstruct the systemic understanding the instructions supplied.
The distinction matters.
Complexity concerns the structure, variation, and intricacy of what is involved. Difficulty concerns the demands of accomplishing it. Systemicity concerns the profile of complexity that makes the realization of purpose non-obvious.
A system can be highly complex yet well understood for a particular purpose; another can be simpler yet systemically demanding because the relevant configuration, dependencies, or path are unclear.
The aircraft’s interdependence remains present even with perfect instructions. The instructions relieve the assembler of having to discover and resolve much of that interdependence. Good representations, tools, interfaces, and accumulated expertise make the undertaking tractable.
The aircraft illustrates only a narrow slice
Even without the manual, this example holds much of reality conveniently still. You know which aircraft you intend to build. Its parts conform to a known design, and assembling them correctly fulfills the objective.
The systemic challenge centers on reconstructing that arrangement and its assembly sequence. An enterprise encounters a much broader problem.
It must determine which capabilities are worth building before it has a design to reconstruct. During development, employees and customers respond to its choices, influencing both what works and what remains worth pursuing. Competitors and technologies evolve independently, changing the value of the intended destination.
A closer enterprise analogy would require deciding what kind of aircraft to build while the available components, prospective passengers, and competing forms of transportation were changing. Building experience would reveal new possibilities, and each commitment would affect which of them remained practical.
The missing manual demonstrates one form of opacity. Enterprise systemicity combines that opacity with emergence, adaptation, changing possibilities, and consequences that feed back into later action.
Return to the fuller account of systemicity’s manifestations.