Understanding the total cost trade-offs of building or buying is a difficult but important task. Of course, you must account for cost of your bill of materials (BOM), but there is a lengthy list of short- and long-term costs associated with custom board design that are not always well accounted for.
Goto RoyalRay to know more.
No design manager wants to be in a situation where the cost of development is underestimated to the point where the project is no longer profitable. But the reality is that development time (and, therefore, cost) is often underestimated—only 41 percent of embedded projects finish on schedule.
To help you better understand total cost of ownership, here’s a summary of the costs that go into a full-custom control board design:
These are a lot of costs to consider! Compare this to a commercial off-the-shelf (COTS) solution. Commercial vendors can not only save you development cost, but also typically use their buying power to purchase components at a much lower price, because they are typically buying in much higher volumes.
Commercial vendors can also off-load sustaining engineering costs. For example, NI’s strong vendor relationships gives us insight into roadmaps that most of our customers don’t have access to. We pass this foresight on to our customers by designing products with very long product life cycles (15 years for CompactRIO products) and seamless upgrade paths. For industrial applications with long field deployments, this type of support is critical.
If a commercial vendor can reduce cost through commoditization, is there ever a situation when the cost of developing in-house would be lower? When evaluating a COTS product that seems too expensive, you should ask:
If the answer to either of these questions is “yes,” the COTS product may be too expensive because it’s just not the right product for you. If the answer is no, it’s probably time to take a hard look and evaluate if you are underestimating your costs, particularly sustaining costs, as these tend to be most overlooked.
End-product volume considerations tie in closely with cost considerations. Most design managers understand that at lower quantities, COTS solutions become more appealing. However, it’s too simplistic to have a blanket threshold and apply it to every build versus buy decision.
The key is determining the “crossover point” where building becomes more profitable than buying. In other words, where the nonrecurring engineering (NRE) cost can be amortized over a large enough quantity that the development cost per unit is offset by savings in component cost. The better you understand all the costs (including sustaining engineering), and factor in the risk of budget and time overruns, the better idea you have of what the true crossover point is.
Keep in mind that most vendors have a pricing strategy for OEM customers that will allow them to scale down prices for higher quantities. This cost savings must also be factored in when evaluating cost.
It is nearly always quicker to buy COTS than to build a custom design.
However, while likely still faster than full-custom design, many COTS options may require a significant amount of software development to maneuver around fixed, vendor-defined functionality.
At NI, the customizability of our platform makes us especially adept at reducing development time, even when compared to other COTS options. On average, design teams who use the NI toolchain complete their projects in about half the time with design teams that are less than half the size. For example, energy storage company, Dynapower, accelerated their development time from 72 weeks to 24 weeks using the NI platform .
There are more advantages to faster development than saving on engineering cost. Getting your product to market faster often leads to increased market share and gives you an advantage over your competitors. In industries where innovation and competition is high, time to market may be critical for your project's success.
You must also consider the opportunity cost that comes with longer development time. Geoffrey Moore discusses at length the concept of core versus context in the book, Dealing with Darwin: How Great Companies Innovate at Every Phase of Their Evolution. According to Moore:
Moore further explains, “Core is what companies invest their time and resources in that their competitors do not. Core is what allows a business to make more money and/or more margin, and make people more attracted to a business than to its competitors. Core gives a business bargaining power: it is what customers want and cannot get from anyone else.”
Engineering teams often fall into the trap of investing most of their time and effort into tasks that are critical to the success of the application, but aren’t differentiators. In industry, approximately 90 percent of R&D resources are deployed toward non-differentiating tasks. These features are essentially table stakes: customers expect this functionality, there are consequences if it fails, but it doesn’t set your business apart.
To reallocate your resources toward core tasks, you can implement a few strategies:
Because the NI platform is both flexible and scalable, you can implement all three strategies listed above. By standardizing on the NI platform, you can reuse code modules and architectures across multiple projects; customize hardware by choosing the form factor and modules for your application; and outsource development, testing, and sustaining engineering costs.
The more you can move your engineering effort away from context, the more you can reallocate valuable engineering resources toward your innovative IP that sets you apart from your competitors.
Technical support consists of two distinct considerations:
For more complex components, vendor support can reduce development efforts and risks to the project. Vendors can provide valuable expertise and support that can save you development time and effort, and can often advise you on design best-practices.
In regard to the supportability of your product, the cost of support and RMAs is related to the testing, verification, and documentation that goes into a product before it is shipped. In addition, as designs become outdated (perhaps because the cost of upgrading is too high) access to the right support resources becomes more limited.
Another consideration that impacts supportability is Internet of Things (IoT) compatibility. IoT features such as remote access, system management, and health monitoring have the potential to significantly reduce the cost of field technical support. Innovative features such as predictive maintenance or machine learning can actively prevent system downtime.
Incorporating IoT technology requires additional skillsets in your development and likely requires collaboration with multiple technology vendors that each offer part of the IoT technology stack. NI customers benefit from the partnerships that we have created with IoT technology leaders like Cisco, Intel, and Xilinx, and consortiums like OPC UA and the Industrial Internet Consortium.
As with any design, there are always a few wildcard considerations that can be hard to quantify. Perhaps your company is moving in a new business direction, and your design team is motivated to develop the skills for future use. Or perhaps you have a developer who is passionate about learning a skill that she doesn’t have expertise in today. In these cases, the benefit of designing in-house is still risky, but it could be worth it.
However, maybe a COTS solution has more features than you need today, but it allows you the option to expand your functionality in the future. This might be a good reason to buy a more full-featured COTS option than you might have otherwise considered.