The PLM Upgrade Nightmare – A True Story

Warning: The story you about to read is true―a PLM upgrade nightmare to keep you up this evening.

A few years back I was working as the IT owner of a PLM system in a large company. The system I was responsible for was highly customized―built using one of the largest PLM software companies in the industry (I will refrain from naming names, but no one is innocent here, including myself). To be honest, I was new to the PLM industry and was figuring a lot of things out along the way. While I had decades of IT experience and knew that upgrading any large system would be problematic at times, nothing prepared me for the education I was about to receive from my PLM software “partners.”

A few years after our initial implementation, I was advised by my PLM software partner that our system had fallen behind, and I’d need to upgrade soon to stay in compliance. Hmmm, I dealt with FDA compliance, REACH compliance, SOX compliance, Dodd-Frank conflict mineral compliance and complying with my own company’s internal auditors, but what is this PLM software compliance you speak of? My partner informed me if we didn’t upgrade our software version, they couldn’t support us any longer. (For the record, can’t = we can for an additional fee).

So, upgrading the core software didn’t sound so bad. After all, at the latest conference, I’d seen some great features in the newer version of the software that I bet my users would love. Besides, they would appreciate being able to use the new browser versions that currently didn’t work. Let’s do it!!!

Ah, so it begins...

As I sat with the lead of my recently outsourced, offshore development team, he informed me that the upgrade would take about nine months, maybe a little longer. Nine months?!?!? Do you know what can be accomplished in nine months?!?! (Yeah, I get the punch line.) What about the other three projects scheduled for that year? The business couldn’t wait that long for them to be done. Promises were made, budgets approved, and resources committed. The rest of the conversation went something like this:


Me: Can you finish the current work for Commercial Marketing while doing the upgrade?

Him: (rubbing his chin and looking thoughtfully at the ceiling) Yeah, we can do it.

Me: How about the project for Package Engineering after that?

Him: (pausing and exhaling for affect and deep in thought) Yeah, we can do that too.

Me: And how about the project scheduled at the end of the year for the Product Development team?

Him: (turning around and looking pensively out the window for additional effect) Yeah, we can do it, but we will need to do all of this in one big release at the end of the year. No time to stop and implement each one individually.

Me: Um, ok. Can you really do all that?

Well, guess what? He couldn’t do it. And guess who spent the week before Christmas talking to three vice presidents from three different business areas explaining that their deliverables and the promised upgraded software would be months late? Let’s put it this way, my development lead couldn’t do that either.

And it Continues….

As I was thinking I would soon awaken from this bad dream, it only got worse. Months later, when the completed upgrade was released, it became apparent that most of the new features and functionality would not work in our environment due to the customizations that we built into the system during the initial implementation and subsequent releases. After all the work and disruption, there were only two things that were different as a result of the upgrade. First, we were compliant to a new browser, so we did get a check for that, but the second feature was something that we did not know about (sort of like the ghoul jumping out of the closet when you least expect it). The software vendor had developed sophisticated monitoring to track the usage of the countless variations of licenses that controlled access to specific functionality. I get the need for this sort of audit, but seriously? That may have been important to them, but it was not high on our priority list.

In the End…

In the end, we completed the PLM upgrade and the “free” software (with our continued payments of the yearly maintenance bill, of course). The total cost was significant―especially when you consider that the end result gave my company little in return. With the costs of the external development staff, internal resources to test and implement the changes along with the total disruption to the organization, I started to understand why many companies forego upgrades and allow their PLM system to fall out of date. I also developed a new level of appreciation for the negative impact of hard-coded customizations in large, enterprise systems. It becomes a simple case of the benefits not worth the cost and effort of the project, even with the understanding that the technical debt will slowly (or not so slowly) put you back in a headlock and you will most likely be forced to re-implement the whole system as opposed to just upgrade incrementally.


A Better Way

How can your PLM system stay current without creating a disruption in the IT flight plan? As a life-long IT guy, I know it starts with the design of a system and the realization that customizations are a way of life. The architecture must be designed to implement customizations without affecting future growth. At Aras, the platform is built on an industrial, low-code platform that not only supports customizations, but encourages it. The platform is so resilient that it can adapt to changing technology and business functionality by applying new releases and service packs whenever you are ready to implement them. Aras is so confident in the resilient design that upgrades are performed for their subscribers, when they are ready, and are included as part of the cost of subscription. Now that’s how you partner with your software vendor.

For further information on Aras’ Resilient Platform, read the eBook and White Paper.

Anonymous