أنشئ حسابًا أو سجّل الدخول للانضمام إلى مجتمعك المهني.
Hope the article might help to understand the question:
Which Kind of System? The Make, Buy, or Rent Decision
By Phil Simon
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.
Considerations
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 many200-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 Fortune500 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
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.
Control
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.
Timeline
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.
Security Concerns
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.
Summary
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.
I see that the main factor is whether the ERP implementation is targeting one of your competitive advanatages or not. When it comes to one or more of your cmpetitive advanategs, It is probably better to develop your own system. Dell did so inautomating thier make-to-order and configure your orderd computer systems
It is related to the man power that the company has, if it has the sufficient experience to make the it will make ERP, otherwise it will depends on outsourcing
To arrive at the decision to make or buy an ERP. Firstly internally GAP Analysis have to be prepared from your existing system and overall requirement. Based on it Make model is advisable (almost essential) if your requirements are so distinct that most of ERPs do not offer those features & functionality or calls for over30-40% customization in any std. ERP System. If your requirement is almost standard one which most or ERPs do offer and if this is going to be your1st time ERP Implementation better to Buy budgeted good working ERP and prepare the right data for they system (which is quite challenging & would few years to build the right data for ERP System of all the modules for those companies who are all new entrants to ERP) and graduate to a well known ERPs like SAP, Oralce etc.
This depends mainly on the requirement or outcome what the company is looking at ? Accordingly it should be decided whether to Make or Buy and ERP. The main factor looked is Cost.
