Product Lifecycle Management (PLM): Critical Issues and Challenges in Implementation - Information Technology and Product Development - page 95

review. Automating the engineering change process can actually dangerously and
needlessly slow it down; even create a false sense of comfort that the decision is the
right one by including reviewers in the process who do not have the ability to add
any value to a change decision other than automatically approving the change.
The engineering change process is one of the more “standard” processes in prod-
uct development. Although the PLM application vendors are not quite there yet,
the engineering change process is a great candidate to develop process maps and
implementation acceleration techniques similar to what is found in today's ERP
implementation tool kits. Knowing this, the PLM implementation team should be
sure to leverage the process experience of the vendor and the implementation partner
since there should be plenty of lessons learned from other projects. Sometimes the
application vendor can secure engineering change customizations that were devel-
oped and implemented at another client site. This can be a tremendous time and cost
savings to the project and should not be overlooked as a valid means of expediting
the PLM implementation effort.
5.4 The Failings of PLM Technology
There are very few really successful, truly showcase, PLM implementations so far.
One can find good examples with significant results in discrete product development
functional areas like resource management or portfolio management, to name two.
However, in the context of truly end-to-end PLM, successes are really hard to find.
Even when PLM solutions are organized into functional categories, the connections
to traditional product development measures such as TTM, product profitability, and
even product quality are suspiciously absent.
5.4.1 Lack of Maturity of PLM Solutions
One probable answer to these questions is that PLM software suffers from a lack
of maturity. As noted previously, the current PLM software market is analogous to
the ERP software market 15 years ago. At that time, the ERP market was a best
of breed smorgasbord of technology and capability. For example, Oracle was only
a database engine and you bought an HR package from one vendor and a finan-
cial package from a different one. When a company wanted a “comprehensive”
solution they purchased a number of applications from different vendors and pieced
them together - often with extensive customizations and interfaces - to address their
entire functional scope.
While the PLM functional footprint is improving, it is still fairly common to need
two to three different vendor solutions to effectively address the company's needs,
especially if those needs span the entire product development life cycle. As a result,
the PLM solution is typically a complex collection of tools, originally developed
separately and then loosely connected - sometimes by a vendor as a tool suite, but
more often by the PLM implementation team.