Buy before Build Strategy | APPLICATION PORTFOLIO

Custom-made, internally built applications cost more than vendor-supplied packages in the long run. For example, most people would not build their own automobile because it takes far less effort and cost to go to the dealer and buy it. Standardized industry software allows a vendor to spread development costs over a large base of customers and integrate industry best practices and new technologies more easily. This allows the company to use resources to build and support areas of applications that are truly unique and provide a competitive advantage rather than expending resources on reinventing the wheel. That is the piece that everyone knows and understands.
The real question is how to change an organization with a strong appetite for custom software to utilize standard software packages. Most organizations claim that they are so different, their business is unique, it has to be a certain way. In fact, just about every company makes that claim. Yet, there cannot be that many different ways to process general ledger, accounts payable, accounts receivable, payroll, purchasing, etc. In fact, at least 80 percent of all business functions or requirements are common to other companies in the industry. The key is to figure out what and where is that 20 percent that provides a true competitive advantage.
Some business units are accustomed to getting software crafted the exact way they want it so they do not have to go through the painful process of changing their business processes to match the software. The following are some suggestions to help make this transition from a custom culture to a vendor-package environment:
  • Give them the facts. Communicate the costs of having custom software to the organization. Cite industry benchmark statistics and the fact that most companies are using vendor-supplied software. Cite competitors in the same industry that use vendor packages. Explain what the cost structure and environment would look like with vendor packages.
    Top Tip : Buy vs. build strategy

    "A buy versus build strategy can backfire. You may think that buying is cheaper, but it can be more expensive when you do not have a clear understanding of what you are buying. You need to ask the right questions as the devil is in the details."
    —Deb Bauman
    Sun Country Airlines

  • Obtain executive commitment to changing to a buy-before-build strategy. Ask for their commitment, as there will be times you will need it. Changing to a buy-before-build culture is not only an IT issue, it is a business issue, and like most culture changes it needs to start at the top of the organization.
  • Build only when it provides a critical, unique, and strategic advantage or if there is no product available to meet the need.
  • Have formal reviews with all IT groups to ensure no other in-house product could provide the service.
  • Educate the business users. Invite vendors to provide informational demos of software and provide examples of how other companies in similar industries use the software. Have consultants and vendors explain how an industry best-practice process would work in their environment. Then look at the new functionality these applications bring and determine the knowledge, time, and costs associated with customizing your own duplicate solution. Ask yourself if there are other things more important that your resources should be doing.
  • Be consistent and relentless. Enforce the new strategy through the governance process. Have any requests resulting in custom solutions and package modifications go through additional approval steps. Challenge any project request to make sure they first looked at your current application capabilities and alternative vendor software. One company had adopted a buy strategy and then defined their project management process. When someone asked, "Did you look at purchasing a project management methodology?" the company had not even contemplated that as an area for a potential buy rather than build option.
  • Engage vendor-neutral experts in the selection process. The project leader of any application selection should be someone who knows industry standard processes and is able to distinguish a requirement that calls for modification to fit within standard processes. The process of identifying the detail requirements and revealing what areas vendors cannot address will help project leaders to understand where and how much the business or the software needs to change rather than claiming they cannot use standard software.
    Top Tip: Do not customize

    "Buy versus build reduces costs. Think inside the box, in other words, don't customize it. The worst thing you can do is buy software and then customize it as you are dependent on both a third party and yourself to upgrade."
    —Mike Degeneffe


Use this same portfolio picture for an analysis of your business applications environment to look for cost savings. The process of identifying application cost savings cannot proceed without a solid understanding of what applications are already in use within the organization, who is using it, where it's being used, for what business purpose, and how much it is currently costing the organization. For significant cost reductions, consider the tactics in this section for changes to the business applications portfolio as shown in Figure 1.
  •  Eliminate unused software
  •  Consolidate redundant applications
  •  Replace applications with high support costs
  •  Consider second-best applications
  •  Standardize application vendors
  •  Consolidate application instances
  •  Standardize development tools
  •  Identify gaps in functionality
  •  Use more functionality
  •  Discontinue source code in escrow
  •  Do an assessment and strategic plan
  •  Consider legacy system renewal
  •  Consider life extension strategy
  •  Consider buy before build strategy
  •  Use a structured selection process
  •  Take an enterprise view
Figure 1: Tactics to get the most from your business applications portfolio

Eliminate Unused Software

It is challenging to reduce costs in the applications area because changes typically take a long time to implement. However, eliminating unused software modules is one of the quick hits that immediately take costs off the budget. Do this by reducing shelf ware. Make sure you are not paying for any unused or unimplemented software. Third-party software inventory and spending audits to validate software licenses frequently find overspending on licenses compared to the frequency of under-licensed software. Retiring unused application software usually results in a reduction in use of supporting infrastructure items, which you then can also eliminate. For example, one company found an application that had never been deployed. This application had 30 communication lines installed but these lines also were never used. Likewise, consider retiring unused modules or excess users of any in-use application to reduce the maintenance costs relative to those modules.

Consolidate Redundant Applications

Review modules that you have purchased as part of an enterprise system that duplicate functionality provided by silo applications. Consider replacing or removing redundant applications that have overlapping functionality in order to reduce costs. For example, recording and reporting employee time is often part of your payroll system. It might also be contained in your human resource system as well as your shop floor control system and project portfolio system. You might also have departmental silo systems to track and report time. In this example, restructuring your applications so you do all time reporting in a single enterprise application will reduce the cost of providing this functionality. Eliminate all use of duplicate functionality in other systems unless there is a compelling argument to do otherwise.
In the case of an organization with multiple geographic sites, look closely at applications that are deployed in different locations as you might find redundant applications that are ideal opportunities for consolidation.

Replace Applications with High Support Costs

Review your maintenance and support costs as well as your full time equivalent (FTE) personnel needed to support each application. Rank the applications by total cost of ownership. Make sure that the business value received from each application is in proper alignment relative to the costs. Review the support costs by application with each business executive to ensure they feel they are getting comparable value. Relative to the other applications, if an application seems costly compared to the business value, work with the business to consider replacing expensive applications with a more cost-effective solution. In some cases, this more cost-effective solution may be a lean or even manual method.
Assess the business applications to ensure they are providing the desired business value. One company did this by working with the IT steering committee to place each application on a grid indicating value and cost as shown in Figure 2 according to the following actions:
  • Applications identified in Grid 1 are high-value applications, funding is a priority, and they are generally maintained as status quo unless expenses must increase for some reason.
  • Applications identified in Grid 2 are also high-value strategic applications, but review them to see if you are able to decrease maintenance costs without negatively affecting value to the business.
  • Applications identified in Grid 3 are lower-value applications considered for consolidation into higher-value applications with a lower priority as they have a relatively low on-going cost.
  • Applications in Grid 4 are immediate candidates to review for consolidation, as the costs are significant relative to the value to the business.

 Figure 2: Application value matrix

Consider Second-Best Applications

When evaluating software options, many organizations implement the best software, best-of-breed, or high-end software. It is like the old saying, "no one ever got fired for going with IBM." In some cases, the second-best software may give you enough functionality to meet the business needs. You may not always need the most high-end software particularly when comparing the price differences. At times, you are able to get 90 percent of the functionality at 60 percent of the cost and that may be sufficient for your needs.

Standardize Application Vendors

If you consolidate the major portion of your application portfolio with one main vendor (e.g., IBM, Microsoft, Oracle, SAP, etc.,) as much as possible, you are able to gain additional discounts due to higher volume purchases, and it will cost less in interfaces and in achieving seamless streamlined processes. Training costs and personnel support costs are also less with a consistent technology stack. On the other hand, be aware that some of your post-purchase leverage is gone with a single vendor approach and a larger footprint has a much higher barrier, or costs, to exit. Therefore, in some instances a series of interfaced niche applications give a company more flexibility and interchangeability, particularly with the use of enterprise architecture and portal technologies.

Consolidate Application Instances

Many large global organizations spend millions of dollars implementing a common Enterprise Resource Planning (ERP) system, but some implement many different application instances to meet the needs of different divisions, locations, or business units. Each separate instance costs additional money for licenses as well as maintenance and support. Whenever possible, try to consolidate application instances into the fewest number for a lower total cost of ownership.

Standardize Development Tools

For both custom development and vendor-supplied packages, standardize on the fewest possible development tools, and classify the ones you retain as primary and special use.Each additional development tool costs the organization money as you need to have trained resources and backup resources that know each language and development tool. Of course, weigh this against the business functionality provided as you do not want to exclude applications that would provide value for the business because they are using a different language.

Identify Gaps in Functionality

As you look at your applications portfolio, contrast it against the business organization and functions. Identify any key missing areas to review for potential benefits from implementing technology. For example, one company did this analysis and found that the company's marketing area did not have automation. The company realized it was because the marketing executive did not have an appreciation of technology and did not drive the need for tools. When looking at the processes in marketing, they found a severe need for improved processes and technology, which, when implemented, resulted in tremendous business benefit.
Give people the tools to foster accountability, efficiency, innovation, and collaboration throughout the organization. Enterprise tools used across the company achieve a significant savings in business costs as opposed to siloed business unit solutions that meet the needs of only one department. One example is implementing a powerful data warehouse and Business Intelligence (BI) system that gets the right information to the right individual faster and cheaper, enabling improved business decisions. Businesses leverage and mine customer data to come up with solutions that allow a business to interact with customers in new ways that drive additional revenue.
Consider using new technology to provide functionality that was not possible in the past. This may help reduce business costs and eliminate other costly IT applications. For example, newer functionality provided with Web 2.0 collaboration products (e.g., blogging, Sharepoint, wikis, and mashups) can be extremely useful.

Use More Functionality

Most companies fail to take full advantage of their enterprise software packages, ignoring important features that drive significant business efficiencies. For example, one retailer created purchase orders to use in planning purchases and shipment timings with its vendors. This resulted in expensive downstream purchase order changes and reconciliations due to subsequent review and feedback from the merchants. When IT instructed the retailer's merchants in the use of purchase requisitions, which was previously an unused function, it significantly reduced time-consuming activities.
Considering both the full range of functionality and potential modules, industry estimates say that companies use 25 percent of the functionality that is available in packages. Work with the business managers and staff at all levels to review additional functionality that you currently own to see if they would benefit from using additional features. Of course, as a company uses additional functionality in existing software, the cost-per-functionality decreases. Payback from software implementations multiplies as the software penetrates more broadly and deeply into the organization.
Also, look at using more of what you own relative to hardware. For example, one company outsourced payroll as they initially did not have the capability to operate it independently. After implementing a secure data center for other needs, they looked at bringing payroll back in-house by using existing capacity, which saved considerable money.

Discontinuing Source Code in Escrow

Some companies regularly subscribe to source code in escrow whenever they license application software. Granted, this is a relatively nominal cost compared to the expense of having to replace an unsupported application. However, all of these nominal costs add up to a sizeable annual expense when a company subscribes to dozens of escrow agreements. Recognize that many source code escrow agreements are structured such that the only release event is where the vendor goes out of business, which is extremely uncommon. Rarely do vendors release source code without a very expensive and heated legal fight. When push comes to shove, most companies choose to continue operating their relatively stable unsupported applications rather than go to the expense of getting the source code and maintaining it internally. Subscribe to source code escrow only when the application is mission-critical and worth spending the additional tens of thousands of dollars required to get the source code released.