Machine Design

A better way to track design decisions

Knowledge-accounting software captures the reasons decisions are made so others can learn from previous experience.

W. Bradley Holtz
President and CEO
Cyon Research Corp.
Bethesda, Md.
How it works

KollabNet software helps engineers capture and track the specifications for a project with techniques that minimize typing. For instance, a designer in a traditional workflow gets a "package" along with the assignment. The package is a bunch of documents from which one is expected to extract design constraints. Today, the documents are usually electronic.

Ordinarily, a team leader would take out a pad and pen and make notes while poring over drawings, and reading emails and Word files. KollabNet replaces the pad and pen. So when users find a statement that describes a design constraint, such as "The device will be used over a temperature range of -40*C to 50*C," simply select or highlight the detail, sentence, or requirement and switch over to KollabNet.

Select what's called a constraint DesignBlock from the software's palette and place it on the DesignMap canvas area. A constraint DesignBlock holds any string -- for example, it may contain specific design targets such as weights, sizes, and operating temperatures. Then click on a button labeled Word to indicate where the requirement came from (in this case, a Word document) and the statement appears in the DesignBlock. This action captures the selected string of text.

Now grab a parameter DesignBlock from the icon bar, place it on the canvas, and stretch a link from the constraint DesignBlock to the parameter DesignBlock. The parameter block contains an agent that detects numbers in the constraint DesignBlock, captures them, and assigns them to meaningfully named variables.

By linking all requirements and constraints in this manner, the user creates a symbolic model of the design. The software, meanwhile, is doing the knowledge accounting -- it's keeping track of what changes, how, and when, so that users have an audit trail of events.

If someone tries to change parameters in the DesignMap, the software asks a series of questions before it allows the change. Questions are determined by company designers and are typically multiple choice, so they are answered with a single mouse-click. For example, when the software asks, "Why is this change being made?" Available answers could include, "Customer requirement" or "Updated spec."

Each DesignBlock retains a complete record and sequence of changes, so the entire DesignMap can be "rolled back" to a prior state. Proceeding in the described fashion, a user can link to the calculations in spreadsheets, to dimensions in CAD models, and so on. Users can also place conditions in parameter DesignBlocks, so if a change violates the condition, the software issues an alert. For example, if voltage at a particular location should not exceed 100 V, the statement is entered into a parameter block that monitors values. With a proper statement, should the voltage exceed the limit, the software shows an alert.

The developer plans more design blocks to meet user requests. One, for example, can hold an entire design map from a previous project. If the previous project solved a knotty heat-dissipation problem, the user might grab that whole map and designate it a design block. The next time a thermal problem crops up, place the solution and thinking behind it on the screen, and all constraints, parameters, notes and other comments come along with it. Of course, users will have to adapt the solution to meet a few new particulars.

When experienced employees leave a company, they take their knowledge, experience, decision-making skills, and tricks of the trade. The company is poorer (less knowledgeable) as a result of the departures.

The brain-drain problem has been recognized for a long time, but there has been little a company could do. Until recently, the prospect of capturing the knowledge of engineering professionals has largely failed, for two key reasons. First, attempts to have engineers recapture their thought processes are doomed to incompletion and inaccuracies when engineers try to remember precise details of what they did and why, weeks after the events. What's worse, they are also expected to type their rationale in lucid prose.

But the end of a project is not the place or time to start remembering. It's probably no surprise that studies from Ohio State University and MIT indicate the best place to improve a design-through-maintenance cycle is at the beginning, ideally in a product's concept or predesign phase. This is where design criteria are listed and enumerated.

And second, recent attempts to capture engineers' thought processes as they occur have always introduced a separate, additional step, requiring engineers to interrupt their thought flow to document decisions. Most engineers do whatever they can to bypass inserted steps. In addition, studies from the 1960s showed that interrupted thought processes add stress to engineering tasks.

The opportunity
To get around the two problems, KollabNet, from KollabNet, Inc., Philadelphia (, has developed software for capturing knowledge and experience in a product-development process, particularly in the early stages of requirements gathering and conceptual design. It does so without inserting additional steps and with minimal key stroking.

The software uses a linking process that reduces the amount of typing. Because the product doesn't care about a specific way of designing and imposes no particular design regimen, it's more comfortable for engineers to use in the free flowing predesign and design phases.

The software changes little in the way engineers work by fitting in with existing design processes. It adds no risk to the process. Instead, it reduces risk while increasing the probability that projects will come in on time and under budget.

The process is simple. Engineering projects often begin with a set of design requirements which can be buried in a stack of (mostly electronic) drawings and documents. While reviewing design requirements, the engineer identifies critical parameters and connects them with links that describe relationships.

The term knowledge accounting was coined to describe what the software does, which is not directly comparable to what other programs do. Knowledge accounting is the act of keeping track of critical parameters, links, and relationships. KollabNet is a requirements-capture tool and is unlike all other knowledge-focused software I have seen. Other programs in this field are intended for explicit narrative entry of requirements, typically for highly regulated projects. They require engineers to type descriptions of what they did. Because most engineers dislike typing -- especially while designing -- those other programs are often employed as after-the-fact documentation tools. Because it is almost impossible for a designer to remember all that was done, post documenting is not the best way to record a design process.

The early stage of a design requires an engineer to keep all the design's complexity in his or her head. This part of the design phase can't be simulated, reused, or shared. And gauging the impact of possible changes is a matter of guessing.

Knowledge accounting sounds similar to the more often-used term of knowledge management. But accounting is less presumptuous and less ambitious than management. Knowledge accounting implies keeping careful track of what occurs, but does not imply anything about how the knowledge is created or used.

A few applications
Most complexity, creativity, and ideas in a manufacturing company lie in the minds of its design engineers where it's unavailable to colleagues. It also cannot be critiqued or simulated, and is not properly documented.

That's why design reviews are often chaotic and raise difficult to resolve issues, especially when someone asks, "Have you tried this approach?" When a designer cannot satisfactorily answer the question, the meeting ends and the designer trudges off to test the "suggestion."

The newer technology can be useful in such meetings by clearly displaying design alternatives, as well as the rationale behind design decisions. A DesignMap (a map or chart of requirements and their relationships) can show all of the pieces (DesignBlocks) of the design, and identify exactly the upstream and downstream impact of any change. So when someone asks, "What is affected if we change this?" the software can immediately show the answer. Everyone in the meeting can then focus on the real issues of the design. Of course, the same capability is also available to the designer working alone.

The software's linking mechanism has other uses as well. KollabNet tracks changes in an underlying CAD model and flows those changes through to its DesignMap. This function is not tied to one single CAD vendor. Consider an assembly with components from two different subcontractors, each of whom uses a different CAD system. The linking technology in the knowledge-accounting software ensures that linked elements are kept in synch. If anything changes in the original design, or if one of the subcontractors tries to make changes, those would be picked up and flowed through to the DesignMap.

At the same time, it is not necessary to expose the entire DesignMap to subcontractors. A contractor need only see those portions that affect them directly. But all links are maintained, regardless of whether or not they are visible. If a subcontractor tries to introduce a change that violates a constraint, the DesignMap flags it to both the engineer and subcontractor.

The program also lets project teams stand on the shoulders of earlier project teams by building a database of design knowledge. Each project's DesignMap can be used as a starting point or included in any future project. Proven designs are key to many organizations, but in most cases there are portions (decisions) of those proven designs that are out of date. Without knowledge accounting, there is usually no way to identify why any particular portion is the way it is. With knowledge accounting, the reason that portion of the design is known and the decision can be revisited to accommodate changed conditions such as price, availability, or strength.

The knowledge-accounting software has other roles as well. Suppose a user selects a new kind of bearing for a product. Researching the component would also let the user gather technical parameters and availability while expanding a DesignMap on the project with appropriate boxes.

Now suppose that the design evolves or engineering requirements shift so the specialty bearing originally selected no longer meets the requirements. What now? In a traditional operation, an engineer might backtrack a bit and start over with a standard bearing in mind.

But with knowledge-accounting software, users simply "cap off" the branch of the DesignMap at a point where the special bearing was selected and focus on a new bearing using a DesignBlock that can actually check every so often for the availability of the preferred bearing at a specific URL on the vendor's Web site. When the condition (a price drop, for example) occurs, the system would send the user a message that the product is now available

What is important is that the system preserves the invested research and makes it available for future projects. Should a message arrive from the system telling that the better bearing is now in the allowable price range, the information needed to use it is ready for the next version or product model.

The basics of the software can be picked up by most users in a couple of hours. The key is to integrate it into the work processes. While the software is justifiable for use on a single project, the more prevalent its use within a firm, the greater the benefit. As the database of DesignMaps grows, companies can better protect their investments in the knowledge of key designers, making it available to the entire design team. And when the time comes that a key designer leaves, some of their knowledge will still be available.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.