Don’t Wait Till You are Thirsty to Dig a Well
Being born and raised in Texas you hear your fair share of folksy sayings on how best to live your life. Most of these sayings are common sense and should be followed. It stands to reason that if you have a complicated problem, it is best to get to work on it before it becomes critical. Recently I have seen a spate of articles on Agile PLM’s demise and what Agile clients should do to address their situation. It is obviously a complex challenge for most companies so it is completely understandable that postponing action for as long as possible would be how most companies would respond to the problem.
The first question is do you really have to do anything at all? Is Agile going on sustaining support in 2027 really a problem that requires a response? I believe most companies think so but there are probably some who feel like if it isn’t broken why fix it? What should be factored into a decision to move off Agile PLM is that there hasn’t been a significant enhancement of the application since 2017. Oracle has been content to tweak its components to keep it compatible with browsers and operating systems and to try and keep it secure from hackers; but has not offered any real enhancements in functionality. That is a long time to use an application without any new capabilities. It is not unreasonable to expect other PLM applications that have had new releases can offer additional capabilities that could benefit most product development organizations. By staying on Agile PLM, you are putting your company at a competitive disadvantage going forward due to the lack of functionality and the dated user interface. There are several PLM offerings that now offer significantly more breadth and capability particularly around collaboration and information sharing. As the workforce ages Agile’s dated user interface becomes more and more of a problem. Finally, after 2027 Oracle will no longer be offering security patches so it will be just a matter of time before it becomes incompatible with browsers and operating systems and is viewed as a risk by most IT organizations. So yes, I would say most companies need to make choices going forward on how to replace Agile PLM.
Deciding that Agile PLM needs replacing is probably the easiest part of this equation. The next question is what do I replace it with? There is no one answer to that question. Every company has a different situation and has different business requirements, but a change needs to be made. Given the Software industry’s aggressive move to the cloud it would be wise to choose a cloud-based solution as a replacement. If companies choose another legacy PLM that is on premise there is a high likelihood, they could find themselves going through this process again in the near future. Legacy PLM solutions like TeamCenter, Enovia, and Windchill are going to have to reengineer and rearchitect significantly to become robust cloud solutions and this could impact the companies currently running on these platforms. Even some of the dedicated cloud solutions like Oracle’s PD offering are really on-premise applications running in hosted environments versus being true cloud applications. We have looked long and hard at the industry and while I believe many of the current PLM offerings can replace Agile PLM, it is Propel PLM that most closely resembles Agile PLM and matches up with the architecture and data model making it the easiest to transition to from the current cloud PLM offerings. The fact that it is built on Salesforce’s Force.com architecture also ensures it has the most robust and mature infrastructure for supporting performance and customization going forward.
Regardless of which PLM application you choose to replace Agile PLM you still have the daunting task of migrating current functionality and configurations and all your legacy data to your new platform. This will be an expensive and time-consuming activity. Data migrations are notorious for becoming very involved and given how long some companies have owned and operated Agile PLM it is highly likely that we are talking about many gigabytes of data and possibly millions of data records. The physics involved in moving volumes of data can mean weeks of system shutdowns which few companies could tolerate. Changing mission critical business systems is a delicate operation like trying to swap out airplane engines in midflight. Adding business transformation to improve process and take advantage of new capabilities is almost impossible to accomplish while migrating from your old system. Most companies consider it a win if they can duplicate their current system’s capabilities and get most of the data into the new environment. Trying to convince management to spend hundreds of thousands of dollars and to potentially destabilize current operations while offering very little return on investment is a tough sell in our current economy.
It is no wonder that most Agile PLM clients are still running the application today and have vague plans to replace it. But the issues I have described will not change and they will just accumulate more data and shorten the runway till they must do something. Moreover, given the age of most IT and PLM resources many of the people most capable of orchestrating the move may not be around in a few years, leaving inexperienced workers to oversee this critical jump. How do we address all the challenges involved in moving to a new PLM without creating more headaches and disrupting business operations? The answer is like with many complex challenges to break it up into smaller increments and do it over time versus trying to accomplish it in one fell swoop. At the risk of overloading this article with too many idioms, don’t try and boil the ocean.
A gradual move from one PLM platform to another may seem impossible. How do you synchronize data and process? The good news is with today’ technologies this problem is very solvable. Also, by selecting certain operations and processes you can get your feet wet with new technology and not even necessarily need to sync data. By launching pilots or limited PLM projects you can familiarize yourself with new capabilities to better plan your future move and to rearchitect business processes to fully utilize this functionality and improve productivity. It also allows you to gradually move data giving you a chance to cleanse and eliminate unneeded data, improving data quality and eliminating bad information. It also allows you to avoid the pain and expense of big bang data migrations. You may still have to do some data migration, but you can be more surgical about when and what you move over to your new system. This approach will also allow you to benefit sooner from new technology by deploying new PLM tools to address your current gaps that have inevitably been created by Agile PLM’s lack of new features since 2017.
In summary, waiting to deal with your Agile PLM problem until you absolutely must is going to create a painful expensive problem and, in the meantime, you are saddled with an antiquated application that lacks many of the features of newer systems. By acting now, you can gain capability and minimize the impact of changing applications in the future as you identify new business capabilities and selectively move data and process to your new system.
We will be highlighting some of the capabilities we have created to support this move with a joint presentation with Propel on August 22nd titled “Coexisting with Agile: A Phased Migration Approach”. Please consider registering for this event and learn more about an easier way to transition off Agile PLM. Digging wells is hard work especially if you are already thirsty.