Build vs Buy Software Decision: Three Critical Strategy Questions

Manufacturers have recognized over the last several decades that software is as critical to a product and its users’ experiences as the hardware itself. Consider the software associated with automobiles; one major manufacturer has new system features added with over-the-air updates, and they may be not just software, but impact the functioning of the hardware, too. Consumer electronics such as smartphones have regular system updates, but at least one manufacturer has proven that storing and selling the data that enrich the user experience is as valuable, if not more so, as the revenue associated with selling the device, itself. Just look to the offers that are often made on discounting the device, so that a vendor’s services are used. Aircraft, building systems, office equipment, heavy equipment for construction and agriculture, utility systems and other manufactured products are more and more reliant on software for operation, service, and customer satisfaction.

This leads many companies that have been highly successful with developing and integrating software into their products to consider branching out into development of enterprise software. They are technically oriented, have successfully and reliably deployed software, so what should prevent them from applying those skills to systems for operating the plant, or even the business, as a whole?

This blog will lay out a series of questions to help you decide whether to Build or Buy Software. The goal isn’t to push for a specific answer but to provide a structured framework for analysis that will be helpful in making the best decision for your company.

Within the analytic framework, there are multiple kinds of software to consider:

• Product software: the software and firmware that operate the product and provide functionality.
• Connectivity software: if the product is smart and connected, this software provides the ability to connect to a network, deliver data of various kinds and provide and deliver varying levels of data analysis and presentation—whether the product is deployed to the field or a manufacturing floor.
• Automation software: software that operates and sequences machinery in a plant for manufacturing or delivery of plant services. For purposes of this discussion, this category includes plant level supervisory control and data acquisition (SCADA) software.
• Manufacturing execution system software: software that coordinates plant operations, provides visibility into performance, can offer track/trace, materials dispatch and use, and other operational functionality.
• Enterprise resource planning (ERP) software: Enterprise financial and transactional software for managing cost, tracking value added, and measuring financial performance.

This blog will talk about the decision-making process in general, but with a focus on MES systems, as this is Critical Manufacturing’s area of expertise. We kick off the series with Three Critical Strategy Questions.

Question #1: Am I a Software company or a products company (or what do I do for a living)?

Let’s assume that as a manufacturer, your revenue and profits are tied to your ability to design, build, sell and service products for which your customers pay, and this could be accomplished in a variety of ways: sale of product, product as a service, services, etc., all of which are the result of delivering value in excess of the purchase cost.

#1a: Where is my critical intellectual property?

In this case, the software that is associated with the product can be considered as part of the product, an essential element to delivering that customer value. It is possible that significant portions of your intellectual property are associated with this type of software; it provides unique user experiences, differentiated performance or business models (such as product-as-a-service), easily delivers upgrades or even promises of uptime or service levels. It is appropriate to protect this differentiation at whatever level makes business sense, just as it would be to protect a proprietary material or thermal management capability by controlling it as a trade secret or by pursuing patents.

Is the IP associated with the other software critical? Connectivity, likely not. Automation? Well, maybe. The automation routine might be critical, but is the SCADA or programmable logic controller (PLC) platform on which the automation runs? Or are the functionalities of the MES or ERP systems? Configurations might be proprietary, but the system functionalities are likely not.

#1b: How do our investors value us?

Are you being compared to companies who make products like yours, or are you competing for capital dollars with companies in the software business? This is important, because if you want to be a software company, your balance sheet might currently have too much investment in things like property, plant, and equipment, or inventory. It’s not that one type of company is better or worse than the other, but they are fundamentally different, and associated capital structures will impact your financial ratios and potentially, your cost of capital.

#1c: Am I prepared to operate software development differently than manufacturing?

Many products companies have adopted more modern software development practices for their embedded product related software: Agile, DevOps, etc. Management within these practices may be fundamentally different than traditional, linear manufacturing methodologies and practices that are currently in place. Consequently, there may be conflict with your current management systems and philosophies. The team that you put in place to develop software will likely be versed in software management practices. A mismatch here will result in higher personnel turnover rates that impact delivery times, cost, and system stability.

Question #2: Am I prepared to invest in software company infrastructure?

From above, companies that have employed modern software development practices may already have answered this. If not, enterprise software development requires infrastructure (which we will explore further in another installment of Build or Buy Software). For now, consider that the investment goes beyond the unique people needed to perform this task, and there are many other skills required other than writing code (which is, of course, critical). Functional analysts, architects, test/QA, deployment, change management and other specialists are all needed, and not at the same time, nor for the same lengths of time.

Software development will also need development tools, DevOps infrastructure, test beds, and licenses to other software used as components of the final system. It is unlikely that the development team will create every dashboard, database, or other functional elements from scratch; these may be more efficiently and effectively acquired from third parties and will carry their own ongoing costs and maintenance requirements.

Question #3: What is the relative ROI of build or buy?

Many companies start this process because of the initial costs of buying and implementing a system. Consequently, they look at their in-house capabilities and consider the advantages of building a custom solution that will absolutely fit their needs, leading to project cost and return on investment analyses.

These analyses must account for a software system being (or should be) a long-lived asset. If designed well, it should take into account the necessary functionality needed for today’s and tomorrow’s users. It is important to remember that that like any long-lived asset, enterprise software systems require maintenance—from adding new, needed functionality, to managing end-of-life issues with underlying components, among other ongoing costs. And keeping the right people involved and engaged is critical to solving issues or improving performance—no matter how well the original documentation was executed. Think about troubleshooting the best documented automation routine if the original author isn’t available. Limited empirical research shows that, in total, annual custom system maintenance will equal about half of the original development cost.

The resulting ROI must be calculated on the total cost of ownership over the system lifetime: design, build, administer, deploy and maintain. Please also consider that if you build in-house, it will be extremely difficult to get an implementation partner up to speed. You built it, and it’s proprietary. How will you train partners to help? So, it’s reasonable to consider the requirement of keeping support heads on board and planning for their overall utilization.

If you have the open, honest, and necessary conversation about the strategic importance developing your own enterprise software and its impact on your overall company, and then decide to go further in the analysis, it is now time to consider the product you need to build. The next blog will go into additional questions around the product itself–design and execution.