Do you want to manage engineering, or just the results of it? (Part One)

I get asked the following question frequently…”Why, when we have <Insert the name of any general purpose Electronic Document Management System (EDMS) here> do we need another system to manage documents for the engineering team?

You have to admit…it’s the right question to be asking. After all, no IT department should agree to manage multiple systems that do functionally the same thing. So here’s my answer…While a general purpose EDMS may be able to manage single files created by engineering applications, they are not designed to manage the complex interrelationships between engineering documents. It’s not sufficient to provide some basic CAD “format” integration because engineering documents created today are typically a composite output of a CAD “engine” and a discipline specific application that overlays on top of it. Without CAD file AND application specific integration, engineering users may be required to use special commands or work arounds that differ from the way that their tools were designed to be used. BTW…they won’t…at least not when your back is turned.

Also, it’s not enough to store and retrieve a single CAD file for display or editing. So some vendors recognize this shortcoming and turn to third parties to add reference/XREF management features. These third party products face the task of adding functionality for which the EDMS repository was not designed at its core. Some do an adequate job of managing a single layeror document (and maybe even references at a basic level), but are not capable of managing the complexity of application integration required by modern engineering teams.

So what?…some ask. Other’s will admit that an EDMS doesn’t have all of the capabilities of a purpose built Engineering Information Management (EIM) system, but they may estimate that 50 or 60 percent or that functionality is enough. “So what?”…”Isn’t x percentage enough?” Well, that depends. This is where I ask the key question, “Do you want to manage engineering, or the results of it?”

My point is that, if you’re only interested in managing a distilled down version of the engineering content, then you’re really saying yes…I only want to manage engineering content after it’s “published” at some milestone.

And to the question as to whether x percentage is enough, I aim to be provocative in saying that regardless of the estimated percentage of feature coverage, if you want to manage content while it’s “in progress” the percent of capability that an EDMS provides when compared to an EIM system is…zero.

How can this be? The key is the “milestone vs. in progress” decision. If all you want to do is manage a dumbed-down version of the data that engineering creates/uses during design, you’re looking for a milestone system. You probably should be aspiring to more but, if that’s all you want, many systems can provide that.

But if you want to manage the beautiful chaos that is engineering, then you require a tool that manages the content AND applications in a very deep way. Such a system should be integrated with design tools to be sure, but that integration should allow the management of standards used and the administration of those applications. Otherwise…well you’re probably back to a milestone system where people make decisions about what to publish when.

The risk of using a milestone system to coordinate engineering is, of course, that the minute something is published, it’s probably out of date. I recall a roadway job with bridges and culverts where a small handful of companies were cooperating on the design. One of the parties had control of the alignment while the others received regular updates. However, after a change to the horizontal alignment due to environmental considerations, no one remembered to upload the modified alignment. A week later, during a project review, the other engineering companies learned that most had wasted a week of effort designing around the wrong data. If all of the parties were logged into the same system, everyone would have know immediately that a change had occured.

This is a BIG deal…but, so far we’re only scratching the surface of the vast difference between milestone and in-progress systems. More coming…