The Death of Change Management

CM2Death-Star-ExplosionAt the heart of any enterprise system, be it Product Lifecycle Management (PLM), Enterprise Content Management (ECM), or Enterprise Resource Planning (ERP), beats the steady pulse of change management.  Truly understanding the evolution of any complex system necessitates some form of change methodology.  It’s interesting though, that outside of engineering/manufacturing  circles, change management in of itself seems relatively unknown.  Even mention the term change management outside this realm of expertise, and the first reaction typically is “Oh, you must mean organizational change management.”  Qualify the term as engineering change management or document/asset change management especially and (with a few exceptions) it’s generally a world of deer and headlights.  Alarmingly, it seems the tenets of change management are to be forever confined to the a world of engineering complexity, not because of their lack of relevance but perhaps their lack of accessibility.  In contrast, witness the explosion of web applications that focus on real-time co-editing of content, sacrificing structure for immediacy.  As the pace of business accelerates, there is mounting pressure to adopt those immediate models.  Is this the death of change management?

Engineering change management practices arose well before any of the current software technologies digitized them, having previously been manifested as heroic spreadsheets governing forests of paper, stuffed in endless file cabinets, and accompanied by change authorization forms piled from here to the moon.  Often entire departments were purposed just to manage, file, sort, copy, and redistribute only the paperwork involved with authorizing and maintaining engineering change.  Any longtime veteran of engineering can easily recall document control departments, that in many ways are now largely defunct and replaced by enterprise workflows.

As a replacement for the paper-centric universe, the PLM, ECM, and ERP systems of the day have carried forth the traditions in an electronic fashion, usually for the better.  Usually.  Many of the systems in place were directly derived from their paper-centric forbearers, and still carry similar limitations in bureaucracy and accessibility.  Sometimes that accessibility is notably worse, from both a usability and flexibility standpoint.  Why?  For reasons of user interface, licensing, and/or specific software/hardware technologies, accessibility of these systems can be worse than their paper ancestors.  That’s an easily resolvable problem, but a common problem nonetheless.  At least a notable benefit has been realized by replacing the routing and processing of physical forms to electronic equivalents moving at the speed of the intranet.

The engineering change methodologies have managed to get by in engineering, where the burden of formal change management has been a fair price for system and product integrity.  Unfortunately, the relatively rigid and serial nature of change from the past has been preserved as is.  Change is generally allowed only if it has been authorized, and systems have little to no tolerance for ad-hoc or parallel changes.  With respect to CAD, I described this in more detail in It’s Time for Check In to Check Out.  But again, the economies of very complex systems have justified both the expense and pain.  Mostly.

So what’s the larger problem?  Wander off a certain radius from engineering or down to a company under a certain size and change management all but disappears.  The unfortunate reality is way too many organizations are getting by with brute force, passing documents back and forth manually like monkeys working on Shakespeare.  The bottom line is change management as offered in the various enterprise tools is neither accessible nor agile enough to be effective at those scales.  And no amount of Sharepoint is going to fix that.

It’s concerning that proven change management technologies on a large scale are all but abandoned when moving to the small scale.  Where do you see adoption regardless of scale?  You certainly see it in software source control.  Software source control allows change to happen in every direction (via forking), but its incorporation is authorized (with merging).  The universal adoption is readily apparent, be it a few hundred lines of an open source app written by a single individual to the millions of lines in a complex engineering project written by a global team.  It’s solid recognition that change management is necessary but also must be accessible to all.

Yet in document circles, things seem to be headed in the opposite direction: toward oblivion and utter chaos.  Case in point, the proliferation of real-time simultaneous editing in authoring web platforms aiming to replace desktop counterparts.  These are often targeted specifically at Small to Medium Business (SMB).  The coolness factor of watching everyone edit a document quickly fades when you understand there is no change control.  All change is throttled with or without authorization with the hollow argument that a version history acts as some sort of insurance.  It’s an all-you-can eat buffet of information anarchy.  So I ask again, is this the death of change management?

  • Wow… You folks make things so complicated.

    I hope it is the death. It was a very simple system and it still can be.

    What you left out in this article is the drawing was, and still can be, the product of all engineering. It would be released to blue prints originally then to microfiche. Today they are released as pdfs.

    Changes were relatively simple. If they were small you would create a 8.5×11 ADCN (Advanced Drawing Change Notice) describing the change and that would be attached to one of the above. From getting the rejection tag to release was very fast. These ADCN’s could be multiple sheets.

    If the change was more intensive, you would create a DCN (Drawing Change Notice) by directly changing the drawing, you would also incorporate the outstanding ADCN’s. This would take a bit longer since the complete drawing would basically have to be check again.

    Today with MBE we need to directly edit the model. Even if it is a hole size change and re-release the part/assembly. MBE does not allow the manufacturer to change the model. It seems like the model is sacred. To some degree it is. But if you have a complete drawing that goes with the model, things are a bit easier and more clear. The problem is with inspection. It is funny to me that we would send the manufacture a drawing and not worry how he made it as long as it matched the drawing. The drawing was basically the inspection tool. It is a bit different today.

    There is another problem with the Pro/e paradigm of linked assemblies. Let’s say the change is enough to alter the assembly or product to require another dash number. All of the assemblies have to change also. I am sure you can not have two of the same part in the assembly controlled by the PL or BOM. But I may be wrong.

    If you don’t have linked assemblies and all the part coexist this is an easy process of just replacing the affected part.

    Change is easy to document and maintain. But you have to realize that the changed part or assembly basically becomes a new entity.

    I have seen many parts at Boeing with changes to double letters AA and beyond. Not just to change the part but to add new configurations (dash numbers)

    You really need to define the deliverables. We need a model, independent assembly (with title block info on each part) delivered in a neutral format. The Pro/e paradigm is just too complicated, even if used in house. Add a complete drawing as a PDF. I suppose the assembly should be exploded if possible.

    I think that is what you are talking about, but I had to read the article a couple of times. Remember changes were in the realm of the drafter. He/she are the experts.

    • A few things here, Joe.
      Unincorporated change (your ADCN’s for example) causes two problems that offset any release turnaround advantage. The first is when that change is finally reincorporated, chances are whoever is tasked with that job is not familiar with the change and may interpret it incorrectly (especially if several changes were stacked together) introducing error. The second and most damaging is the interpretation cost of that attached change throughout the use of that drawing. Anyone who has seen a drawing with unincorporated changes stapled to it and highlighting everywhere are quite familiar with that cost. The problem is that cost occurs *every* time someone has to look at the drawing.
      In most cases, making the change at the part level should take exactly the same amount of time, unincorporated or not. In the manual drawing world that wasn’t exactly true – because time was needed to fetch the original drawing. In CAD, that should not be an issue. Authorization should be exactly the same for either method of change. If not, there is a double standard in place.
      It sounds like your MBE process has eliminated unincorporated change, probably for the reasons above. Why should that in of itself be an issue? With regard to drawings, it’s true that most humans still prefer interpreting a drawing than a model – but there’s no reason a proper MBE process could provide both. There is nothing in MBE that precludes the presentation of that information to a user.
      As for assemblies rolling due to non-interchangeable part changes, that is the classic configuration control price – the ultimate example of which every change is rolled up to a new end item (top level). This can be mitigated either by predetermined points of interchangeability or use of effectivity (which does allow you to have variations of the same part for different applications in the same BOM). Trouble is, because of implementation complexity, organizations have trouble enough just with BOMs, and very few have figured out proper effectivity models.

      • “Unincorporated change (your ADCN’s for example) causes two problems that offset any release turnaround advantage. The first is when that change is finally reincorporated, chances are whoever is tasked with that job is not familiar with the change and may interpret it incorrectly (especially if several changes were stacked together) introducing error. The second and most damaging is the interpretation cost of that attached change throughout the use of that drawing. Anyone who has seen a drawing with unincorporated changes stapled to it and highlighting everywhere are quite familiar with that cost. The problem is that cost occurs *every* time someone has to look at the drawing.
        In most cases, making the change at the part level sho uld take exactly the same amount of time, unincorporated or not. In the manual drawing world that wasn’t exactly true – because time was needed to fetch the original drawing. In CAD, that should not be an issue. Authorization should be exactly the same for either method of change. If not, there is a double standard in place.”

        We are talking about those that understand the engineering release system. Can we do the ADCN today? Of course, if we are still releasing drawings. But we have to get over the problem with the supplier modifying the part. If we use the drawing as the inspection document it is very easy and should be of no concern. The ADCN is very fast to release and easily documented. When a supplier would get the ADCN they would mark up the change on the drawing. It is very simple if you can read a drawing and understand the process. I have incorporated many ADCN’s, remember they are released with the same process as a drawing and are checked for form, fit, function and drafting practices.

        To change a model directly with any of the Pro/E programs would require a review of the original part as compared to the revised part. Many times history only programs can have unexpected consequences caused by the change. Especially if the original designer is not involved. Direct edit pretty much eliminates these problems. Now if you are using complete drawings the CAD system highlights any of the dims that have changed.

        “It sounds like your MBE process has eliminated unincorporated change, probably for the reasons above. Why should that in of itself be an issue? With regard to drawings, it’s true that most humans still prefer interpreting a drawing than a model – but there’s no reason a proper MBE process could provide both. There is nothing in MBE that precludes the presentation of that information to a user.”

        I do not have a model/PMI only process. I have a model and a drawing process. A complete drawing. As above you can release an ADCN to solve the problem. I feel that the model should only be used as a pattern.

        “As for assemblies rolling due to non-interchangeable part changes, that is the classic configuration control price – the ultimate example of which every change is rolled up to a new end item (top level). This can be mitigated either by predetermined point s of int erchangeability or use of effectivity (which does allow you to have variations of the same part for different applications in the same BOM). Trouble is, because of implementation complexity, organizations have trouble enough just with BOMs, and very few have figured out proper effectivity models.”

        In the past we delivered copies of the original drawing. It was something you could not change. I believe we should do the same today. We have the native part which has the model with the drawing created from it. We release the part or assembly in a neutral format, step, parasolid, .sat etc. Hopefully they will have the names of the parts in the part tree with a PDF drawing or even a excel parts list. Remember every part has a title block engraved on it. This gets stored as what could be call the “Blue Part” LOL. Each configuration release separately in its own file, it is really nothing more than saving a file as a new name. Much better than a dash numbers in an obscure BOM in reference to the drawings in a list of effectivities as in the past

        Here is a parasolid assembly created in Solid Edge and brought into both IronCAD and ZW3D. Both products can bring the complete assembly into one file. Notice that they come in with the part names listed in the part/assembly tree. We would have to make sure the standard format would include the part names/numbers. Now this with the title block engraved into the part leaves no doubt what you have when referenced with a drawing with bubbles and BOM.

        PDM Management
        http://www.tecnetinc.com/PDM MANAGEMENT.html

        Now when you bring this into a SW, Inventor, Creo Parametric, NX, Solid Edge, etc, all come in as external parts in an assembly file. This is a bit more trouble to work with. What I find a bit troubling with the PLM expert is that they really don’t have a good knowledge of the different CAD products available and how they could relate to PDM/PLM. Solidworks Mechancal conceptual works with all the parts in one file and call it “The Single Model Environment”, I call it the “Unified Design Environment” and I consider it the most productive CAD function.

        My PLM concepts is getting the information to those that use it and will not be modifying it. Like those that used to get the drawings, analysis, manufacturing, marketing, sales, etc. But today they can use the model as they see fit. I still don’t understand why the data management is not in a webpage format. You can have all of the data necessary available to the approved personnel. The designer wouldn’t even have to be involved. It could be done by a trained admin person working with a webpage template. I like how Dassault has done it with

        3D ContentCentral
        http://www.3dcontentcentral.com/default.aspx

        The only tools necessary to access the above it a web browser, Adobe reader and a CAD system that can read the neutral format, actually the web page can make a myriad of different CAD formats available.

        The PDM/PLM limitations are tied to the CAD platform. What is very disturbing is that this PLM problem is inherent even in the native system. Vested interest is probably the biggest problem. There has not been an investigation into a standard system. It really is very simple. I think even simpler that the original system. You know it would have been better if we called it 3D drafting in the beginning then you have the folks that understood and were responsible for this process still involved: The Drafter.

        The bottom line. Engineering data is not a system that can be easily automatized.

        • I agree with you Ed. I worked in several global companies which have all types of award and certifications (six sigma, lean, PPM and CQE and others) but have challenging time with understanding the change management process for either products, processes or production equipment. Each discipline is nibbling away but few or no one view it as enterprise configuration Management as strategic initiative within their company

          • Maher, completely agree! I don’t think any of those award certifications serve to do anything other than assure CMII is being honored and used as a blunt instrument, despite the specific needs of the enterprise. That’s where true lean philosophies should kick in to optimize, but sadly that’s often not what happens.

        • Joe,
          Your ACDN argument doesn’t compute – if the same approvals are required – change the original documentation. Don’t you think?

          I think what you struggle with is you place more emphasis on the drawing, while the PLM status quo places more emphasis on the model. The reality for me (and hopefully everyone else) is that both are equally important.

          As I’ve mentioned before, PLM can easily provide the right data to the right people, even through a web browser if the system is implemented with the right end users in mind.

          Your other comments are MBE related (it’s important to separate PLM from MBE one does not require the other) – there’s a new post to talk about some of those issues.

          • Joe Brouwer

            I have more clearly defined the definitions of the products generated from our CAD systems in this article.

            The Death of the Drawing
            http://www.tecnetinc.com/The%20Death%20of%20the%20Drawing.html

            I have designed parts directly since 1982 with CV. The solid model is nothing but a bit of graphics that can be used in a variety of ways, patterns for CNC, images for
            marketing, Analysis, graphics for planning, etc. I think many think these are
            the real parts. The AID (Associated Information Document) no matter what form
            adds critical information and travels together with the model. But in many
            cases there may not be a solid model and only a “Drawing”. So do we
            base our initial information search on the AID or solid model? It really is a
            no brainer. This is where MBE falls apart.

            The Embedded Title Block! A PLM solution!
            http://www.tecnetinc.com/The%20Ultimate%20Part%20Mark.html

            As for MBE or as the Cultist like to call it “MBD”. Boeing has implemented the MBE PMI system. They have two separate AID’s that travel with the Model. Can you
            imagine trying to manage all of this data? From one concise document “The
            drawing” to a multitude of different files doing the same thing!! As I
            have said many times “Band-Aids for self-created problems.

            Compare and Validation Programs? Band-Aids for Self Inflicted Wounds!
            http://www.tecnetinc.com/compare%20and%20validation.html

            The problem with the whole PLM thing is that they are trying to use the native CAD file for the deliverable. It is quite shocking to me. In the beginning (1982) we delivered a
            wireframe IGES and AID. I have never delivered a native file to manufacturing,
            even if we were using the same CAD system.

          • Joe, the fact that an AID is necessary at all points to a deficiency in the model based definition, and that downstream users have neither the skills nor the technology to process said information even if it were there. So it gets decimated into pieces, mixing old techniques and new – confusing many. We know much of the problem stems from the fact that 3D as of yet is not as ubiquitous and accessible as a 2D image. That will change in the future.

            Collecting all the critical information into the 3D space has tremendous value, and will drive a revolution of automation in the manufacturing floor. Just because today’s implementation thereof is half-baked, doesn’t invalidate the concept. One day we’ll look back and laugh that we simplified anything to 2D.

            With regards to a native CAD file as the deliverable, again this is an artifact of the present, where proprietary CAD formats rule the day, and a cohesive neutral format that can carry *all* the information yet be easily used downstream is still not there. That will change, it has to or we will continue to be stuck in the status quo.

          • Joe Brouwer

            It is amazing how you try to complicate the simplest problem.

            You have a solid model and you have an AID that has all of the critical information of the part or assembly. You may or may not have views on the AID. What is there to automate?

            I just chuckle when you say “drive a revolution of automation in the manufacturing floor”. Once manufacturing gets the information and their planning and setup is compete the original documentation is discarded. Engineering puts the original engineering in the electronic vault and may never be used again.

            So what is automation going to provide??? The CNC still has to be done, the machine set has to be done. So where is all this automation going to take place.

            You know…why don’t you design a part in a CAD system then take the part and deliver it to manufacturing. Find a supplier and work with them and ask what they want instead of demanding them to take what you want to deliver. They mostly just shake their heads and do the best to get the job done no matter how much it costs the customer. Manufacturers unlike engineering have to perform or they don’t get paid.

            You will then understand the process first hand.

            I do about 10 parts a month and I have been doing actual design and getting the parts manufactured for almost 50 years. Take a look at a few of my projects. Hands on experience has to count for something.

            TECH-NET Services
            http://tecnetinc.com/services.html

            You are right, today’s system is created by the vested interests of the major CAD vendors and can never work. Standardization makes them no profit. Take it from someone that worked for them, profit is everything. A neutral CAD standard format will be fought tooth and nail.

            Ed, why don’t you come up with a solution instead of saying the implementation is half-baked and waiting for a solution. It truly is very easy to write article after article complaining about the PLM industry.

            I have offered solutions, but they don’t come from a PHD with their hands in the pocket of the Major CAD vendor and their own interests. I offer a solution that is simple, can be standardized and mostly free.

  • pgarrish

    You’re right that there doesn’t seem to be a middle ground with engineering change – be that documents or designs (MCAD or otherwise). It’s either full-on CMII style change or version control if you are lucky.
    I think you’ve hit on the right approach with the ‘authorise acceptance’ model – rather than authorise the start of a change or even all the steps, you let people develop new solutions and authorise the acceptance of that solution into the set.

  • Pingback: Do you believe in Engineering “Real time Collaboration” Neo? | E(E)()