When Revision Control Isn’t Enough

Revision Control

In a previous article, we examined why engineering change management is so difficult. A major one is the fact that change requests can originate in several different departments and can come in at any point in the engineering process — from initial design all the way to after the plant has been assembled or the product has been installed.

In that post, we touched on another aspect that complicates engineering document management — revision control.

In engineering, there are two terms that describe the process of tracking changes made to a project: revision control and version control. Many people use these terms interchangeably, but at Aucotec we use them to describe two “levels” of changes.

Revision control

When the design team is finished with their initial design, they release the project documentation. This puts the documentation under revision control.

If, in the next stage of product development, changes come in from the purchasing department, the design team will review and implement the changes and then release the documents again under a new revision number. Changes from the production design department may also result in a new revision number, as will changes made during the build phase, and so on down the line.

What revision control does is to mark the documents as being in a static state — not necessarily final, but rather “final for now.” In the course of a project, you may end up with multiple revisions, each representing a stage in the development process.

Version control

Version control, also called “versioning,” refers to the changes that take place between the revisions. It allows engineers to track all of the changes in the project irrespective of the document revisions.

Version control is important because designers need to be able to track what’s happening to the data in the project, whether or not it affects the documentation. For example, if a designer replaces a part with one from a different supplier, the change may affect the bill of materials without impacting the drawings. But this change still needs to be tracked because it’s relevant to some teams working on the project — namely, purchasing and installation.

Here’s another example, following the manuscript collaboration scenario in the previous article.

After the initial round of editing, our manuscript is sitting in a folder called “My Google Docs.” If anyone makes changes to the document, those changes will be tracked under revision control.

Author A decides that since this is a collaborative project, he shouldn’t appear to being taking complete ownership of it. So, he copies the manuscript and supporting materials to a new folder, called “Our Google Docs.” This is now the master.

How is this change tracked? It doesn’t affect the manuscript directly, and the revision history will not reflect it. Rather, it alters the wider view of the project — the current manuscript is now housed in a different place. If Author B goes into “My Google Docs” to make a change, she’ll be working on an outdated manuscript and not even know it.

This kind of thing happens in engineering all the time. Not necessarily files being moved, but rather changes to the data that don’t directly affect the documentation. You can imagine how disastrous the consequences could be down the line.

___________________________

In engineering documentation discussions, most people focus on revision control. If your installation team is working from Revision 7 and your design team is finalizing on Revision 9, you’ve got a problem. Revision 8 got lost somewhere.

But revision control isn’t enough. While it’s great for tracking changes to individual documents, it isn’t sufficient for tracking changes to the underlying data, which may or may not impact the actual documentation.

The solution to this problem is that you need both — revision control and version control. You need a way of tracking every change that’s made to a design, as well as a way of viewing those changes without having to comb through hundreds or thousands of pdfs and spreadsheets.

You can make this much easier by taking data-first approach to your design and documentation, as opposed to the traditional drawing-first approach. When you focus on the data, the drawings take care of themselves. To learn more, read From Drawings to Data: A Radical Paradigm Shift in Engineering.

Leave a Reply

Your email address will not be published. Required fields are marked *