5.1 Challenges stemming from institutional and cultural misalignment
After Company E implemented its PLM system, supply chain partners could use the online meeting function to synchronously review and analyze products prior to making final decisions. The related review data is stored in the PLM system database. Although the system is used synchronously in the product review process, misalignment appears to stem mainly from the exchange of knowledge among NPD participants, which can be analyzed from both institutional and cultural perspectives. Within the field of organizational change innovation, an institutional perspective explains the social-economic conditions in which collaboration between supply chain partners has taken shape as a management practice (e.g. Guillen, 1994).
Likewise, a cultural perspective addresses how team members react to new management practices such as knowledge sharing (e.g. Zbaracki, 1998).
The challenge in the institutional domain centers on IP segmentation and the standards for relevant documentation. The supplier regards material development techniques as proprietary information, and is reluctant to share such information. Thus, for integrated product design, only certain problems are resolved, making it difficult to improve product weaknesses. In addition, the technical documentation for problem solving stored in the project management system must be stored in the ISO format, but engineers consider data entry to be a mere formality, and the company failed to require a standardized documentation procedure.
The challenge in the cultural domain is related to engineers’ attitudes towards maintaining technical knowledge. The information engineers store in the platform is limited to solutions to partial product improvements, and they are reluctant to input detailed explanations for solutions in the project documents. This prevents engineers from obtaining key knowledge from the project’s knowledge database. The major reason for this failure to share information is that engineers treat problem solving knowledge as their own proprietary information and a source of job security. Thus, following discussions project engineers tend to not update the database, but rather deposit technical information in their private computers and only upload partial information to the platform.
5.2 Problems in business process redesign
The BPR methodology needs to provide a clear adjustment process to bridge the gap between the As-Is and To-Be models (Muthu et al., 1999). The problem in the institutional domain is the lack of integration engineers for the final product. When the NPD project encounters problems, the PM cannot determine how these problems interrelate. Since the participating engineers are specialized in different technical areas, none can provide a holistic description of the generic problem or propose a detailed and effective solution. The R&D Manager fails to assign a senior and experienced engineer to assist in managing the whole project structure, thus the PM has to seek the advice of senior engineers to identify project problems, and then ask the corresponding engineers to solve the problems. Thus, technical reports written during the problem resolution process only record solutions at a superficial level with insufficient technical knowledge.
The problem in the cultural domain is failing to link the project’s success or failure with engineers’ performance assessment. Since project engineers lack integration and cross-domain technical skills, they are not intrinsically motivated to develop solutions for project problems. When a product problem appears, the PM has to seek assistance from experienced engineers, and the PM is forced to ask the R&D Manager or material suppliers to provide solutions. Overall, the collaborative mechanism cannot be used to find a solution to project problems.
5.3 Leadership and intervention
The field of organizational change innovation provides a theoretical lens for explaining how key individuals deal with organizational contingencies during organizational transformation (Birkinshaw & Mol, 2006). The PLM system provides considerable help in building up the reward system because it can be used to summarize various kinds of project results and progress. Following system implementation, managers and engineers need to understand the system’s usage processes and make changes to current operation processes.
However, given the ongoing nature of the project, engineers are likely to complain about perceived unfairness in their KPIs. Managers frequently fail to make timely assessments or miss the final check on the process data, leaving the engineers ultimately responsible for project delays or data errors. The fundamental problem is that managers are not familiar with the system interface, and thus are unable to make quick decisions through the online system.
The CEO not only has to deal with operational level requests from engineers, but also needs
to ask managers in the project to provide performance assessment and incentive plans based on the system records to ensure positive interaction between managers and engineers. Once such a plan is established, project members become more willing to use the platform to acquire project related knowledge and engage in real-time communication to accelerate problem solving.
5.4 Collaboration among participating units
The success of supply chain collaboration relies upon the integration of internal and external operations, and the ensuing alignment of product characteristics (Holweg, Disney, Holmstrom, & Smaros, 2005). To engage in a collaborative R&D process, the enterprise and its supply chain partners needed to integrate of a variety of data and processes, and previous studies have shown that PLM can provide this kind of integration (Cantamessa, Montagna, &
Neirotti, 2012; Cassina, Tomasella, Taisch, & Matta, 2009; Gunendran & Young, 2010).
The marketing department and project PM are the main coordinators of technical matters during the NPD implementation, and all product documents in the NPD are developed based on standardized processes and document templates. The PM has to be responsible for integrating the PLM activities between the upstream and downstream and making sure that all documents are developed based on PLM system requirements. Thus, implementation of the PLM system requires a plan for system integration developed by the marketing department, the PM and the enterprise R&D department. The marketing department has to research the R&D system and other customer-related processes, while the project PM needs to examine the product’s design environment (including CAD software, document formats and internal communication documents) and the R&D department studies the organizational processes and document formats. The three departments jointly compile all data and integrate processes to develop the standardized communication documents and processes for the PLM system. The product is finally examined by the related supply chain members through the sales contact in the video conferencing environment.
The collaboration of the participating units is the driving force for the realization of the resolution process described in Figs. 3 and 4. The document format is discussed via the 3D functions, and the supply chain members thus engage in real time discussion and verification, thus familiarizing all members with the system’s discussion environment. As shown in Fig. 4, PLM system and its 3D capability provide assistance to project teams and supply chain partners in terms of identifying product failures. From a long term perspective, it is necessary for the organization to enlist support from upstream and downstream partners to overcome
the technical barriers. Therefore, adopting the PLM system gives the organization opportunities to not only integrate the resources of technical knowledge but also enhance the coordination capability for the technological development in the supply chain. Furthermore, it is also a resource for enhancing organizational competitiveness.