≡ Menu

Bottom-Up Release is a Lie

section-1Top-Down-vs.-Bottom-Up.png
Share the knowledge

In my work in the PLM world (ha! See what I did there?) I often hear that release must be bottom-up. But from what I’ve seen that is rarely what is actually done. In truth, release is usually done top-down. We say that components need to be released before the sub-assemblies they go into, and the sub-assemblies need to be released before the assemblies they go into. But that isn’t necessary. It is often not even desirable.

Releasing Parts Top-Down

Let’s say I’m designing an Airplane. I know the airplane has two jet engines. I know the engines have a turbine. But if it’s early in the design cycle I probably don’t know how many turbine blades will be in the turbine. Regardless, Purchasing wants a bill of material released so they can start the process of ordering parts and material. I cannot hold up the release of the engine until the design is completely finished. For an initial release of the BOM it’s enough to say that the airplane has two engines but the details will be finalized later.

Releasing CAD Designs Top-Down

Later in the design cycle I need to develop an assembly drawing of the engine. For my drawing I need to show how the fan and the compressor and the turbines and the nozzle all go together. But I really don’t need every detail of the contents of each sub-assembly fully defined. For an assembly drawing I only need the exterior dimensions and interface. So my CAD design may still be a work in progress.

Releasing vs. Freezing

What may confuse people is that what we don’t want is for the CAD design used for the drawing to be modifiable. We want a static representation of the turbine, even if it isn’t completely correct yet. Therefore we generally insist that the components go through some sort of process where they are made read-only before the assembly can be released. We might call it releasing the components, but it probably doesn’t involve a formal or full review process — if it did, that would be significant delay in the schedule. Would you really want to hold up release of a top level assembly drawing because some bracket four levels down wasn’t released yet?

We don’t really need bottom-up release. What we want is a bottom-up freezing of the CAD design.

What does this mean in our PLM system?

Multiple Release Statuses

First, it means that you need a way to distinguish between something that has been fully reviewed and approved and something that has been merely frozen so that it can no longer be modified. Different release statuses are the obvious way to do that.

Different revision sequences

Second, you need a revising system that can handle the different release statuses. If your business rules say that the first full release of each part is done at rev and you need to freeze a revision of a CAD model so it can be used in a higher assembly you can’t be freezing rev . So you need some other revision identifier, perhaps numeric revs (01, etc) are used pre-release. Or perhaps you use a baseline style revision, –.01.

Single revision sequence?

It would be interesting to hear if anyone has simply said, revisions start at 001 and run to 999. The first released revision is the first revision with the Released status.

Freezing Part Structure

If you’re releasing a Part BOM it probably isn’t necessary to fully release or freeze the component parts. But you probably do want to freeze the structure. In other words, you may not need to freeze all the attributes of the jet engine, but you do want to freeze the fact that the plane uses two engines.

Separate Parts and Designs

I think it means that is helpful to distinguish between Parts which are what is bought and sold, and Designs which are the representations of those parts, generally as a CAD model. If you have a single record for both then you’re tying the release lifecycle of your Part data to your CAD data. The initial release of the part structure may not contain any CAD data at all. It may be just a BOM. Then again maybe you could have a single record for both but only add CAD models at a later revision.

On the other hand…

If your assemblies are small and your design times short, you might feel that this is all way too complicated for your needs. You can probably do just fine with a single item type that is both the Part and Design and insist on full bottom-up release. You’ll probably have the occasional bottleneck in your process, but the extra overhead may simply not be worth it the rest of the time.

Closing

That’s how I see it anyhow. I’m always a bit leery of making generalizations about how things like this do or should work. I know there’s lots of you out there who come from lots of different industries that are completely different from the industries I’ve worked in. I’m really curious if what I’ve said makes sense for you or not.

Please leave your thoughts on this in the comments. Thank you!

  • Teamcenter Heretic

    Great article Scott!
    I’ve been doing this Teamcenter thing for quite a few years and this topic ALWAYS comes up.
    One of the fundamental problems is that Siemens chose to call the status a “Release Status” instead of simply a “status” or as I prefer to call it a “maturity level”.

    Folks always get wrapped around the axle with the word “Release” and forget that if they view this as a level of design maturity (that can be read/write to any group of people) their universe can be significantly expanded.

    There is definitely a need to cut an RFQ for something like a forging (typically a long lead time part) or even packaging for a product before the product is completed. But you do need to make sure that version of the part is locked down so when your quotes come in you know what you asked for.

    So, simply combining a Status Object, Revision identifier, Rule Tree and Revision rules you can do amazing things with Concurrent Engineering.

    • Don Knab

      I agree Mark. “Release Status” is misleading for users, especially once you get past a standard OOTB configuration (which unfortunately many people don’t). A phrase we started using was “Flagged” since we came up with many different colors of status flag icons denoting different stages in the Part lifecycle.

      Scott, I think this also ties in nicely with your Master Model blog since separating models from drawings (as one example) allows you to manage them with different lifecycles. And of course separating the EBOM from the CADBOM enables all kinds of possibilities….didn’t you do a blog on that too? Too many blogs for me to remember :)

      • http://plmdojo.com/ Scott Pigman

        You know, Don, the scary thing is that it’s getting hard for me to remember what I’ve blogged on and what I’ve said in those blogs — it’s getting harder and harder to keep my story straight!

    • http://plmdojo.com/ Scott Pigman

      One simple thing that might be worth trying would be to edit the DisplayName business object constant for statuses to add “Maturity Level:” before the status name. “Maturity Level: Frozen”, “Maturity Level: Pre-Released to Mfg”, Maturity Level: Released”. Maybe a bit wordy, but it might help reset the thinking.

      http://plmdojo.com/tc/config/labeling-objects-codelessly/#.UW5x6KvF26w

      • Teamcenter Heretic

        Some folks also change the column name to something like “Date Statused”

  • Jeremie FEBURIE

    Great post,

    This topic is so frequent when deploying Teamcenter in a new company.

    Releasing and freezing are definitively two different concepts but supported by the same mecanism in TC : Status

    I share your opinion where freese is mostly performed top down and release is bottom up …

    Release is more away to control that all business rules are respected. It take time but it is the only way to control before sharing an official definition of the product.
    Freeze is more a baseline process where you want to save an intermediate state of your structure.

    Separating CAD and Parts could be a good idea to be more flexible.
    Freezing Part structure allows to push information to other businesses like supply chain and purchasing and avoid disruption of CAD designers who work on CAD structure.

    Each company has different way of working, different organization, different history.
    Best practice are not always applicable for all company and all industry sectors.

    Just one question : for which industry sector have you worked before ?

    Thanks for your blog.
    Jérémie

  • http://www.facebook.com/randy.ellsworth Randy Ellsworth

    Mark hit it on the head. Your article is more about the mis-match of status and maturity level. It omits other key factors like Baselining, Precise/Imprecise, End Item and Effectivity that could shed light on the topic. Both bottom-up AND top-down are required in most companies. The key factors help determine which is required for various situations. Otherwise we would have all settled on one method over the other. This is a tough subject to tackle and I applaud you for taken it on.

    • http://plmdojo.com/ Scott Pigman

      I agree, the problem is about defining maturity level. Mark’s suggestions about referring to release statuses as maturity levels was spot on.

      In the post I was thinking of “Released” as being the most mature maturity level. There often has to be wiggle room to allow for designs that aren’t fully mature to be used in a higher level “mature” design. I accept that both bottom up is often necessary too, but the idea that true bottom-up release is the only way that things will be released is false.

      I touched on baselining slightly (“baseline style revisions”), and I have some half-baked ideas about using imprecise assemblies in conjunction with precise assemblies (I know though that some have some, ahem, heretical ideas about never ever using imprecise assemblies ;-). End Items and Effectivity are issues that I haven’t used and need to learn about.

  • http://www.facebook.com/yogesh.fegade.56 Yogesh Fegade

    For businesses that manage products linearly (i.e. only one working revision at a time, latest released revision is the only revision that Engineering and Manufacturing is looking at, components are not revised as frequently, etc), it makes sense to enforce the rule where children must be already be released or be on the same ECN as the assembly.

    But for businesses that manage multiple variations/versions of product at the same time (managed using serial or date effectivity), top-down or bottom-up does not really make sense. All assemblies and components revisions are managed using effectivity. And as long as the entire assembly configuration has a valid structure for a given effectivity, all is good.

    • Teamcenter Heretic

      I’ve run into very few engineering Organizations that understand precise/imprecise and Revision Rules. Now throw in the various types of effectivities and let the fun begin…

  • pgarrish

    The key point is that whatever you ‘freeze’ to pass onto another group for use, be that procurement, or manufacturing or whoever, you need to (a) be able to denote that some form of handover has taken place (i.e. a dependency is now active) and (b) lock that part of the information set so it is obvious (or requires authorisation) when it changes. For me, Teamcenter fails on B because you cannot partially lock something easily. On a previous project, we split the part into pieces to enable access control to different portions, but it had the benefit of enabling lockdown of part of the dataset (e.g. design) whilst not locking other parts (e.g. production engineering). The global ‘frozen’ flag is just not granular enough.

    • Teamcenter Heretic

      Not sure what you mean but you can “partially lock” something.
      Can you explain a bit what you are seeing as a deficiency?

      • pgarrish

        Confession time first – this was Enterprise 2007 so UA may be better. But we wanted to lock certain fields on the Part Revision – so fields A,B,C after the initial review, D,E,F at the next review, then G,H and J at the final review, freeze the part and pass to manufacturing. We then wanted to enable and allow editing of some further fields relating to in-service ops. Siemens advised that couldn’t be done so the part was split into bits so each could be controlled independently

        • Teamcenter Heretic

          Ahhh… you mean “attribute level security”
          We int he former iMAN world have been asking for this for a very long time.
          Hope that you Metaphase folks can get it for us ;)

          • pgarrish

            So when you said you can ‘partially lock’ something, what were you referring to?

            For info, the way we managed the above was different UI (web) screens depending on control attributes – so Status and a custom Sub-status field were used to determine which fields on the screen were view only and which were changeable. In some cases we may even have used group membership to control field access. And then we had workflow managing whether the item could be checked out or not at all. So the combination provided extremely granular security/control. But it was complicated.

          • Teamcenter Heretic

            Lots of strategies can be used to lock/unlock/control access to a single object. The use of statuses, workflows and ACL is what I meant.

            Attribute level stuff is done using UI techniques similar to what you are doing.

          • http://plmdojo.com/ Scott Pigman

            This has been an interesting discussion, thank you to you both.

            I had one idea , but I have no idea if it would work as advertised. Supposedly now you can create pre-conditions on the setValue operation for properties. So perhaps you could implement a custom operation that would accept a status as a parameter and would grant or block the setting of the value.

          • Teamcenter Heretic

            re a value form write, but very few that can do this for read.
            Unfortunately all the techniques I know of simply obfuscate the value and any knowledgeable person can go find them.

            for instance, if you are not careful the values of a form storage class are visible outside of the UI via simple custom query. This is irrespective of what you fdo to the form itself.

  • Pingback: Git, and why We Need Distributed PLM | The PLM Dojo

  • TeamcenterOne

    The biggest problem with branching & merging in a broader PLM context, is not the merging, that’s quite easy. (Old time Teamcenter Enterprise had the option to use “Alternate Revisions” which was kind of branching items.) The biggest problem is how do you merge item revisions from different branches. While code (=text) can be merged with somewhat reasonable effort, how do you merge different geometric bodies or a electrical circuit board? How do you merge attached product documentation or test information?

    • http://plmdojo.com/ Scott Pigman

      Manually.And with moderate to great difficulty.
      You’re right, it’s not something easily done. But the need is real.

      Thanks for the information about old-timey TcEnterprise’s alternate revisions. I had not heard of that.

      • Dustin Neifer

        We used to use branch/merge/integrate functions in Pro/INTRALINK and Pro/ENGINEER like a decade ago. Granted Pro/INTRALINK was a “PDM” solution and not a “PLM” solution.

        The need to leverage those operations was infrequent however they did work as expected as long as whoever was performing them was of a certain caliber and could deal with the sophistication.

  • fguillaumin

    Good post, correct these questions are happening in every PLM implementation. I feel you mix different subjects: how working with different design team (one for the engine, one for the plane), and the release/maturity process. For the first one, the point is that the interfaces between sub systems (wing/engine) have to be released first in order to give each team the ability to work with a frozen environment. Usually we introduce configuration items, which are levels up to which the bottom up release process apply. The engine team has to modify (revise) this level in case it’s interface is modified, in order that the wing team is aware that the design need to be reviewed. But there is nothing automatic.
    Regarding staged release process for different functions, the technology has to provide a solution. I feel that multiple steps on the same object is not a solution, as all steps are required for each change, which is not true usually, except when the product is produced, and each change need to be approved in order to pass control plans etc.

  • fguillaumin

    Good post, correct these questions are happening in every PLM implementation. I feel you mix different subjects: how working with different design team (one for the engine, one for the plane), and the release/maturity process. For the first one, the point is that the interfaces between sub systems (wing/engine) have to be released first in order to give each team the ability to work with a frozen environment. Usually we introduce configuration items, which are levels up to which the bottom up release process apply. The engine team has to modify (revise) this level in case it’s interface is modified, in order that the wing team is aware that the design need to be reviewed. But there is nothing automatic.
    Regarding staged release process for different functions, the technology has to provide a solution. I feel that multiple steps on the same object is not a solution, as all steps are required for each change, which is not true usually, except when the product is produced, and each change need to be approved in order to pass control plans etc.

Optimization WordPress Plugins & Solutions by W3 EDGE