Information Technology Reference
In-Depth Information
is to keep the team focused on a vendor-supplied PLM solution and not a new one
created by the engineering department.
Flexibility issues and application performance can continue to fuel the engineers'
“not invented here” attitude. In Silicon Valley there is a large company that was
about to embark on a PLM implementation project. An external PLM consulting
company was asked to come in and meet with the product engineering team that
was leading the project to discuss how one might formulate a PLM business case
and validate some of their benefit assumptions. About 20 minutes into the meeting it
became obvious that they intended to build the PLM solution from scratch. Probing
at the decision criteria, the external consultants soon encountered a fairly typical set
of conclusions and reactions to the PLM software capabilities: medium functional
fit; a focus on hardware development and not on software; ridged technical appli-
cation structure; limited flexibility; and generally a poorly performing application.
But ultimately, as the discussion continued, it became apparent that the real reason
that this company chose to build their own solution rather than purchase from a
vendor was because the application selection committee (that was led by product
engineers) had convinced the company's senior management that “
we have the
best engineers in the world, and therefore we can build a better PLM solution
...
...
.”
Rumors are that they are still working on it.
5.2.3 Do Engineers Really Need Help?
Ask any product engineer if they might need help implementing a PLM appli-
cation and most likely they will say “we don't”! The truth of the matter is that
engineers have been implementing technical solutions for years - way before there
were COTS, consultants, or IT departments focused at automating the PLM pro-
cesses. The problem is, over the years, engineers have shown again and again a
disregard for typical implementation best practices when leading large application
implementations.
5.2.3.1 “Doers” Often Don't Plan
Regardless of how one defines PLM, a critical challenge that all projects face is cre-
ating a defendable “business case” for the project. IT vendors will focus their sales
message on “the big numbers”: total time to market (TTM) and product development
productivity. The typical engineer does not think this way. As noted previously, for
years, engineering has been automating parts of the product development processes
around the edges of their normal responsibilities. The engineer's mentality is - if the
automation is helpful then by default it is a valuable thing to do. Such a perspective
is appropriate when the solution is internally directed at a contained, “local” product
group and when the costs are negligible.
On the other hand, in the executive suite, there is a maniacal focus on the costs
and benefits that these projects will generate. It is not that the engineering group is
against a solid business case for the project. Instead, it is more of a desire to move
Search WWH ::
Custom Search