The genesis of many application software products is a great idea. Someone conceives a better, newer way to achieve a business outcome, complete a process, etc. That idea gets codified and becomes an application. In some cases, it becomes a process-wide collection of applications (e.g., how ‘Financials’ can contain several discrete applications like general ledger, accounts payable and accounts receivable).
Yet, the purveyors of these solutions will want more. They will want more customers, more applications and more revenue. To achieve these goals, the vendor will either create additional applications or buy them from other firms. In the former scenario, a smart vendor will make all these applications from one common architecture, use all of the same development and execution tools, have the same user interface, etc. These new applications will be extremely well integrated to each other and to the architecture that they share. A customer will assume these new applications were always part of the vendor’s original product suite.
In contrast, the acquisition path may present a faster way to achieve certain financial goals but could create longer-term issues. In the acquisition model, acquired applications are often lightly integrated to the vendor’s legacy applications. These products are stitched together. They often look like they originated from different vendors and with different underlying tools/architectures. Vendors may promise that future versions will eventually coalesce into a single unified solution but that may take many years to occur.
Like the Frankenstein monster of film, the stitched together product suite looks like something that could terrorize villagers everywhere. And, like the film monster, the stitched together product suite looks odd. Some acquired applications will be overkill. Some will be underwhelming. Some could possibly be rejected by the host body. But, with enough of your maintenance monies, a powerful electric jolt could bring this monster to life.
Yet, the ultimate manifestation of ERP’s Franken-soft occurs when a vendor continues to expand their solution via more, redundant application parts of cadaver software firm donors. These acquirers may possess several redundant applications of most everything in their product line. Need a CRM solution? They have three of them. Need a general ledger? Pick one of the six they have available.
These massive product suites may generate maintenance revenue for the vendors. They may even create some additional in-fill sales opportunities. But, they also dilute the research and development budgets of these vendors. Why? Vendors will need to sprinkle a bit of R&D spend on every acquired product line and application to appease these customers and have some sort of story that proves that their maintenance monies are going to enhancements.
What’s behind the creation of Franken-soft ERP firms? I suspect that some software firms may acquire adjacent solutions (e.g., a financial software firm acquiring an HR product line) to gain more customers, more maintenance revenue and more in-fill sales opportunities.
But, when software companies start acquiring redundant products or product lines, they’re just out for short-term revenue and sales gains. They’re putting short-term shareholder concerns over those of their long-term customers. They’re also throwing in the towel on innovation, too. They’d rather buy more customers than earn them.
When a vendor possesses so many redundant applications it could also slow down their progress to the cloud, their approach to adding analytic capabilities, their mobility solutions development, etc. Why? Each of these new technology directions (e.g., cloud, mobile, social, video, analytics, etc.) requires an existing application (and its attendant process design, data model, etc.) to be re-thought. If a vendor only has one of each application, the effort can be big. If a vendor has dozens of redundant applications, the effort grows arithmetically.
A vendor with a history of stitching together acquired or new technologies to existing products will see new tools like analytics, cloud, mobile, etc. as merely something else to append to the Franken-soft creation. That’s a mistake. Some things, like a new application, can be bolted to the existing suite and may, in fact, deliver value to customers. Other items require platform changes, data model changes and more.
At Workday’s recent user event in Las Vegas this week, analysts saw the following:
The Workday event was quite a positive event. Some of the announcements, like the analytic one above, were possibly lost on the mostly HR attendees in the crowd. But, for those who care about the structural stuff of software solutions, the difference between Workday’s offerings and those of the Brand X folks is startling.
Disclaimer - Workday provided airfare and hotel accommodations to their conference. No other consideration was offered.