Excerpt from:  Value Network Analysis
.
May 07, 2009

Some common "role" challenges

Can virtual spaces or databases serve as nodes or "roles" in value networks?

Network expert Pati Anklam (author of Net Work) asked for the current thinking about adding a virtual space (a social networking site, a document repository) etc. as a role in a value network map. This question comes up frequently. There are different schools of thought on this. From the Help Library in the ValueNetworks.com application comes the following:

Why can’t a Role be a computer or a database?
Work is a social activity. Humans may create technologies that mechanize certain tasks, but machines do not make their own decisions about which activities they engage in. Only people make those decisions, determining what activities and transactions are important, and assigning the tasks either to real people, or technology enablers such as applications that can complete the tasks.

But don’t applications sometimes take the place of humans to play Roles?
Yes, they can and do. As technologies become more sophisticated a software program may well be capable of filling a Role. An example might be using an online reservations program to book airline travel. In that case the technology supports fulfillment tasks by acting in the Role of “travel agent” or “reservation service provider.” So even though a software program is capable of filling that Role it is fulfilling it based on the way a real human would typically behave in that Role. The technology is merely a mechanism for a Role to be executed. Focus on the Role first; then consider what might be the most effective mechanisms to support the Role activities.

So, given those guidelines the “role” of a social networking site is really the role of “community organizer” That role is supported by the technology of a social networking platform. But the platform itself does not make decisions – it only does what it is told by the real human “community organizer.” We program applications according to how a real human would execute the role.

Databases are very tempting for people to identify as a role or node in a value network. But the database is just a mechanism to support information deliverables moving from one role to another. From the standpoint of the network it is irrelevant whether the message “your order is in” is delivered by telephone, text message, a website, a face to face meeting or a nod of the head. The deliverable of the message itself is what is important – that it happens between two specific roles.

What happens when people make the database a role is that it becomes a “dumping ground” for all the information and knowledge deliverables that people really don’t want to think through carefully. A common justification is “we just put that in the database for everyone to see.”  My position is that if you are posting something for everyone then you are posting it for no one. Until you have indentified the specific kinds of information that must be exchanged between specific roles you have not really considered the real value (or user) of that deliverable. People do sometimes create a role called “database” but once they start to really go deeper into the analysis it becomes problematic pretty quickly.

Topic Tags:  databases, Pati Anklam, roles, value network analysis, virtual spaces
Comments
.

Why can’t a Role be a computer or a database?

Products and services can (and should) be treated as roles - specific roles for jobs that need to be done.

Clayton Christensen, renowned innovation expert, states...

"[Consider] the sequence of thought you go through when you ultimately end up deciding to buy a product. Somehow, you become aware you need to get something done for yourself. And then the next thought is, "What can I buy or what can I hire, to get this job done for me?" And then you start the search. But what comes to your mind, after you're aware that you have a job that you need to get done for yourself, is that you then start to think, "Who can I hire to do this job?" And so in many ways, we hire products to do jobs for us. We hire services to do jobs for us. If an innovating company focuses on the job, then when you go through that sequence, and you become aware you've got to get that job done, there'll be a product sitting there designed to do that job."

.
.

RE: Some common "role" challenges

This is very much along the same lines of thinking. However, there might be some slight differences. See if this helps.

Let's take the example of sending a contract.

The sending role would be "contractor". The action of "sending" is an action that must be initiated by the role. The "contract" is what is sent to yet another role of "customer".  Now that action of "sending" can be enabled by a technology (email, snail mail, courier, shared work application, whatever.)  So the contract is a product (which we call a deliverable in VNA). I propose that services are also deliverables, not roles. In that sense they would be closer to how I believe you and Clayton Christensen would define a product.

So if I get a massage (which would be really nice about now), that massage is a service. In VNA the role that delivers that service is the "masseuse." The "massage" is a service package that that role delivers to me the "customer."  Therefore the "massage" is the deliverable.  If you want to get really technical they deliver the "massage experience" which includes a whole lot of things, including value enhancers such as cushy robes and slippers, nice smelly things and so forth.

Now this perspective does not completely negate your quote from Christensen, but it does drill it a bit deeper into what a product or services really is in terms of deliverables, which is the value of using VNA to actually model that. The language of "roles" and "deliverables" forces people to be very specific about exactly what it is they (in their specific roles) are really delivering and to whom. It thus drives the accountability for that deliverable to a finer level.

Not sure if this helps. These perhaps are very different ways of looking at the issue. Both can be valuable. We have just found over time that that making  distinctions between a "product" and a "service" can be very difficult because they overlap so much. Products have mini "services" packed into them and services often require products for their delivery. The more generic of "deliverable" seems to sidestep many of these issues.

.