Problem Definition
Rarely
does an enterprise look at developing all their own software, more typically
the development decision centers on a specific area, for example customer order
management or promotions. These projects are actually two projects in one. The
functionality required plus the integration to other software has to be built
and maintained. The build versus buy decision is typically seen as a two different
options. In reality, a third option exists; modify a product to reach the objective.
Modifications have their own plus and minus issues, as developed in the article
"Should
You Modify An Application?". Who will build the software should also be
considered. For the typcial enterprise , software development is not their primary
business, why should they be developing software in-house? In today's market,
finding and keeping the right IT skills is a major challenge and few companies
can afford the time or money to have these skills on the payroll. Outsourcing
the development means you can get the skills you need, immediately. Doing this,
however can impact your short and long-term cost and risk either positively
or negatively depending on many factors.
The Motivations for Building
Visiting companies who have decided to build their own software or are in the process of deciding; we see several motivations, some good and some bad. If the motivation is a business practice that creates competitive advantage and is not found in any available package, the motivation is good. This practice helps you gain market share or increase customer service and it is part of the company's approach to the market. The business practice should be preserved if it truly gives competitive advantage. However, you need to have your eyes open. On the subject of competitive advantage, is the advantage seen as delivering competitive advantage only in the eyes of the seller? Ask your customers if they see it as your competitive advantage. Is this function not available in packaged software or is it just that you have not looked hard enough? If the business practice does not create a competitive advantage the motivation should be challenged. The practice should be changed to a more common or best practice that is typically available in software packages. If there is not competitive a reason to be different, what is the business advantage to being different? What if your needs are "simple" and the available products are "overkill"? This may happen, but you need to take a long-term view. If you are convinced that the need will remain "simple", then perhaps building a simple solution is an acceptable approach. The reality is that all needs become more complex over time and only if you can convince yourself that this situation is the exception to that rule should consider the building alternative. Are the "simple" needs appropriately addressed in a different package? Investing in finding that simple package can be a very good investment. If the motivation is technology based, the motivation is usually bad. Unless you are in the technology business, how you achieve results is not important to the results. Using the "right technology" may lower your cost due to standardization, but if the "right technology" is one that is new to your business, it is a dangerous motivation. The technology motivation is often rooted in an emotional foundation coming from technology advocates. Their true motivation, usually not recognized by them, is often the desire to move into a technology this is more personally interesting. The technology motivation may be wrapped in a business case, but you should always challenge motivations that extend the technology portfolio because they always extend the fixed cost.
Why and Why Not
Two factors must be considered in the build versus buy decision, short and long-term economics and the impact on your competitive position. All other issues can and should be related to these two issues. As a rule, if the build decision has no impact on competitive position, the realities of today's software market will lead to a buy decision due to economics. The discussion for building software always includes a list of functions that are not available in the packaged options. As discussed above, are these functions creating competitive advantage? Although it is seldom done, a list of the functions that the package options do provide and are required by the business should also be compiled. Examples of items on this list include integration to other systems (order management to accounts receivable, inventory, sales analysis, etc.) at the master file and transaction levels, basic maintenance (price list, terms, standard messages, etc.), any many more. The list of what is missing from a package and what is available from the package must be taken together to understand what the new system must provide. This combined list drives short and long-term cost. This cost must be compared to the cost of buying, perhaps modifying and installing the packaged product. How long will the build process take, from the decision date until the new system is operational? If the time difference between the build and buy options is significant, this can drive the decision in one direction or the other. There is a business reason for needing this software. What is the cost delaying the satisfaction of that need? This cost should be considered in the economics.
For
example, if the development estimate is just for coding time, it grossly underestimates
the overall cost of the project. A substantial amount of resources should
be allocated to design, prototype, and testing.
When the cost of building a solution is estimated, it usually focuses on the direct IT cost. However, the demands on the business/operations staff of a company will be significantly more with an internally developed system as opposed to a packaged application. The users' input is the sole source of information for the product design and testing. This is a cost not faced when a package application is licensed. Which users are usually demanded for this input? The users who know the needs of the business who are often critical to the daily operation of the business are the resources that are called upon.
Build or buy, the software still needs to be implemented. The implementation process: set-up, data conversion, testing, user training, change management, and go-live are all people costs which should be roughly the same as with a packaged application, or at best slightly less. While a company may feel that software that they build will be much easier to implement, this has not proven to be the rule. Although the custom solution should fit the business better, it usually lacks the formal training tools and documentation of the packaged solution. When evaluating the build versus buy options, a long-term view must be taken. The cost of initial development can be significant but the long-term cost must also be evaluated. The long-term cost is the annual cost of maintenance, modifying the resulting software to continually meet the needs of the business, maintaining the integration with other systems as these systems change, etc. As a rule of thumb, the long-term cost is proportional to the initial cost and can range from 5 to 40% of the initial cost per year. The actual cost depends is a function of how dynamic the business function proves to be and the number and volatility of the integration points. Internally focused systems, for example accounting systems, are less demanding while systems that deal with customers tend to be the most volatile. Customer oriented systems face forced change due to both customer demands and competitive pressures.
Summary
If you are considering building software, the key issue is "Why?" If the answer is not building or maintaining a competitive advantage, the economics and realities of today's software market will lead to a buy decision. If the answer is building or maintaining competitive advantage, will it be more cost effective to start with a package and modify the package to meet your needs? Finally, if it both cost effective and addressing competitive advantage, by all means, build.
About the Author
Olin
Thompson is a principal of Process ERP Partners, LLC. He has over 25
years experience as an executive in the software industry with the last 17 focused
on the process industries including the ERP, SCP, and e-business related segments.
Olin has been called "the Father of Process ERP." He is a frequent
author and an award-winning speaker on topics of gaining value from ERP, SCP,
e-commerce and the impact of technology on industry. He can be reached at Olin@ProcessERP.com.