The Upgrade Process: Frontline Operations Platforms vs. Traditional MES

We’ve all seen firsthand the impact a small upgrade or bugfix can have on improving your day-to-day workflows, unlocking new functionality, or resolving a critical issue that you are experiencing.

Upgrading is essential for keeping your systems functioning optimally, fixing bugs, and capturing value from new vendor-developed innovations, yet for some manufacturers, it takes months to get the updates they need.

Discussing with Tulip’s very own Olivier Néron, it became clear that waiting a few months isn’t even the worst part of upgrading MES.

Olivier spent the last 25 years in the Life Sciences industry implementing the top 5 traditional MES systems. Oliver had the opportunity to work at small, mid-sized companies (ELAN, Propack-Data, and Werum) and large corporations (Honeywell, Körber, and Rockwell Automation), implementing several different types of MES systems like the XFP, PMX, PharmaSuite, POMS/POMSnet, and PAS-X.

In this post, we will explore the hidden (and unfortunately generally accepted) cost of upgrading that impacts the total cost of ownership MES solutions. We’ll then discuss the approach enabled by no-code app platforms, such as Tulip, and the resulting advantages.

Before we dive in, I think it is important to differentiate between customization and configuration when comparing the MES approach to the new approach with Tulip’s no-code platform. ‘Customization’ refers to code changes that a vendor or integrator makes to a product to provide a more tailored solution for a customer. These code changes impact the base functionality. ‘Configuration’ refers to how a customer sets up the existing functionality to create a more tailored solution for their processes without touching the code. In both cases, these changes are based on customer requirements.

The approach that traditional MES vendors take to provide tailored solutions to their customers is through product customizations via code changes. According to Olivier and a few other MES veterans I spoke with, this is a very standard approach. As we’ll see, customization is fine and great until the system needs to be updated.

Product Updates

With MES software (and most software products), you have the main product branch and then a product patch branch. The main product branch has major releases every 6 months to a year, usually with big new features and updates.

The product patch branch results from a mix of features and error corrections (between 10 and 450). When it comes time to update to the latest features available with the main product branch, a vendor will install a backport of error corrections for the customer on the branched version. This entails regression testing to make sure the updates don’t cause problems.

In this scenario without customizations, you can see that things can get messy pretty quickly, but an MES vendor can deliver corrections fairly quickly in days or weeks.

Adding Customizations per Manufacturer

Now let’s add to the impact of customizations. For each customer, a vendor will create a project instance copied from the product source code and invest 1,000s of hours on product adaptations (customizations) for a solution to meet the customer’s requirements. These customizations are made with hard-coded changes. Now the customer has a customized software version that needs to be validated and deployed.

Whenever a new product update is available, the vendor representative needs to provide a customized backport for the customer’s custom version of the product. Corrections take weeks or months to complete.

Adding Customizations per Manufacturing Site

To add even more complexity, a single manufacturer may actually have multiple sites that all require site-specific customization.

Whenever a new product update is available, the vendor representative needs to provide a customized backport for each of the customer’s custom versions of the product. Corrections take one to two months to complete.

Impacts of the MES Approach

This MES approach comes with plenty of disadvantages and headaches.

Enticed by new product updates, a manufacturer may want to rejoin the main product branch again and complete a large upgrade project. Fed up with trying to maintain multiple versions of the same product, the manufacturer will try to adopt just one version and each site will claim their customization is the best.

For each code update, a validation step is needed to prove the system operates as it should.

With the complications of upgrading, after a vendor product update is available the site will not be able to see the latest updates for months.

Tulip’s Frontline Operations Platform handles solution tailoring a little differently. As mentioned earlier, Tulip does not provide product customizations for each of its customers. Rather, Tulip’s no-code platform is configurable and you can update the interface, data structure, triggers, connections, etc. on your own — or with a little help from a Tulip or a Tulip partner. Tulip is also a cloud-native platform that can be deployed with AWS, Azure, or AWS GovCloud.

What this means from an upgrade standpoint is that platform updates are incredibly simple and fast. If your company prefers biweekly platform updates, you can see new features and bug fixes automatically. Tulip also offers long-term support releases 2-3 times a year for customers that prefer more control of when they upgrade. In each case, you can stay on the main platform branch and get the latest features and bug fixes without disrupting your configurations.

If you or any Tulip customers need a correction, Tulip can provide it with a point release within a couple of days. This update is available to any customer that wants it. And there is no risk to waiting, as the fixes get rolled up into the main platform branch for the next full release.

Tulip can deliver corrections in hours or days. For changes that involve tailoring the solution, you can make the changes in-house without relying on the vendor or an integrator.

Tulip allows for a simpler validation approach with each update. Tulip has an auditable QMS and provides a fully validated platform release every 6 months. Apps created based on customer business needs are considered configuration in the context of validation and are in themselves the documentation of the MBR. The MBRs are version-controlled and accessible within Tulip. Apps when they are executed, generate a fully compliant history record that is fully digital and linked to the MBR version.

MESs provides a solution to a subset of the problems that Tulip helps companies solve.

Tulip’s frontline operations platform provides a solution that can address more use cases, including work instructions, logbooks, quality reporting, lean manufacturing, and more. See the Tulip Library of apps, templates, and connectors.

Tulip’s platform can collect more information than just from machines and sensors, including from humans, camera triggers, and devices. Give your production data more context and have a more holistic picture. This data is accessible to those that have the correct permission to see it and you can create real-time dashboards of key metrics with powerful analytics built-in.

Tulip is easy to update and the no-code app editor makes it easier for companies to own their system, rather than rely on vendors and integrators to make simple changes.