Financial institutions today buy software for a multitude of tasks: lending, operations, product development, accounting and compliance. And bankers know, in general, what they’re looking for: an effective solution at a good price.
But, of course, there’s a lot more involved in the purchase of a software system. Here, from an experienced vendor, is a checklist of helpful tips for managing the evaluation, purchase and ongoing management of a software system – although they could also be applied to any other product. Bankers might find some of these intriguing since they come, so to speak, from the “other side” of the banker/vendor relationship:
The client-vendor relationship should not change radically as it moves through its phases. You most likely expect that the sales person is not going to be the installation technician, who may not be the support person. You also have a right to expect that if, pre-sale, the product is represented as flexible and customizable – in other words, that after implementation the product is not a rigidly controlled black box. Or vice-versa. Pre-sale, the discussion is about a stable product to perform specific tasks, but after implementation there is a new release every couple of months. Predictability in the client-vendor relationship means that over time expectations for both sides will match up more closely.
Any software vendor that wants to allow prospective clients to test drive software can figure out a way to do so. Purchasing software often represents a significant financial commitment and almost always a long term commitment. In those ways it is like buying a car. Most people will not purchase a car without some kind of test drive. Buying software based on static screen snips is like buying a car from a picture on the web. Buying software based only on a demo is like only allowing the salesperson to handle the car during the test drive.
While taking software for a test drive can be much more complicated than driving a car, don’t give up on the idea too quickly. All software companies have development and test systems, and many have demo systems that sales people use. If it cannot be arranged to test drive one of those, perhaps a web meeting can be arranged with a reference user. Some software is too complex to be used without significant training or the vendor co-driving, but it is important to get a feel for that too.
Successful implementation is based on both client and vendor effectively communicating their requirements and capabilities. The objective of implementation is the same for both the client and vendor: complete a successful implementation as quickly and efficiently as possible. This is true whether it is simply running an installation program once for packaged software, a few hours of work by a technician, or a multi-month project with hundreds of tasks to do a core system conversion. Mismatched understanding of either requirements or capabilities puts even simple implementations at serious risk.
Clients should expect stable, functional software that does what it is supposed to do within expected performance standards, but should not expect perfection. All software that is functional or flexible is not 100% bug free. Clients should report issues and expect timely responses to substantive issues. Vendors should welcome all input and be prepared to provide timely and reasonable responses to substantive issues. Small issues should be kept in context, but they still have value. For example, when we fixed a spelling error in a software release an amused client took the time to tell us they had noticed the corrected spelling. They had actually been aware of the error for years, but never reported it.
Don’t force a solution to do what it was not designed to do. Both client and vendor will regret forcing a square peg into a round hole. It ruins the peg and does collateral damage to the board and hole. This warning applies equally to clients and vendors. Having a constructive client-vendor relationship during evaluation and implementation goes a long way towards avoiding this pitfall. Sometimes it crops up later as needs change. Clients and vendors should talk about the possibilities. There may be viable customizations, workarounds or add-ons. Ultimately, however, it is a mistake to force a system to do what it was not designed to do.
It’s your data; you have a right to access and use it. Over many years, it has never ceased to amaze me how many vendors make it difficult, expensive or virtually impossible for clients to access their own information. Roadblocks include: not providing read-only database access except through the licensed product; excessive interface fees; long elapsed times to create interfaces; and outright refusal. Vendors have a legitimate interest to protect copyright, trademarks and proprietary techniques. These are generally covered under license and confidentiality agreements. Vendors have no legitimate interest in preventing a client from having access to the data they are generating in the normal use of a product.
Clients and vendors have different interests, but they overlap. Clients license a system to solve one or more business needs. Unless they hired someone to develop a completely custom solution as a “Works for Hire” so it is not exclusively theirs. Vendors develop and must maintain products for many clients, but the solution as installed within a specific client’s business environment is exclusively that client’s implementation. In a successful client-vendor relationship, both sides fulfill their own business requirements while maintaining respect for what the other party needs to accomplish.
Understanding and managing the client-vendor relationship will increase the benefit and utility of your investment in software. As an added bonus, a constructive client-vendor relationship removes stress-points and overhead for those who implement and manage software solutions in your organization.
Mr. Basri is president of Mathews, N.C.-based Point Enterprises, Inc. developers of branch office management software solutions. He can be reached at [email protected].
