In the first part of this series, we explored some of the difficulties inherent in selecting a product lifecycle management (PLM) system, including the usual psychological resistance to change, as well as ways of managing and preparing for this change. One of the strongest weapons in the arsenal of change management turned out to be the PLM system document, which outlines the company's vision for the PLM system. We turn now to the specifics of the actual implementation, including implementation management, prioritization of customization needs, and kickoff of the new system.
Part Two of the series An Overview of Product Lifecycle Management Implementation Challenges.
Implementation Management
Once a vendor is selected, the company should consider how to manage the entire implementation. The following gives some idea of how to manage this important issue.
i) Scope of work and establishing a steering committee
Sign a scope of work (SOW) document with the vendor which describes all the items that are to be covered during implementation of the PLM System. Provide the PLM system document, and all other information to the finalized vendor. Involve senior members of the organization in preparing the SOW document. Define the scope with mutual understanding.
Establish a steering committee with consultants from the vendor company and senior members of the organization (as well as with stakeholders of the new PLM system). Formulate the strategy for implementation, and chalk out a milestone-driven plan. The SOW document needs to clearly indicate milestones which signify some remarkable achievement, and which will also stand as payment gates (meaning that payments to the vendor should be linked with these milestones). The steering committee should meet at regular intervals to resolve any issues, and its decisions should be final.
ii) Infrastructure and installations
Once the SOW is prepared, the implementation will be kicked off. The steering committee contains a certain set of people who will lead various teams which will fulfill certain responsibilities. The various functionalities are the infrastructure group, the implementation group, and the quality group.
The infrastructure group will team up with various sections of the enterprise to procure the required infrastructure (such as the server machine, client machine, and file servers), and to identify and procure resources which can work on the implementation internally. If need be, they initiate the recruitment with the responsible human resources (HR) department, and form various teams.
The implementation group will be led by senior functional and technical managers who will drive the implementation by arranging the training required for the resources identified by the infrastructure group. It will also form a project plan for implementation.
The quality group will contain a highly experienced quality head, with a team which is well-versed in ensuring the software quality of new systems. They will assist the development through timely testing and by implementing the industry-accepted procedures to deliver quality systems.
Mapping of Current Processes to Software Features
Once the new system is installed, the next step is to perform a gap analysis and prepare a mapping document.
i) Gap analysis and mapping document preparation
Any software will have good features. After all, that's what impressed in the first place and led to the decision to buy it. But keep in mind that it is impossible to get everything out of the box. There should be rigorous study to understand the new system, its benefits, and the implementation procedure.
Since a PLM system document is already available, there is clear description of what is expected of the new system and what the current process is. Map the solutions available in the new system to the requirements. There should be mapping against each feature, and explicitly stated when a feature is non-available. If a feature is available through a different process, this also need to explained. This will raise questions of whether this different process is best practice in the industry, and also of the organizational benefits should this new process be followed.
However, if a requirement is so important to the organization that it cannot be ignored, it should be explained why compromise is viable, and the effort required to implement the compromise needs to be assessed, if possible.
Identifying Customizations and Assigning Priority
Once the mapping document is prepared, it will pave the way for identifying what features are not available in the system, and it will also illustrate the level of complexity involved in meeting these requirements. This mapping document will be presented to the steering committee. This committee will discuss and arrive at the list of customizations, ranked by priority.
i) Identifying customizations
The steering committee will have the mapping document validated through the input of the respective teams. These teams should explain the necessity of requirements if they are not available, and the possibility of changing any process as per the design provided in the new PLM system, to avoid customization. It is always better to avoid customizing new systems too much because it leads to loopholes, and the cohesiveness of the system will be reduced. There can also be related problems when there is an upgrade, or if the vendor releases new versions with enhanced features. Thus, only the most required features lacking in the new PLM system will be identified for customization.
ii) Assigning priority
Careful evaluation will limit customization. However, before a decision is taken about customizing for some feature, its importance and criticality need to be evaluated. Some features, though important, may not be required immediately. An enterprise should identify the immediate requirements that might be show-stoppers for a new PLM system implementation. Those requirements which are less important can be implemented at a later stage. It is always better to give ranking to these customizations, and to assign an end date for implementation for each of these items.
Technical Training on PLM Software
Once the process of implementing the new software system is in place, it is always better to obtain technical training for the resources within the organization, to avoid over-reliance on the vendor. Usually, this will be part of the purchase agreement. This will improve the organization's capability to solve many small issues that might arise after implementation.
i) Selection of the team
The selection of the team is an important first step. One needs to see what kind of core software the vendor is using in the PLM system (such as Java, .Net, C++, and so on). Organizational resources experienced in that technology should be selected. This will ensure that learning happens faster. Once they start learning about the new system, they need to have some practical exposure, and should be involved in the customizations identified.
ii) Scheduling the training
It is always good to plan things well in advance. Once a team is identified, obtain the consent of each selected member, and then free the trainees from all other assignments in order to minimize distractions.
Milestone-based Development
As per the SOW, the development should be milestone-based. At the end of each milestone achievement, a summary report need to be submitted to give information regarding key issues that may have come up, along with solutions to them. It should also identify potential risks that might hamper the implementation, so that a mitigation plan can be prepared. This will give the steering committee enough time to find ways to mitigate the risk. At the end of each milestone, the feedback of all the resources related to that milestone needs to be obtained, and analysis has to be performed about the expected results and the degree to which they are satisfactory. If some milestone has not yielded the results it was supposed to deliver, it should be not "closed" until proper steps are taken to ensure that the output of each milestone implementation is satisfactory.
Final Implementation
Once all the milestones are reached, the system is fully developed. The following phases will have to be followed to obtain full-fledged implementation.
i) Testing and adherence to quality
The quality phase consists of thorough system testing, acceptance testing, and stress testing. As modern PLM systems are web-based and used by multiple clients, the guidelines available in our article Guidelines for Performance Testing of Multi-client Systems (word document) can be followed. These guidelines explain how to ensure that the performance of new systems will be satisfactory, and enable the final rollout to go without any major issues.
ii) User training
Once the system is found to meet quality standards, then the new PLM system can be considered ready to replace the old system. This is the stage when users need to be trained. Some real data for any one product can be used for training on the final PLM software system. As PLM systems guide all the processes of product development, from design to market, this kind of data will be useful for training various users in different departments. The training process should include audio-visual tools, and every user needs to stay focused, and train in a systematic and proper way.
At the end of each day, there should be a question-and-answer session, where all the users are encouraged to raise any questions that they do not understand. They need to be allowed to create data of their own, and to work on various modules which are related to their work. It is best to frame some kind of tests which will identify the level of user understanding about the new system. This will raise the confidence level of users.
iii) Legacy data migration
Once users are trained, the stage is reached for transferring the legacy data from the old system to the new. There needs to be a "no-improvement period" for the old system (a no-improvement period is the time during which no new data creation or data modification is allowed). The data migration should use techniques like programming and simulation to facilitate smooth and fast data migration.
Once the data migration is complete, the new system is ready for launch.
iv) Kickoff
When all the data is available in the new PLM system and users are well-trained, the retirement of the old system can be announced, thus opening the new PLM system for users.
Initially, there might be erroneous entries or transactions, and there should be some sort of support available for undoing the transactions. Critical processes need to be carefully watched to see that erroneous entries do not cause any major damage.
Users who are performing well using the new systems need to be rewarded. The major benefits of the new PLM system need to be posted on an intranet or bulletin board in order to raise morale and motivate staff to use PLM system.
Conclusion
In this series we have identified various challenges that may come up during PLM implementation, and tried to provide possible ways of overcoming these challenges. We discussed how to motivate employees with respect to the new PLM system, how PLM software can be selected by making a PLM system document, how to use team meetings, brain-storming sessions, and the like, and how to use a scorecard for each vendor. Once the vendor is selected, the infrastructure and other initial procedures can be handled. We have discussed the preparation of a SOW, which clearly states the milestones for payment and provides a strategy of implementation.
During the implementation phase, we discussed various issues about how to map existing processes to the PLM software features, and how to arrive at a list of customizations and their prioritization. Then we discussed how a team can be selected, and the importance of training resources on the new PLM software. Further to this, we discussed how the data can be migrated from legacy systems to the new PLM system.
We do believe that this will help chief information officers (CIOs), design, manufacturing, and production engineers, and all those who play a crucial role in PLM system implementation.
In future, companies will be forced to release products practically every other day, due to fierce global competition, and the significance of PLM implementation will thus increase, along with demand. PLM implementation will need to be more rigorous, and methodologies such as rapid application development (RAD) and extreme programming (XP) might be followed to achieve this.
SOURCE :http://www.technologyevaluation.com/research/articles/product-lifecycle-management-challenges-from-solution-evaluation-to-kickoff-18616/
Part Two of the series An Overview of Product Lifecycle Management Implementation Challenges.
Implementation Management
Once a vendor is selected, the company should consider how to manage the entire implementation. The following gives some idea of how to manage this important issue.
i) Scope of work and establishing a steering committee
Sign a scope of work (SOW) document with the vendor which describes all the items that are to be covered during implementation of the PLM System. Provide the PLM system document, and all other information to the finalized vendor. Involve senior members of the organization in preparing the SOW document. Define the scope with mutual understanding.
Establish a steering committee with consultants from the vendor company and senior members of the organization (as well as with stakeholders of the new PLM system). Formulate the strategy for implementation, and chalk out a milestone-driven plan. The SOW document needs to clearly indicate milestones which signify some remarkable achievement, and which will also stand as payment gates (meaning that payments to the vendor should be linked with these milestones). The steering committee should meet at regular intervals to resolve any issues, and its decisions should be final.
ii) Infrastructure and installations
Once the SOW is prepared, the implementation will be kicked off. The steering committee contains a certain set of people who will lead various teams which will fulfill certain responsibilities. The various functionalities are the infrastructure group, the implementation group, and the quality group.
The infrastructure group will team up with various sections of the enterprise to procure the required infrastructure (such as the server machine, client machine, and file servers), and to identify and procure resources which can work on the implementation internally. If need be, they initiate the recruitment with the responsible human resources (HR) department, and form various teams.
The implementation group will be led by senior functional and technical managers who will drive the implementation by arranging the training required for the resources identified by the infrastructure group. It will also form a project plan for implementation.
The quality group will contain a highly experienced quality head, with a team which is well-versed in ensuring the software quality of new systems. They will assist the development through timely testing and by implementing the industry-accepted procedures to deliver quality systems.
Mapping of Current Processes to Software Features
Once the new system is installed, the next step is to perform a gap analysis and prepare a mapping document.
i) Gap analysis and mapping document preparation
Any software will have good features. After all, that's what impressed in the first place and led to the decision to buy it. But keep in mind that it is impossible to get everything out of the box. There should be rigorous study to understand the new system, its benefits, and the implementation procedure.
Since a PLM system document is already available, there is clear description of what is expected of the new system and what the current process is. Map the solutions available in the new system to the requirements. There should be mapping against each feature, and explicitly stated when a feature is non-available. If a feature is available through a different process, this also need to explained. This will raise questions of whether this different process is best practice in the industry, and also of the organizational benefits should this new process be followed.
However, if a requirement is so important to the organization that it cannot be ignored, it should be explained why compromise is viable, and the effort required to implement the compromise needs to be assessed, if possible.
Identifying Customizations and Assigning Priority
Once the mapping document is prepared, it will pave the way for identifying what features are not available in the system, and it will also illustrate the level of complexity involved in meeting these requirements. This mapping document will be presented to the steering committee. This committee will discuss and arrive at the list of customizations, ranked by priority.
i) Identifying customizations
The steering committee will have the mapping document validated through the input of the respective teams. These teams should explain the necessity of requirements if they are not available, and the possibility of changing any process as per the design provided in the new PLM system, to avoid customization. It is always better to avoid customizing new systems too much because it leads to loopholes, and the cohesiveness of the system will be reduced. There can also be related problems when there is an upgrade, or if the vendor releases new versions with enhanced features. Thus, only the most required features lacking in the new PLM system will be identified for customization.
ii) Assigning priority
Careful evaluation will limit customization. However, before a decision is taken about customizing for some feature, its importance and criticality need to be evaluated. Some features, though important, may not be required immediately. An enterprise should identify the immediate requirements that might be show-stoppers for a new PLM system implementation. Those requirements which are less important can be implemented at a later stage. It is always better to give ranking to these customizations, and to assign an end date for implementation for each of these items.
Technical Training on PLM Software
Once the process of implementing the new software system is in place, it is always better to obtain technical training for the resources within the organization, to avoid over-reliance on the vendor. Usually, this will be part of the purchase agreement. This will improve the organization's capability to solve many small issues that might arise after implementation.
i) Selection of the team
The selection of the team is an important first step. One needs to see what kind of core software the vendor is using in the PLM system (such as Java, .Net, C++, and so on). Organizational resources experienced in that technology should be selected. This will ensure that learning happens faster. Once they start learning about the new system, they need to have some practical exposure, and should be involved in the customizations identified.
ii) Scheduling the training
It is always good to plan things well in advance. Once a team is identified, obtain the consent of each selected member, and then free the trainees from all other assignments in order to minimize distractions.
Milestone-based Development
As per the SOW, the development should be milestone-based. At the end of each milestone achievement, a summary report need to be submitted to give information regarding key issues that may have come up, along with solutions to them. It should also identify potential risks that might hamper the implementation, so that a mitigation plan can be prepared. This will give the steering committee enough time to find ways to mitigate the risk. At the end of each milestone, the feedback of all the resources related to that milestone needs to be obtained, and analysis has to be performed about the expected results and the degree to which they are satisfactory. If some milestone has not yielded the results it was supposed to deliver, it should be not "closed" until proper steps are taken to ensure that the output of each milestone implementation is satisfactory.
Final Implementation
Once all the milestones are reached, the system is fully developed. The following phases will have to be followed to obtain full-fledged implementation.
i) Testing and adherence to quality
The quality phase consists of thorough system testing, acceptance testing, and stress testing. As modern PLM systems are web-based and used by multiple clients, the guidelines available in our article Guidelines for Performance Testing of Multi-client Systems (word document) can be followed. These guidelines explain how to ensure that the performance of new systems will be satisfactory, and enable the final rollout to go without any major issues.
ii) User training
Once the system is found to meet quality standards, then the new PLM system can be considered ready to replace the old system. This is the stage when users need to be trained. Some real data for any one product can be used for training on the final PLM software system. As PLM systems guide all the processes of product development, from design to market, this kind of data will be useful for training various users in different departments. The training process should include audio-visual tools, and every user needs to stay focused, and train in a systematic and proper way.
At the end of each day, there should be a question-and-answer session, where all the users are encouraged to raise any questions that they do not understand. They need to be allowed to create data of their own, and to work on various modules which are related to their work. It is best to frame some kind of tests which will identify the level of user understanding about the new system. This will raise the confidence level of users.
iii) Legacy data migration
Once users are trained, the stage is reached for transferring the legacy data from the old system to the new. There needs to be a "no-improvement period" for the old system (a no-improvement period is the time during which no new data creation or data modification is allowed). The data migration should use techniques like programming and simulation to facilitate smooth and fast data migration.
Once the data migration is complete, the new system is ready for launch.
iv) Kickoff
When all the data is available in the new PLM system and users are well-trained, the retirement of the old system can be announced, thus opening the new PLM system for users.
Initially, there might be erroneous entries or transactions, and there should be some sort of support available for undoing the transactions. Critical processes need to be carefully watched to see that erroneous entries do not cause any major damage.
Users who are performing well using the new systems need to be rewarded. The major benefits of the new PLM system need to be posted on an intranet or bulletin board in order to raise morale and motivate staff to use PLM system.
Conclusion
In this series we have identified various challenges that may come up during PLM implementation, and tried to provide possible ways of overcoming these challenges. We discussed how to motivate employees with respect to the new PLM system, how PLM software can be selected by making a PLM system document, how to use team meetings, brain-storming sessions, and the like, and how to use a scorecard for each vendor. Once the vendor is selected, the infrastructure and other initial procedures can be handled. We have discussed the preparation of a SOW, which clearly states the milestones for payment and provides a strategy of implementation.
During the implementation phase, we discussed various issues about how to map existing processes to the PLM software features, and how to arrive at a list of customizations and their prioritization. Then we discussed how a team can be selected, and the importance of training resources on the new PLM software. Further to this, we discussed how the data can be migrated from legacy systems to the new PLM system.
We do believe that this will help chief information officers (CIOs), design, manufacturing, and production engineers, and all those who play a crucial role in PLM system implementation.
In future, companies will be forced to release products practically every other day, due to fierce global competition, and the significance of PLM implementation will thus increase, along with demand. PLM implementation will need to be more rigorous, and methodologies such as rapid application development (RAD) and extreme programming (XP) might be followed to achieve this.
SOURCE :http://www.technologyevaluation.com/research/articles/product-lifecycle-management-challenges-from-solution-evaluation-to-kickoff-18616/
No comments:
Post a Comment