(I generally don’t like RFPs for software because they never seem to produce responses that can be evaluated apples to apples, but I talk about RFPs in this post because people are familiar with them. What I recommend is a “Process and Requirements Document.” We’ll get to that in a later post.)
When I see a typical RFP for ERP software, it usually begins with something like, “ability to define chart of accounts,” “GAAP-compliant financial statements,” etc. Don’t get me wrong, these are important criteria. The problem is that most software packages from the bottom to the top of the market meet these requirements. An RFP needs to pay primary attention to two critical key areas: feature coverage and unusual requirements.
The Concept: Common software features are not selection criteria.
The easiest software choice is for a company that needs basic features that all ERP software has. I’ve seen companies do elaborate RFPs for general ledger and accounts payable systems. They needed to print financial statements, documents required for accounting, track accounts payable and print checks. Every system I’ve seen from QuickBooks to SAP has these features. It doesn’t matter which system the company chooses, any one will do.
Of course, no company (particularly yours) has needs this simple. But many RFPs include mostly these types of requirements. These requirements are not going to help make a decision on the right ERP system for your company. If you feel that you need to state these requirements, put them in an appendix as a checklist. Then refer to them in the selection document. So what should you focus on in the body of the RFP?
Feature Coverage: The ticket to get in the door
The first thing you need to cover with software vendors–right up front–is the general list of features or functions that you need in the software. In the old days, we might have called these “modules,” but I mean something a little different. So let’s assume that you make toothpaste (process manufacturing). You’ll need at least basic accounting (G/L, A/P, A/R, maybe P/R). You’ll need inventory, purchasing, and sales orders. These things you’ll find in most products (see section above). I would generally summarize these to “basic accounting, inventory management, sales and purchasing.” You’re also going to need some other features, I suspect. It’s these other features that you should focus on in the feature coverage section. Manufacturing recipes (BOMs), shop floor control (if needed), production reporting, work in process, MRP, scheduling, etc.
These features form the “first cut” in selecting software. If you need a feature and the ERP software you’re evaluating doesn’t have it, mark it off the list without further ado. Don’t spend time watching demos of software that doesn’t have the features you need. By the time you get to the demo stage, watching demos will get tiring. More about that later.
So let’s say that by applying your feature coverage needs, you get to a dozen packages that you think might meet your needs. What now?
Unusual Requirements (that aren’t necessarily unusual to you)
Once you weed out the packages that don’t have the feature coverage you need, you should focus on requirements that not all software packages have or that you suspect not all packages have. These generally have to do with the way you operate your business, but they can be accounting requirements. Let’s take accounting requirements first.
Example: Unusual accounting requirements.
Suppose that you have four companies. Two are in foreign companies and keep their books in Euros and Rand’s (ZAR). The other two companies are in the US and keep their books in USD. You need a monthly consolidation of these four entities. To make things a little bit more interesting, you only own 75% of two of these companies (the ZAR currency and one US company). One of the companies has commodities as assets that need to be revalued daily and entries booked in a particular way, and these entries have to be processed in a very unique way for the consolidation. That’s an unusual accounting requirement, and should be documented right up front. In effect, you’re saying to the vendor, “If you don’t have this feature, we can’t use your software.”
Example: Unusual operating requirements.
A second type of unusual requirement relates to the way your company operates. Suppose you have a small manufacturing company. Eighty percent of your revenue comes from products you manufacture and sell through distributors (manufacture to stock). For this business, you make the same products over and over. Twenty percent of your revenue comes from specialty manufacturing orders that come with engineering designs. You create the tooling for these orders, and generally manufacture these only once (manufacture to order or job shop operations). You need to keep up with the costs on a product-by-product or job-by-job basis. Right now you do that with a “job envelope,” but you want to automate this.
So is this really unusual? No, not really. It’s a typical job shop. What makes this unusual is that you also do repetitive manufacture-to-order work. And what makes this important in an RFP is that many ERP systems that have repetitive manufacturing will also say they can do job shop or manufacture to order. Can they? Yes, they can. But you may have to jump through hoops to get the information you need into or out of the system.
Using these Requirements
Once you have these, here’s how you use them. Feature coverage is your screening criteria. You don’t consider a product that doesn’t have feature coverage. We’ll talk about how to do this screening in a later post.
Unusual requirements become part of your initial requirements list to vendors and are your demo criteria. First, you’ll send an email (or letter) to the software vendor with your requirements. You’ll ask, “Does your software do this?” They’ll respond, and you’ll filter the products by looking at the responses. When you get to the point of demonstrating products, you’ll prepare a demo script. Basically, it says, “Here is the setup you’ll need. Demonstrate how this, this, and this work in your product.” The “this’es” in your email will be unusual requirements. When you see the demos, you’ll be able to compare product to product.
So now you know all my secrets…almost.