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.
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.
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.
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.
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.
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?
The address for the RSS feed of this blog has changed. It is now http://feeds.feedburner.com/esjewett.
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 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.
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.
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.
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.
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?
FriendFeed is the hot new thing in social activity aggregation. The basic idea is that it aggregates all of your activity from various online services into one big activity stream. You can find mine here: http://www.friendfeed.com/esjewett.
Doing this type of aggregation means querying the services where content lives on a regular basis for each user. I signed up this blog, so this blog's RSS feed gets pinged on a regular basis. Perhaps too regular a basis.

Those are the stats for a single day. In case anyone didn't notice, I don't post here all that much, so checking ~65 times per day (every 20 minutes or so) might be overdoing it a tad!
Some other feed-catchers do checks at increasing intervals when no new content is found, with a reasonable maximum interval of an hour or so. Such an algorithm, tweaked for FriendFeed's particular case, might save some serious bandwidth. It might also open up bandwidth and processing time to allow it to stay even more ridiculously up to date with frequently updated content.