What are people using to manage the management of change process?

We currently have a paper system which is atrocious.  I am looking to upgrade and would like some references to good functioning systems.

Thanks
 

I'm not familiar with the management of change phrase, so had to look it up.

http://www.google.ca/search?hl=en&q=management+of+change&btnG=Search&meta=

Which link best suits your situation?

we do paper, it is atrocious but it is just the first check BEFORE the change is made. It is easier for the guys in the field to fill out/understand. They hate it nonetheless. They would probably hate anything that means getting "permission" to make a change

<<A good friend will bail you out of jail, but a true friend
will be sitting beside you saying " Damn that was fun!" - Unknown>>

At my current job we use a PLM.

My last company used all paper. I reorganized it by creating an Access database and an Excel spreadsheet to manage and track changes.

Chris
SolidWorks/PDMWorks 08 3.1
AutoCAD 08
ctopher's home (updated Aug 5, 2008)
ctopher's blog
SolidWorks Legion

Cor
I refer to MOC in chemicals industrial setting.  The ad at the top of your link actually has some potential.  

ct
What is PLM?

Managing the MOC process and paper is a horrible undertaking.  I've done it with paper and circulating files, with multi-user Access database, and an elaborate designed-for-purpose application.  The inflexible application was by far the worst.  The Access database worked ok as long as a designated individual had ownership and made sure the data quality was up to snuff.  When he got busy with other stuff, entropy quickly took over.

The key is knowing who's desk an MOC is on.  If you can do that, then the rest is pretty manageable.

David

PLM = Product Lifecycle Management

A quality configuration change system would have a brief cover sheet with approval signoffs, before and after descriptions, and expected benefits [wt, cost, performance]. Another item is disposition of material. Do you want to use up present stock, rework, save, or scrap it? Introduction point in time is another item of interest, which over-rides the usual material dispositions.

In an aviation engine plant we called the system the 'Chevrolet' system. The implication is that a major change would cause the creation of later revision numbers. In this manner the change does not get lost. PN xxxxx-02 [assy or detail part] would include the desired change. It would be built into a corresponding higher level assy number, etc.

You also need to cover spares and servicing - can the new part be used to cover these? Is there a problem with mixing new and old level parts?

Cheers

Greg Locock

SIG:Please see FAQ731-376: Eng-Tips.com Forum Policies for tips on how to make the best use of Eng-Tips.

You may find some posts of use over in forum781: -Engineering Configuration Management.

At previous employer we had paper system that actually worked better in my opion.  However, it was only really dealing with the drawing/data pack.  How it got cut into production and/or units in the field was handled separately.

We have a 'filemaker' data base here, meant to be goind to Access but the 'access guru' quit some time back and we don't have a replacement.  With this they try to also manage cutting into production/field and frankly, from an Engineering point of view it's a real pain, very cumbersome without any where near as much benefit as you'd hope from having an integrated change system.

KENAT,

Have you reminded yourself of FAQ731-376: Eng-Tips.com Forum Policies recently, or taken a look at posting policies: http://eng-tips.com/market.cfm?

At my previous employer we had a paper system that worked pretty neatly. The MOC process is supposed to be a funnel, first nothing should bypass it, then all you have to get right is the inputs and outputs.

Nothing should bypass it = have a very clear definition of what a change is and write it on the walls (I mean this literally). Any unmanaged change is highly discouraged (nearmiss investigation).

Change initiator compiles his paperwork (have clear definition of requirements for various types of changes) and sends it to MOC committee for their weekly meeting. MOC committee reviews and clearly indicates any corrections required. One member is administrator, keeps all packages and verifies corrected package. MOC committee then checks any applicable boxes on the "documents and procedures to be updated" list (= outputs). Administrator verifies document/procedural updates.

Much of whether it works or not is determined by people's attitudes.