If you're working for a large, established company, your engineering change process may have been set in stone for as long as you can remember.
But if you're working for a smaller company, maybe the way changes are managed depends on who's involved, the size of the change at hand, or the level of crisis-mode you're in. (So in other words, there is no set process for managing change, or there is a process that's not always followed.)
Generally, a change is made up of the following steps:
Finding an issue
Reporting an issue
Proposing a solution
Discussing a solution
Agreeing on a solution
Implementing a solution
Reporting that the solution was implemented
If one ore more of these steps are not happening when it's time to make changes to your product, there is a good chance you are experiencing a higher volume of scrap, cost overages and internal conflict than necessary.
If you don't have a process for managing changes (and a process that everyone follows) here are some reasons why you should push for one in 2012.
You may be able to get away with an informal or non-existent process for managing change when you’re first starting out, but as you scale, part quantities become more significant. With more money on the line, leaving things open to error or chance just isn’t worth the risk.
Additionally, conflicts between team members are more likely to occur if key people are left out of the loop, or if there is no process to turn to when things get hectic.
If you're looking to improve the way you manage change in 2012, keep in mind that an ideal system balances flexibility, speed and control. You want the right people to always be advised about changes, so there are no surprises later on when you’re buying parts in volume, but you also need to be able to make changes before issues get out of hand, so you want a process that can happen fast.