A Roadmap to Transition Off AgilePLM
Previously I have discussed some of the ways companies can maintain or extend the lifespan of AgilePLM. I have also warned that it is not a good idea to stay on the product too long and then to have to scramble when using it becomes untenable. One of the major challenges in moving off a system like Agile PLM is figuring out exactly how to do it without completely disrupting your company. Mission critical systems like AgilePLM play a crucial role in day-to-day activities and changing systems can create significant headaches and impact productivity and throughput. Careful planning is necessary to ensure that a smooth transition to a new system is achieved. To that end I thought it would be helpful to discuss based on 25 years of experience how this might be done in the most effective way.
As most of you are aware, AgilePLM is scheduled to move to sustaining support in 2027. This means that Oracle will no longer offer patches for security and compatibility with browsers and servers which will create issues in the future with most organizations’ IT departments. Running software in this state can be problematic and it would be prudent to make plans to move off the application sooner than later. The temptation would be to select a product and plan that minimizes the delta with your current environment. While there are merits to this approach from a cost and time perspective doing a pure lift and shift is a missed opportunity to improve current business processes and methodologies and fails to take advantage of newer functionality offered by more modern PLM solutions. If you are going to go through the time and cost to replace your PLM application, you should take the time to revisit decisions made years ago and to make sure you have the best solution in place to allow your company to maximize the value of the investment you are making in your new PLM application.
To that end step one on your PLM replacement roadmap should be an internal audit of your current system. Review what is working and what is not working and make notes for your future system. Identify functionality that you currently lack that is needed to support your business requirements and make sure it is supported in the new system you select. You try and think forward as much as you can to ensure you are not saddled with a limited PLM that cannot grow with your company and limits your capabilities. Out of the box capabilities and “quick start” type implementations are tempting but will ultimately lead to frustration when you cannot adjust to accommodate the inevitable changes that will impact your company in the future. Taking the time to do a full inventory of your current system will allow you to go into your next PLM project prepared to put a system in place that will justify the time and effort it takes to replace your current system and ensure future success.
The second step on your PLM journey will be to assess new PLM technologies to determine which one is best suited for your company. Going through the internal audit should give you a good idea of the features and functions you might need. PLM applications tend to fall into roughly three categories for discrete manufacturing companies. Engineering centric applications were originally derived from PDM technologies although not always. These applications are oriented around engineering data like CAD models which then drive bills of materials (BOMs). These systems tend to be complex and technical and are used by engineering heavy organizations with large groups of engineering resources. The PLM systems in this group are 3D Experience/Enovia from Dassault, Windchill from PTC, and Teamcenter from Siemens. The second category of PLM is manufacturing centric products. These types of PLM technologies are typically extensions of Enterprise Resource Planning (ERP) solutions offered as a module and tend to be very limited in true PLM capability in comparison to stand alone PLM solutions. Products in this category include SAP, Oracle, and Microsoft. The final category of PLM is stand along PLM applications. These solutions tend to be more oriented towards Configuration Management and Quality and Supplier Management. Companies that are currently using Agile PLM will find the functionality in this group of companies to be very similar to AgilePLM. In fact, some of these companies have ex-AgilePLM employees that were involved in development so it is likely there will be significant overlap in capabilities. Products in this category include Arena, now owned by PTC, Aras, and Propel.
Evaluating these applications should involve significant due diligence. Ensuring that the applications can handle the volume of data you have and can provide your users with necessary functionality is crucial. Some form of benchmark would be ideal, but pilots can be expensive and time-consuming. One approach would be to have initial demos and then down select to one company for some time of a pilot to ensure you have the capabilities you need to succeed. Partners with multiple relationships with vendors can accelerate this process and if you work with a company that understands your current system and business processes, they can be very helpful in this stage. They say,” decide in haste and repent in leisure” so make sure you take the time needed to fully vet your technology and partner. This decision will likely be one that impacts your company for the next decade, so it is important to be thorough.
The final step on your PLM replacement roadmap is to decide on your approach to deploying your new PLM system. I have often compared replacing your current PLM system with changing an airplane engine in mid-flight. It is important to create a plan that allows for significant user input and involvement without disrupting current operations. I have discussed the merits of gradual replacement in a previous article “Don’t wait to dig a well until you are Thirsty”. If this type of approach is possible it will yield the best outcome and minimize the impact on current operations and productivity. Regardless of the approach it is important to be realistic and give yourself plenty of cushion for unexpected challenges. Data migration can always present difficulties and if you are expecting to move large amounts of data into your new system it will take time. Working with an independent partner to create a plan versus working directly with the PLM vendor will produce a more robust plan that considers all potential challenges and options. PLM vendors’ priority will be to get you onto the new system as soon as possible while partners will be more focused on making sure everything goes smoothly and that the companies’ interests are best served.
The trip to PLM replacement is an ambitious journey and the steps needed to make sure you arrive at your destination are important. If you miss one or do it poorly you could find yourself lost in the desert of failed IT projects. Planning early and thoroughly is critical to success and gathering data about your current and future capabilities will serve you well. We are always happy to discuss options with our clients so feel free to reach out if you are looking for directions on your future trip and I wish you good luck and safe travels.