Information Technology Reference
In-Depth Information
team - always results in a change to the existing, known BOM definition. But this
BOM structure change is important, even critical to the successful implementation
and adoption of the PLM application. Without a properly designed BOM - or to be
more accurate BOMs (often there are more than one BOM per product) - some of
the delivered features and functions will not work in the PLM solution.
Unfortunately, the PLM implementation changes three important variables used
by the product engineer: (a) the BOM definition; (b) how the data is recorded; and
(c) where the data is recorded. It would be no surprise that by this point of the
project, the project supporters are at best disgruntled sponsors. But even with all
of this change, the PLM implementation project is not addressing the one require-
ment that everyone thought that they would “get” - product development process
automation. So when the CTO asks whether the new PLM processes will have a
direct positive impact on the quality of a product, the project lead is often unable to
confidently answer the question.
5.3.5 Finding the Right Change Management Balance
One of the huge benefits of standardizing an engineering development process and
all of the procedures, documents, and data that go along with that effort is that it
is easier to now standardize and implement an effective engineering change man-
agement process. Theoretically it should be easy: what needs to be reviewed when,
by whom, and in what time frame. Also, the importance of the change process will
not be doubted nor debated by anyone on the implementation team, in the product
engineering department, or even in the company. As a result, one would think that
this functional process area would be easy to implement - WRONG!
5.3.5.1 “Do as I Say
...
NotasIDo”
Product change management definitions and implementation challenges run a gaunt-
let of issues. On one extreme are the managers who are so excited to now, finally,
have a way to get involved in the detailed development activities that they want
everything (all change events) to go through a formal change approval process. At
the other extreme is the truly renegade engineer who agrees that a change process is
important, but thinks all of his or her changes do not fit the change management def-
inition and therefore they do not need to follow the change process
except when
he or she thinks that they should. Each of these groups has a defendable argument
supporting their position with lots of examples of what “did not work” from past
experiences.
Getting the approval process right is tough, tenacious work. One of the change
management hurdles that need to be addressed in most all PLM implementations is
responsiveness. Product managers and even engineering managers will often design
change approval processes that “work on paper” but are cumbersome in practice.
One of the critical measures of a product development organization is time to
market (TTM). In order to drive TTM consciousness deep into the engineering
organization, “segments” of the product development process need to be measured.
...
Search WWH ::
Custom Search