John Parkinson: Secret Software Agents

By John Parkinson  |  Posted 10-01-2004 Print Email
Opinion: John Parkinson: Software agents can give you huge gains in the efficiency of business processes—but only if you get the rules right.
I get a lot of e-mail—we all do—but with around 800 messages a day, I simply can't read them all, and only 100 or so really require my attention. The challenge is to handle the rest automatically, but still be able to get to them later if I need to.

Enter software agents.

In early 2003, I wrote a few rules for our Microsoft Exchange corporate e-mail system that lets it scan the messages I get and automatically file most of them in subject-sensitive folders.

Attachments are removed from the messages and saved into the file system so the message archive doesn't get too big. The agents also keep statistics on where the mail is coming from and periodically send me a report so that I can update my white (always accept) and black (never accept) e-mail lists. That way I don't have to deal with most of my incoming messages at all.

The system isn't perfect, but it saves me a lot of time.

Based on tests I ran when I started using this approach, the roughly 40 hours I spent developing and testing the rules have saved me around 80 hours a month. I need to fine-tune the rules periodically, but even with that overhead the system is worthwhile.

Agents can do a lot more than filter and manage e-mail.

A lot of business scenarios are rule-driven—in fact, any business scenario can in theory be modeled as a finite state machine (FSM), where you define every possible state of each business process and provide the rules that determine how to move between states based on one or more measurements.

Finite state machines can be thought of as large n-by-n matrices in which each cell defines a transition with associated rules that specify where to go next.

Think about online shopping and the state of your shopping cart, for example. If it's empty, you can't delete an item or check out, but you can add items or just abandon the cart. If there is at least one item in the cart, you can add, delete or modify the item, or check out, or save the cart—and so on.

The problem with this approach is that in practice (a) processes have too many possible states; (b) not all state transitions are possible; and (c) not all the states are equally probable. In general, you want to focus on the most likely states and transitions, which have to be actively managed, and be sure that you stay away from transitions to bad states.

Agents offer a different way to solve the problem.

With relatively few rules (my e-mail agent has less than a dozen), the agents can check on the state of a process and decide whether to act or not. Getting the rules right initially may be difficult, but once you have them, applying them is computationally much cheaper than the full linear optimization processes required by an FSM.

Agents also have the advantage that they don't have to know everything about the process they're monitoring to be effective. By creating hierarchies of agents with different levels of "responsibility," you can segment optimization problems that are impossibly large or computationally very hard into smaller local problems.

"Supervisory" agents at higher levels of the hierarchy can affect the operation of agents at lower levels by adjusting the control rules when they detect deviations from a desired state.

There are now quite a few agent tool kits available, so getting the technology isn't hard. But how do we get the rules right?

Modeling the process based on instrumentation and observation is a good way to start. Modelers often begin with the formal definition of a process—but this can be a mistake, because few processes actually work the way they are defined.

It's usually better to look for the "domain experts"—the people who know how things really work. They will often be the people who do the work, not the people who manage it, so it will be necessary (and perhaps politically difficult) to find them and start to capture what they do.

In general, their knowledge will be incomplete, but by observing them, you should be able to build good initial rule sets and tell you where more instrumentation is needed.

Next, look at where the closed-loop controls will have to be.

Closed-loop controls keep a process operating within its designed performance objectives and prevent fluctuations from disrupting operations.

In many business situations, the controls for these "smoothing" functions will also be people, and it's as important to understand what they don't react to as it is to see why and how they do intervene.

Now you have enough information to construct a model of the process, replacing the human or static automation controls with rule-driven agents. You can then run real data through the model and concentrate on eliminating errors and improving exception handling until the results from the model are reliable enough to put into production use.



 

Submit a Comment

Loading Comments...