One of the most frustrating aspects of the Product Data Management (PDM) and Product Lifecycle Management status quo is just how much of the core practice is steeped in a configuration management tradition, harkening back to the days of the battle of Dagorlad, or in other words, a really, really, REALLY long time ago. These time-tested configuration management rules have but one fault: they were chiefly devised in a world absent of all the seemingly magical computing technology of this age. Yet many are never revisited, because it’s more than just a simple matter of contemplating new possibilities, but rather an intractable struggle against well entrenched software and organizational foundations. There are many such hard tenets of PLM lore that are often quoted as absolutes, be it that tradition and entrenchment has lasted since the ancient days (about 1965 or so).
Thankfully, Oleg Shilovitsky recently reminded me of just one of those longstanding configuration rules. Don’t shoot him, he’s only a messenger (as am I) of a long-established configuration management axiom:
“So, typical document (e.g CAD assembly or drawing) will have document number and additional version / revision. One of the common mistakes (especially in small companies) to use document number as identification for parts. This is wrong. The right identification for parts is Part Number. Parts have no versions and revisions.”
And so it is written. Parts have no revisions. Let that digest. But as pre-NCC-1701D Levar Burton would say, “you don’t have to take my word for it.” In the Land of Mordor, in the fires of Mount Doom, the Dark Lord Sauron forged MIL-STD-100, which begat DOD-STD-100, and ASME Y14.100, and pieces of CMII, and just about any book, pamphlet, or diorama on configuration management in manufacturing. All of them say more or less the same thing: Part numbers don’t include revisions. You know, just in case you missed the news flash.
So if parts numbers can’t include revisions, how can you revise parts? You can if conditions are right, under the rules of interchangeability otherwise known as the three F’s: Fit, Form, and Fuuuu-nction. If the change doesn’t affect the three F’s for all the applications of that part, then you can revise the part. What that means in practicality is if someone batted blindly at a piñata mixed with both revisions of the part, what falls out is irrelevant. Both revisions are interchangeable in every way, and so it doesn’t matter which one is actually used.
That’s why every PLM system has the capability to revise parts. The capability is there for interchangeable revisions, which might include things such as an update of metadata on the part itself. But, as you can imagine, under such a strict rule, few changes can truly be considered interchangeable. Even the alteration of an insignificant fillet alters the weight and load behavior of a part – perhaps in relatively insignificant ways but nonetheless so. Often from a performance, reliability, and maintainability standpoint the rule must be followed strictly. And so all changes which fail to be interchangeable, or otherwise introduce a new application that is different from the original, require a new part number. Fast forward a few changes cycles, and you might collect enough part numbers to lay siege on Minas-Tirith. Take a non-interchangeable improvement on a part, which might also be useful for a second application of the part under a different part number. To effectively communicate that design relationship requires traversing three part numbers that may be entirely unrelated. So much for reuse.
But there’s an additional price to pay. With each part number change the next higher assembly must be changed also to reference the new part, and its next higher assembly and so on until you reach a point of interchangeability. Hopefully in most cases that’s the next higher assembly, but certainly not always. Revising parts is to be alone, Frodo. That’s where the prevailing configuration management wisdom attempts to address the burden with something like what Kenneth Crow @ DRM Associates carefully describes:
“Determination of when interchangeability is re-established is a matter of judgment. Strictly speaking, it could be argued that in many of cases that a change is made, a subtle effect on specified fit, form or function could be identified in the end-item itself (i.e., interchangeability is not re-established at the end-item level). Practically, Engineering and other functions will make a judgment that interchangeability is reestablished at the lowest possible level in the product structure to avoid the impact of the change on logistics, tech manuals and maintenance. In a complex product with a high volume of changes, changes should be grouped together and implemented in blocks to improve control over these changes and minimize the overall effect of changing part numbers and revision levels.”
In other words, when using a complex system to manage changes, don’t try to change so much, ok? Otherwise, it’s the ruin of all. Probably. If you think about it though, it doesn’t really have to be this way, now does it?
How about we allow non-interchangeable revisions on the same part number? “Woah, there.” you might say, “Step away from that Mountain Dew Code Red. I’m afraid you’ve had just a little too much.” Perhaps I have, indeed.
On the manufacturing side, if you stock parts by revision level, not only will many consider you (Tony) stark raving mad, but you’ve just successfully replicated the problem in a different way. With each revision in its own bin, the revision ID has -in effect- become an extension of the part number. Not only that, but now every change is a non-interchangeable change with its own bin. Crap, those orcs get in everything!
So let’s try a twist (M Night Shyamalan style). Suppose you revise on the same part number, control revision use in each assembly by effectivity, and have some method to designate whether each change is interchangeable or not. That way interchangeable parts are comingled, and everything else gets its own bin. Right-sized binning but without as much collateral change overhead. Then let that interchangeability designation pass to ERP to handle accordingly.
There’s a small problem, however. And it’s a problem that really held back progress up to this point: a core assumption of ERP understands there’s only one revision of a part that matters, because you don’t stock by revision. And so we’re stuck – we have all been deceived. There’s nothing in any PLM-ERP bridge that can really fix it reliably, again because that old assumption from configuration management ages gone by is at the very core of these technologies as they stand today. Maybe it’s time to try something radically different. Those eagles are pretty handy.