Writing the ERP RFP

The RFP is out. After months of requirements gathering, stakeholder interviews, and process documentation, we've sent our formal Request for Proposal to four ERP vendors. Here's what I learned about writing an RFP that actually gets useful responses.

The Purpose of an RFP

Most RFPs fail because they're written for the wrong purpose. They're either legal CYA documents (so long that nobody reads them carefully) or fishing expeditions (so vague that every vendor says they can do everything). Neither produces useful vendor differentiation.

Our RFP had three goals: First, communicate our specific requirements clearly enough that vendors can self-assess fit. Second, create a structured framework for comparing responses across vendors. Third, establish contractual expectations that flow into the final agreement.

The Structure That Worked

Section 1: Company overview and project context. Who we are, why we're doing this, what the current state looks like. Vendors need context to provide relevant responses.

Section 2: Functional requirements by business area. Finance, operations, warehouse, sales, purchasing. Each requirement with a priority level (must-have, should-have, nice-to-have) and space for vendor response (native, configurable, custom development, not supported).

Section 3: Technical requirements. Integration capabilities, security expectations, deployment model, performance requirements. Our integration with BFC Dakota, Adobe Commerce, Shopify Plus, and Paycom got detailed subsections.

Section 4: Demonstration scenarios. The same scripted scenarios we've been using for demos, now formalized in the RFP so vendors know exactly what we'll ask them to show.

Section 5: Pricing structure. License model, implementation estimate, annual maintenance, and a total-cost-of-ownership model that vendors must complete using our assumptions.

Section 6: Company viability. References, financial stability, industry experience, support structure. We're betting our business on this platform - the vendor's staying power matters.

What We Learned

Responses came back with interesting variations. The vendors who know food distribution (Aspen Canopy, notably) provided detailed responses showing they understood the nuances. The more general platforms (D365, NetSuite) provided thorough responses but required more follow-up questions about food-specific scenarios.

The pricing section revealed important differences in commercial models. License costs varied by 40% across vendors. But implementation estimates varied by over 100%. Total cost of ownership analysis shifted my assessment of relative value significantly.

The reference section was illuminating. One vendor couldn't provide references in food distribution, which tells me something about their actual experience in our vertical. Another provided references but with notable limitations on what we could discuss with them.

Next Steps

We're scoring responses now using the weighted criteria we established earlier. Then final vendor selection by end of May, followed by contract negotiation. The timeline remains aggressive but achievable.