A Different Perspective
Commercial off-the-shelf (COTS) software provide functional capabilities commonly shared across multiple users. The ability to fit large groups of users into a single class having common needs and objectives benefits that class through the economies of scale that COTS offers. Word processing, spreadsheet, and presentation applications are generalized COTS software suitable for a large audience of office users. This allows significant economies of scale if the user base is large.
Business transaction management becomes less common the further you go up the transaction stream from general ledger (GL) and financial reporting needs. Generally accepted accounting principals (GAAP) allow many businesses to share the same COTS software. When it comes to Accounts Payable (AP) and Accounts Receivable (AR) accounting, things start to get more complicated. A financial services firm will need to handle Receivables differently than a manufacturer, and may have significantly fewer functional requirements for Payables.
To feed AR transactions, Order Processing capabilities needed by a manufacturer of lightbulbs (discrete manufacturing) is very different from the needs of a manufacturer of food additives (process manufacturing). Among discrete manufacturers, the transactions leading to the formation of AP transactions may require a more complex handling of the Bill of Materials (BOM). A computer has many more parts than a lightbulb and may involve a BOM of components within a BOM for finished goods.
The Bill of Lading (BOL) a concrete reinforcing steel fabricator needs must include weights of packaging that is uniquely determined by the lift capacity of cranes. While the BOL of a process manufacturer of food additives or hazardous chemicals must include product component details to comply with safety regulations.
If your business competes on having trade secrets in process controls and methods, the last thing you want is software that shares these secrets with your competitors, which is what COTS is all about.
How to decide Buy vs. Build
By the time you are reading this, you have already determined that you need software to solve some businesss problem. You have already considered the features you need. You may have even made some forms to collect the data you need. You just need to determine if it is more cost-effective to buy something off-the-shelf or to build it from your requirements. You need to consider four things to make this decision.
1: Examine Your Organizational Constraints
Application updates and technical support require some sort of access to the computer systems hosting the application.
* What is your existing information access/security strategy? Does it require a badged individual with Top Security clearance to be on site? Or can an outside vendor connect over an internet connection into your user’s workstations to provide end-user support?
* Are data integrations with other systems required? What are the access contraints of those systems?
* Does your organization have platform, language, or framework standards that constrain your choices?
2. Review Capabilities of Your Existing Software
No matter the size, most businesses have an existing system or two within the organization serving some purpose. Your may consider that with some modification, these systems may satisfy your need cost-effectively. Existing systems often cannot be modified because of insufficient documentation or support. It cannot be modified if no one understands it, has the source code, or exists to support it. Or it may just be too costly to modify it. This widens the scope of your requirements to include replacing the existing capabilities.
Even if your requirements are outside the scope modifying of existing software, you may have to integrate new software with existing systems to provide transactional data. This adds cost to your project for new feature development and depends heavily on your organization’s other standards and constraints. These constraints can also limit the availability of human resources with the required skills to get your project done.
3. Review COTS Customization and Support Requirements
COTS software rarely satisfies all of a business’s requirements. Oftentimes, COTS software is designed to satisfy the majority of requirements for all users in a certain class. Some COTS software will allow simple modifications like adding a few custom data fields that can be manipulated in the application’s reports. But if reporting is incomplete without integrating the data from the new COTS system with other applications, then this integration will still be necessary. Such customization of COTS software can make updates and patches extremely burdensome to the organization.
4. Evaluate Cost of COTS vs Custom Development
Evaluate the cost of customizing, integrating, and supporting COTS software. Evaluate the cost of writing your software solution in-house or hiring a professional services vendor. These comparisons involve both hard and soft costs. Hard costs are what you pay to get the features that can be delivered. Soft costs are what it costs you in time to use and support the system. Soft costs also include the marginal cost of NOT getting any features one way or the other. It is in the negotiation of these soft marginal costs that great decisions are made.
Scope creep has killed many projects due to cost overruns. When users start to use a system, they find a way to communicate additional requirements. Well into the initial phases of a software development project, a good programmer analyst will discover these requirements and document change orders for the marginal cost of adding these features. The marginal benefits can be insignificant. For instance, if automating a process to move data to a file on a network saves a user four hours of manual work to complete the same task once per month, does this justify the cost of development of automating that process? Not likely. If it saves them one hour a day, then it is more likely beneficial enough to automate it.
Just like COTS, Custom Developed software also has continuing support costs for patches and updates. The sooner you can get users using a Custom Developed solution, the quicker you will discover these needs. You will want to minimize your financial exposure to getting users on the system early.
You should choose a COTS solution IF:
* It complies with your organization’s constraints.
* It meets most of your functional requirements for the next 3-5 years with little or no customization.
* It does not have too many features than you will use, but for which you must still pay.
* The support costs do not exceed your operating budget.
You should choose a Custom Developed solution IF:
* No COTS software adequately satisfies the business requirements without material modifications.
* Support costs are within your operating budget.