One of the great challenges facing traditional ERP vendors is getting customers to keep up with the latest version. Customers on older versions often don’t keep up with innovation and spend too much time on workarounds leaving both the company and the vendor unhappy.
All traditional ERP vendors face this problem, whether it be SAP trying to get customers to upgrade to S4/HANA, or Oracle and Infor trying to get the customer to move to their cloud offerings.
True multitenant cloud ERP systems are supposed to solve this problem, by making the vendor responsible for upgrades and keeping all customers on a single version. However, from time to time, even SaaS providers need to make changes that are so significant and potentially disruptive that customers resist the change.
Rebuilding a Multitenant Cloud System in Flight
One example of this is Plex Systems. As one of the first cloud ERP systems, Plex is now going through an architectural change to rectify several shortcomings of its original system, which it now refers to as Classic.
The new architecture, dubbed “UX,” includes a more modern user interface (hence, the name UX). At the same time, Plex is making major architectural changes, which go much farther than a user interface face-lift. These include a role-based security model and a transition to a microservices architecture instead of reliance on database stored procedures.
Moreover, Plex is taking the opportunity to refactor its program code, which over the years built up quite a bit of what it refers to as “customer-funded development” —short-hand for modifications to the single code base to accommodate unique, often mission-critical, requests for single customers. Although customer-specific functionality might have been acceptable when Plex had a few dozen customers, it has created unnecessary complexity now that Plex has reached several hundred customers and will not be sustainable when Plex reaches several thousand customers.
The launch of UX created a dilemma for Plex. Should it force all customers to make the transition to UX, when many of them may not be ready or willing for such a major change? Or, should it go slow and allow existing customers to use Plex Classic, allowing them to migrate at their leisure, while putting all new customers on UX? In other words, Plex faced a dilemma similar to that faced by the traditional vendors: How do we get our customers to upgrade?
Fortunately, the multitenant nature of Plex offered a way out. Instead of rolling out UX as a separate product, it could implement UX within its single code base, allowing customers to switch over from Classic on a user-by-user basis, or a function-by-function, basis. For example, a customer could switch accounting users over to UX while allowing shop floor users to continue running Classic (a common scenario). This gives customers a way to move to UX in an incremental fashion, which is less disruptive.
Missing Out on Innovation
Apart from architecture change, there are other incentives that encourage customers to move to UX. Most importantly, Plex is limiting updates to Classic to bug fixes and changes necessary for regulatory compliance. So, if an existing customer wants the latest-and-greatest innovation from Plex, it will need to adopt UX.
There are plenty of innovations. At its recent user conference, Plex described new and soon-to-be- available capabilities, such as a new Industrial Internet of Things (IIoT) suite, demand planning down to the building level, role-based security and segregation of duties, sequence planning and control for automotive manufacturers, enhanced loT and serial number traceability, drag-and-drop document attachments, a built-in knowledge center tool, new flexible billing options, and more. The catch? The customer must migrate to UX.
This approach appears to be working. In 2018, Plex reported 55,000 UX logins per month, while this year there are over 400,000 logins per month, as shown in the graphic above—a 700% increase. Moreover, there are now 150 customer plants running completely on UX, and based on current growth rates, Plex expects that number to double by the end of this year.
A Slow Start
So, are there any obstacles on the road to UX? During interviews with existing customers, we found two main impediments.
-
The first is simply customer inertia, as discussed earlier in this post. In this regard, cloud ERP customers are not much different from traditional on-premises ERP customers. If they have a system that works, there is not much of a driving motivation to make a migration. “If it ain’t broke, don’t fix it,” is the mantra. To this point, for many customers, the innovations in UX are not enough to get them to move forward.
-
But the more significant obstacle is the discontinuation of many customer-specific modifications in UX. Without getting into specifics, we learned from one customer interview that, in some cases, these are critical capabilities and not just “personal preferences.” Until Plex agrees to incorporate those customer-specific changes into UX, or the customer can find a solution outside of Plex, the customer is stuck in Classic. Fortunately, the new microservices architecture allows customers and partners to develop the custom functionality as extensions to Plex. In some cases, however, the customizations make more sense to incorporate into the core business logic.
More generally, it appears that Plex may have initially underestimated the extent to which customers would need hand-holding to make the transition, and it got off to a slow start. To its credit, it recognized the challenge and put Jerry Foster, Plex’s co-founder and current CTO, in charge of the customer UX transition program. Foster’s team developed the tools and documentation to make it easier for customers to deploy UX.
The UX transition program includes five phases:
-
Guided Discovery, to understand the differences between Classic and UX and whatever customer-specific development in Classic will need to be remediated.
-
Planning the cutover, in what sequence of job functions, and whether it will be via self-support or assisted by Plex or a partner.
-
Setting up and validating UX for the customer’s requirements.
-
Deploying cutover scripts and end-user training.
-
Stabilizing the customer’s use of UX and dealing with any outstanding issues.
The result has been the acceleration in customer UX migrations over the past year.
Realizing the Benefits
For manufacturers considering Plex, it is important to understand the real story behind Plex’s move to UX. Some competitors are apparently claiming that, in its move to UX, “Plex is running two versions.” The truth is that the transition is all being accomplished within Plex’s single code base. Additionally, UX and Classic share the same data tier which simplifies the customer’s transition by eliminating data migration and data integrity issues. Moreover, the transition only affects existing Plex customers. New customers will only be implementing UX.
Having started in the cloud in the early 2000s, Plex is now old enough to need an upgrade of its core architecture. But unlike traditional ERP systems, its multitenant nature makes it possible to accomplish this change in an incremental fashion without disruption to its customer base. Unlike traditional ERP systems, Plex’s approach removes the technical obstacles to upgrading. Although some customers will need to figure out how to accommodate special requirements, most customers only need to overcome their natural inertia to realize the benefits of a migration.
