CEO Berk Birand on how AI is making factories greener:
Watch the interview

Should You Build an In-House Industrial Machine Learning Solution?

• February 2023
Randy fath ymf4 9 Y9 S A unsplash

Many are enticed by the prospect of owning their machine learning solutions, rather than relying on external vendors. At Fero Labs, we frequently get asked: “Can’t I just build this myself?”

Yes, in theory, an in-house solution can give you a competitive advantage, creating a highly individualized solution that turns all your organization’s proprietary know-how into actionable improvements. However, the costs of developing an in-house machine learning solution can be considerable. You’ll need to build hundreds of ML models, which means hiring product owners, data scientists, developers, and dev ops personnel. And once the solution is built, the models must be updated constantly based on production values in order to yield any value.

Value is critical. Consider machine learning a digital asset, just like the machines in a factory. To provide ROI, the value must be greater than the cost. Two out of three manufacturers report failing to realize ROI on their ML investments, suggesting that they’re failing to take into account the total cost of ownership—which ranges far beyond initial coding investments to knowledge transfer in case of personnel fluctuations as well as software and hardware life cycle management, such as dealing with tickets and change requests.

We advise manufacturers considering in-house solutions to think about the cost not only in terms of money but also time. It takes a long time to develop and code an internal solution. Furthermore, the difficulty of communication between engineers and data scientists can stretch out already-lengthy product cycles. As the table below illustrates, these can quickly add up.


Internal vs external ML solutions


We worked with a major international chemicals company that was trying to analyze a particular chemical process and predict when the catalyst would need to be cleaned or replaced based on operating condition trends. They’d developed their own models internally, which required a lot of code to maintain and had been built by a global team working for over a month to develop a standalone solution for the plant. Using Fero software, a single engineer reproduced the ML models and user interface in 1.5 hours—no code required.

As this makes clear, saving time is a key benefit of choosing an external machine learning solution. The vendor manages everything except hardware, so you don’t have to deal with huge personnel costs or internal processes—just install software. Assuming the software has a way of encoding the specific process information relevant to the use case, this will also minimize pesky back-and-forth between engineers and data scientists, shortening project cycles significantly. And last but not least, there’s far more cost flexibility. If the solution no longer fits or doesn’t prove any value, you can easily uninstall it and pursue a different direction, enabling you to locate the best digital solution for your company.

However, there are always risks to relying on an external vendor. The software may not be individually fitted to your needs, like a custom-built solution. And if you choose the wrong solution, you won’t get any value from your investment. It’s important to take careful note of any prospective solution’s technology and feature set and make sure they apply to your use case.

If the reason you’re partial to building your own tool is that you already have data scientists and want to take advantage of their expertise, you can also consider taking both routes. Start with a software solution as a prototyping tool that lets you move quickly and see if the value is there, then have your internal data scientists conduct more in-depth analyses. With software eliminating the time it takes to build models and clean data, your internal data scientists can get to work on the tasks that are most closely aligned with what they were hired to do—solve the most complex problems.