Manufacturing Platforms: Build or Buy?

When it comes to manufacturing platforms, buying decisions are complicated.

You might think that this is because there are so many vendors offering such a wide variety of solutions–and you’d be right.

But buying decisions aren’t just complicated by a crowded playing field. For many manufacturers, the decision isn’t which vendor to put their faith in. Instead, it’s whether or not they should build a solution in-house.

In short, buying decisions often boil down to an age-old question: build or buy?

Here are the seven questions you should ask:

1. How expensive is it to build in-house?
2. Are you accounting for ongoing costs?
3. Will it scale?
4. How will you manage complexity?
5. Does IT understand your manufacturing operations?
6. Will it be simple enough to use?
7. How flexible will it be?

Without further ado, let’s drill down into each question.

1. How expensive is it to build in-house?

If your organization has a team of software developers, building in-house might be the logical solution.

Working with an in-house team can allow for greater precision in project scoping, greater control over execution, and it can ease many of the project management difficulties that come with purchasing from a vendor.

However, that doesn’t mean it will be the most cost-effective. It also might not be the fastest.

Getting a sense of the costs just takes some simple math.

Depending on which source you consult, the average software project takes roughly 10 months to complete. Smaller projects may clock in around four months, while bigger projects can easily extend over the year mark.

If an average developer makes between $60-100 an hour, that brings the cost of a software project to roughly $107,400 – $179,000 for a year-long project. For one developer.

Further, you might want to factor in the opportunity cost of the time your software engineers spend on a project. What projects are you putting on hold while your engineers build shop floor applications?

2. Did your calculation include ongoing costs?

In our experience, software costs don’t stop with the initial delivery. (I’ll tell a story about one manufacturer’s experience incurring ongoing support costs below, so stay tuned).

Often, house-built manufacturing applications need to be modified and updated to account for changes in manufacturing processes.

If the solution is built in-house, that means every modification requires ticket submission, fulfillment, and redeployment. If it takes two weeks (assuming changes take a sprint) to push a change, that’s two weeks of software engineering time to bill, as well as lost revenue from delayed process improvements.

3. Will it scale?

The big benefit of an in-house, custom-built solution is that it can account for the unique needs of a production line, cell, or process.

But will your custom solution work for multiple lines? Will it work for every line in a plant? Can it be rolled out across a whole region or internationally?

One concern with custom-built solutions is that they won’t scale. Transferring the solution to a new context can incur similar project costs and timelines as the initial solution.

4. How will you manage complexity?

As home-grown systems expand, there’s a tradeoff between scope and complexity.

As systems encompass a wider range of processes and operations, they become more complex.

While this isn’t a natural law, it’s been fact in manufacturing for decades.

So as your in-house solution grows in scope, will it also grow in complexity?

5. Will IT build the most efficient manufacturing processes?

When polled by consultants, engineers outline a recurring message: “IT doesn’t understand OT problems!”

This often calls for a Manufacturing IT Group to be formed internally – which itself can be costly.

Only manufacturing operations (engineers) know what types of solutions they truly need on their shop floor.

IT typically acts as a service provider to the manufacturing operations group. With any service agreement, success depends on solid working relationships and clear communication.

Yet when the IT group is in charge of developing the solution on behalf of the OT group, the requirements are often misinterpreted or missed altogether.

This can create unnecessary tension between IT and OT. And tension can lead to suboptimal project results.

6. Will the workers who need it be able to use it?

Many user interfaces (UIs) on the shop floor look and feel like they were designed for Windows 95/98 era.

As a result, operators, supervisors, and new process engineers often struggle with data input and must be trained extensively to use these systems.

In 2020, we’re accustomed to highly optimized user experiences.

Whether we realize it or not, consumer interfaces are designed to facilitate our goals and intentions.

At work, we should be able to interact with solutions that enable experiences as seamless as those found on smartphones.

7. How flexible will your in-house solution be?

Manufacturing processes change. Perhaps only subtly. But as product lines, customer demand, and technologies change, so do manufacturing processes.

Will your in-house solution be able to adapt?

How long will it take your developers to push the changes? Will managing small variations in product create massive headaches?

This last question about flexibility brings me to a story that I think nicely summarizes the points in this post.

I recently had the opportunity to hear an executive at a large, multinational manufacturer describe the thought process behind his decision to work with Tulip rather than build a solution internally.

Here it is:

The executive started by describing his organization's commitment to lean principles. All of his plants pursued continuous improvement aggressively.

This meant that work cell layout and process design were highly flexible.

Every time an engineer suggested a new work cell configuration or the company updated their product lines, IT would need to make subtle but time-consuming software updates. This meant hardcoding every change in C++.

This state of affairs quickly became untenable. Front line workers were unhappy that small process improvements required a time-consuming back-and-forth with IT. IT grew frustrated that small shop floor changes resulted in grueling hours for their software developers.

Ultimately, the manufacturing executive decided that it was easier to work with a manufacturing platform vendor than to build a solution in-house.

When engineers need to make a small change to an application, now doing so is as simple as making a change in a Powerpoint–no IT support required.

The number one benefit of building a solution in-house is that it can be custom-developed to meet a specific need.

Taking on a software project in-house can give a manufacturing organization greater control over the final product. Working in-house can eliminate many project management difficulties

And yet these potential benefits are also the source of custom software’s greatest drawbacks: ballooning costs, bloating requirements, and lack of configurability.

Ultimately, what works for you is a matter of project requirements, budget, and resources.