The Dirty Little Secret about RFQ's

RFQ's or Requests For Quotations are the bane of the accounting software industry. They take a long time to prepare, a long time to complete, and I have to wonder whether they improve the process of selecting accounting software at all.

The idea makes perfect sense:

1. You determine your needs, e.g. multi-currency, an inventory module that will handle obsolescence, a fixed asset subledger, etc.
2. You write all those needs down in the form of questions, e.g. "Will your software allow daily changes to exchange rates?"
3. You distribute the questionnaire to software consulting firms who complete it and send it back.
4. Based on their answers, you select a shortlist of consulting firms to interview and demo their product.

Simple, right? No! The dirty little secret is that accounting software vendors know that they can never answer "no" to a question on an RFQ or they will never be selected for the interview, so they bend over backwards to answer "yes" to all the questions. Strictly speaking, they're not wrong, because software can be changed or work arounds can be developed, but the result is not a true picture of what the software can do.

So, rather than using the shotgun approach with a huge questionnaire, determine your top ten features and grill the vendors about how their system approaches them. Pick features that are operational (e.g. how Sales Orders are handled) or unique to your industry. Secondly, spend a lot of time following up on the references supplied by the consulting firms (you DID ask for references, didn't you?) In my experience, other users have been happy to talk to me about their systems, even taking the time to invite me over to see it in person. Then you can ask them about the vendor as well.

Happy Hunting!

Organizing Your Data

When implementing an accounting system, how do you determine how to identify your Vendors, Customers, Employees, Inventory Items, Fixed Assets, etc. etc. etc?

That is a subject that requires some thought. An important question to ask is whether the identifiers need to have any "intelligence" built into them. An example of an intelligent identifier would be using the vendor's main telephone number as the Vendor ID in the accounting system. Another example would be to use a variation of the company's name (e.g. ABCCAN for ABC Canada Inc.) Intelligent identifiers make intuitive sense, but they suffer from a common problem: what if the underlying information changes? You need to plan what to do if the company moves, gets acquired or changes its name. Some systems let you change the identifier retroactively. Others, particularly older systems, do not.

Employees are a special case. Traditionally, many companies used the employee's Social Insurance Number (SIN) as an identifier. SIN's have been ruled as private information under The Personal Information Protection and Electronic Documents Act (PIPEDA), so you cannot use them as identifiers. Even using the last four digits of the SIN has been ruled as private.

But let me put another idea on the table. When I talk to computer developers, they ask why is there ANY intelligence in indentifiers? Modern systems can sort and filter based on any field. You don't have to use a telephone number as a Vendor ID since you can search your vendor file by telephone number at any time. In that case your Vendor ID could be "VE" followed by a five digit serial number that starts at 00001 and goes up. The two character prefix is handy so you can tell at a glance whether it is a Vendor or a Customer (etc.) that you are talking about.