How can surges in demand be proactively addressed before they saturate resources and disrupt flow throughout a system? How can constraints be addressed before they impact broad segments of customers? Engineering and operations each have their own unique characteristics which impact how these challenges can be addressed. Luckily, they both can be characterized in Figure 1, which shows how work flows through the value chain.
To explain the critical features of such a model, let's explore something routine - purchasing an item on Amazon. Many separate activities must be integrated across a series of transactions for something like order fulfillment to work. These activities include orchestration of the supply chain, responding to inquiries, billing, invoicing for payments, and arranging for the logistics of shipping and delivery. Yet all customers need to know about this is what they are being offered, how much it will cost, when they should expect delivery. They don't care about all the underlying details, which involve activities like inventory management, expediting processing, and material handling. They don't care about scaling to thousands of countries, millions of businesses, or billions of customers. They don't care about the complexity of managing inventory, computing taxes, or providing security. All that stuff must be done correctly to make money and provide an acceptable customer experience, but the details only become an issue when something isn't working.
Consider the coordination and collaboration that must be performed across the actors and through the information and goods managed across a value stream. These activities may require orchestration across many different individuals, teams, operating units, locations, and companies. By monitoring the transactions passing through this value stream over time, surges and shedding of demand become more evident. Such fluctuations introduce turbulence, regardless of whether the product is tangible like groceries, or intellectual products like engineering designs. To understand the dynamics of such production systems, each step can be thought of as an abstract engine which accomplishes a transformation incorporating upstream outputs and providing inputs to downstream steps through an interacting set of stocks and flows. A simplified view of this collective network is depicted in Figure 1 (click for an expanded view). Each of these operations can be further broken down into successively more elemental transactions that are performed by roles within each organizations.
In either case, to realistically portray interactions, the flow must represent a managed set of work patterns, and be built from threads of standard work that are capable of producing the right results at the right time. For this to happen, of course, the right resources must be available at just the place and time. Since the size and expected pace of work can vary widely, especially in engineering development, information itself becomes the 'raw material' feeding this flow. Yet without a way of capturing and characterizing this flow, and providing useful feedback to make the necessary adjustments,
Many different mental models are likely to exist about how to respond. At one extreme, everything is in play, and actors are constantly fighting fires. At the other end of the spectrum, centralized control is necessary to authorize each operation and expedite it, much as a packet flow is managed within an information network. To be successful, each actor must have actionable work and make a personal commitment to working together in order to make what needs to happen happen; no one should use the excuse 'it is not my job'.