Skip to main content
S
surajakumar1-Visitor
1-Visitor
July 4, 2011
Question

configuration management

  • July 4, 2011
  • 1 reply
  • 1172 views

Dear All,


We would like to implement configuration management in our process. But we dont knowwhere to start.


Please help us to know the basic concept behind that and what is the procedure to implement.


Thanks in advance.


Regards,


S.Rajakumar

1 reply

A
AL_ANDERSON12-Amethyst
12-Amethyst
July 5, 2011
PDMLink Solutions Group:

We found that breaking down the Windchill enterprise change process into
Lean process terminology (i.e. "Supermarket", "WIP", "Exit") has helped
quit a bit in explaining the change process to our users and their
managers.

Basically, we turned our change process into a "pull" system in which we
can pull work into various points of the process as WIP exits that part of
the process while maintaining a cap on the amount of change WIP we are
performing in a giving context at any one time. We can then measure our
backlog and throughput times to help manage and control the process.

Here are the tool we used to explain the "big picture" of our change
process.





Then here is the tool we used to explain in a little more detail how the
change objects in PDMLink fit together. It is important to flesh out what
the new and old data versions will be on your ECTs. In our case, we only
included our WTDocument "Drawing" type object for release in this
particular training aid. At our company, we convert all CAD drawings into
CAD-neutral TIFF primary and PDF secondary files in a "Drawing" type
WTDocument for Release on an ECT.



Finally, the detailed breakdown of tasks by state across the entire
process if often difficult to communicate. We found flow charts and swim
lanes too complicated. Finally, we settled on this approach in excel.
Some of our Change Managers have actually printed this out on large,
wall-sized color print outs. It is very helpful since it uses the same
color coding as the "big picture," but breaks down every state into
individual tasks, not all of which are required depending on the type of
change and the routing options selected by the users. The combination of
all of these tools is a powerful way to communicate our change process.



The biggest benefit of this approach has been agreeing on the definition
of states and terms across all business units so that even when each
business unit processes changes differently (i.e. one group always starts
at ECNs, while another always uses Full Track ECRs, while another always
uses Fast Track ECRs, etc.), we can use common reports since there is
universal agreement on what is a "Supermarket," "WIP," or "Exit" task and
state.

I am including these for general reference as a format to communicate your
own change process. Of course, you would need to modify them to your own
states, processes, tasks, and terms to be useful to you at your own
implementation site.

Al Anderson
Solar Turbines Incorporated

Terms & ConditionsAccessibility statement