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

PLM application vendors do not always have the necessary skill sets internally
to configure or customize a particular PLM feature function. In 2005-2006, one
leading PLM vendor completely outsourced the change management functional-
ity revisions to their India-based development partner. This must have seemed
like an effective strategy until customers started requesting “experienced ven-
dor resources” to round out project team capabilities. On one project, the team
needed help customizing the approval routes required to promote an engineer-
ing BOM to a manufacturing BOM. After what appeared to the customer to
be unexplained and unnecessary delays, the vendor eventually responded to the
request with the local contact information for their partner's consulting ser-
vices and an “aw-shucks” explanation of how they had actually outsourced the
development.
5.4.4 Oops! Reporting
Reporting is the task most often left until the last minute of the project. Although
not a best practice approach, many project teams wait until the period between the
deployment and the testing (or even during system testing) to start working on the
required reports. For some projects, it is not until this “slack period” when the imple-
mentation teams have finished their configurations and customizations and they are
waiting for the rest of the application to be completed that the reporting solution
is even addressed. Regardless of how the reports are approached, the problem of
reports will always surprise the inexperienced PLM implementation team. But what
exactly is the problem with reports? Can it be different or worse than what we are
all used to from ERP or CRM implementations? Unfortunately, yes.
5.4.4.1 Who Forgot the Reports?!?!
Reporting on the progress of a product development effort is a very company spe-
cific requirement. Since there is no way for the PLM software company to predict
the infinite number of different ways all of the different customers will layout the
same data most of them don't really even try.
The reasoning aligns with some earlier points in this chapter: ERP solutions have
the benefit of standardization - especially for public companies complying with the
Sarbanes-Oxley regulation. This is simply not the case for product development.
Escalation definitions, acceptable timeframes, approval windows, where used parts
are all examples of critical management action information that is different for each
company and could even be different for the same company across different product
lines. Furthermore, it is not uncommon to have a lively discussion with the PLM
pre-sales team regarding whether you need reports at all. The standard argument is
not without some merit; the way that the PLM applications are constructed, many
of the data lists that are displayed to an engineer as he/she works their way through