*Urban Dictionary defines a hoopty as any car that meets certain characteristics, including but not limited to requiring the driver to enter through the passenger side; requiring half a clothes hanger to hold up the exhaust pipe and the other half to serve as an antenna; and/or requiring the manual up and down movement of the turn signal to signify the driver’s intention to turn. (Variant spellings: hooptie, hoopdie, hoopdy. See also: clunker, jalopy)
Eventually, everyone needs to replace their commercial finance software, unless you think that system you bought 25 years ago will last forever — like that old guy down the block with the decrepit 1985 Chevrolet.
This article will present a high-level overview of the process for identifying the best software for your business.
Include Everyone
Throughout this project, please keep in mind the best sources for information on the system sit in the cubicles of your own staff. End-users provide valuable prospective on the current system and what a new system should include. To assure the best possible outcome, wise managers include key staff people in the investigation and decision-making activities from the beginning.
What Do You Need?
The first step in the process requires a clear definition of what you need from the new system.
Your definition of the system requirements starts with an idea of the scope of the project. Will you want a factoring system or an ABL system? Do you want one system to handle both?
Look at your current system and consider what you really like about it. More importantly consider what you do not like.
First, regarding what the current system does well you want to avoid taking a step backward in these areas. For example, you may value how the current system handles short payments. Note this and verify that the next system handles these transactions well.
Second, your current system probably falls on its face in a couple of areas. Perhaps the current system does not have any interfaces to your general ledger or the ability to upload deposit details from your bank. You know that these capabilities would make your operation more efficient. So you want the new system to include these features.
Last, step away from your current system and consider where your business is headed. The new system needs to handle your strategic initiatives. Will you be opening overseas offices? If so, can the new system handle multiple offices and the potential language, currency and time zone issues? Taking this step back and documenting these future changes in the context of the system review could prevent a costly mistake.
Think about what has changed in technology since you last bought a system. Specifically, you probably want some Web access for your clients to load data, request funds and get information on their financial position. Also, you will want data storage and retrieval processes strength every day. You may want to run your own queries and reports against your data without relying on the vendor for support. Can you access the system from home or on the road?
Some software vendors can host the system on their own servers — possibly an attractive alternative. In this situation the lender can focus on their clients and not worry about network and software maintenance issues.
Who Can Meet Your Needs?
There are software suppliers out there … you can hear them breathing. Here is how to get their names:
- Experience — your management team and staff probably have experience with several potential software suppliers.
- Advertising — many software companies run ads in trade journals and on industry websites.
- Networking — hopefully your managers and staff have friends in the industry that can provide recommendations.
- Trade Shows — software vendors exhibit at industry trade shows.
- The Web — there is nothing like a plain old Google search.
Request For Proposal
At this juncture you know what you want and who can provide it to you. It is time to reach out and see what the vendors have to offer.
Now you have a choice on what to do next. Some buyers contact the vendor and ask for an introductory demonstration of the software. This demonstration often takes place online. Some presentations are done at trade shows or in person. Based on the results of that demonstration, the buyer than submits a Request For Proposal (RFP).
Your RFP consists of information about your needs and questions to the vendors. You should cover all your critical issues surrounding the software decision. There are websites with discussions of RFPs and RFP outlines. However, your RFP requires a significant investment of time from your management team and important staff members.
RFPs can be extremely detailed affairs, here are a few of the highlights:
- Information on your company and project. Vendors need to know who they are dealing with. Also they need to know what capabilities you want and where the users work. Think of this section as the who, what, when and where part.
- Questions about the vendor, including company background, financial data and references.
- General information on the software:
- Technical data on the programming language
- What hardware and ancillary software licenses are required
- Security and backup tools
- Ongoing support requirements
- Questions regarding the specific functionality you are looking for. Now the data generated in the “What Do You Need” section above all comes into play. If you must have green screens with a Tartan plaid background ask for it now. Seriously this section of the RFP cries out for as much detail as possible.
- Vendor expectations: Ask how long the vendor expects to take to install the system and train the users. You need to avoid surprises about the conversion process. Can the vendor transition data from you existing system to their system.
- Money: How much does the system cost? What are the ongoing maintenance charges? What does the vendor charge for installation, training, conversion support and programming?
Reviewing the RFPs
Assuming that more than one vendor responded to your RFP, the staff needs to get busy reviewing all the responses. Since a good RFP covers many detailed topics, the responses should in turn include significant detail. It takes time to pick these responses apart and compare answers.
This management challenge may require a divide and conquer approach. Send the technical responses to the technical people and ask for a comparison of each system’s strengths and weaknesses. Give the operations people the section on the specific functionality and request a comparison of each package’s abilities; be sure to get their opinion on the interfaces. Send the cost sections off to the finance people for review. This is not rocket science, it’s just detailed analysis.
After each group has given their feedback, one or two systems should rise above the others.
Workshops
Assuming you have selected one vendor as the most likely candidate. Now they have to prove they deserve your business. The vendor should perform some more detailed presentations of their solution to various managers and system users. As the buyer you should prepare specific business situations you want the vendor to address.
Ultimately the vendor will have to participate in some detailed workshops to identify gaps in the system. Many vendors require some reimbursement for these workshops because they should take place at your offices over a couple of days to a week. At the end of the workshop, you and the vendor will have identified the most significant gaps. The vendor needs to give an estimate of the time and cost required to address these gaps.
Compromise
Now that you have a handle on what you want from the new system reality rears its ugly head. Reality takes the form of compromises between the new system and your business practices. Every software package enables you to continue doing business as you have for years in many areas of your operation. However, almost every package requires some changes to a few business practices. You need to confront the question: Do I change my processes to fit the software, or do I change the software to fit my processes? This calls out for a cost/benefit analysis.
Contracts
Hopefully you can begin negotiating a contract. The vendor should have a standard contract form. Be sure of what you are buying. Most sell a license to use the software. The developer seldom sells the right to change the code. The contract must include a maintenance agreement or service level agreement (SLA). The SLA often requires an annual fee. You need to be sure the SLA includes help-desk support and specific time frames for the vendor to address any issues after the software is installed and running. You do not want the vendor walking away after the system is in place. Also, the contract should cover all the details regarding how gaps will be addressed, system installation, staff training, data conversion and project management costs.
Summary
So unless you want to be like that car guy and get another five years out of the old car, eventually you have to bite the bullet and buy a new system. The rewards of a system acquisition will improve your bottom line, the staff’s quality of life and your clients’ experience.