Implementing and maintaining an IT infrastructure is a big decision for any distribution company. Here are guidelines to help you avoid pitfalls.

Data plays such a big part in business that it is imperative distributors study and install a system that will be able to meet their needs for the present and the future. Of course, making this job difficult is the fact that computer systems and software seems to go out of date as soon as they hit the store shelves. That brings up the inevitable question of whether it makes more sense to design and build a custom system or buy a package solution.

“There are a number of obvious things to first take a look at 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 customer service representatives to check the status of any customer’s order while that customer is on the phone.

The first thing that Litke advises is to do a complete “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 vs. 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 vs. 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 simple system lets you weigh scores to make your most important requirements stand out. First, take the candidates and line them up horizontally across the spreadsheet. Then, vertically list the requirements such as low cost, personalization, time factor, etc. Give each of these requirements a percentage score with the total equal to 100 percent. Then, go through each candidate and assign a number to show how well you think it achieves each 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 criteria. 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 that you like the best before the analysis is the one who 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, Litke and Pelletier say the build/buy cost analysis still isn’t finished once you complete the decision analysis spreadsheet. 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 vendor.”

Can people work on it? 
“From a developer perspective, it’s important to remember 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.

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 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 non-quantifiables.

A number of companies fail 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 on line 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, businesses 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.” 

back to top                                          back to online exclusives