“Having a clear perspective on where we expect to get value out of [the software] is good, and sometimes you get value out of places where you didn't expect, and that's great, too. But having that framework in place is part of making it overall successful.” - Samuel Weiss, CTO of Instrumental Inc.
Since the beginning, Instrumental has been helping our customers break new ground in their organizations. While the engineering and operations leaders we work with are experts at purchasing parts, fixtures, and services, Instrumental may be their first software purchase as most engineering software is purchased by IT or an MCAD organization.
On top of that, it may also be the organization’s first-ever cloud software purchase.
Those distinctions come with a learning curve. I sat down with our CTO, Sam Weiss, to discuss what key friction points leaders can avoid when purchasing software.
Mindset shift: From Capital Expenditure (CapEx) to Operating Expense (OpEx)
We find our customers often approach the software buying process as if they were buying a piece of hardware, and as a result, they set themselves up for difficulties. Software is not only a very different type of product but comes with different payment and contract models.
Where equipment is a capital expenditure, software will usually best serve you as an operating expense. You can buy some software as a one-and-done (though it’s becoming increasingly rare). I find that model appeals to purchasers not only because of concerns about intellectual property for the data the software processes but because once you recoup that initial investment, you get 100% ROI. In reality, though, less and less software is available to purchase this way. For one, modern software is often more than a singular program that you can own – it often is integrated into multiple systems, runs out of a web browser, and may provide storage or ongoing processing services. More importantly, the public markets reward dollars from recurring revenue significantly more than one-and-done purchases – which has driven most software to recurring models. The more cutting-edge the software is, the more likely it will leverage a usage-based or software-as-a-service (SaaS) model. These models cannot (and should not) be purchased as a CapEx.
The problem with OpEx purchases is that depending on how your finance team classifies them, they might add directly to a BOM or per unit cost – which is often a lightning rod cell in the spreadsheet to hit. Whenever possible, it’s best to classify these expenses as infrastructure – the same places your CAD and Microsoft 360 licenses end up. One major benefit of software subscriptions as an OpEx purchase is that the upfront cost is lower. Rather than having to amortize a hefty one-time investment with a long payback period, the time it takes to realize a return on the investment can be super fast – maybe even within weeks or months. As an ongoing OpEx, you have the flexibility to turn service up, down, or off, as well as access to ongoing updates, maintenance, and support from the vendor.
If you haven’t purchased software before, it may make sense to discuss with procurement how the purchase will be classified. It’s possible this classification is negotiable, which can impact the budget available.
Always Make a Business Case for ROI
As for any technology purchase – hardware or software – unless you are the budgetary decision maker, it’s important to build a business case. Typically presenting a net new expense to leadership that is unsupported by a business case will not lead to investment. There are two key aspects to keep in mind when determining the ROI of software technology: the value the technology will generate and how to estimate its actual cost.
“Having a clear perspective on where you expect to get value out of [the software] is good,” says Sam, “and sometimes you get value out of places where you didn't expect, and that's great, too. But having that framework in place is part of making it overall successful.”
When estimating value, some aspects are tangible – the specific metrics that will be moved by the purchase. For example, Instrumental provides quality control. Our technology will catch defects, minimize loss from parts that need to be reworked, and safeguard brand value by avoiding customer returns and contract loss.
Some ROI aspects will be less tangible – such as how it changes your process. In Instrumental’s case, we are often able to account for significant engineering efficiency gains and NPI acceleration when we work with customers on new product development. The product changes how our customer-users work day-to-day, amplifying their efforts over a larger number of issues and challenges.
One thing we’ve learned from nearly a decade of selling technology in our industry is that the visionaries who make business cases as part of considering a technology investment are much more likely to get the investment approved, but also more likely to deliver realized value back to the business. This is so critical that we work directly with our visionary champions to build a value study, helping them determine the many different elements of pockets where Instrumental generates ROI and put together the most compelling case to take back to their buying teams. You can read more about our approach and start an analysis yourself here.
As Sam puts it, “I would think about how the business model scales and whether that aligns with how my value scales.”
Set Realistic Expectations for Software Integration and Implementation
When comparing vendors, purchasers may have to weigh the trade-offs between a larger, more established tool or a smaller, up-and-coming offering. The former may offer more robustness but the latter is likely innovating more quickly and is more invested in making sure iterations scale in value.
Vendors may also offer varying levels of support for integration and implementation – the cost of which is a big piece of the total cost of ownership, the denominator in the ROI calculation. Does the technology work off the shelf or does it require an integration effort? If the latter, who handles that – the purchaser, the vendor, or a third party?
One of the biggest challenges Instrumental has seen companies struggle with is deciding to take on too much of the integration effort themselves when they lack the resources or expertise to staff it appropriately. This creates friction to technology adoption and delays the time to value being delivered. Our experience is that the accelerated value that comes from prioritizing tie-to-value more than pays for the extra integration costs – and enables your team to remain focused on their business objectives.
The Upside of SaaS Models for Hardware Manufacturers
We touched on it above, but SaaS is often treated as the unfortunate alternative to outright software purchases. However, at Instrumental, we’ve found that offering software as a service has some distinct advantages.
Without a hefty upfront investment, SaaS offers a lower financial barrier to entry, and if it doesn’t realize the gains that you had expected, you’re not sitting on the sunk cost of a system you can’t use. Additionally, you can often use the same hardware you used with your initial software purchase with other SaaS products. For example, Instrumental is able to process images from any camera. So if a customer’s experience with Keyence or Cognex didn’t fit their expectations, or they had to pivot away from their own custom solution, they could implement Instrumental with minimal downtime and no new hardware investments required.
Perhaps most importantly, SaaS solutions have to stay competitive. Software that can be purchased outright may lose support after a certain date, and developers might not be incentivized to patch issues that only affect small numbers of users. SaaS products, however, perpetually need to demonstrate why they’re the best solution on the market. They’re incentivized to iterate and refine—precisely because customers can easily switch to a competitor or cancel outright. As a subscriber, that means you benefit from the most bleeding-edge innovations and updates.
Final Thoughts
Purchasing software, especially for the first time, presents unique challenges for engineering and operations leaders accustomed to hardware acquisitions. The transition from CapEx to OpEx requires a fundamental shift in mindset, and it’s important to connect with your finance team to find out how they’ll classify it. There’s no reason to fight an uphill battle with stakeholders if it can be avoided by a quick discussion with accounting.
With so many solutions available on the market, it can be difficult to decide which one is best for your needs (we’re obviously a little partial). No matter which one you select, you’ll have to demonstrate the business case for your purchase. But by measuring the effect it has on quality and making an effective ROI case, you can make a compelling argument to leaders still on the fence about the benefit of new software.