New Software Roles Drive
Confusion and Contention
Remember the joke about “What if Microsoft designed a bicycle?” In a similar spirit, ask yourself “What if machine, equipment and hardware OEMs designed a software business? Or worse, a new software business model?”
SOFTWARE AND HARDWARE ARE TWO DIFFERENT ANIMALS
On its face it might not seem so outlandish that a hardware OEM, realizing much of its market is being overtaken by software, would decide to go into the software business itself. In fact, this has already happened many times.
And in many cases it has produced disastrous results.
That’s because the economics, design and development protocols, financial treatment, and scorekeeping of software creation are all diametrically opposed to those of hardware manufacturing. For physical equipment and machines, the product is paid for once and has to work from the moment it’s installed in the customer’s operating environment. Both the manufacturer and the customer know what to expect from the product and its performance—from its dimensions and weight to its reliability/MTBF, throughput, servicing, and so on.
In software, on the other hand, users and customers pay on a monthly or similar basis for a continuing stream of new features, upgrades, patches and improvements, but with less predictable product performance parameters such as easier workflows, app integrations, self-configuration, automatic updates, faster onboarding, etcetera.
For manufactured equipment and systems, the product’s margin is the primary measure of its profitability. But in software, product margins make no sense as a performance measure, and applying traditional hardware cost-reduction lessons to software is incoherent. Hardware pricing starts with cost-of-goods and manufacturing costs, and then OEMs add their target margin and adjust for competition or market conditions. Software costs, when compared to equipment and machines, are far more intangible and far more about finding and keeping the best developers rather than finding the cheapest components.
In equipment manufacturing, the design and engineering/development cycle is, of necessity, distinct and separate from the manufacturing cycle. In software, design and development are completely integrated. OEM leadership is quite accustomed to driving out costs and improving the performance of their machines and equipment. That is completely orthogonal to the software business.
OEMs tend to give software away as an incentive to the customer to buy their machine or to protect their pricing of the equipment, and they treat incremental software value as hardware value in their accounting systems which turns the software business into a cost center. This in turn makes it even harder to justify hiring more software resources because the ROI does not work.
In the software business, software is distinctly charged for and it is assigned a real value in the accounting system so it can be treated fairly when it comes to investments. Giving software away for free devalues it for the OEM as well as for the customer and forces most OEMs to view software as an expense, not as a distinct strategic value.
For more perspective on software-focused growth ventures, read Harbor Research’s “The Software Paradox.”
A CLASH OF CULTURES
Everyone we talk to in the OEM space tells us the same thing: Software is very challenging. Hardware players have never been good software business people. They’ve never understood software culture, never learned not to confuse software with their own core equipment business and value propositions. And they have continued to think that they can do anything to anyone, and everyone will have to keep playing by their rules.
But that story is over. Substantial value has already shifted from the physical system to software, and the question on everyone’s mind is, “Who is going to be the Google or SAP of the future OEM software business?”
Software product realization is not like hardware product realization. Jet engines have to work the instant they’re released, and they have to keep working over a long life of service. Software is never finished, never “done.” Thus, it’s almost understandable that OEMs act like they’ve never heard of the software developer community. But that has to change. Ecosystems now need to include developers, systems integrators, professional services and independent software contractors and the like. Manufacturers need to get onto developer exchanges where someone posts something and someone else sees that it can be used to solve a problem.
The scale, scope, and sophistication of Smart Systems and IoT software opportunity for both OEMs and new software startups has not progressed very fast or evolved very far. Smart Systems, the IoT, and software have added considerable complexities to the worlds of OEMs and new software startups alike.
While many will point to a specific OEM’s software strategy, lack of marketing investment, or potential technical missteps as the cause of such failures, Harbor believes that many of them can be traced to a broader confusion about roles. Sometimes companies need to ask themselves, “Who are we, and what part should software play in our business and for our customers in the market?” Spectacular failures can occur when players either fail to ask the question or answer it wrong.
Think of the classic OEMs that build machines, equipment, and devices like MRI scanners, power plant turbines, offshore drilling rigs, mechanical power transmission systems, precision bearings, and low-voltage power devices. They work with a unique blend of complex engineering skills, manufacturing expertise, long established channel partners, and strict financial controls. The traditional core operating models of these companies make adding software to their portfolio mix very challenging.
And yet today, OEMs are developing, embedding, or integrating software to monitor, operate, diagnose, and analyze the performance of their machines and equipment. Many of them have entered the software business outright, while others have created new fangled software ventures. To the casual observer, it would appear that many OEMs made these decisions without understanding or consciously thinking through what role software might or should play in their businesses.
The results have been, to say the least, uneven.
Traditional management practices in OEMs tend to assume that, whatever the OEM’s particular focus, their business and their peer OEMs share similar characteristics, organization structures, product development protocols, and sales and marketing practices. Management attention in OEM businesses has traditionally focused on the known, the visible, the predictable, and the quantifiable. Anything too difficult to measure is often treated as if it were unreal.
Even more misleading is the assumption that by adding software to the mix, “business as usual” will prevail over a given planning period. Such assumptions leave little room for dynamic management (or creation) of change, the early identification of technology discontinuities, or the increased presence of unfamiliar competitors.
OEMs have developed long planning horizons with a built-in bias that reflects their established operating models. The significant differences in the strategies, business characteristics, and operating models of these two worlds—hardware manufacturing and software development—cannot be overstated. Simply put, software lives in another world.
“Software Role Reversal” is supported by our overview of the Smart Systems and IoT Software Opportunity.
Fill out the form below to download the overview for free.