Value Stream Management: Process Depends on Architecture

Value stream thinking is an essential overlay on the traditional organization chart. Org charts are an important structure for control and the flow of information through organizations. The org chart is almost always the main “map” to understand an organization. Yet there are many ways to map a system, and each provides a distinct lens and insight. To paraphrase statistician George Box, “all maps are wrong, but some are useful.”

Org charts speak only to the internal structure of organizations. They don’t express that organization’s relationship with the outside world such as customers and partners. They also don’t express the organization’s most important internal relationships: Those through which work gets done.

Imagine mapping an organization in terms of “how work gets done.” This requires that you first understand “what work are we doing?” We can look at this from different levels of detail. From the company’s mission statement down to the daily activities of an individual employee, we can identify different “whats” and “hows.”

Most of today’s work is knowledge work, which is inherently invisible. This makes value stream mapping in knowledge work organizations even more important than in industries like manufacturing that deal in tangible goods. Yet we are early in the journey of mapping our organizational value streams.

Optimizing the Value Stream

How can we optimize a value stream? There are many approaches to this, but Jan Bosch’s BAPO (business, architecture, process, organization) framework is one helpful approach. This is analogous to the classic People, Process and Technology triad. But rather than a simple triangle, BAPO emphasizes a sequenced approach. The model focuses first on business needs, how the organization generates revenue and profit. Business needs should then drive architecture choices since your architecture needs to support business effectiveness. The architecture in turn determines processes (and how you can improve processes). The organizational structure should in turn be designed around the processes you need to conduct.

Too often companies approach this backward, building processes based on their organization structure; choosing an architecture based on the processes in use; and then attempting to run an effective business based on these choices of architecture.

At the end of the day, every business needs to create and sustain revenue in excess of its costs. Just as energy intake needs to match or exceed energy expenditure for a living being to survive, profitability is viability.

Architecture Should Be Driven by Business Needs

Business needs center around “what value do you deliver to your customer?” The architecture provides the means to achieve these goals. Architecture includes systems you acquire, the way you integrate and customize them, and any custom applications you build to support your business. It also includes the technology stack you use to build and maintain these systems. Often businesses implement a platform like Salesforce, but neglect to consider the DevOps tools needed to safely build, test, and deploy applications on that platform.

The recent State of Salesforce DevOps Report issued by the company I work for, DevOps solution provider Copado, showed that although 82% of organizations in 2020 increased their budget or effort towards digital transformation, 55% did not consistently automate their Salesforce deployments. Most organizations have many opportunities to improve their processes through automation and innovation.

Process Depends on Architecture

Process necessarily depends on architecture. In terms of the development lifecycle, the process depends on what applications you’re building, and the tools you’re using to build them. Typically, we consider tools to be less important than people and processes. In a sense, they are. But processes are constrained by the capabilities of your tools. If you change tools, your processes must change too.

For example, do you have tools in place to make information available to everyone else who’s working on the same system? Version control and agile planning tools function mostly to provide a single source of truth for distributed teams. Do your tools help you reduce risk and deliver value, all while keeping traceability for compliance purposes? All of these are capabilities of your development architecture.

Value stream management is primarily an approach to process optimization. It shows how long work spends in different phases, whether active, or waiting, or inactive. How many handoffs are involved? What is the quality at each stage? Can you reduce, for example, the number of handoffs? Can you reduce the idle time between phases?

The most common villain when looking at process optimization is WIP, or work in progress.  If you have too many simultaneous items in progress, all of the items in the flow will slow down. Limiting work in progress is an important aspect of value stream optimization.

Organizational Structure Should Be Subordinate to Process

The final step is to look at your organization. This is the opposite approach to how most organizations approach this challenge. Most companies begin planning based on their present organizational structure. Changes to the org chart are disruptive, and then begin to look at processes from there. So they, their processes, and their tools and so forth are all subordinate to the org chart, the org chart is considered to be a fixed entity over which no one aside from the executive tier has much power. Org charts involve an expenditure of money; they involve political power within the organization. And while they might be refactored once per year with a reorg, such reorgs are necessarily expensive both in terms of the time involved in planning them and in the disruption that lingers for months after each reorg.

By looking at organizations as subordinate to processes, you can begin to optimize your organization around your changing processes. This is the highest level of adaptability for an organization. Apply human resources to a process only to the degree necessary, and be flexible with allocating your workforce according to the processes required. Importantly, this also means bringing all of the people involved together to collaborate on making updates to the process.

This is one of the most important aspects of value stream mapping. It cannot be a top-down activity, because it necessarily involves knowledge that only people doing the daily work possess. Executives may dictate broad initiatives. But they don’t have the situational awareness to identify the detailed aspects of the value creation process. Value stream mapping as an exercise is a way of bringing people together to identify the stages, as well how long they’re taking and so forth. Just this common activity helps ensure that communication is rich between the teams. This high communication bandwidth between members of the team helps catalyze empathy and coordination.

Underlying the organizational structure is the psychology of each individual person. Just as we often see org charts as a structure we simply have to work around, many people consider psychology to be a fixed element that cannot be reworked for process improvements. In fact, our psychology is quite malleable if we use the appropriate methods. To maximize learning and adaptation, teams need to apply energy and put effort into collaborating with one another, developing a benevolent motivation for their work together and reducing all of the egos involved in the process.

Feature image via Pixabay.