Information Technology Reference
In-Depth Information
5.3.1 Standard Processes - One Size Does Not Fit All
As noted previously, the duration and cost of PLM implementation effort, often
drives the executive team to a significant level of frustration. The executive
perspective is that it is the products themselves that are complex, while the pro-
cess of product development is straightforward. And as such, they believe PLM
implementation would also be relatively easy, but they are wrong.
One of the big contributing factors is that the standard PLM process is anything
but standard. Even within a company it is not uncommon to have a “lite” pro-
cess for those projects that involve the development of a new product based on a
common, existing product platform (or products that simply do not require a con-
sistent amount of development rigor). The key issue is that not all the products in a
company's portfolio are created equally. Often times a company's product portfolio
becomes diverse, full of products that do not have the same complexity levels, test-
ing, or even regulatory requirements. All of these factors inject a level of diversity
into the product development process too.
Understanding a company's product development process variances is critical
when planning a PLM implementation. It is important to know early on how the
project team intends to deal with the different products and processes already
deployed. Deploying more than one significant development process per project
phase is not a best practice. The most common way of addressing this challenge is
to analyze and configure the more complex of the process variants for the first phase
of the PLM implementation and limit the deployment to development groups that
use those broader processes for their new products. The goal here is to minimize the
amount of “re-configuration” the project has to do during subsequent phases; having
said that, this is a very tricky PLM implementation strategy to successfully execute.
Complicating the task is that the configured application cannot be the only deliv-
erable in the overall solution. The project team must also be thinking about the
necessary process changes required to effectively leverage the PLM solution. This
would further increase the value addition to the product engineers and provide the
right incentives for them to use the solution. If the development processes are not
properly addressed and effectively aligned with the PLM application, the solution
will not deliver enough value to individual engineers and they will soon find a way
to work around the system.
There is a large global electronic equipment manufacturing company that has
a very diverse product portfolio. They recognized a number of years ago that it
did not make sense to push the “simpler” products through all of the approval and
tolerance gates; change management sign-offs, etc. So they authorized a simpler
product development process to be used when designing product for certain product
families.
Unfortunately, the difference between the “lite” process and the standard process
was dramatic and the perceived value gained from following the more compre-
hensive process was very low. After a number of years, the management team
recognized that it was time to replace some of the aging application infrastructure -
PLM was one of the areas targeted for renewal. As the PLM planning team started
getting into the detail review of process metrics, phase gate deliverables, part reuse,
Search WWH ::




Custom Search