Under the Hood

Tip Tuesday! Add Related Items to BOM and Change Orders

A big time saver when working with Bill of Materials is to add affected items.  If you have a significant BOM structure, you can grab parents and children all at once. This eliminates errors and serves as a catch all, as well as provides an understanding of what your proposed changes might do to corresponding parts and assemblies. 

I demonstrate in this quick video:

 

Check out the Help to learn more.  Let us know what future content you'd like to see in the comments!

 - Tyler Beck, Technical Marketing

 

Vault ECO - You Must be This Tall to Ride

This post may be an exercise in the bleeding obvious for some, but I thought as a final post on the ECO topic (for now) it may be worthwhile to provide some guidelines for working with change orders, in terms of who can do what.  For a more detailed understanding of ECO roles and permissions as usual make sure you visit the Vault help documentation and check out the ECO administration section.

The first thing to know is that a change order routing references individual Vault users, we do not support "group assignment" as part of the ECO process, in part as we really should be assigning ECO tasks to specific contributors rather than a group of users, in part as using groups would result in ill defined responsibilities and of course result in an overabundance of task notifications.  

Clear responsibilities and efficient notification come from purpose built routing's with only required participants.

Now, its fine if the users inherit their role based permission from groups of course but when it comes to creating your routing they should be added separately and should meet the following requirements:

 

Being Change Order Editor (Level 1)

If you are not at least a Change Order Editor (Level 1) you cannot participate in ECO's, you simply won't appear in the routing user list and this is bad, most people in the company should be able to at least create an ECO.  It's worth noting too there is very little difference between Level 1 and 2 for change order editors, we really define the users capabilities via the roles they are assigned in the routing list.

 

Filling all the roles

At very least your routing needs to have assigned a Change Administrator, Approver, Checker* and Responsible Engineer.  Without these folks the change order cannot be completed, so we do not let you create a routing like this.

Keep adding and editing participant roles until all the requirements are met for a complete process.  More role details can be found in help.

 

Being an Item editor

You are almost there - you are a change order editor, you have all the routing roles worked out, but do you have the right item permissions?  If you are planning to manage items through ECO's there are certain transitions that require us to edit items and change lifecycle states.  If you don't have at least an Item Editor (Level 2) assigned to responsible engineer or change administrator, you will see the warning below.

If you do not intend to manage items via change orders you are OK to ignore this warning and continue, otherwise you are going to have to go and add permissions on the security tab for one of these users.

With this done you should be set to go, everyone on the list is able to work with ECO's, all the key roles are under control and the participants can carry out the item actions required.  Now you just have to make sure people do the work assigned to them, the nice thing about a well defined routing is we can check up on this too!

-Allan

*Checker is only required when you opt to have a check state in your change order process.

Vault ECO - Not so fast with that state change!

We have spent a fair bit of time now learning how to control file and item release process through Vault ECO 's, releasing items when the ECO is done, making sure no changes can be made to files and items unless they are associated with an ECO and ensuring that the ECO cannot be moved to review unless its records are in the correct state, but we still have one small gap here, ensuring that record lifecycle state changes cannot be made unless your ECO is at the correct phase.

An excellent example of this is releasing files and items.  While we are able to change the states of items after approving, how can we be sure that files and items are not released before approval?

Here we can rely on lifecycle transition rules, setting the correct Change Order state a transition criteria.

In the image above the transition from Review to Released cannot be completed until the associated ECO state is "Approved", so not only does a file using this lifecycle definition need to be associated to an ECO, the ECO must be approved in order to release it.  You can of course add this transition rule to a number of state changes extending to "Review" or "Work In Progress" transitions.  

Once the conditions are met users are, as you would expect, able to change file state directly from the ECO "Records" tab or if not restricted to ECO's, from the project explorer or item master.

Its worth pointing out that in my previous post here we discussed how administrators are able to restrict all files and item lifecycle state changes to Change Orders, but from the transition criteria tab we are also able to add the transition rule "Controlled by Change Order is True", providing a more flexible approach to ECO restrictions.

By checking association with an ECO only on specific lifecycle transitions it allows organisations to restrict state changes to ECO's on certain files or items managed by this lifecycle definition or even just on specific state transitions within a definition.

That's about it though, you should now be able to choose either all records or specific record lifecycles to be managed by ECO's, control the record states as they leave ECO phases and the record state changes themselves based on ECO phases, making sure we have an audit-able trail of edits and approvals for all our mission critical design data.

- Allan

Vault ECO - Finishing your Work so it can be checked or reviewed

Another useful Change Order control we have traditionally managed via system settings is the ability to limit transition out of the "work" phase based on object lifecycle state, put simply, not allowing users to send a document for review while it is still in a working state.  

This can be important in many processes as we want some editing restrictions on a file or item that is being reviewed.  Changes to documents being reviewed can completely invalidate the process.

To set this, we again go to Change Orders tab on the Vault Settings dialog and this time select to configure (the quite descriptive) "Restrict Change Orders from moving out of 'Work' state based on File and Item Lifecycle states".

Here, for every lifecycle definition we can decide which states are NOT permitted on your Item or File when moving your ECO between Work and Checking or Review (depending on the workflow in use).  We can also here decide whether to apply this restriction to Items or files, or both.

Typically as I said we should look to place some delete and modify controls on documents in review state and make this state the only valid state when transitioning out of work for files and items.  Previously this option of course could only be applied to items and only the the review state, so the new settings here allow us to cater for flexible workflows as well as files.

Now - when we move out of work state with any of your records in an unacceptable state you will get an error:

How do we fix it?  Simply change the status of the file or item.

This is something which can be done directly from the records tab without leaving the ECO, provided your user, typically here the responsible engineer, has permissions to carry out that lifecycle transition.  

While in Edit mode on the ECO, select the affected records and right click to change state, assigning these to an acceptable state before transitioning the ECO to either Check or Review.

While we are controlling the ECO transitions with lifecycle state here, my next post will look at how we can do the opposite, limiting object lifecycle states based on the change order status, thereby providing a complete picture on how we tie record lifecycles to the change order process.

 - Allan

Vault ECO - How do I enforce this stuff?

There has been a number of subtle changes to ECO object behaviors of late, with the extension of flexible lifecycle definitions to items and addition of ECO record support to files we have seen necessary changes to the close ECO behavior as detailed in my last post, but also the addition of new properties and settings to control ECO workflow and manage lifecycle transitions.

First off we should take a look at the primary method for how we now enforce change order control over objects.  Typically once a change process is defined via ECO, administrators will want to ensure user adoption of the process, requiring any lifecycle transition to be approved via an ECO.  To enable this, from the tools and Vault administrator settings you are able to select the Change Order tab and configure "Restrict File and Item Lifecycle state changes to Change Orders".

From the dialog above we can see that the options to tie lifecycle state changes for either or both items and files to an ECO, providing a blanket requirement that all files and items states be controlled through an ECO and meaning that an ECO is required not only for change management, but initial file release.  This is a great way to ensure noone is accidentally releasing or "sneaking" designs into production without additional approval and we can capture the approval process for new designs as well as your change requests.

Depending on your teams needs it is of course possible to provide different routing's for initial release vs design changes (with different approver's etc) and if desired we can also permit the administrator to override the ECO control and change object states, something you may consider for special cases. 

So what does it look like when a user tries to change file states now without an ECO?  You will see here our user gets a descriptive error message indicating they require change order control for state changes:

Of course your administrator can be made an exception here and will not see this error, but otherwise the user has little choice but to assign the file or item to a change order and follow the prescribed approval process.

Once in the ECO we have additional means by which to control state changes which is worthy of a longer examination in my next post, where we explore how to limit or enforce state changes throughout the ECO process.

- Allan

Vault ECO is Done - What Now?

This blog relates to a change we made some time back, but this has some renewed importance with the modifications we made to Item lifecycles, specifically, merging these with the file lifecycle definitions to provide more flexible release processes and states.

In the olden days of ECO when you approved the ECO and the Change Administrator closed it out you were prompted to select an effectivity date and all associated items were automatically released based on that effectivity date.  What happens though if the ECO change is designed to "obsolete" an item rather than release a new change?  Well, you never really had an option there as release was the pre-configured outcome of an ECO closure.  

This automated release process was also hard coded to the previously fixed item Released state, meaning that when the ECO was closed we knew we had to change the item state and we knew exactly what that state would be - "Released".  By adding flexible states we lose this certainty, not only could it be released or obsolete, there could be more than one possible released state and it may have a different state name than we expect, so there is a need to provide flexible outcome in terms of the final item state as well as some manual user input to choose this.

For these two very good reasons (and also in part because of changes to the use of effectivity dates) we are now given an option at the end of the process to change states for attached items - whatever the final state required in your custom definition, based on the ECO intent and the available states in the lifecycle definition.

Looking at the actual process, once the ECO changes are approved and the Change Administrator closes the change order the above dialog appears prompting for the final item state, here, all affected items are listed and state can be set for each (independently or all affected) prior to closing the ECO.  Once complete the items are released or obsoleted and the ECO closed.

It is worth noting this workflow only affects items, files attached as a record are not impacted by the ECO close and manual state changes are required here.  We can though link the ECO state to file lifecycle transition controls and manage file release based on ECO approval (ECO must be approved before transitioning to Released state), certainly something worth looking at in greater detail in another post.

- Allan

Feature Friday: Gearing Up to Talk About Lifecycle Transition Checking in PLM 360

Let’s talk about a new feature we recently released to help your Change Management process.

Perhaps when creating the Change Order and adding the parts to the Affected Items tab it’s still up in the air as to which release path they would follow – is this an initial design revision or are we going to fast track its release?

Now if the lifecycle has not been set, there’s a friendly reminder to do so before the workflow moves to a locked or managed state.

I’m sure you guys will find this helpful!

--Michelle

Photo: Brent 2.0

Tip Tuesday! PLM 360 is Capable of That?

Looking to expand your company’s use of PLM 360?  We’ve updated our main webpage with more information about all of the key benefits of PLM 360 in a new PLM Capabilities section.  You can navigate to different pages covering the different core areas of many PLM implementations: BOM Management, Change Management, NPI, Supplier Collaboration, Quality Management, Cost Management, and more!

Be sure to visit and see what other pain points can be solved using the solution you already have. 

Interested in how other customers are using PLM 360?  Several customers presented at Autodesk University last month.  A couple classes you may want to check out:

BO2858: One Small Step for Man, One Giant Leap for Autodesk PLM 360 Implementation: Sprint to the Finish from Porex.

PL2024: Choosing Autodesk PLM 360: A Customer Perspective

from Greenpoint Technologies.

A great tip from Avi Robbins from Porex in his presentation on how to approach a PLM Implementation: “Think Big. Start Small”. 

--Michelle

Closing the Loop (PLM 360 links to Vault data)

This week’s PLM 360 tip covers how to establish a link from PLM 360 to Autodesk Vault. Now, for review we know that Vault Professional integrates with PLM 360, but this post covers a clever way to round-trip the process. This will involve some minor tweaks to any existing Workspace by creating a new field. First, let’s start with how we would get to the Vaulted file.

Whether you’re targeting a Vault Pro Item, Change Order, or a File, there is an option under the File pull down menu called Send Link. See image below:

Furthermore, you can shift-select a group of data and send it, and it will group all the Vault objects together. The key here is the link that it produces. In my example here I’ve chosen one Item. Note that is creates a link to the exact Vault object – Item, CO, or File.

Now that we’ve established one way to get the link to Vault data (yes, there are more elaborate ways) let’s focus on getting PLM 360 ready for the link. Log in to PLM 360 under an administrative account, and go to Administration>Setup and find your target Workspace. I’ve chosen Items and BOMs for my example.

Next, expand the Workspace and click the Item Details Tab entry. Click Add field and enter a name like ‘Vaulted File’ or something that establishes that this is a record that resides in Vault, as opposed to a url to another location.

Drag the field over to a section and Save Layout. Go back to the Workspace front end and choose an Item to edit.

Now, go copy the link to the link and paste it into the field you created. Save the item and examine the new data in the field. This is the link directly to the Vault file. But how does one use this?

Here’s where your mileage will vary. Depending on the browser you’re running and the settings therein, you will have to use a couple of techniques. First thing is to click the url.

If you have access to a Vault client, this will download a .acr file. Different browsers had this differently as mentioned, but the key here is to open the .acr file. By the way, this is the same functionality as getting an email from Vault Professional Change Orders when you are on the routing list.

However you chose to open the .acr, just be sure to set up your Vault client to ‘Automatically log in next session’ as this will save you the step of entering your name, password. And if I may suggest, use the Windows Authentication combined with auto log in for the best user experience. Finally, you will be brought directly to the Vault Item, CO, or File – providing you have rights to see it, but that’s another Blog post isn’t it?

PLM 360 Video Spotlight - Lifecycle Management

Hello all PLM 360 fans, enthusiasts,and aficionados. This week’s video spotlight is on Lifecycle Management. This video is timely as the Vault to PLM 360 Sync tool is now live on Autodesk Subscription Center. http://subscription.autodesk.com/

Lifecycles are a key part of Items in PLM 360 that go through revision changes. Items in PLM 360 that are in a Revision Controlled revise though the use of a Revisioning workspace that follows a defined Lifecycle definition. Within the Lifecycle route are states and transitions that define the behavior of the Items.

This video takes a behind-the-scenes look at the Lifecycle editor and how to advance Lifecycle states using a Change Order in PLM 360.

http://wikihelp.autodesk.com/PLM_360/enu/community/Videos/Lifecycle_Management_Guide

-Brian Schanen