business

The infrastructure coop and the web

(In which I take a moment to meander on a topic about which I know very little.)

In Doc Searls' recent writing on "The Ultimate Alignment" he writes on the disconnect between the interests of the companies that are building the web and the people who are using it. To summarize, companies have (or are supposed to have) their investor's best interests in mind rather than the best interests of their customers and users. 

Theoretically, our efficient market system is supposed to align these two groups of interests. Or at least mediate between them. In theory, theory and practice are the same. In practice they tend to differ and one group of interests has a tendency to be subverted. When it comes to situations like the recent Facebook acquisition of Friendfeed or cable and telecom companies colluding with the recording industry to restrict peer-to-peer connections, the disconnect between the interests of users and investors comes into stark relief, and we see that users can be left out in the cold when interests conflict.

Customers have generally been getting the short end of the stick, or the pointy end if they're especially unlucky. This can, and probably should be attributed to a lack of customer organization and a resultant lack of bargaining power; something that is starting to be addressed with varying success by the social web, and which Searls sees culminating in a real capability for direct customer negotiation, which he calls Vendor Relationship Management.

A somewhat alternative approach proposed by Dave Winer, which Searls writes about in the above linked article and to which he appears sympathetic, is the tale in which the customers seize the reins of power and re/self-organize companies into a sane and impeccably moral engine of economic progress, for the good of all. [Ed. Sometimes he has a hard time keeping the lid on the sarcasm, especially in entries written on airplanes. Must be the altitude.]

Despite the sarcasm, I'm incredibly sympathetic to this idea, so after all of that throat clearing, I'd like to think about how it would work. What Searls and Winer are suggesting is a customer-owned coop.

Coops are cooperatives

My understanding of a customer-owned coop is that it is a business which is wholly owned and capitalized by its customers and the purpose of which is to provide a specific service rather than to turn a profit. If additional capital beyond what is required to deliver the service is generated, that capital is returned to the customer/owners. If an existing customer would like to become an owner then they can invest the requisite amount in the coop that is required to receive an equal share. Usually there is some ownership incentive provided, such as the ability to make use of the coop's services, or a discount on those services.

There are lots of kinds of coops, from housing and utility coops with services available only to owners to grocery stores and book stores which operate as commercial entities and often provide only slim discounts to owners. Public companies and governments are arguably coops, though they are not usually acknowledged as such and are usually not strictly customer/user-owned. (Though this is usually fairly close to the truth in the case of democratically elected governments with an electoral process that is relatively uninfluenced by monetary concerns ... and we know there are plenty of those around. [Ed. This sarcasm is getting a tad out of control, isn't it?])

Coops are often formed to establish some vital piece of infrastructure that a community feels is not adequately provided by existing commercial or governmental entities. A community that is lacking a quality grocery store will sometimes establish one as a coop. A university community that feels its access to academic books is restricted or provided at far too high a price by a commercial book store might establish a coop bookstore, effectively buying itself a distribution channel that did not exist before. Same goes for utilities.

In this way of thinking, coops are usually focused on infrastructure, with a special focus on distribution infrastructure during the 20th century. Distribution of food, books, natural gas, or electricity.

Open source is a bit like a coop ... and how

Open source software development is like a coop. The buy-in is contribution, of code, testing, bug-wrangling, documentation, publicity, or community process. The ownership privileges are varied. Contributions of code usually buy the contributor partial ownership of the code-base and the accompanying control, depending on the license - a privilege that cannot be purchased in any other way. Same goes for contributions of documentation vis a vis the body of documentation. All other contributions buy a less well defined voice in the community process.

Open source projects often resemble coops in another manner in that they are usually established to fill a need that a community feels is not adequately met (or is not met at an appropriate price) by existing commercial offerings. Some of the most successful open source projects have been and continue to be focused on infrastructure.

Open source as barter coop and the problem therein

This ground has been pretty heavily tread before, but the above description is of a coop established via barter, rather than exchange of more abstract monetary instruments and the signing of binding legal contracts. Importantly open source projects are only open to ownership by individuals who are prepared to deal in a particular instrument of barter. Open source is a bazaar, but it is a bazaar that is only accessible to those who can pay the entrance fee in a particular currency. It is a bazaar, frequented only by merchants and large distributors, not by individual shoppers. It has the best prices and the best goods, but good luck getting to them.

And therein, of course, is a problem with the open source cooperative model. The strength of many cooperatives is that any interested user can become an owner (and often does), and this is the model that Winer and Searls would like to see, it seems. But in the open source world this is not the case. In meat-space cooperatives, and bazaars for that matter, the answer is money. Anyone with money can buy a share in a coop grocery store. You don't necessarily need to be able to contribute broccoli or organic lamb to participate. 

Coops as cooperatives (and the trouble with staying that way)

Often coops seem to work best when they are providing services to a local community. This may be partially the case because it reduces the interest in joining a coop for reasons other than taking advantage of the primary service that a coop provides. This local focus can be used as a hedge against the possibility of a group of disinterested investors taking over the coop and turning it into a profit-making operation, divorced from a direct interest in providing a service to its customers and instead focused on providing a service to its owners (now two different groups of people). Viola! Modern commercial entity.

For this reason I very much doubt that founding a new company and immediately IPOing as Winer suggests would not accomplish the goal of creating a company that is truly aligned with its users and customers to provide a service they desire or require. Some guard or incentive must exist, as is the case with coops, to keep the coop owned by its users and customers, yet still open to membership from new and interested users and customers.

Open source projects don't have the local angle going for them, but truthfully there is precious little to gain from participating in an open source project if ones goal is not to improve the project. Ego and a bullet on the resume perhaps. Through narrow focus and severely restricted ownership, these projects make sure that all owners are user/customers, even if they cannot guarantee (and in fact do not aspire to a reality) that all users are owners.

And so we come to the point

We have open source projects, which are fairly successful at making sure that they are guided primarily by input from user/customers but which can do a fairly bad job of making sure that all users/customers are well-served. We have commercial entities which do a good job of serving their owners but a bad job of making sure that their owners are also their customers, resulting in divergent interests. We have local coops, which tend to do a pretty good job of both but don't tend to scale well past a local community.

And then we're talking about essentially a distributed infrastructure coop that shares some of the best features of local coops and commercial entities. What structural features could a web-infrastructure cooperative boast that would meet the following necessary requirements?

  • Any user/customer can (and often does) become an owner
  • Only user/customers become owners (with the possible exception of a small minority ownership by other interested parties)

I don't know the answer to this question. In fact, a part of me doubts that there is an answer and that we will be better served attempting to scale community processes. But it seems it is the crux of the problem of the dis-alignment in web infrastructure.

Process flexibility

As currently available, nearly all process platforms are organized for central design of the process and, by extension, require central control of the process. This sort of systems design does a poor job of identifying and enabling process improvement.

The best central design process platforms are spreading out control within a hierarchical system that is designed for central control. Sometimes these systems can succeed, as in the case of the Toyota manufacturing system or Best Buy's ROWE system. But they seem to be working against the grain. Existing platforms work against the management maxim to push decision making as far down the hierarchy as possible because they demand that the final decision be made in a central group, or even more awkwardly, by a consensus of central groups that have grown up their own bases of power.

This is in contrast to a mythical system that allows for organic process growth by facilitating small (or even large) process changes at the periphery, without any involvement from a central decision-making organ. The work of the organization is then to measure the effectiveness of these slightly changed processes in the real world rather than in a mental model or simulation. Decision making becomes a matter of choosing the right measures for these processes, itself a process that can be measured. The measures go all the way up the chain to "what do we want to accomplish?" and "what are the constraints on how we ought to get there?"

At what level should processes be personalized? How far down the chain should the decisions be pushed? Ideally, any person who has a job description be able to control their job process, at least within limits. An important part of this is giving each person the resources to understand and evaluate the impacts of changes to their processes. These impacts might be in productivity, cost, environment, employee/customer satisfaction, etc. Impacts are also on multiple levels: the individual, the department, the group, the division, the company, the industry, etc. The resources for understanding and evaluation will inevitably be focused on a few of these facets but should acknowledge the existence of all of them.

What about the risk? How can we allow people to run off and change the way we do business without vetting the impact before-hand? They might mess something up.

I'm pretty certain that we're already messing up. There's definitely a lot of upside potential in the organizational effectiveness department. The keys here are going to be developing organizational strategies for understanding and evaluation rather than developing securities and controls, as most damage that is done by errant employees appears to be done through a lack of understanding rather than any sort of maliciousness. The effectiveness of most IT and process controls is in their ability to prevent people from making inadvertent mistakes rather than knowingly causing damage. Once this is accepted it becomes clear that establishing control is secondary to establishing understanding.

Organizations may begin to focus the design of their process systems on aligning change and impact, thereby allowing for isolated changes that avoid side-effects across the organization. A sort of functional programming paradigm of process design. This is not the only option, but it fits in with the ongoing theme of decoupling business units. Another option might be to control change to be within certain predetermined guardrails, or to be in accordance with business rules developed in a parallel business rules and controls system, to allow for maximum optimization and flexibility within a more integrated business.

I hesitate to say that this will enable "evolutionary process", as it seems unlikely that we will never achieve the level of iteration and competition that might be necessary for evolutionary process design in the near future. But there appears to be a lot of room for tapping individual and small-group initiative both to improve processes at an organizational level that is not currently seen as cost-effective, and to relieve frustration with centrally developed and decreed processes.

Process problems and one answer from thingamy

I've been playing around with a business process platform called thingamy lately. It's an impressive piece of work. As with all software, it has a long way to go, but the path is fairly clear. I'm looking forward to the day when it is interoperable enough that I can use it as an everyday tool.

For me, the really interesting thing about thingamy is not so much the tool or the technology (Java, semantic, etc.) as the thought behind it and the difference of approach to a well-known problem, which has gotten me thinking (yet again) about process design and some of the problems in that area. Thingamy is built around the concept of a barely repeatable process (BRP), a concept that almost immediately causes one to recognize that the cost of instituting processes is too high and current process platforms are not sufficiently robust.

What's a process?

A process is a set of tasks and decisions that is part of the daily work of getting the job done. If you work in the average office, you deal with processes on a daily basis - checking out a conference room, asking a question of a colleague, getting a new keyboard to replace your broken one. If you don't work in an average office you deal with process too, but it might not be as recognizable as such. Some of these processes are more human than others, some are more repeatable than others, some more useful than others, but they all share the trait of being steps that result in getting something done.

In many organizations there is a belief that processes like those described above should not range free through the organizational structure as in the days of yore. Rather, they should be corralled into technology systems where they can be properly monitored and maintained. The efficacy of this approach to process is debatable, but it is not much debated. It is these organizations and these types of processes that I'm talking about below.

The cost of process

One of the largest hurdles to turning an organic process in a business into a technology-supported process is the time and money involved in doing so. In most medium and large companies with current ERP systems a person who sees an opportunity for improvement in a process or for the creation of a new process is faced with the daunting task of justifying an expense that totals in the $20,000 - $500,000 range.

That's a big number. Let's back that up:

This is an example of a workflow/process build estimation tool tailored to SAP's workflow technology. For the simplest possible workflow (5 steps), it provides an estimate of 32.5 person-days for the technical build. This does not include a myriad of things that require significant effort, like business process design and testing, or ongoing maintenance. I use this example not to pick on SAP (estimates on a similar order of magnitude hold for most process development environments) but to show the magnitude of the problem. (Hat tip to Jim Spath for making this available and Susan Keohan for blogging about it on SDN.)

Those who read the BRP link above will now say, "that makes it nearly impossible to justify the creation of processes that will only be used by one person or by a small department." Those people are right, but it's worse than that: this cost also stunts the ability of an organization to conceptualize, test, and grow processes. A lot of process growth that occurs naturally is organic, starting with one or a few people as a trial and then spreading out to the rest of an organization once benefit is realized. The high initial cost of process mostly precludes this sort of organic, exploratory process-building.

Thingamy certainly takes aim at the difficulty and cost of creating a new process and maintaining existing processes. Process creation is surprisingly easy and robust (we'll get to this later). Check out the video on creating an expert consultation process in under 20 minutes. The flow isn't complete, but it would be conceivable to iterate development on this flow 3-4 times in a single day; more if the person building the flow is also the person who will be using the flow.

Robustness of the process tool

Thingamy is also a robust process building tool, once you figure out what the heck all the pieces are doing. This is important because a lot of no-code business process modeling tools trip up on branching, looping, or interfacing problems and end up requiring code. Additionally, they have often so over-loaded their visual representations of processes that it is next to impossible to model anything but the most simple process.

For a basic example of this complexity, take a look at these "Email voting process" outlined here. The email voting process itself is made up of a several other processes such as the "Collect Votes" process, each of which are of similar complexity and is completely invisible from the overall process view. Thingamy's textual representation, focus on robustness of process description, and process re-usability is an example of another, apparently better, approach.

Onward and upward

Those are some gripes about the current state of business process systems where I see some light at the end of the tunnel. There are also areas like personalized processes and exploratory process-building where I think the hurdles above exist but the tools haven't even begun to attempt to address the problem.

What areas do others see where improvements could be made? What interesting tools haven't I seen?

Getting on with environmental and social responsibility

Personal environmental impact reporting has taken off over the last couple of months. I've seen personal carbon reporting crop on on Dopplr and The Carbon Account. The corporate side of this movement is documented on blogs like Green Monk and Wisdom of Clouds.

Over the last few weeks, some thoughts have been bubbling around thanks to multiple conversations and some interesting blogs linked below, the motivating question being how to close a feedback loop around environmental and social impacts, and thereby (hopefully) influence behavior.  One example paradigm is the area of nutritional information on packaging.

Nutrition reporting

Nutrition facts on our food products are now a fact of life. Nutrition labeling arguably allows consumers to make more informed purchasing and eating decisions. The value of this informed-ness is, I think, dubious in the context of an individual purchasing decision because of deficiencies in our ability to extrapolate from specific experiences to the general conclusions, from health impact data to healthy life choices.

But providing information gives the purchaser the power to take a more methodological approach to comparing choices.  Advocacy groups have seized on this information to raise awareness and recommend good choices for purchasers.

Competing on nutrition

Food producers, in turn, compete on the basis of the nutritional content of their food and the resulting third-party analyses. For leading corporations and small producers who relish the opportunity to seize the initiative, this new competitive arena has proven rewarding. Rewarding in the sense of profitability and brand recognition, but also in the sense of an evolutionary (though certainly not revolutionary) improvement in the nutritional health of those who eat these products.

Competing on carbon, water, and industrial emissions

With the growing awareness of the environmental, social, and economic impacts of our lifestyle and our production, I wonder if the time is ripe for a more comprehensive acknowledgment of impact through reporting on packaging. Should we have a "carbon impact" section on our packaging right next to "saturated fats"? Should we list water consumption in liters? Should environmental poison emissions like mercury be listed next to the "vitamins and minerals"? Should this reporting be applied to all products, not just those food products that currently sport "nutrition facts" labels?

The answer is probably yes. Leading corporations and producers should welcome and embrace this sort of challenge. As JP Rangaswami has been repeating lately, following Peter Drucker: People make shoes, not money. Anything that can help us make better shoes is probably a long-run win. "Better" is consistently coming to mean greener, healthier, and more socially responsible.

What would be needed?

To report externally in these areas would not be easy, but work on the thorniest issues appears to be underway. Development of reporting standards and metrics would be required. Independent organizations like the AMEE, GRI are working on these issues. Government organizations like the EPA or the DHHS (and equivalents) would probably need to be involved. A knotty question: Could this be a voluntary movement or if it would require government mandates?

Reporting competency would have to be developed internally before accurate external reporting is possible. The internal reporting infra-structures of corporations tend to be focused on financials, specifically revenue and costs. It may be possible to re-purpose or extend financial systems to include additional measures such as carbon costs. Other systems may have to be built from the ground up, such as energy usage monitoring and management systems.

All this costs money, but I wonder if these campaigns can be financed as marketing, employee satisfaction, corporate transformation, or performance management efforts? I'm sure most capital projects for energy efficiency have been justified in this manner. The payoff from a well-executed impact reporting effort would come in all of these areas and more.

Is it going to happen anyway?

If a carbon tax or universal cap-and-trade system is ever put in place in a country where a company operates, this type of reporting will become a requirement of doing business, rather than a requirement of doing business well. Would it be advantageous to get ahead of the curve and start doing business well now?

Intellectual property value - speed is key

Knowledge isn't worth anything if you don't use it. Similarly, intellectual property, the crystalized product of knowledge, isn't worth anything if it isn't consumed. Compounding this is the fact that knowledge products age fast. Screencams and whitepapers are old news in a few months. Blog-style analysis is out of date in a matter of weeks or even days. There is some content that stands the test of time, but most of the output of knowledge workers experiences a very fast decay in value.

Over the last few weeks I've found myself making the same point several times, so when I saw this image, it struck a chord.

Intellectual property has the shelf life of a banana

(Image courtesy of Tom Matrullo and the FASTForward blog.)

When evaluating how to handle knowledge products, businesses tend to focus on how best to defend the value of their investment by keeping it out of the hands of their competitors. This approach is especially prevalent in knowledge- and skill-focused industries like professional services and it is usually misguided.

Since most intellectual property loses value so quickly, it is imperative to extract as much value as possible as quickly as possible. Protecting the investment should be a consideration, but value extraction should be the focus. Value extraction is often enhanced by sharing these types of quickly diminishing IP.

The exception is when a firm has developed a considerable ability to quickly extract value from intellectual property in a closed system. Companies like Gartner and Forrester have this type of ability in place, but even some analyst firms like Redmonk have gone the open source analysis route and found it to be a solid business model.

The bottom line: If it's not your business to sell IP, I'd second guess the impulse to act protectively towards your IP. Instead, think about extracting the maximum value as quickly as possible. Then get back to work generating more of the good stuff.

Syndicate content