It's one of the biggest decisions any company will make: implementing and maintaining information technology (IT) infrastructure. Information plays such a major part in business, and it's imperative for an organization to study and install a system that's able to meet its needs for the present and the future. Of course, making this job difficult is the fact that computer systems and software seem to go out of date as soon as they hit the store shelves. That brings up the inevitable question of whether or not it makes more sense to design and build a custom system, or to buy a package solution.
This is not a new question. IT specialists contend with the custom-build versus buy decision on a regular basis, and they've come up with some points to help them make the decision. IT and supply chain professionals must approach each given situation as unique and subject to different variables. Most industry analysts tell us that the best bet is to leverage packaged applications.
There are a number of obvious things to look at first when building or buying a new IT system, says Christian Litke, an engagement manager for Pinnacle Decision Systems, a computer consulting and software development company in Middletown, Conn. For custom systems design, you have to deal with hard costs like development, testing and implementation. For packages, you have the initial package cost, ongoing licensing costs, and costs to customize. Yes, testing has been done, but you still need to configure and possibly modify the package and test it in your situation. It's a very difficult decision but companies can use some techniques to help make the picture clearer.
Suppose you are managing a company that is looking to design and implement a corporate intranet that would allow employees to do things like find the current value of their 401(k) plan or the number of vacation days they have left. The first thing to do, Litke advises, is to complete an "envisioning phase," where company managers decide what the system requirements will be based on its ultimate usage. This is extremely important, because these requirements will dictate the points to look at during the build versus buy analysis.
The next step is to research what types of products are on the market that may be able to do the job," says Michael Pelletier, emerging technology strategist for Pinnacle. "Chances are there will be many programs available, but you will need to weed out the programs that are designed by manufacturers that you feel don't have the track record you need or ones that your IT people may not feel comfortable with. Once you have compiled a group of possible candidates, then you need to do an analysis of their strengths and weaknesses versus your requirements and how they compare to the design and implementation of a custom-built solution."
Litke says the easiest way to compare strengths and weaknesses is by doing what is called a "decision-analysis spreadsheet." This is a simple system that lets you weigh scores to make your most important requirements stand out. First, take the candidates and line them up horizontally across the spreadsheet. Next, vertically list such requirements as low cost, personalization and time factor. Give each of these requirements a percentage score with the total equal to 100 percent. Then go through each candidate and give a number to show how well you think it achieves each individual requirement on a scale ranging from positive one, meaning the alternative fully satisfies the business requirement or decision criterion, to negative one, meaning it doesn't meet any of the requirements or criterion. Multiply the requirement's weighted percentage times the individual score.
You add up the numbers to get a score for each option, and the candidate with the highest number is the one that theoretically will be the best," says Litke. "But the formula can be easily swayed by changing the weights. While you may be trying to take an unbiased view, it's easy to inadvertently make the formula work so that the candidate you like the best before the analysis is the one that gets the highest score. You have to be very diligent to make sure that you approach the process impartially to get the best answer for the company's needs."
However, both Litke and Pelletier say the build/buy cost analysis still isn't finished once the decision analysis spreadsheet is completed. The chart is just the first step in choosing which solution is right for the situation.
"Most of the decisions also have to deal with intangibles that are hard to quantify," says Pelletier. "There are costs that you can identify up front, but you also have to remember that there are other costs that are hidden. These are the things you need to worry about for the long term."
The following are some of the "intangibles" that Litke and Pelletier say companies should consider during the build/buy decision process:
§ Look for longevity: "Say a company has designed a product that meets most of your needs. You have to ask yourself if that company is going to be around years from now," says Litke. "What if they're not around to support the program and you don't have the source code to service the program yourself? You may find yourself having to reinvent the wheel or find a new supplier."
§ Can people work on it?: "From a developer perspective, it's important to remember that if your system needs fixing or modification, it's easier to find a developer to support generic languages (i.e. Microsoft Visual Basic, Oracle, etc), but finding people who are Broadvision experts can be a lot more difficult and costly," says Litke.
§ Consider owning the code: Additionally, Litke says it's important to own the source code so that developers can work on the system. With a custom system, you can own the code if your contract is written correctly (check it). But with a packaged system you have to pay licensing fees and may not get access to key parts of the code.
§ Are you going to change?: "Three years from now you may get to the point where the business model changes and this will create new needs for your software or system requirements," says Pelletier. "Maybe you didn't plan to have your system be easily expandable. This could cause you to have to buy a whole new system or do custom development. Sometimes you may want to look at your plans and discuss scalability options for your system choices."
§ What is the scope?: "With a custom system, developers can usually design in the features you need. This can be both good and bad news," says Pelletier. "If the project is well-managed, the development and final product can work. But if you let everyone weigh in with an opinion, the result could become a huge mess. Just like too many cooks can spoil the broth, too many end users can spoil the code."
§ Is it overkill?: "Many packaged software solutions have lots of bells and whistles and you may be getting more from the package than you really need," says Litke. "If you're only using a quarter of the features in a software package, chances are you paid for lots of functionality that you didn't need. Be careful not to overbuy."
§ Remember the end user: "Since people will be using the final system, you should remember to calculate how easy and receptive they will be to your candidates," says Pelletier. "Many older ERP [enterprise resource planning] systems look more like emulations of mainframes than modern GUI systems. While the functionality may be there with the GUI system, the front-end is really a turn-off to users. It's always a huge challenge to get people to change and if you choose a solution that will turn off employees, the usability factor will be really low."
§ Time isn't on your side: "Time can be one of the biggest unquantifiables. There have been a number of companies that have failed to realize how long it takes to implement a new system and have been burned," says Litke. "The company says it needs X number of features in six months. If this is the case, time is the most critical factor in the build/buy analysis. If the system is being built, the company will get incremental features along the way. But if it is a buy solution, the features can come online very quickly. With a buy solution you have a steep functionality slope but then you have to factor in the time it takes to learn the functions, too. Time is a very tricky component of a build/buy analysis."
As if there weren't enough factors to investigate when deciding what solution to choose, Pelletier says companies need to make sure they don't let the process of investigating the factors result in project failure. While there may be dozens of factors to investigate, companies run the risk of "paralysis by analysis." He says companies need to keep the big picture in mind and not get tied up in the micro level of review.
"Don't think that a build/buy analysis only works for major software or system decisions," says Litke. "Sometimes a company may be looking at just adding a component to an existing system. In this case, sometimes a developer may be able to develop a solution in say two to three weeks. But a pre-existing module is already on the market for $100. In that case, the choice is obvious. But sometimes the answer isn't as clear. A build/buy analysis will work in these sort of cases, as well."
"It always comes down to money," says Pelletier. "No matter how you slice it, companies are in the business of making money, and the least expensive solution to the problem always has the upper hand. But doing a build/buy analysis helps companies discover that spending a bit more on a solution may save money down the road. You really have to evaluate the functional needs of proposed solutions. Does it do it? How does it do it? How hard is it to manage? All of these questions are important to ask and I think that a build/buy analysis is the only true way to even come close to an answer."
And, the more money you have to spend on a system the more accountable you must make the solution providers, suggests David Thompson, Chief Information Officer for PeopleSoft, an enterprise application software provider based in California. Hold the software supplier accountable contractually and get the supplier of your software involved in your implementation [consulting]. Thompson further suggests that if you go the packaged route commit to fewer suppliers with broader product lines that provide best of breed, then you'll have fewer integrations.
For more information on this, you can reach Christian Litke at [email protected] and Mike Pelletier at [email protected].
