Columnist: September 1, 1994

The paperless office: must or myth?

Jack Ganssle,,
Embedded-systems Contributing Editor

Experienced engineers know that a new college graduate is really nothing more than a blank slate with no experience and little practical knowledge. The four years of cramming Maxwell's equations and cranking triple integrals give a nice theoretical grounding in the basis of our profession but leaves much lacking that only on-the-job training can fulfill. I remember that our instructor did not allow us to solder in our lab courses because he feared we might burn ourselves. Appalling, but true.

Your white-collar self-esteem may bristle at these words, but engineering is very much like the trades people practiced hundreds of years ago. We've substituted "junior engineer" for the word "apprentice" and "senior engineer" for "journeyman," but master craftsmen hand down most of the practical aspects of our profession to newcomers.

This isn't bad; because technology has a half-life of, perhaps, three to five years, no college could ever adequately prepare engineers for the work place. An engineer not constantly involved in self-education becomes obsolete in short order.

One thing we never discussed in college was drawings--amazing, since most engineering output is nothing but drawings. Sure, we sketched a few simple schematics and analyzed circuits on the blackboard, but, somehow, we never addressed the creation, maintenance, and updating of the drawings that are the product of our work.

Every small company goes through a phase of creative chaos. Crank out a few sheets of OrCAD schematics and hand-annotated assembly drawings, and ship the product. In time, the product line broadens, necessitating more drawings (all stored in a drawer somewhere). Management expects new hires to build and maintain the products, often working from memory. They'll often hear comments like "Oh yeah, we always put a 10k resistor in that spot," or "Jeez, you forgot the mod we do to that version of the product."

This is a classic case of the company's systems breaking down. Management texts talk about planning and inventory-control systems but ignore the most important system for manufacturing and engineering: the drawing-control system.

My company went through this evolutionary phase, during which it accumulated hundreds of drawings. Sure, we had bills of materials and assembly drawings, but they were impossible to track. Which was the current version? What changes were implemented between versions?

In desperation, I tasked a young engineer with developing a formal drawing system, not realizing that, having had no experience with functioning systems, he had no idea where to start. The result was, well, primitive.

On a memorable cross-country flight shortly thereafter, I pounded in a specification for a document-control system, drawing on the experience I had obtained as a junior engineer years before. Frankly, I pirated the concepts from a former employer. That system, in turn, is derived from one used by the airplane industry. Though our system has refinements for handling embedded designs (PAL and ROM files, for example), it looks much like any system dating from the '50s or even '40s.

Now, I secretly smile, realizing that my company's crop of engineers will probably take this third-generation system along to other employers in the future, keeping many of the core concepts for two simple reasons: It works, and it has become another comfortable tool in their skills bag in their journey toward master craftsmanship. There is nothing new under the sun!

Teaching apprentices is very much like having children. Your own kid is a source of genetic immortality; the protégé you mentor likewise perpetuates a piece of you.

The paperless office

Although journalists have written plenty about the evolution to the paperless office, few technology companies have made this transition, even in the highest of the high-tech environments--engineering. Sure, we now use schematic capture instead of a pencil and vellum, and word processors rather than scrawled notes. But almost all electronic documents get reincarnated in paper form.

Production wants paper drawings for the assemblers. Test needs test procedures and schematics on paper. Let's face it: Even engineering wants the schematics on paper. You can scribble and make notes on a paper schematic. You can't do that on screen.

Electronic documents suffer from another flaw: Every drawing runs under a different application! Schematics use one of dozens of capture packages; assembly drawings may be in AutoCAD or another format; even text documents can be in Word, Lotus, or any of a hundred other formats. You cannot display and manipulate all of the system's documents unless you own all of the applications on your workstation.

Does this suggest that an organization should standardize on a single word processor, single database, and the like? That's the tack we've taken.

The new reality of a drawing-control system must recognize that, although masters are inevitably in some computer format, working copies are almost always on paper. Paper is not bad per se; it is yet another component of a modern information-management system.

To handle the realities of standard office equipment, all schematics and other documents should, if possible, be formatted for 8.5311-in. paper. The days of D-sized schematics are long gone. You can't copy them without a monstrous blueprint machine, you can't fax them, and you can't store them without special cabinets. My company's entire drawing system fits in one drawer of a standard file cabinet--a space-conserving, easy-access format that greatly simplifies life.

"But," you sputter, "we've always used huge drawings!" Times and technology change. Embrace change. My dad says that in the pre-Mylar days they did drawings on starched linen in ink. One bead of sweat in those pre-air-conditioned '50s could ruin a week's work.

When I first entered this field, all we managed were drawings and bills of materials. The digital age has only increased the kinds of "documents" any reasonable drawing system must manage.

Perhaps, though, it makes sense to outline the goals of a document-control system:

Guarantee that all departments are using accurate, up-to-date, drawings.
Control product versions, so production knows how to make each kind of product.
Provide a historical record of changes, so the service group can bring older products up to current revisions without heroics.
Ensure that adequate backups exist so that the knowledge in the system can survive a fire or malicious intent.

Goals 1 to 3 have been around since the dawn of engineering. I suppose John and Washington Roebling themselves built the Brooklyn Bridge with a primitive drawing system that obviously functioned well. The fourth goal is a result of challenges from the computer age and the realization that a company must survive despite any disaster.

How do you manage a document that lives in some purely electronic form? Schematics and artwork should have paper (or film) copies filed in the drawing drawer, but what about the original files?

One solution is to define an electronic repository. At my company, one computer has a master directory, available to everyone over the network, where a copy of every critical file is stored. Modern networks are great because even a simple one lets you define read/write access rules and passwords. There's little problem leaving these files available to everyone, but a paranoid outfit could easily restrict write-access to those folks with a "need to write."

Every project has its own subdirectory, with further subdirectories containing ROM, PAL, CAD, and word-processing files. Draconian rules and an assigned "enforcer" ensure that changes to the files get copied back to the master computer.

With all of the files on one machine, it's easy to run weekly backups to tape. In effect, we can back up everything critical to the business in 30 minutes from a single machine and need not rely on forgetful and busy employees to run regular backups of their own systems. In a break-in a year ago, a burglar destroyed or stole almost every decent computer. Yet we lost virtually no data.

PALs and ROMs pose special documentation challenges, because they are physical devices that you must purchase. As a result, they require call-out on a bill of materials. Yet, the device itself is incomplete until it is burned with the proper equations or program. Our solution is to call out the chip on the bill of materials, with an associated drawing number that describes the part's programming.

The ROM/PAL drawing includes the file names of all source-code modules used to build the equations or program. PALs are always a single .PDS file compiled via PALASM. ROMs invariably are composed of dozens of source-code modules. By listing every file used, its full file name on the master computer, and the required make files, it's possible to re-create the program from the backup files, even if a software engineer's computer dies (or is stolen).

No system can work unless it's clearly understood who is in charge of keeping it up to date. Tasking an individual with the responsibility of managing the drawing system means everyone knows whom to turn to for help and advice. The responsible individual knows what is expected, and management can crack the whip. The drawing system is too important to leave to chance. Its management should be part of the responsible person's annual review.

The E Myth by Michael E Gerber (1986, Harper Business, New York) examines how businesses start, grow, and sometimes choke on their own success. The book's most important point is that the entrepreneur should work on, not in the business. That is, spend time designing systems and procedures that make it possible for the business to thrive, despite its success.

Though Gerber never mentions drawing systems, document management is surely as important as any other system.

Jack Ganssle is the president of Softaid, a vendor of emulators and other embedded-systems tools. You can contact him via Internet: jack@softaid.net. Or send mail to Softaid, 8310 Guilford Rd, Columbia, MD 21046.

Jack's Home Page