I love Web services, for all the things they can't do.

It's not that I'm a pessimist, prone to look at the glass as half empty. Quite the contrary. Whenever I hear about Web services, I think about all the promises that won't be kept, and to me that looks like an opportunity to fill a void.

Web services will undoubtedly create an avalanche of new development opportunities. By standardizing interfaces and protocols, we can provide a common way for applications to communicate and data to be transmitted.

Solving application integration and data integrity eliminates two of the biggest headaches for CIOs today. (Security, policy administration, and others should naturally follow.)

But it's the next phase of Web services that I don't buy. And, unfortunately, this is the one where many people believe the hype. This is the notion that if we can break our applications into small enough chunks, and make them talk to one another, these components will magically come together to provide services that automate many tasks within our business processes.

You've probably seen the consumer-oriented demos that illustrate the point. You're on the road and your gas tank realizes it's running low, so it pings the GPS/cellphone combo to find the nearest gas station for your preferred brand. An enterprise version of this scenario might be around a business process. Perhaps it's a procurement system that constantly monitors a set of suppliers for the best price on a particular component and automatically places the order when its time to replenish the stock.

What's wrong with this picture? The problem is in the way we think about and model business processes. On paper or in theory, all business processes are perfect. Perfect, that is, until we get people involved.

In any business process, we have both transactions and interactions. We can automate transactions in black and white, yes/no binary format, but people interact in a world of fuzzy decisions, and work in that gray area of abstract concepts.

Worse yet, humans are unpredictable in behavior. We like to change things. We like to tinker with processes. We're not fond of talking to machines; we actually prefer to communicate in unstructured environments with other people, all of it disconnected from the world of transaction-based systems.

While our enterprise applications hum along automating transactions, we're holding discussions and debates, delegating tasks, and seeking approval in a parallel universe. Typically, this is done by e-mail, inarguably the de facto environment within the enterprise for communicating and collaborating.

So we design the perfect processes and build software applications to help automate the processes. Then we deploy the apps, and chaos ensues. This chaos manifests itself in what the industry euphemistically describes as an "exception."

There are two types of exceptions: those generated in a silicon-based world that doesn't understand the vagaries of human thought, and those generated in a human world that can't resist changing the rules. Let's look at each case.

Imagine a supply chain: an order is received on your docks from a supplier - only the count comes up short. Your receiving clerk will enter the count into an order management system and it will recognize the disparity. The best systems will even generate an e-mail alert.

What happens next? The recipients of that e-mail work to resolve the problem. Typically, they'll communicate and collaborate with their colleagues and superiors - by e-mail. When they reach a decision, they'll go back to the systems world and input the changes.

In the second scenario, imagine an application for automating pricing policies. Our star sales rep has a deal that's just too good to pass up. Problem is, it requires a 45% discount and the pricing policy is set at a 20% limit. No sense tinkering with the CRM system, it isn't programmed to accommodate a one-off change to the pricing policy. So our sales rep fires off an e-mail to the VP of sales, who makes an exception.

In both instances, we have parallel universes of systems and people. One works in a structured, binary mode; the other is more comfortable in the gray nuances of unstructured discussions, debates, and a little variety.

Which brings me back to Web services. Not only will Web services fall short of solving this problem, they'll actually exacerbate it. How?

All business processes require both transactions and interactions. The more transactions we "automate," the more opportunity we provide for exceptions that must be resolved in a world of human interaction.

So for those in the industry working to provide collaboration solutions for resolving those exceptions and bringing those business processes to a fruitful conclusion, this can be a very big opportunity indeed.

While the pundits say to developers: "Think Web services," the counterintuitive among us say, "Think about what Web services can't do."

Let's put it into perspective. Twenty years ago, computers were going to do away with the need for paper. Today, paper consumption is up by orders of magnitude, since computers not only failed to eliminate the need for paper, they actually increased the demand, as each of us mindlessly hits our "print" button. Hence, the big winners in the computer age so far are not the low-margin PC companies but the printer manufacturers.

Or how about this: 10 years ago, the Internet was going to "democratize information," threatening the very survival of traditional information-gathering operations, such as newsrooms and librarians. Ironically, the big winners turned out to be the professional news- and information-gathering organizations, who, with growing mounds of misinformation and (even worse) disinformation, have the critical skills to tell the true story.

And so, I'm predicting Web services will follow this trend, where the real winners will be those who clean up after the next big myth.