Released Items vs Released Files

[Anonymous]

After years of running 100% WIP, thanks in part to some early producststream scarryness, we're getting ready to transition to using some of the tools/features within the vault. Particularly we're looking at releasing items and implementing the ECO tools (thru the thin client).

Quick workflow questions for those of you that release items and or files thru the vault.

Files -

What's the point of releasing files when you can release items?

All of our files, except for the select few that I've been testing with, do not belong to any lifecycle definition, will that cause problems?

For that matter, what's the point of file lifecycle definitions?

Items -

I think that part of the intended workflow is that all library part items should be released, permenantly. That correct?

Anyone want to take the time to describe their item release workflow for me, as an example of what/what not to do?

Thanks!

Eric

Inventor 2014 Pro 64bit Build 246 SP2
Vault 2014/15 Pro Admin Update 1
Windows 7 Ultimate 64bit
Intel Xeon E5-2643 @ 3.30GHz
32GB RAM
Nvidia Quadro K5000

[paul.gunn]

Hi Eric,

Hopefully people can share their specific experiences. That said, normally someone would choose to go with either file lifecycles or item lifecycles. I think it would be pretty uncommon to use both at the same time. The point of having both in the product is more to provide multiple options - as different organizations have different needs. e.g. having file lifecycles is useful when customers may not have adopted items. If you are using items already than using item lifecycles would seem the best choice - I would not see a need for you to also use file lifecycles.

Paul

[Anonymous]

@paul.gunn If you choose to go the Item route, what are you supposed to do if on a drawing you need to display accurate lifecycle and revision information? This information is now contained in the Item but the drawing can only reference the part that is placed on it. Mapping the Item system properties to UDP properties in the part does not work because the parts are locked by the Item before these properties can be updated.

[Anonymous]

That's a very good point. We currently drive the rev level from the part thru the item, releasing the item may break that workflow. Thanks for the heads up!

[Anonymous]

I'm afraid it would. I have spent the last several weeks trying to come up with a usable workflow for managing everything from the Item side of things and haven't succeeded yet. I'm now getting ready to try setting something up similar to what you describe. I take it that you are using Items to manage your BoMs for more control and the ability to add non-modeled parts but managing all lifecycles at the part level? How is that working for you or are there any things I should watch out for? I'm moving from Vault Basic so it's all new to me...

Here is a recent thread where some others were helping me with this exact question and there are some third party options you might be interested in:

http://forums.autodesk.com/t5/vault-general-discussion/items-or-not/m-p/6274149

[Anonymous]

Our items and files have been perpetually in the WIP state and we link all item data contained within the Items and Item BOM to MS Dynamics thru a custom piece of software. It works great so long as the engineer puts everything in, just as it should be.

We've been doing this for so long that I doubt I could describe all the pitfalls especially if you already have a large data base. One big one might be mapping all the data correctly, this is where you will want to spend a lot of up front time deciding on what you want your items to display and perhaps compromising with regards to what you already have in your file metadata.

Another change will be the parent/child relationship and locking that takes place when you start linking to items. A lot of your freedom to modify is taken away by the new relationship.

A big, and ongoing, item pitfall is the fact that the item master uses a semi-unreliable web server connection to the clients and that link can sometimes drop out putting your item into an uneditable state. With 2015 vault pro includes a tool to unlock them but it's still a PITA.

[paul.gunn]

@Anonymous The security in the release state is fully configurable. So a common practice is to make the security read-only for most users but allow write access to a specific job processor user for purposes of syncing properties.

Paul

[paul.gunn]

@Anonymous Starting in vault 2016 the item locking was changed to survive a web application restart (cause of issues such as you mention). You should find that this should no longer be a problem for you moving forward.

Paul

[Anonymous]

@paul.gunn I hadn't thought of setting up a user with permissions to sync those properties. There a few ways I can see that working but none of them seem reasonable to me:

1. Purchase another seat of PDS just for the Job Processor to consume while it updates properties - sorry, there is no way our small dept. can get approval for an $8k purchase to do what we were led to believe would be a seamless process with Vault Pro
2. Have my users Release an Item, close out of Inventor, wait for the Job Processor to update properties, open Inventor, generate any required PDF documentation and finally be ready to send an updated order to a vendor?

I don't see that happening in real life but maybe I'm missing something?

[Anonymous]

I'll look into the configurable release permissions, that may solve the issue of backwarding the rev level but seems to defeat the purpose of releasing items.

[swalton]

As I understand it, you will also need an extra Vault Pro License and the workstation to run the software...

Our Windchill install includes a headless copy of Creo as a "CAD Worker" that runs on the server to handle Job Processor-type tasks. The lack of something similar in Vault has been one of the reasons that we have not used Lifecycles in Vault Pro.  

I've never understood why Autodesk does not include something similar.  Maybe you get to pick the CAD system you want installed (Inventor, AutoCAD, Revit, or whatever) and have to buy licenses for additional ones?

[Anonymous]

---

@swalton wrote:

As I understand it, you will also need an extra Vault Pro License and the workstation to run the software...

Our Windchill install includes a headless copy of Creo as a "CAD Worker" that runs on the server to handle Job Processor-type tasks. The lack of something similar in Vault has been one of the reasons that we have not used Lifecycles in Vault Pro.  

I've never understood why Autodesk does not include something similar.  Maybe you get to pick the CAD system you want installed (Inventor, AutoCAD, Revit, or whatever) and have to buy licenses for additional ones?

---

That would be awesome to simply have that all handled seamlessly on the server!

[Anonymous]

@swalton For the system properties like state and revision that you want synced between Items and Files why can't Vault manage these as a group and automatically keep them in sync without all this workaround custom mapping and Job Processor work?

http://forums.autodesk.com/t5/vault-ideas/manage-document-lifecycles-and-revisions-easily-with-items...

[swalton]

@Anonymous:

I sidetracked the thread a bit.  I wanted to reinforce the point that Autodesk's licensing decisions add cost and setup overhead to some customers. 

More Sidetrack:

We have a bit of an odd-ball setup.  The only reason we have Vault Pro is because we need replication between two sites and Autodesk stopped selling Vault Collaboration.  You get better performance at the remote site with replication than with VPNs.  We don't have an ERP at all. 

I am hoping to start using file lifecycles to better communicate which designs are complete and which are still in flux.  I want to control the files tighter, so I can know if parts are ready for detailing or production or if they need more design time.  We sometimes stop work on projects for 4-6 months or longer and it is hard to remember if a components is done or not.  Most of the other users don't want the overhead of changing lifecycle states prior to changing files, so anything that increases the cost/effort of file lifecycles makes using them a harder sell.

[Anonymous]

@swalton

Even More Sidetrack:

We moved to Vault Pro because we are an OEM that desperately needs better tracking of lifecycles and revisions and change management. It is really hard to generate accurate spare parts catalogs, etc. without this information! I also hope to lock files down so that they cannot be edited without communicating the changes to the whole team and ensuring that our ERP system is updated.

[Anonymous]

I built a little team and we discussed the benefit of releasing data, formally. Honestly, we couldn't see any clear benefit. It's a bunch of extra steps to do the same thing we already do by assigning to the item master, we're already saying that "because it's assigned to an item it is released" (unless it's obsolete). Seriously, we sat in a room for an hour and couldn't come up with one single convincing reason to release anything via items or files, only reasons not to do so.

So tell me ladies and gentlemen, waht's the point of changing the state of any file or item to released?

[Anonymous]

I have pretty much given up on using items. I do still plan on releasing files through Vaults lifecycle management so that the revision history is captured in a formal process but we are planning on managing BoMs entirely in ERP.

[Anonymous]

Just finished moving our Lifecycle and Revision schemes from the Item category to the File category. Things work much smoother now. You can change state from the ribbon commands inside Inventor, view up to date information at any time on the Vault Data Card inside Inventor, all without jumping through all kind of hoops and updating Item / syncing properties in Vault.

[Anonymous]

I still wish that this could be easily done using the Items workflow...

[Anonymous]

Congrats!

Seems to be a much better, more user friendly, way to go.