Value Networks and Value Stream Management
From Purpose to Process
This is the third episode in our series of posts on Value Networks.
Verna Allee initially developed this mapping and modeling technique and elaborated on it in her book Value Networks and the True Nature of Collaboration.
While she developed these ideas in contexts other than software product development, I believe they help us express the collaborative nature of complex knowledge work in richer ways than many of the techniques we use today to model software development processes.
This post will discuss how Value Networks relate to Value Stream Management in software product development.
Value Stream Management
Peter Hines and colleagues introduced Value Stream Management (VSM) as “a strategic and operational approach to the data capture, analysis, planning, and implementation of effective change within the core cross-functional or cross-company processes required to achieve a lean enterprise1.
This remains an excellent general definition of Value Stream Management, even if the original concepts were developed in the context of industrial production processes and supply chains.
Let’s focus on a few key aspects:
VSM is fundamentally about improving processes.
It targets cross-functional and cross-company processes, those that require collaboration across organizational or inter-organizational boundaries.
VSM has both strategic and operational components.
It relies on data to analyze, model, plan, and implement system-wide changes.
The primary goal is to ensure effective change—improving the enterprise's ability to create value more efficiently.
Under this definition, VSM is focused on changes beyond local, continuous improvement efforts (e.g., Kaizen); it emphasizes collaborations at the company and cross-company levels that require coordination among autonomous participants to identify system-level improvements and implement changes2.
While these changes are typically strategically important, they are among the hardest to operationalize. Therefore, a holistic approach to visualizing, modeling, and reasoning about them is critically important.
Value Networks are a powerful tool for tackling this challenge.
Value Networks: A Recap
The Value Network is a straightforward concept built from three simple primitives: roles, transactions, and deliverables. Roles represent (groups of) people and the parts they play in a value-creating collaboration. Transactions represent interactions between roles that exchange something of value. Deliverables represent these things of value and may be tangible or intangible.
Value network mapping aims to identify the roles, transactions, and deliverables in a network of value exchanges.
In our previous episode, Value Network Mapping: An Example, we illustrated how we might model a value network for an example software company, AssetManager PRO. We mapped the value network at three levels of detail and explored choices for modeling the flow of value.
Figure 2 from the last episode shows an example of these levels of detail.
By mapping roles, transactions, and deliverables, Value Networks enable us to capture tangible and intangible value exchanges between participants.
This helps us see the big picture, defining the ‘flow of value’ and revealing key areas where value is created or could be enhanced across the business network.
With these fundamentals, let’s dive into how these models represent the flow of value within an ecosystem.
Modeling the flow of value
At the top level, the business value network, roles represent business entities such as the company, its market, suppliers, partners, and competitors. These are the participants in the product ecosystem.
The business value network serves as the strategic canvas for Value Stream Management, where the goal is to harness and optimize value flows within the network to maximize value for both the company and its customers.
This network is a model of an open, complex adaptive system in which roles are evolving populations of participants, and transactions represent measurable value exchanges between these participants.
The “flow of value” is defined by the value exchanges in the business value network. Transactions between roles and their deliverables represent fundamental, measurable units of value exchanged between participants. These include tangible exchanges such as money and products and intangibles such as brand value, reputation, trust, customer satisfaction, etc. Only transactions that result in a concrete exchange of value, whether tangible or intangible, contribute to the flow of value.
Figure 3 shows the business value network for AssetManager PRO. I recommend reviewing our description of this network in the last episode.
The business value network is, first and foremost, a sensemaking and visualization tool that allows a broad range of stakeholders to come together and build a shared model of the value-creating ecosystem the company supports. This brings greater clarity to our questions about how the product ecosystem creates value.
Constructing a value network model should be collaborative, drawing on diverse stakeholder perspectives to represent the product ecosystem accurately. The choices made when modeling roles and transactions in the network will significantly impact the insights you can derive from them.
From Visualization to Analysis
When we augment the value network with notions of state and history, the visual models can also be extended to build powerful tools to analyze value creation dynamics in the network.
We may, for instance, define the network's state as the value accumulated with participants based on their history of value exchanges. Transactions cause changes in the network state and may also change population distributions between roles; for example, a successful sales transaction may convert a consumer from Prospect to Customer.
By analyzing the system dynamics of the value network with these definitions: the value exchanges, the population movements between roles reflecting value-seeking behavior, and the analysis of transaction activity over time, we can identify causal relationships to understand value-creation mechanisms within the network.
Systems dynamics models help identify where we can intervene to improve the flow of value in the network and verify whether the changes we make to the system are effective—i.e., do they enhance the flow of value?
In an upcoming post, we will explore how to create these types of systems dynamics models for value networks.
Modeling the flow of work
Once we have modeled the flow of value and identified potential areas for improvement, we can focus on improving the processes needed to support this.
This is the core mission of Value Stream Management. Traditionally, operating model design, organizational design, and lean process engineering have all focused on this topic.
These disciplines focus on the organization’s internal structure, processes, and resources within its boundaries. They position customers, partners, and other external actors outside the system boundary and aim to optimize internal structures, capabilities, and processes to serve these external actors.
The value network offers fresh perspectives here. Since every value exchange in the business value network crosses an organization's boundary, it is helpful to have a way of representing these exchanges that cross the boundaries of the system being analyzed.
In our previous analysis of AssetManager PRO, we introduced the notion of refining a value network, which allows us to zoom in on a value exchange in this fashion.
Every such refinement of a business value network creates a new value network with roles and interactions that cross organizational boundaries. The refined network models the dynamics of these collaborations across organizational boundaries at increasing levels of detail for roles, transactions, and deliverables. We’ll find this technique helpful in analyzing both cross-functional and cross-company collaborations.
The refinement operation is somewhat different from a structural decomposition of the network. Rather than breaking the network into parts and studying how the parts behave, we focus on the interactions between the parts and examine how those interactions behave at greater levels of detail.
Since system behavior emerges from these detailed interactions, refinement is an essential technique for modeling and analyzing value exchanges in complex systems models like business value networks.
In Fig 2, we showed the business value network refined to two levels of detail. Let’s examine these more closely.
Organization Networks
At the first level of detail, we are primarily concerned with how the organization is structured to support the business value network activity effectively.
The refined value network is focused on interactions between teams, departments, etc., within the organizations and with their collaborators outside the organization in the value network.
Figure 4 shows an example of a refinement in which we zoom into the interactions between different AssetManager PRO departments and the market.
Note that we continue to model both “sides” of the value exchange in this network. Thus, there are cross-company transactions (which refine the business value network) and new cross-functional transactions between departments, which we will largely focus on in Value Stream Management.
This refinement can be used to model the impact of changes in the organizational topology on the flow of value in the business value network.
We could also have created refinements using other organizational perspectives, such as teams, or with other external collaborators, such as partners or suppliers.
Transaction Networks
The second level of refinement, the transaction level, zooms into the interactions for a specific transaction using even more detailed roles. Again, we are zooming into detailed collaborations within and between organizations that lead to a successful value exchange in the business value network.
Figure 5 shows the transaction network for a Buying Transaction in the business value network. Note that in our refinement, we have maintained roles for buyers and sellers and that the transactions in this network span organizational and functional boundaries in the asset manager PRO organization.
This is the domain of traditional processing engineering. Value network models are also applicable at this level. However, it is helpful to view them as augmenting the conventional process-oriented perspective focusing on the steps required to create the deliverable (the value stream view) with a collaborative perspective that captures the roles and interactions of internal participants involved in producing these deliverables (the value network view).
Combining value network representation with value stream maps and other related processing engineering tools is feasible and valuable here. Figure 6 below shows a traditional Value Stream Map for the Buying transaction alongside the value network map view from Figure 5 above.
Both maps provide helpful ways of examining the underlying collaborations in the network. The value stream map is much more convenient when reviewing a summary view of the process and where time is spent. It tells you what needs to happen to close a deal successfully and surfaces critical metrics that drive this success rate. In particular, it lets you focus on where time can be shaved off in the process.
The value network view is much more detailed and focuses on who must collaborate to close a deal successfully. Sequencing the map will often yield insights into poor information flows that lead to excessive delays in the value stream map.
In collaborative knowledge work, the real constraints to workflow are often people’s capacity to fulfill their collaboration roles due to incomplete knowledge and information flows and poor collaboration and communication structures.
Looking at these sequences of interactions in the value network reveals a temporal view of this map. These can be used to build causal models for the metrics in the value stream map. You may also drill deeper into each of these transactions with an additional value stream or value network map to model and optimize them in more detail.
Value networks are potent tools for explicitly visualizing, modeling, and reasoning about these collaboration constraints. The example above shows that they effectively complement process-oriented representations like value stream maps.
In her book, Verna Allee demonstrates many use cases for value network models in process improvement. She shows how to use value network maps to optimize complex internal operational delivery process workflows. Her applications often followed a lean process engineering approach to the problem!
We highly recommend reviewing more examples from her book to understand how these techniques can complement each other.
Beyond this level of detail, we can focus on the flow of work needed to produce specific deliverables for the transactions in this network. Since deliverables have a single source role, we are now zooming in within a single organization in a business value network to understand the processes that produce a single deliverable.
We are now squarely in the realm of process engineering, and as shown above, value network maps are one additional tool we can use here.
Summary
One of the most appealing aspects of Value Networks is their simplicity and flexibility. With carefully defined semantics, a single representation can capture and clarify the relationships between the flow of value and work across various levels of detail.
While Value Networks integrate seamlessly with other models, their unique strengths make them particularly effective for modeling complex, collaborative knowledge work.
Value Networks complement and extend existing VSM practices, helping to realize Peter Hines and his colleagues' vision of creating leaner, more collaborative enterprises.
In the next episode, we will study the Buying transaction in more detail to understand the relationship between the flow of work and the flow of value3.
See you next week!
This definition of Value Stream Management takes a much broader view of VSM than what you might find in existing descriptions of VSM in software development from industry consortia or analyst firms.
I start with this definition intentionally. I believe the narrower focus on current approaches to VSM comes from the concept being first introduced in large, non-native digital companies transitioning from project-based software delivery to product orientation. Here, the main focus is building a product-oriented software development capability to replace siloed handoffs between technology and business functions.
The methods and models we describe here are well-suited to those environments. Still, they may be too advanced to implement without the basics of a product development infrastructure.
In pure-play software product companies, the basic technical and product management infrastructure for creating and delivering software products is already in place.
Thus, the more general framing of VSM here highlights the core problem VSM is best suited to tackle: structured approaches to cross-functional and systemic improvements in existing processes so that we can improve the effectiveness and efficiency of software product development in a market-driven environment.
Hence, we are basing our definition of VSM on the classic definition, which I think is much more suited to software product companies. It will eventually become the focus even when non-native software companies' basic product development infrastructure has matured.
This is not to say Kaizen is not important—it is critically important. But with VSM, we are interested in systemic changes that do not happen purely organically from local improvements made by autonomous teams.
“But I thought you would talk about product development, Krishna? What’s all this focus on Sales?” you might be asking.
Patience, I’ll get there!
There is a method to this madness.
Just like it is simpler to study roundworms before we move on to humans, we’ll look at the somewhat more straightforward case of Sales to understand how we can frame the problem of what it means to connect the flow of work to the flow of value using the machinery we’ve built up so far and then see what it takes to generalize this to product development.