Writing a Request for Proposal for Enterprise Resource Planning

Choosing a new business management platform is one of the most expensive decisions a manufacturer will make in a decade. The document that frames that decision is the request for proposal, and the quality of the procurement document usually determines the quality of the software you end up living with. Australian operations running multi-site facilities from Perth to Brisbane cannot afford an unfocused briefing that lets vendors fill the gaps with assumptions.

A disciplined procurement document turns strategic intent into a structured conversation with the supplier market. It forces the buying team to be honest about scope, surfaces internal disagreement early, and gives every responding vendor the same picture of the business. The exercise is often more valuable than the responses themselves, because it exposes the operational debt that has quietly built up across finance, warehouse, production planning, and HR.

Build the business case before you write a single line

The most common reason software procurements run late and over budget is that the business case was never properly defined. A written statement of intent, signed off by the leadership team, sets the guardrails for every requirement that follows. Without it, the document expands into a wish list pulled together by every department that has ever been frustrated by the current system.

Anchor the case in operational metrics that already matter to the board: days sales outstanding, schedule adherence, inventory turns, and labour utilisation. For an Australian manufacturer competing against imports from larger Asian operations, these metrics translate directly into margin protection. Tie the platform choice to a small number of outcomes, such as reducing month-end close from ten days to five, or replacing three disconnected spreadsheets in the despatch bay with a single source of truth.

Assemble the team that will live with the software

Writing the brief is a cross-functional project, not a procurement exercise handed to finance or IT alone. The steering group should include an executive sponsor, a finance lead, a warehouse or production manager, an IT representative, an HR or payroll specialist, and a project manager who can hold the timeline together. In a typical mid-market Australian manufacturer with between eighty and three hundred staff, that is often the entire leadership group, which is a useful reality check on scope.

Give each member ownership of a section of the document. Finance writes the commercial and reporting requirements. The warehouse lead documents receiving, pick, pack, and dispatch flows. The HR owner covers payroll, rostering, and the Single Touch Payroll reporting obligations that flow to the ATO each pay run. When the document is written by the people who will use it, vendor responses are evaluated against lived experience rather than abstract feature lists.

Map current processes and capture the real pain

Before any vendor sees the brief, the buying team needs to map the processes the new platform must support. Walk the factory floor, ride along on a forklift route in the Brisbane warehouse, sit with the accounts payable clerk during a three-way match, and time how long it takes to raise a purchase order. The goal is to record what actually happens, including the workarounds, the shadow spreadsheets, and the manual rekeying between systems.

Document the pain points honestly. If the warehouse team has been re-entering data from a paper traveller into the legacy system for fifteen years, say so. If the finance team closes the books using a complex set of journal adjustments because the chart of accounts was never cleaned up after a 2017 acquisition, write that down too. Vendors who can address those specific problems will offer stronger responses than those who simply promise transformation.

Structure the procurement document itself

A solid request for proposal follows a predictable pattern: company overview, scope of supply, functional requirements, technical and integration requirements, commercial terms, contractual terms, and evaluation criteria. Each section should be detailed enough to constrain vendor creativity in the right places, while leaving room for them to propose alternatives where the market is genuinely innovative.

Functional requirements are best written as use cases rather than feature checklists. Instead of asking whether the system supports multi-currency, describe a scenario in which a Melbourne head office invoices a New Zealand customer in AUD, books the receivable against a forward contract, and reports the exposure to the treasury team. Technical sections should cover hosting model, data residency, API strategy, cybersecurity posture, and expectations under the Australian Cyber Security Centre Essential Eight maturity model. Weighting should be explicit, for example forty per cent functional fit, twenty-five per cent technical, twenty per cent commercial and total cost of ownership, and fifteen per cent vendor capability and references.

Address Australian commercial and compliance realities

Procurement teams often lift templates from overseas and forget the local overlay. Australian vendors and global suppliers selling into Australia expect to be asked about their Australian Business Number, their Goods and Services Tax registration, and whether pricing is in Australian dollars inclusive or exclusive of the ten per cent GST. Payment terms are typically thirty days end of month, and many local suppliers will not accept Net Sixty.

Compliance questions belong in the document, not buried in a side email. Ask how the system supports reporting under the Modern Slavery Act, how it handles notifiable data breaches under the Privacy Act, and how it integrates with Single Touch Payroll. Confirm data residency and whether backups are held onshore. For manufacturers in the resources supply chain or those handling defence work out of Osborne or Henderson, ask about export controls and the Essential Eight maturity level the vendor can evidence for their own environment.

Set the timeline and engage the vendor market properly

A brief that gives suppliers two weeks over the Christmas shutdown in Sydney will not produce serious responses. Build a timeline that respects school holidays in your state, the summer break that is common across Australian factories, and the lead time vendors need to put their best team on the response. A realistic cycle from issue to decision is eight to twelve weeks, with another four to six weeks for structured demonstrations and a pilot.

Engage the market broadly but realistically. The Australian enterprise software landscape includes local platforms such as Pronto, Attache, and MYOB Advanced alongside global names like Microsoft Dynamics 365, SAP Business One, Oracle NetSuite, Infor, and Epicor. Each has strengths in different parts of the value chain, from food and beverage batch traceability in Victoria to heavy engineering and project accounting in Western Australia. Shortlist four to six vendors, allow each a discovery call, and then issue the final document.

Evaluate responses and run a structured proof of concept

Scoring should follow the weighting published in the document, with at least three evaluators scoring independently before discussing. Shortlist three vendors for a scripted demonstration, where each presenter answers the same scenario with the same data set. Ask for client references in Australia, ideally from a business of similar size and sector, and pick up the phone rather than relying on the written reference.

Before signing, run a paid pilot on a contained scope, such as one warehouse, one product family, or one sales entity. Define exit criteria up front, including cycle time improvements, data migration accuracy, and user acceptance thresholds. The pilot is the last chance to validate the promises made in the proposal, and it is far cheaper to walk away after eight weeks than after eighteen months of implementation.

A well-written request for proposal is really a project plan in disguise. Treat it as a working document that the steering group reviews weekly, update it as the team's understanding matures, and use the discipline of the writing process to surface the operational questions you would otherwise discover during cutover. Australian manufacturers who invest that effort before signing tend to be the ones who hit their go-live dates on the first try.