One Revision to Rule Them All

SauronMILSTDOne 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.

  • pgarrish

    I think you’ve hit on one of the most ‘discussed’ issues in any company that deals in parts. From my experience, a lot of the behaviour relates to managing drawings – hand-drawn, A0, paper drawings. Where a tiny change in a GA meant a LOT of work to re-draw mostly the same stuff, but to change one number. So practices were developed whereby as few part numbers as possible were generated. Manufacturing or Production could have a ‘little revision’ in their system and, lets be honest here, no-one else mattered did they!? So design could make changes without changing part numbers and re-doing those big diagrams, and production and manufacturing could manage things like holes, condition of supply etc, with their own ‘revision’ scheme (yep, their own part number, but design never saw it so it didn’t count).

    To my mind, the computer brings two things that render a lot of this as wasted effort – Ctrl-C and Ctrl-V. Those two, plus my rather purist view suggest we should have lots and lots of part numbers – if you need to identify the part later on, give it a new number, serialise it as well… Let the computer do the donkey work of replicating the change. Invest time and money in making the computer do what it is really good at – the same task lots of times – auto-update drawings to change part A to part B, ditto planning documents, tech pubs, whatever. But no, we still resist new part numbers and invent revisioning schemes to avoid it.

    As you say, ERP doesn’t really do revisions… and it tends not to remember them once it has used them. So we have a whole eco-system built on new numbers (production and in-service) and another based on as few new numbers as possible (design). You get away with this to some extent when the systems are not linked tightly, or are built to enable it, but most PLM ERP integration just doesn’t support this now – the revision (as you say) just becomes part of an intelligent part number (alpha rev is draft, numeric is released, slash rev is manufacturing….)

    So I don’t agree with your suggestion of revising without a new number, I think we should get the system to make that as painless as possible. But I do agree that interchangeability identification can help with that.

    • Nice analysis, pgarrish.

      Some thoughts – If only it were as simple as Ctrl-C/V (I like Ctrl D in Balsamiq personally). But that’s where I think many of the tools of the day have largely failed to deliver. Too much of that change still requires manual intervention because we’re crossing so many formats, applications, and relationships. I think it’s achievable eventually but it will take a much more pervasive and holistic network of federated point solutions working together like neurons in a brain. We’re far from that.

      The thing with keeping part numbers is in part a human element. Part of PLM is to encourage reuse. When products are changed for the better, ideally you want that change judged and applied everywhere it might be useful. Similarly, you don’t want to engender an environment where wheels are constantly reinvented. Both happen when the sea of part numbers becomes large and confusing. Again, that’s a limitation of the systems in use, but a limitation nonetheless.

      How do we improve this situation quickly and cost effectively?

      • pgarrish

        agreed Copy/Paste (or Duplicate!) don’t solve all the issues, especially since as you rightly point out, very little application work has been done to make it as easy as it should be. But I still maintain that we should be far less reluctant to generate parts than we are, and we should drive the s/w vendors to make that a more manageable prospect – better search, more automatic classification, geometric search (have you seen Shapespace?), more intelligent relationships – could all make it easier to manage a larger part library.

        • Agreed, perhaps new software vendors will take note.

  • Maher, good point. Interchangeability rules as they have been developed are highly biased from a mechanical part perspective – I think electrical design never had parallel champions to adopt variations that made more sense in the electrical design domain. The challenge is how to change the status quo, don’t you think?

  • Pingback: Mavericks of Engineering Change | E(E)()