This article illustrates the three main system options for organizations seeking to upgrade their systems and the pros and cons of each. Having made the decision to upgrade its systems, the next step that an organization needs to take involves the classic "make or buy" question: Is the organization going to build its own system from scratch or purchase a "mature" system that tens, hundreds, or even thousands of organizations currently use? Note that the traditional make or buy decision has been complicated somewhat in recent years by the advent of SaaS (Software as a Service). Vendors like Workday and salesforce.com provide a third option for organizations that want to "rent" software.
Many factors drive an organizationís decision to buy, build, or rent.
Size of Organization
As a general rule, a small organization is much less likely to purchase and implement a very large, expensive system than a larger organization. For example, not too many 200-employee companies poised for modest growth can justify a $500,000 outlay for a new system such as SAP. For these organizations, relatively small-scale solutions are probably sufficient for the time being. If not, then the rental option may be appealing for simple cost reasons.
On the other end of the spectrum, a very large, 40,000-employee firm in multiple countries would tend to find it easier to justify the expense of a large system that has been thoroughly tested. In this case, building a system is often just plain silly. For example, pharmaceutical companies should make enterprise-wide systems about as often as network security companies should manufacture their own aspirin. The vast majority of Fortune 500 companies have some type of enterprise system, even if itís a very old version that it has significantly customized.
Number of Expected Annual Transactions
SaaS agreements tend to be transaction-based. In other words, the organization that enters more sales or pays more employees will receive larger bills from their vendors than will companies with fewer transactions. Thus, a small organization would be more amenable to a "pay as you go: system. At the end of the year, if the organization pays more, then it probably had a stellar year.
A large organization will typically not rent software, at least enterprise-wide. Certain pockets or departments might go this route, perhaps on a trial period. Consider a company that expects to conduct $4M financial or employee transactions at fifty cents per transaction. It is facing $2M in annual expenses, an amount often large enough to sway that organization towards buying its own system.
Budget is a primary driver of the make, rent, or buy decision. ERP vendors know that it is very expensive and time-consuming for organizations to build comprehensive payroll, general ledger (GL), and procurement systems from scratch. They also know that many prospective clientsí legacy systems have long outlived their usefulness. Major vendors are all competitively priced. One might be a bit more expensive than another on any one deal, but it is fair to assume that comparable vendorsí prices will be in the same general ballpark.
Renting or purchasing software from a vendor may restrict a clientís ability to tinker with that software. An organization with the desire, knowledge, and resources to customize its system probably wants no part of renting. The organization that builds a system from scratch or "gets under the hood" of a purchased system controls that system.
The organization that needs to go live in a relatively short period of time may be tempted to rent, thinking that it does not have the time or budget to endure a traditional soup-to-nuts implementation. For example, perhaps a start-up has recently received funding and is looking for a "quick fix." The thinking here is that employees are probably too busy to participate in a full-blown implementation. All else being equal, a SaaS solution may have a shorter ramp up time than that of a traditional system. However, there are no guarantees.
Certain executives are not comfortable with key employee, GL, or sales information lying outside of their control. While companies like salesforce.com and ADP claim to house their "hosted" information in a secure manner (and I certainly cannot claim that they do not), a CIO simply might feel uneasy about not "owning" his companyís information.
There is no simple answer to the question of whether organizations are best served by renting, buying, or building systems. The factors discussed in this chapter differ for every organization. However, the following general rule remains: Absent a compelling business need, organizations should purchase or rent a tested, proven solution rather than build one from scratch. From a business perspective, the amount of time, money, and effort required to build a new GL, supply chain, or payroll system will dissuade all but the most naÔve or stubborn senior managers. As a last resort, an organization determined to create a new back office system--and incurring the related risks--should consider this: these systems result in no real sustainable business advantage.
For smaller organizations, renting may be a more viable option, particularly if the application addresses a relatively common business need (such as accounting, sales, or payroll) and will result in relatively few annual transactions. These organizations do not tend to have the budget for a large, expensive ERP, unless they project massive short-term growth. They generally do not have the resources to "reinvent the wheel" and build their own core systems.
The case for building is perhaps strongest for organizations that have a niche need with no apparent software application on the market, at least for a reasonable cost. While this is not a book on software development, suffice it to say that many "custom" systems suffer from poorly defined design specifications. As such, an ISV or internal developer may need to make certain leaps of faith that turn out to be incorrect. This hinders development and causes delays and cost overruns.
About the Author
Phil Simon (www.philsimonsystems.com) began independent software consulting in 2002 after six years of related corporate experience. He has cultivated over twenty clients from a wide variety of industries, including health care, manufacturing, retail, and the public sector. Phil has extensive experience with a wide variety of applications, both mainstream and homegrown. He has assisted organizations in all phases of systems implementations, including vendor selection, project management, business needs analysis, system design, application training, system testing, custom report and interface development, and end-user documentation.