Authored by John Mezger
For most modern enterprises, the closer your system is to your value proposition, the more likely it will require customization to deliver on the precise needs that your business serves. As proven in Part 2 of our Build vs. Buy series, there are core functions that cannot be delivered without being built by the company driving that unique value to the market. This is self-evident in certain practices. But what about industries in which “commercial off the shelf” (or COTS) platforms promise massive functionality and flexibility at a fraction of the perceived cost?
The pitched promise of accelerated adoptions, effortless install, and easy customization is often a siren call that these enterprises cannot ignore. This siren call springs from the fallacy, discussed in Part 1 of this series, that “software is the cost of doing business.” Extrapolated out to its full yet simplistic definition: If software is a cost of doing business, then it stands to reason that driving down the cost of software will result in a net positive for your bottom line. Less cost makes you more profitable. However, looking at software as a costly decision to be survived is an anachronistic point of view.
Enterprises are littered with the decaying hulks of this bad decision in the form of shelfware, undelivered projects, missed deadlines, and, ultimately, unrealized business value. The oasis of lower cost and easy integration is, in fact, a mirage that often leaves companies stranded with a solution that does not fit their needs, and with costs that end up similar to those of a custom software system. Meanwhile, the business is forced to adjust to the purchased system. This puts almost any company at odds with the modern business landscape, in which users and customers both derive value from their interactions with companies’ software platforms.
This chronic misunderstanding amongst enterprises of the perceived vs. actual costs of choosing custom or COTS can be corrected with a deeper understanding of how software generates value.
Realizing value: Perceived costs vs. Real costs
If you’re looking at software as a cost to be borne, then you might think that the easiest way to control cost is to buy from a vendor, as you would for a CRM or HR system. The integration costs, while steep and oftentimes ongoing, can be justified by the belief that the value of a custom solution would not outdo the initial investment.
But does this hold true for a system that brings the value proposition of your enterprise to life for end users and customers? One that realizes the very business value that investors and other stakeholders are obligated to deliver?
Let’s explore what some of these decisions look like in practice.
The price of sacrificing functionality
Say you’re a 100-year-old insurance company with a set of core beliefs that puts generating long term value for the company and customers at the core of every decision. It can often be difficult to determine cost and value when making software decisions, especially because software platforms historically have been considered a burden to be borne.
As such, when your decades-old, house-built mainframe system requires modernization, the perceived initial cost of a custom build can seem too much to bear. The burden is intensified by the lack of functionality and flexibility in the existing system that prevents your business from moving forward. Thus, buying a vendor-based system that handles industry-specific requirements can seem like the right course.
Let’s examine this from the logic you’d apply here: If the cost of solving existing or short-term problems with a COTS solution that delivers 70-80% functionality is 50% less than building a new solution with 100% functionality, the assumption is that you’re realizing a net gain upfront. However, from an actual business practice perspective, the cost and time to implement the missing 20% functionality is exponentially higher than incorporating that functionality into a new build. In the end, the final functionality will come at the compromise of your internal business practices, efficiencies, and, most importantly, the ability of the software to flex to evolving business requirements.
In this scenario, business output and interaction are coerced to meet the needs of the software: When business and product decisions are held hostage by the platform needed to bring them to market, there is a very real cost associated. More importantly, this erodes the business value that any modern enterprise must deliver in the form of self-service-driven customer support, seamless interactions, and new products—all designed to accelerate business best practices and deliver on customer or user needs.
What’s best for the business’s future?
Making the distinction between perceived costs and real costs requires attacking problems from the aspect of what is best for the business, beyond the constraints of software. For example, if you’re a contract manufacturer, does it make the most business sense to utilize one set of Manufacturing Execution Screens (MES) screens across all production lines, especially when the key KPI for your business is efficiency? On the surface, maybe yes. It may be that the cost of building custom screens for every line is much higher than an off-the-shelf product that can be utilized across the board. However, the cost to integrate this product and customize—due to the variance of functions and screens required—can become too great. On the ledger sheet, the cost is much less on day 1, but from day 2 on, you might find that the requirements of the business cannot be adequately handled by an off-the-shelf product in production. The volume, quality, and efficiency that end users/customers demand will not be delivered if constrained by a system that cannot hope to understand the individual complexities of each production process.
Closing the Circle: Day 1 Perceptions vs. Day 2 Realities
If decisions are based on day 1 costs, what are the cost and value implications for day 2 and beyond? Many times, enterprises fail to account for the real, long term costs of integrating and attempting to customize off-the-shelf products. The cost associated with this type of implementation is often close to, if not more than, building a custom system. Compounding this cost is the very real constraint on the business. More often than not, the business must adjust to the software, rather than the software adjusting to the business needs—as it should be. (This is something Headspring’s Chief Architect touches on in his recent conference talk on monoliths and microservices).
Off-the-shelf products are chosen based on native features that more than likely address around 70-80% of business needs on Day 1; however, starting on day 1 and beyond, there is an important decision that needs to be made. That is, if the business discovers a new revenue stream or wants to release a product that requires new functionality, the enterprise must A) ask for new features to be delivered by the vendor or B) create an integration/workaround between the off-the-shelf solution and net new functionality. The insurance company in our earlier example found that the off-the-shelf product they chose had an approximate 30% functionality gap that prevented them from creating meaningful new features and products necessary to keep up with the needs of their customers. The outcome of a situation like this is that value streams are blocked and progress is stymied, sometimes indefinitely. What initially, on paper, looked to be a significant cost saving proved to be a much more expensive proposition. This decision also has the unintended consequence of undermining business value in terms of the ability to produce net new products in a rapidly changing industry and customer space.
The build vs. buy decision is a very nuanced one in that initial cost must be balanced with long term value. The length of time it takes to recoup your investment in software used to be measured in near-decades—now it’s measured in mere months. The moral of the story is this: Stop throwing good money after bad investment and build a system that drives continuous value. A COTS system with a tiered cost that trends upwards while its value trends downward could sink your ship. The modern enterprise must come to terms with the idea that software is how they will drive business value far into the future, rather than the cost of doing business right now.