Use Value Network maps to understand how your organization works from the bottom up

August 23, 2010 by  

We usually look at organizational networks at three levels. The first (described as a knowledge factory) is at a strategic level, built on the high-level inventory of an organization’s intangible capital. Today, I’ll talk about the next takes the perspective of the knowledge factory down one more level of detail (third perspective, personal networks comes tomorrow).

This perspective looks at the roles people play in your organization. This is the Value Network methodology described by Verna Allee in The Future of Knowledge (still one of my favorite books on the knowledge economy and why I pursued certification in this methodology*).

This approach involves mapping a network where a specific task or process occurs. The nodes in this network are “roles.” A role speaks to the specific function that a person is playing. This is not their title on an org chart—it is usually more descriptive—such as advisor, buyer, designer, marketer, mentor, partner, problem solver. It is common for a person to serve in more than one role.

Once you identify the roles, then all the different “exchanges” between roles are catalogued and mapped. An effort is made to identify both tangible and intangible exchanges. Delivery of a product, document or money is a tangible exchange. An intangible exchange is something like the sharing of knowledge, an introduction to someone else or personal support. Generally, the tangible exchanges are more formal. The intangible, while less structured, can be critical in creating trust and facilitating better communication in an organization.

This is an excerpt of a Value Network map. It was developed to improve the process for handling complex technology repairs at a large utility company. The excerpt shows the sequence of activity that takes over once a problem has been reported and documented. Solid arrows show tangible exchanges and dotted line arrows show intangible exchanges. The first step is for the Service Coordinator to send the Field Technician a dispatch ticket (tangible) and suggestions on the potential solution (intangible) based on information the coordinator has obtained from the customer. The Senior Tech Advisor also gets a copy of the dispatch ticket (tangible) and provides advisory (tangible) to the Field Tech and the Service Coordinator. The Field Tech provides the service (tangible) to the Customer Tech Manager. If all goes well, the Customer Tech Manager and the Service Coordinator exchange completion documentation and the process ends. If not, the field tech informs the field manager that an escalation may be necessary and a new phase of the process kicks in.

The full version of this map includes upfront agreements as to customer expectations and commitments on service level agreements. There is also a set of procedures for escalating problems that cannot be resolved through the initial work of the field tech. The analysis found a number of places in the process where responsibility shifted from one person to another but the person receiving the hand-off wasn’t getting full information. Communication flows for these hand-offs was improved. The map also graphically showed that initial service level negotiations were handled without input from the field which often led to agreements that did not work well in reality. Small work groups were able to make dramatic progress in the span of just a few weeks.

The power of this approach is that the map is created by the people that do the work that is being mapped. It helps them think through what actually happens in their everyday work—and how to improve it. Unlike pure process maps, this approach also captures the critical exchanges of information and assistance, the human-centric intangible exchanges that help make the system work. The concept of mapping intangible exchanges helps, we believe, to make sense of the multiplicity of goals and benefits that network participants have in a business setting. It also empowers the people doing the work to improve it themselves. This kind of bottom-up thinking is critical to the optimization of the knowledge enterprise.

We also like Value Networks as a case study for operationalization of knowledge and its 21st century business model. From its beginnings in the mid-1990s, the methodology has been developed into both an open source and commercial offering. There is also a software package that facilitates the analysis and visualization of the network maps. Rather than trying to keep the methodology as a proprietary offering, the group is maximizing its reach and impact by empowering people on the line inside organizations to model and optimize their own work.

Adapted from Intangible Capital: Putting Knowledge to Work in the 21st Century Organization by Mary Adams and Michael Oleksak.

*Mary Adams is an Advanced Practitioner and
Facilitator of the Value Net Works methodology and is currently working
on several articles about our firm’s work with Value Net Works.

Enter Google AdSense Code Here

Comments

4 Responses to “Use Value Network maps to understand how your organization works from the bottom up”

  1. Verna Allee on August 24th, 2010 1:29 pm

    Mary, you did a great job summarizing both the method and the philosophy – including the”open” philosophy of the value network community in sharing know how. Verna

  2. Mary Adams on August 24th, 2010 1:40 pm

    Thanks Verna! I am a real believer in the power of this bottom-up approach to problem solving and innovation that engages employees from the beginning. Mary

  3. Peter Evans-Greenwood on September 5th, 2010 9:23 pm

    Hiya,

    Interesting, but this falls into the same trap as most other process improvement methodologies. Namely, it’s focused in the incremental improvement of an existing process, rather than providing a means to find the optimal way to deliver the desired outcome. Mapping the roles and interactions is a good way to establish the best way to support these established roles, but what if a bunch of these roles are not really required? What if our process is solving the wrong problem? This approach allows us to streamline cruft, but it doesn’t allow us to eliminate it.

    Methodologies like i* have done a nice job of working from stakeholder hard- and soft-goals (i.e. functional and non-functional requirements) to define what must happen to deliver the outcome we want. Integrating value networks with the late requirements phase of these goal-based techniques would be interesting. Plus a lot of the work on formal methods done by i* et al would explicitly connect the network to SME incentives etc.

    r.

    PEG

  4. Mary Adams on September 6th, 2010 7:00 am

    My experience with value networks is that having employees engage in mapping a process from the bottom up leads them to question all sorts of things about the process including what are the right roles and what are the needs of those in the network (which gets to your question about defining the problem and stakeholder goals).

    Although this post doesn’t explain this aspect of the methodology but we often create an “as is” map and a “how it should work” map. To do this successfully, you are right, it is important to start with the goals of the process/network and of each of the stakeholders.

    Thanks for the references and the new vocabulary with cruft!

Feel free to leave a comment...
and oh, if you want a pic to show with your comment, go get a gravatar!