RFPs: what implementation teams wish their clients knew

What happened

An SAP News Center article from 24 September 2026 describes, from a systems integrator’s point of view, what separates a good RFP for enterprise software from a bad one; it refers to marketing and customer experience solutions and names as a recent trend holding short demos and conversations first and writing the detailed requirements catalogue only afterwards.

Who is affected

The article is not about ERP implementations. But every programme lead choosing an implementation partner for an S/4HANA transformation or an SAP TM implementation knows the pattern behind it: the RFP is meant to find a vendor, describe the problem and produce a reliable plan – and surprisingly often ends without a decision. So it concerns programme leadership, procurement and the business department that has to formulate the questions.

What to do

The article names three things a client should have ready before starting: its own key metrics, its expectations of service commitments and a rough idea of the budget. For an SAP programme we would add a fourth: the decision on which processes are to run in the standard and where the company deliberately deviates. Without that prior decision you compare offers that price different undertakings. It is also worth calculating the timeline backwards from the desired go-live and leaving room for an open conversation in the procedure – a question round after the written answers, or a shortlist with a demo on your own process.

Our assessment

We think the observation is right that very long question catalogues lead to answers nobody reads any more; the article sharpens this to RFPs written with AI, answered with AI and summarised with AI. A few questions that only the company itself can ask in that way say more about a vendor than a hundred general ones. We see the approach of putting the demo before the requirements document with one reservation for large SAP programmes: it helps to see early whether a partner understands the business, but it does not replace the written definition of scope and responsibility against which later change requests are measured. In our view the quality of a selection is decided less in the document than before it – by whether business and IT agree on what they are actually tendering.