The tendency in recent years to prefer packages — preferably universal packages — has meant that more and more portfolios have, at their core, a set of “Swiss Army Knives” that are capable of handling most of the technical function required in the company.
I certainly take little exception to the notion of maximizing the return on a major investment such as an ERP package by expanding it out to its limits in CRM, SFA, industry-specific capabilities and custom-built modules for “company-specific” needs. (I do take great exception to what I often find, which is that there are one or more other packages with overlapping functionality also in use, often splitting processes across them, as a legacy of prior mergers or divisions allowed, for a period of time, to select their own technology.)
I am seriously questioning, however, whether this is the model organizations should follow.
There are two reasons for raising this concern.
First, I note the decline in competitiveness (defined in terms of rising SG&A expenditures consuming net profit margins) that has followed in organization after organization following these transitions.
Not only do they lack necessary differentiation capabilities, they also tie up far too many processes and service options into a framework — that of the package — which, by its nature as a “generic solution”, cannot possibly be optimal. Extreme attention to process design, and the setting of options, paradoxically, has not helped: these organizations begin to deviate (in the way they work) from the package as implemented far sooner than those who accept the compromises involved in taking a “generic” implementation.
Organizations which have a selection of applications show less degradation, despite their general lack of a single data model or other desired characteristics that come from a “master package” solution.
Second, I note these organizations become slower to respond to changing circumstances.
With so much of the company’s technology base tied up in a single upgrade decision and project, getting any changes accomplished becomes a major event. This leads to increased erosion of the “single package” through business area implementations — including software as a service — and the resulting retro-fit once the value of “jumping the queue” has been obtained and these acquisitions are turned over to IT to integrate and operate.
Meanwhile, waiting in the wings, is the need to move to take advantage of some of the Enterprise 2.0 characteristics of cross-enterprise collaboration as the competitiveness bar gets raised again.
What does this mean? Vendors will continue to expand the scope of their packages, overlapping function more extensively for organizations that at one time followed a best-of-breed selection philosophy.
Meanwhile, Enterprise 2.0 information sharing will become more of a challenge.
Finally, differentiation will increase in value — quickly, and dramatically — and require a far more responsive delivery cycle.
It is time to begin weaning the organization from the “one big package” model.
This will be a decade-long transition, so there is no reason to hold off a planned upgrade today (far too many organizations have done this for years and now face withdrawal-of-support issues). But rethinking the portfolio, and how the pieces of it should best be delivered, is an urgent task, as is acquiring the necessary replacements. Throughout, the goal should be on flexibility, increased change speed, and decoupling of the parts to allow each to change on its own schedule.
As anyone who has ever tried to eat a meal using a “Swiss Army Knife”, you simply can’t hold the meat and cut it when all the utensils are attached to the central core.
So, too, for today’s IT. Let the connections be network in nature — not common core-based.