Build Or Buy - Turning Around A Bad Software Decision

 By:  Norman Katz, Katzscan Inc.

One decision that can bring a company quickly to its financial knees is the decision to build custom software to address standard business requirements.  Problems relating to these projects include poorly understood functional requirements, cost overruns, excessive timelines, technology selection and experience, and a final product that will likely always be functionally behind existing, proven, third-party “off-the-shelf” software applications, thus requiring continual work and investment.  There is no shortage of readily available software solutions for common business functions such as accounting, sales order processing, and inventory control.

Custom software will also need to be “shaken out” to ensure data integrity, such as security features, transaction balancing to the general ledger, and transaction logging.  And “custom software” includes packaged software that has been (heavily) modified over time.  Eventually one is likely to find that the modifications have caused more problems than they helped to solve, and are actually restricting new and needed business functionality from being added.

A key element to the “build or buy” decision is to recognize that regardless of how unique you believe your business to be, it is a business and performs basic business functions on a daily basis.  Finished goods are sold to customers, purchase orders are sent to suppliers for raw materials, invoices are processed for payment, and inventory needs to be tracked.

So, how can you be sure that a third-party software application is the right one for your business, where there are so many similar ones to choose from?  Inherently, at a very detailed level, there will be some differences between similar software applications: the available data fields or how easy it is to do data entry of entities (i.e. customers, items, and suppliers) and transactions (i.e. sales order, purchase order, or invoice payment). 

One area likely overlooked is how to bend business requirements to software functionality without breaking either.  I’ve helped several of my clients slash project costs by tens of thousands of dollars, increase ROI, and gain better-than-expected functionality by implementing a packaged application solution over custom software.  The trick, which is critical in any software implementation, is how the data is setup.

When converting from one computer system to another, you must look to setup the data in the new system to take advantage of its functional features, and sometimes this is not obvious.  Look at the data fields available and how they are used within the system.  Are reports driven off of a data field?  Does a data field cause the system to act in a certain way?  What data fields are required versus optional?

One common error is to judge the software application’s functionality by the standard reports produced.  No software company can think of all possible reports for the infinite ways data could be setup.  A software application is a repository of data, and there are efficient ways to produce reports outside the system that accurately reflect the data being housed in the software application.

Finally, when reviewing a possible software solution, walk through the system using your own sample data, and make sure the samples accurately reflect how you want your business to run, not necessarily how your business is currently running.  The implementation of any new software application will cause business processes to change – often for the better – and therein lies the unique opportunity to transform from “exception management” (where nearly everything that happens is an exception to the norm) to “management by exception” (where the majority of business transactions require no intervention, and only the rare exceptions require human interaction and decision-making).

Copyright (c) 2006 - Katzscan Inc.