Having been part of the manufacturing software industry for over three decades, I have seen a lot of messaging and value propositions shared by the vendor community. Examples include “Factory of the Future”, “Smart Manufacturing,” and “Industry 4.0,” just to name a few. As part of this narrative, there seems to be a growing reference to “Toolkits,” especially from the Product Lifecycle Management (PLM) and other “big box” vendors as a way to create Manufacturing Execution System (MES) functionality. I know. I used to work for one of these companies! I would urge you to seriously think through what purchasing a “toolkit” really means – it might not be your best option.
These companies offer ways to create everything from a Manufacturing Bill of Materials to Routings and allocating components to operations. After all, the PLM vendors already have the key object also known as the 3D model, essentially the product definition. Why not attempt to add to that a functional process definition? It turns out, this is harder than it seems. Especially for industries dealing with highly complex, model-driven manufacturing processes such as Aerospace and Defense, Medical Device, Nuclear, Ship Building, or Electronics.
So, just what is a Toolkit? It is a set of libraries and tools that give you what you need to develop an application. A starting point, if you will, that in the end will typically turn into a custom development project for the vendor. These projects start with good intentions. But, when the customer tries to leverage the toolkit and imagines all the different ways that new features and functionalities can be added, they then find out that the toolkit does not meet their needs.
For instance, a vendor may offer a “Routing” toolkit. This toolkit allows clients to create an operation, assign an operation number, and enter a title for the operation. The challenge is that the toolkit might not have a field to add the Work Center that will perform the operation on the shop floor. So, the customer must then define a new Work Center field. And so, it continues. With so many options and choices, the vendor will continue to add new fields to the toolkit. Each of these actions veers the customer’s solution off of the standard product roadmap.
The more custom functionality that gets added, the more technical debt accumulates. Technical debt (also known as design debt or code debt) is a concept in the software development arena that reflects the additional efforts required to develop or customize a toolkit into a software solution.
The exact opposite of a tool kit is an Out-of-the-Box (OOTB) MES solution. Manufacturing Execution Systems have historically seen both approaches, so I thought this would be a good solution category to explore the differences in greater detail.
To start, just looking at the names of these solution categories, the difference is obvious. An “Out of the Box” MES solution refers to one that works immediately after installation without any customization. A toolkit is used to build a solution, which can then be installed and used. This is a much longer time and resource commitment. Alternatively, when an OOTB solution is purchased, it can be installed right away, and with a little training, customers are off and running much faster.
The final term that is part of this discussion is “Solution.” For this article, let us assume a solution is an aggregation of technologies, products, and services that brings it all together. Solutions are bought to solve problems. Note that these types of problems do not typically happen just one time. They are systemic, so they must continue to be “fixed” over time. In other words, a solution must be managed and maintained over time to continue to solve the problem and reap the benefits.
As simple as this sounds, in the world of manufacturing design, execution, and distribution, manufacturers are faced with multiple, complex solution offerings. Each one often features different selling points and value propositions. This makes it very difficult to make the right choice to solve your specific problem.
I thought this table might be a great way to help you better understand each of these options:
Which is Best?
Given the complexity of manufacturing operations, different solutions will work better depending upon your needs. If your operations processes are so custom and unique, you may be forced to adopt a toolkit. The investment of the extra cost and labor to support such a system may be a necessary cost of doing business for you. For everyone else, however, an OOTB solution offers a compelling option that can get your problem solved much faster and offer a far lower Total Cost of Ownership than any toolkit can promise.
Remember, as an Out-of-the-Box MES, this functionality has evolved over time based on customer input. With each deployment, new knowledge is gained that can be used for continuous process improvement. A custom, one-off development, however, typically starts fresh with each new instance. Do you really want to recreate the wheel every time? A better approach is to operate within a framework of a proven solution while having the flexibility to apply incremental innovation if needed. In other words, “think out of the box to stay in the box”.
In conclusion, what is most important is that you are aware of the difference in both. Go into your vendor selection process with eyes wide open. Do not think that a vendor trying to sell you a toolkit can give you a “quick and easy” solution – by definition, it simply is not possible. Alternatively, if time is important, resources are constrained, and you are tired of paying an annual technical debt payment to all the previous vendors you have worked with, perhaps an OOTB solution might be worth considering.
Darrell Sabourin has 35+ years of complex discrete manufacturing experience within the Aerospace and Defense (A&D) industry. As a Client Partner at iBASEt, he advises clients how to best implement Manufacturing Execution Systems. Prior to iBASEt, Darrell worked for 18 years as a code developer, system architect, software designer, trainer, and business consultant for SAP. This experience, coupled with the 17 years he was a Manufacturing Engineer at Kaman Aerospace, provides him with a balanced perspective of how best to select and implement MES solutions.