The Revenge of Custom Applications

Nov. 12, 2018
Fast-development platforms have been catching on to provide easy implementation of one or two MES/MOM functionalities, along with the ability to customize as needed.

In the past year, I’ve seen a significant increase of requests for proposal (RFPs) of manufacturing execution system (MES) applications to be developed on non-traditional MES platforms. They are typically not looking for fully functional MESs, but rather “basic” MES functionalities such as overall equipment effectiveness (OEE), downtime analysis, etc.

Nevertheless, the trend has been a little surprising. I’ve spent almost my entire professional career convincing customers of the importance of using a standard platform for developing MES and manufacturing operations management (MOM) applications and of leveraging as much as possible the out-of-the-box functionalities those platforms were providing.

I was confused by the change of approach and it took me a while to better understand what the reason was behind it.

In the market, there are four types of products/platforms that can be used to implement MES/MOM functionality:

  • Enterprise resource planning (ERP) systems: These are platforms that weren’t developed to fully support the operation’s needs. They provide mostly financial, commercial and planning functionalities. Many of them have extensions to expand to the operations, but most of them are ineffective in doing that. Operations is a different world they were not created for and this makes them struggle in supporting the operator’s daily activities, especially if real-time data management is requested.
  • MES/MOM platforms: There are several of them in the market, each of which best fits a specific kind of industry. Some are more oriented to process industries, others to discrete. All of them have a significant amount of pre-built functionalities that can be configured and used out of the box. The value proposition is that you do not need to reinvent the wheel and can use those functionalities almost as they are, with some configuration, to adapt to specific business processes. Moreover, working inside a platform to add functionalities or update the system is easier and the investment is better preserved. The flip side is that each company is different in its organization, even if it produces the same product. So there’s not a single solution that fits all the needs, and the required customization is still pretty significant.
  • MES/MOM function products: These are single applications that solve a specific single problem (or a very limited number of problems tightly connected to each other). Easy examples are the products used to implement OEE or downtime functionalities. These are pretty specific requirements that can be fulfilled by a standard product—as long as you accept that you’ll have to adapt to how they do the calculation and solve the problem, with limited ability to customize. They are cheap, easy and fast to implement. But they cannot be expanded and their usage is limited to solving the single problem they were created for.
  • Fast-development platforms: These are the outsiders and the new elements in the landscape. They were not built to solve a specific problem or to implement a specific type of system. So they do not provide out-of-the-box functionalities for any kind of application. They do not provide order management, work in process (WIP), OEE, tracking or genealogy functionalities. They were designed with a focus on keeping development and maintenance easy and fast. They limit the need to write code and provide a visual environment to build both the front and back end of an application. They have visual tools to rapidly create appealing user interfaces providing modern user experiences. They also provide visual tools to develop the back end, connect to data sources, and fetch, elaborate and deliver data. They enable customization through scripting or standard code development, but everything is done inside a platform to guarantee compatibility and maintainability and avoid conflicts between different components or functionalities.

In the above list, I did not include the standard code development tools or environments, which are always available but not frequently used to build an application if it’s not meant to be reused many times.

In this scenario, the fast-development platforms are the outsiders and the ones that are really changing the trend of requests we are receiving. The reason behind that—or at least the reason customers are telling us based on their perceptions—is that MES/MOM solutions, despite the platform they’re based on, are seen as requiring a lot of customization. The standard functionalities provided by many platforms are considered constraints rather than pre-built, easy-to-use components.

Moreover, those platforms require a significant initial investment. And since they theoretically provide full MES/MOM capability, they have a pretty heavy footprint. Although they are sold in modules, there are some general components that need to be installed from the beginning, requiring a bigger hardware infrastructure, a more complex architecture and—last but not least—some overhead in implementing the first functionalities. This is less true if the MES/MOM project is a fully functional project from the beginning. But if the client wants to start by solving a single problem and then expand progressively with more functionalities, this is definitely true. The situation changes from platform to platform and cannot be completely generalized, but the same considerations can be applied to all the platforms.

The fast-development platforms, on the other hand, have by design a light footprint and enable implementation of one or two MES functionalities quickly, customizing the solution exactly to the customer’s needs. These first modules are built within a platform, guaranteeing that they can be expanded or connected to new modules easily and without the risk of losing compatibility as would happen with the use of specific solution-oriented products. These platforms enable progressive development of an MES/MOM system, fully tailored according to customer needs, reducing the overhead and risk typically related to a custom solution.

This is why they are becoming appealing to many clients and they are eroding some market share of the other approaches. I do not support one approach or another (well, I’m not a big fan of single-functionality products or MES implemented on an ERP system) but recognize that there’s value in both of them. Depending on the project and on the client’s goals, one or the other could be the best choice. For sure, the landscape has changed in the past 24 months and it has happened without many vendors being fully aware of what was happening.

Luigi De Bernardini is CEO at Autoware, a certified Control System Integrators Association (CSIA) member based in Vicenza, Italy; and president of Autoware Digital. For more information about Autoware, visit its profile on the Industrial Automation Exchange.

Sponsored Recommendations

Why Go Beyond Traditional HMI/SCADA

Traditional HMI/SCADAs are being reinvented with today's growing dependence on mobile technology. Discover how AVEVA is implementing this software into your everyday devices to...

4 Reasons to move to a subscription model for your HMI/SCADA

Software-as-a-service (SaaS) gives you the technical and financial ability to respond to the changing market and provides efficient control across your entire enterprise—not just...

Is your HMI stuck in the stone age?

What happens when you adopt modern HMI solutions? Learn more about the future of operations control with these six modern HMI must-haves to help you turbocharge operator efficiency...