The standard ERP RFP is a two-hundred-row feature checklist sent to three vendors. Every vendor responds "Yes" to nearly every row. The CFO finds the responses indistinguishable and selects on the pricing column at the right edge. Six months into implementation, the business discovers that "Yes, our platform supports multi-entity consolidation" meant ten different things to ten different vendors.
The RFP that actually drives selection looks nothing like this. It is shorter, structured around the buyer's business, and completed by the buyer before any vendor is contacted.
Section one — business architecture summary. One to two pages on what the business does. Entity structure. Revenue model. Operating geography. Transaction volume per category. A vendor responding to a feature checklist cannot tell whether the platform fits. A vendor responding to a business architecture summary can.
Section two — current-state pain points and target outcomes, stated specifically. Not "improve reporting." Instead: produce entity-level P&L by location within five business days of month-end, replacing the current twenty-day Excel-based consolidation. The specificity is what produces evaluable vendor proposals.
Section three — integration requirements, with named systems and data flows. Salesforce. Bill.com. Avalara. The marketplace platforms. Each named system with direction of data flow and criticality. A vendor responding to "we need ERP integration capability" is responding to a question that produces no information.
Section four — implementation partner evaluation criteria, separate from platform evaluation. The platform decision and the partner decision are different decisions. Evaluating them together produces bias toward whichever vendor's partner is most polished in the sales process. Partners get asked for: engagements completed in your business model, three reference clients with comparable complexity, a named project manager, and a delivery methodology document.
Section five — five-year cost model template. Not just first-year license and implementation. Year-two through year-five license escalation. Customization renewal. Connector subscription cost. User-count growth. Internal staff capacity required to operate the platform.
The complete RFP fits on eight to twelve pages, not eighty. The shorter document forces specificity. The longer document hides it.
The reason most ERP RFPs are two-hundred-row spreadsheets is that the spreadsheet was authored by a VAR. If your RFP was authored by your implementation partner, the selection process is biased toward whatever they sell most.
Filed under
