In some enterprise software selection projects, clients are tempted to skip the Request for Information (RFI) stage and go straight to a Request for Proposal (RFP). This is a mistake and often the result of not fully understanding the value of a well-written RFI.
What is the difference between an RFI and an RFP? In our software selection consulting services, we develop an RFI near the beginning of the vendor evaluation process. The RFI includes a description of the client’s organization and the client’s project. It also includes a list of key requirements for the new system—not an exhaustive list, but essential functionality or processes that are distinctive for the client. Vendors are asked to respond as to their ability to satisfy those key requirements. Vendors are not asked for a cost proposal at this time. We typically make the RFI available to as many vendors as we think are qualified to respond, or to those that express an interest in responding—usually five or more.
An RFP, in contrast, is published near the end of the evaluation process, after each finalist vendor (typically 2-3) has conducted its demonstrations or other proof-of-concept. The vendors are asked to provide a cost proposal, along with their proposed license/subscription agreements and a high-level implementation proposal with costs and schedules. The vendors’ RFI responses are incorporated as an attachment, which they can revise based on what they’ve learned since they first responded to the RFI.
Developing an IT strategy for some organizations can be difficult because of the presence of a legacy system. Legacy systems that are old, out-of-date, and difficult to maintain are a huge obstacle to innovation. As a result, business leaders become increasingly frustrated by their inability to roll out new mobile apps, connect with customers, analyze business performance, or become a digital business.
In recent years, it has become popular to describe organizations with an out-of-date legacy system as being in “technical debt.” I would take this a step further. If an organization ignores the need to update the system for too long, it can lead to what I refer to as “technical bankruptcy.”
We can define technical bankruptcy as a situation where the organization cannot, or finds it exceedingly difficult to, pay off the technical debt. It does not mean that the organization is in financial bankruptcy but rather that its systems are broken or held together in a way that makes them extremely difficult to upgrade.
Significant Percentage of Organizations Are at Risk of Technical Bankruptcy
In work with our clients at Strativa over the past several years, we have gained new insights into challenges facing organizations that have out-of-date legacy systems. We recently took the opportunity to combine those insights with survey data from our sister IT research firm, Computer Economics, to produce a new report, Avoiding Technical Bankruptcy in Legacy Systems. (Click the link to download the report free from the Strativa website.)
Figure 3 from the full report shows the magnitude of the problem as it applies to ERP systems. A small but significant percentage (7%) of organization have not upgraded their ERP systems for 10 or more years. These are likely to already be in technical bankruptcy. But the 13% of organizations that have not upgraded their systems in the five-to-nine-year time frame are in the danger zone: Technical debt is building, and if the organization does not undertake a major upgrade, it risks falling into technical bankruptcy.
Signs of Technical Bankruptcy
What are typical signs that a legacy system has reached the stage of technical bankruptcy? We found five characteristics:
Extensive modifications, extensions, and interfaces.
Poor understanding of the system by users and IT alike
Direct involvement of IT personnel in business processes.
Legacy system atrophy as shadow IT emerges.
Upgrade or replacement hard to justify.
In the full report, we explore the symptoms of technical bankruptcy and the devastating effects that it has on the organization. We continue by quantifying the scope of the problem specifically for ERP systems, using our research on the typical age, frequency of upgrades, and extent of modification of these systems.
Most importantly, we conclude with recommendations on how to avoid technical bankruptcy and, for organizations that have reached this stage, strategies for getting out and staying out of technical bankruptcy going forward.
In many markets for enterprise software, the battle between cloud and on-premises (or hosted) systems is over. Salesforce, the market leader in CRM, will soon pass the $10 billion mark in annual revenue. Workday, with its cloud HCM offering and growing financial management applications, expects to hit the $2 billion mark in 2018. Traditional Tier I providers, SAP and Oracle, are certainly not out of the race. But the only way they have been able to compete is by building, or buying, their own cloud services for CRM and HCM. Cloud has won.
Nevertheless, there is no cloud ERP provider the size of Salesforce or Workday, and there is certainly no cloud ERP provider for the manufacturing industry with that scale. NetSuite was founded in 1998, around the same time as Salesforce. But it only reached the $741 million revenue mark in 2015, before being acquired by Oracle. Claiming more than 30,000 companies, organizations, and subsidiaries in more than 100 countries as customers, it is by far the largest cloud ERP provider. Although it has done very well with professional services firms, software companies, and other services-related businesses, manufacturing companies form only a small part of that number. Plex Systems has a pure cloud ERP system for manufacturers dating from 2000 and has been rapidly growing over the past four or five years. But its customer count is under 600. After NetSuite and Plex, the number falls significantly: Cloud-only systems such as SAP’s Business ByDesign, Rootstock, and Kenandy, each have even fewer manufacturing customers.
To understand how great the market opportunity is for cloud ERP in manufacturing, consider that, according to the U.S. Census, there were about 63,000 manufacturing firms in the United States in 2014 with 20 or more employees, as shown in Figure 1. Considering that the estimated customer counts by vendor in the preceding paragraph include customers outside of the U.S., it is safe to say that manufacturing cloud ERP probably has less than 2% market share in the U.S. The market opportunity going forward, therefore, is enormous.
In our software selection consulting, clients often seek our advice on implementation partners. In fact, our experience over several decades tells us that the choice of an implementation team is as important, sometimes more important, than the choice of a new system.
In choosing an implementation consulting group, clients often start out thinking that it’s best to choose the vendor’s own professional services group. They think that no one can know the software as well as the vendor’s own personnel. They think that when problems arise, the vendor’s consultants will be in a better position to deal with the software vendor. They also think that there will be less finger-pointing: the consultants blaming the vendor, or the vendor blaming the consultants.
These considerations have merit. But there are other factors to consider, factors that may make an implementation partner, or even an independent consulting firm, a better choice.
Since the turn of the century, there has been an ongoing ERP
consolidation trend, with Oracle, Infor, Epicor, and others buying up
smaller ERP providers. During this same period, newer ERP vendors have
risen up to challenge the incumbents. Nearly all of the new entrants are
cloud ERP systems.
One of the most interesting of these is Seattle-area-based Acumatica,
founded in 2008—just yesterday in “ERP years.” Like many other ERP
startups, it initially focused on services businesses but soon added
distribution and CRM functionality to its horizontal capabilities. Its
go-to-market strategy is 100% through value-added resellers (VARs), who
can add their own industry-specific software on top of Acumatica. Its
VAR strategy, in this respect, is similar to that of Microsoft Dynamics
and Sage. In fact, many of the new VARs in Acumatica’s channel program
have come from the Microsoft and Sage ecosystems.
Acumatica’s
partner and customer conference in January gave us an opportunity to
update our view of this emerging cloud ERP provider. We find that
Acumatica is interesting because of three characteristics that are
somewhat novel in the ERP world.
Small businesses play a vital role in the economy and are often the
leading innovators in new products and services. According to the U.S.
Census Bureau, organizations with fewer than 500 workers account for
over 99% of businesses, and companies with fewer than 20 workers make up
nearly 90%.
But small business doesn’t always mean simple
business. Like larger companies, small and midsize businesses (SMBs)
need to reach new markets, develop new products, satisfy customers, and
control costs. The main difference is that SMBs need to do these things
with fewer resources.
In recent years, however, software vendors have announced new products to address
the challenges facing small businesses. This post outlines two of them.
