People-oriented automation

One of the reasons why businesses want more agile IT is that today's flatter management structures depend on giving greater autonomy to individual managers and workers. The trouble with traditional enterprise software is that it's rooted in an organizational model that assumes a large bureaucracy shuffling documents around according to preset procedures. Whereas 21st-century business is carried out by delegating decision-making responsibility as far down the reporting line as possible. This doesn't have to imply loss of management oversight, provided there's a way of tracking and monitoring what's actually happening at the end of the line (in truth, this is a far more realistic position than the command-and-control model anyway, which in spite of whatever the procedures manual actually prescribed, was always liable to subversion by individual acts of initiative, incompetence or rebellion.)

Of course, the command-and-control model is much more convenient from a software programming point of view, because it's much easier to write software if you assume that:

1. there is only one true way of completing each process,
2. the software designer intuitively understands every nuance of that process, and
3. the process can be perfectly represented in software.

Reality demands a different approach, one that recognizes that:

1. the process is liable to change frequently in response to changing conditions,
2. the individual who is directly responsible for the process is the only person (if anyone does!) who really understands it, and
3. the best way to refine the automation is through fine-tuning in the light of actual use.

It's because reality is the way that it is that I like the principles behind agile development, especially the one that says,"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." But even agile development I feel doesn't quite go far enough: valuable software (as opposed to software that's no use at all) is a great improvement on what businesses often have to live with, but what they really want is productive business automation. Software is just part of the underlying mechanism rather than the end result in itself. Frankly, the average business person really wouldn't care whether the stuff under the covers was C++, J2EE or a team of genetically modified hamsters on a treadmill, so long as it did the job (provided it didn't contravene the company's published ethical policy I should add).

So why not cut out the intermediary and let the user modify the business automation directly? The traditional response is to say that users aren't software experts, and of course that's a valid argument if the only way to change the automation is by recoding the software. (Although no one ever seems to explain why it's so much worse to have process experts messing with software they don't understand than it is to have software experts messing with business processes they don't understand. To me, the business is a much more precious thing to have amateurs messing around with it than any software package).

So I was very pleased this week to find out about the online services available from Nsite, which made a bit of a splash this week announcing new customers, new funding and a new CEO. Nsite describes its services as "business automation on demand." Users can set up forms-based processes such as approval procedures, task management or change control, start using them, and then analyze performance and make changes to fine-tune each process. The service is hosted online, so users don't have to touch the underlying software, and the cost starts from $40 a month for a process with up to 10 users. This hosted service approach means it's possible to get started within days and see a return on the (very small) investment within the first month. It's a very neat way of bypassing the software bottleneck for automating the myriad of small but often troublesome people-oriented processes in a business, and handing control directly to users (but at the same time being able to track the processes that have been set up and also monitor how they're performing). Information Week reports on some very satisfied customers in a story this week, Using a Web Service To Automate Business Processes . Don't be misled by the headline: This of course is a web service only in the sense of being a service that's offered on the Web, rather than a web service in the sense of using web-based SOA standards like SOAP and WSDL.

In offering an online service, Nsite is using what used to be called the ASP model, which I've seen a lot of examples of in my former guise as founder and one-time managing editor of ASPnews.com. I find the approach laudable, but there are some hidden catches that customers need to be aware of:

• Process lock-in: In principle, you can cancel your $40-a-month contract and walk away at any time. But in fact, the more you use the service, the more your business becomes completely reliant on it. Each process that you automate becomes another tie that prevents you from going elsewhere. There are no standards (at present) for porting processes to other platforms — which come to think of it is true of conventional software too. So it's no worse in this respect than your existing software, and costs you less. But that makes it all the easier to forget that you're still getting just as tightly locked in.
• Process integration: ASPs have typically had trouble automating links from their hosted services to existing in-house software (or to services from other ASPs, for that matter). Web services standards are starting to overcome those difficulties, but it's still early days and so you'll have limited scope for automating integration from your Nsite-hosted processes back to your internally automated processes. But you'll probably want to start with the processes that require manual intervention to set up anyway, so this isn't going to be a major setback to start off with, just something to bear in mind for later.
• Process management: This is not specifically an ASP thing, but a more generic observation. As the number of processes hosted begins to expand, then there's going to be some need to catalog existing processes and manage them to make sure that duplication and fragmentation doesn't get out of hand. It looks to me that this is something the people at Nsite need to do more work on at present.

posted by Phil Wainewright 4:25 PM (GMT) | comments | link