Imagine following scenario: 1.Sales department wishes to have some change. They fill "change proposal" for a specific top level item. This change proposal needs to be actually accepted for work. 2.The R&D department checks it and sees that it is a low priority change and that they can't do it now. The processing of the changed proposal is pushed back in queue. 3.The customer support finds a serious bug. They fill "change request" for the same top level item. 4.The R&D have to find resources to handle this change request. 5.A five month period passes, R&D have now free resources and they can pick up the first "change proposal" now. This workflow is possible in all free open source change management systems for software. We coders (and your software development team too) have a "ticket" system in which creating a ticket for a project does not lock up creation of other tickets. It is up to R&D team to pick them up in logic order. We can attach ticket to project without a problem. Thanks to "history branching" system (GIT users knows what I am talking about) we can even work at the same moment at overlapping changes, but it is of course too much to ask for. In Autodesk Vault the top-level product item is the "project" for us. This is where you start when looking for information about the "project" - ideally everything should be possible to locate with top level item as a starting point. Currently Autodesk Vault prevents us from creating second "change order" on the same item, thous this nice workflow is impossible. We have to resort to secondary "change order" system. Practically speaking Vault "change orders" are "changes about which management already decided that we have to do them NOW". Having two systems to manage changes is a pain in behind, generates maintenance costs, training costs and a lot of mess. My idea is then: 1.Assume that we have two primary groups of states for change orders: "created" and "working on it". 2.When change order is created, it is in "created" state. 3.When work on change order begins, the change order goes to from "created" to one of "working on it" states. This includes all acceptance stages, post-processing, whatever, until work is completed and can be a base for new changes. 4.As long as change order is in a "created" state there is no restrictions on what item or file can be added to it. Especially the fact that item is already contained in some other change order (in any state) doesn't prevent it from being added to "created" change order. 5.When change order is to make state transition from "created" to one of "working on it" states, this transition is prevented if any of contained items can be found in other change orders that are in any of "working on it" states. 6.When change order is in any of "working on it" states, a standard, current rules do apply. That is it is impossible to add items which are in other "working on it" change orders. This should make possible to: 1. Treat "Change orders" as "change proposals" until they gone to any of "working on it" states. 2. Bind "Change proposals" with all related projects (top level items) thous make it easy to find them. 3. Prevent processing of conflicting changes when actually making them thanks to restriction on state transition to any of "working on it" states. 4. Have one "change proposal" and "change order" management system what would save licensing costs, training costs and reduce risk of human mistakes during synchronization of two systems. Please consider it.
Show More