Workflow applications: Cimlinc - the Cimlinc software toolkit provides integration tools for linking a manufacturing environment to a workflow management and development engine; one of a series of articles on workflow in groupware and applications for managing workflow

RELease 1.0, Sept 30, 1992

Cimlinc, a workflow toolkit for manufacturing environments, is an excellent example of a workflow system, since it makes certain concepts clearer than an equivalent system in an office. The computer really has no more idea of what Fred is doing with his spreadsheet than of what Rosie is doing with her rivets. It may have a production plan for the riveter, and it may "know" that it should load Excel and a certain file for Fred, but it doesn't know what Fred is doing. A programmer may write a routine to look at a certain cell or a named range on Fred's spreadsheet, Just as a routine may check a counter on Rosie's riveting machine, and make a decision on that basis.

The problems of office groupware are no different. A spreadsheet is almost as foreign to a database as a machine tool. It needs to communicate with it through a protocol; it knows something has been done only when it is told.

The problem with workflow groupware is that so much of what it normally has to deal with is undefined: The transactions between people are complex and subtle. It turns out that the same problem applies in the manufacturing environment: Although the processes involved are tangible, most of them haven't been defined to a computer that can understand them in any global way. That is, even in an "automated" factory, each part of the assembly line or process queue is independent. Some stations may pull down inventory information from the same mainframe, while other stations may use a graphical workstation with CAD diagrams and engineering instructions. But Just as physical goods pass directly from one location to another, bypassing the information system, so does information generally pass directly from one location to another, in the form of engineering change orders, special requests, etc. (There may be some information passed to and from the mainframe periodically, such as number of items received or assembled, or configurations of larger items might be noted -- although typically that's kept on a form taped on to the item in question.)

"We rashly assumed that just because people automated manufacturing activities, they had automated manufacturing," says president John West of Cimlinc, a maker of manufacturing groupware. "But in fact, they had Just automated the individual steps." The process was still as ad hoc, paper-ridden, and unorganized as ever. Each manufacturing station was linked to a mainframe, perhaps, or to a CAD system, but they were not linked to each other. There was no way to manage the flow of work from station to station. There were no links in the mainframe, and no links on the floor -- except for paper forms, memos, meetings, phone calls, and hurried consultations as engineers tried to fix things, change production amounts, etc.

In fact, manufacturing is never routine. Machines go down, part specifications and formulas change. special orders come in, people go on vacation, new products or processes are developed.

Cimlinc got into the groupware business a while ago, with an image-routing system. Thus there were three orthogonal tracks: Computer information, which went up and down between people and various information sources; physical goods, which went through the manufacturing/assembly process according to a mostly pre-determined path, perhaps with detours for rework, quality testing or other exceptions; and images, which provided an automated way to route information which had frequently floated around on slips of paper: requisition forms, engineering diagrams, engineering change orders and the like.(3)

You could query a given system, and get some kind of information (such as planned production), but there was no single information system that could reliably integrate and report what was going on. The images were not "alive." Usable information was divided among brittle mainframe or mini systems, people actually on the line, and pieces of paper or images floating among them. There was no reliable way of either sharing information or sending comprehensible, live messages from one place to another.

Fast-moving but static

The image system solved the problemof losing pieces of paper, and got them from one place to another faster, but they were inert. A person had to look at the image, do something about it, and then generate some information of another form. Or perhaps he merely did something physical, such as turning a knob or changing a paint color, without informing the system that he had done so. Now a person querying the mainframe would have no way of knowing that the next batch would be green.

Cimlinc basically has everything except a workflow engine; it's the environment within which a workflow engine can operate. (Originally it did have its own Concurrent Engineering Control System, which incorporated a database and some workflow templates built with the Cimlinc scripting tools. However, Cimlinc's direct customers, who are mostly systems integrators within manufacturing companies or third parties, preferred to use their own database or workflow engines, and use Cimlinc's tools to hook into the manufacturing environments.)