The Rules Are Meant To Be Broken

In our ever-increasingly frantic lives one theme has become abundantly clear: Everything is changing. Whatever the experts say today will most likely change tomorrow. From our earliest years we learn that limits set by our parents can be broken and, until we're out on our own, we're pushing those rules every waking hour. Why?

Because we learn early in life that rules are really guidelines established by others who are trying to protect us. Unfortunately these "others" typically had hidden agendas--things like safety, propriety, etc.--that didn't always support our quest for happiness. Is it no wonder then why we cringe today when handed a new set of "rules"?

Nevertheless, when it comes to your business, rules are a comfort, a habit. They imply stability over time. But successful rules aren't written in stone. They must be continually revisited, challenged. This can be painful, but it's necessary. Oh how quickly we forget the joy and insight we found as a kid when we first discovered the ultimate question: Why?

"Because that's how we've always done it," was a popular phrase for my father and grandfather. That's not a good enough answer for manufacturers today. In today's global economy, the manufacturing company that does not continually reinvent itself dies.

For the longest time, manufacturing business rules found their home in long manuals' operating procedures. Then the software revolution came, and the structure of computer programs seemed like a perfect new home. Traditional software development has always been a labor-intensive task surrounded by a wall of mystique that was built and well guarded by a cadre of geeks that could speak without real words coming out. Static industry rules were made for such an environment.

If nothing changes, these mysterious black boxes we common folk call computer programs will last forever, ensuring their creators a spot in the Pantheon of Geekdom. Rarely did this point of view coincide with those of the supporting organization, but as long as nothing changed and the automation worked, all were none the wiser.

The challenge with the black box approach is that things do change. Rules change, business objectives change, technology changes. Without insight into the gears inside the box, it can be difficult to maintain such a programmatic approach to managing automation. Anytime anything changed, the engineers had to prostrate themselves before the priestly class of programmers in order to keep the automation engine running.

Capturing Rules in a Dynamic Environment

First of all, it is important to understand the types of rules manufacturers need to capture and maintain. Basically, if you can express an engineer's thoughts so that another human can get the same results you do, then it is a rule. Rules go beyond equations and calculations to enforce compliance checks, constrain pricing and cost, govern part selection and quantity and even determine manufacturability.

Next, realize that where the rule is captured is as important as how the rule is captured. Rules may change, but they affect every aspect of the manufacturing process, from design to production to delivery. Storing rules inside a CAD drawing or a sales automation tool limits the extent to which you can capture, update and reuse rules.

Today's CAD offerings don't allow for design decision information to be captured in a way that converts data into actual knowledge. RPM, however, is able to capture knowledge in a way that helps everyone in the manufacturing cycle. While it's true that the VP of engineering usually doesn't care about the same things that the VP of manufacturing does, they still have to talk to each other in order for the organization to be successful.

Many a company has used a knowledge-based approach to automating design processes, but these attempts were limited by difficult interfaces and the black box nature of the system of record for rules--are they stored in the CAD drawing, in the PDM system, or somewhere else? Some of the world's largest companies still use knowledge-based systems, yet most of these solutions, many of which are home grown, fall far short of their expectations.

By applying a knowledge management framework to PLM, RPM can provide many benefits. It can help manufacturers reuse knowledge from previous design efforts to shorten the time and cost required to execute new or custom designs. It can also reduce design errors, improve the quality of designs, increase innovation, and preserve the organization's intellectual property.

Realizing that a rule for manufacturers today may be nothing more than a footnote at best tomorrow, RPM encourages change. RPM's focus on quantifiable engineering processes differentiates it from earlier attempts at solving this challenge. With RPM, manufacturers can more easily capture, reuse and modify rules while managing product complexity and accelerating innovation.

My father and grandfather were right about a lot of things, but they were wrong about the rules. Rules can change--they should change. The technology you use to capture rules should enable change, not hinder it.