{"id":2159,"date":"2026-08-20T08:12:31","date_gmt":"2026-08-20T08:12:31","guid":{"rendered":"https:\/\/www.scmchamps.com\/blog\/?p=2159"},"modified":"2026-09-12T13:03:22","modified_gmt":"2026-09-12T13:03:22","slug":"sap-tm-s4hana-rfp","status":"publish","type":"post","link":"https:\/\/www.scmchamps.com\/blog\/sap-tm-s4hana-rfp\/","title":{"rendered":"SAP TM S\/4HANA Implementation RFP\/RFQ: Criteria That Decide the Project Before It Starts"},"content":{"rendered":"

Five implementation partners receive the same SAP TM S\/4HANA RFP. Five proposals come back. One quotes 14 months, one quotes 26, and the gap between the highest and lowest price is more than double. All five say the same thing: yes, we can do this.<\/span><\/p>\n

At that point, most teams assume the difference sits with the partners. Usually it doesn’t. It sits in the RFP.<\/span><\/p>\n

Most SAP TM projects that go wrong were already going wrong on the day the contract was signed. The design wasn’t bad. The consultants weren’t bad. The RFP simply never asked the questions that mattered.<\/span><\/p>\n

Some things a good implementation partner can still fix later. Messy master data, a weak cutover plan, and a commercial model that needs renegotiating painfully but is survivable.<\/span><\/p>\n

This article is about the other kind.<\/span><\/p>\n

What actually decides an SAP TM project’s outcome?<\/b><\/h2>\n

The five RFP decisions that create the most implementation risk are <\/span>architecture, scope and volumes, partner capability, carrier onboarding ownership, and client-side availability.<\/b><\/p>\n

None of these can be technically unaltered after signature. But by the time they surface, the architecture is built, the budget is approved and the team is hired, so changing them has real cost, schedule and contractual consequences. This is what makes them different from the gaps you can take in delivery.<\/span><\/p>\n\n\n\n\n\n\n\n\n\n\n\n
RFP gap<\/b><\/td>\nHow recoverable is it after signing?<\/b><\/td>\n<\/tr>\n
Master data quality<\/span><\/td>\nRecoverable \u2014 ugly, but manageable<\/span><\/td>\n<\/tr>\n
Cutover approach<\/span><\/td>\nRecoverable \u2014 can be designed later<\/span><\/td>\n<\/tr>\n
Commercial model<\/span><\/td>\nPartly \u2014 renegotiable, with effort<\/span><\/td>\n<\/tr>\n
Architecture and licence position<\/span><\/td>\nVery difficult and costly<\/b><\/td>\n<\/tr>\n
Scope without volumes and modes<\/span><\/td>\nVery difficult and costly<\/b><\/td>\n<\/tr>\n
Partner capability mismatch<\/span><\/td>\nVery difficult and costly<\/b><\/td>\n<\/tr>\n
Carrier onboarding ownership<\/span><\/td>\nVery difficult and costly<\/b><\/td>\n<\/tr>\n
Client-side resource commitment<\/span><\/td>\nVery difficult and costly<\/b><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The bottom five rows are what the rest of this article covers.<\/span><\/p>\n

At SCM Champs, we’ve seen all five turn up in RFPs that looked completely professional on paper well formatted, properly governed, signed off by three committees, and still missing the questions that decided the project.<\/b><\/p>\n

Criteria 1 \u2014 Have you answered the architecture question or left it to the bidders?<\/b><\/h2>\n

If your RFP doesn’t state whether you want Transportation Management <\/span>embedded<\/b> in SAP S\/4HANA or deployed as a <\/span>separate (sidecar) system<\/b>, each bidder will assume a different answer. Your quotes will then not be comparable, and no amount of procurement analysis will make them comparable.<\/span><\/p>\n

Three decisions hide inside this one question.<\/span><\/p>\n

Embedded TM or a separate TM deployment<\/b><\/h3>\n

With <\/span>embedded TM<\/b>, transportation runs inside the same SAP S\/4HANA system as sales, purchasing and finance. The integration sits within a single SAP landscape rather than between two separate systems, which usually means lower integration effort. The trade-off is coupling: transportation follows the S\/4HANA upgrade cycle, and planning load shares a system with your financial close.<\/span><\/p>\n

A <\/span>separate TM deployment<\/b> can be relevant when transportation has its own sizing, integration or lifecycle requirements, for example, in more complex landscapes, or where multiple source systems feed transportation. The trade-off is that you now own the integration between them.<\/span><\/p>\n

Neither option is universally right. The decision depends on your landscape, release, integration needs, operational model and sizing. But leaving it open in the RFP is always wrong.<\/span><\/p>\n

Your licence position<\/b><\/h3>\n

Do not assume that the<\/span> SAP TM<\/b><\/a> functionality described in your RFP is covered by your existing entitlement. Scope items such as optimiser-based planning, charge management and settlement can carry different licensing implications depending on release and edition.<\/span><\/p>\n

Ask SAP to confirm, in writing, the licence position required for your exact release and your exact scope <\/span>before<\/b> the RFP is issued. Discovering a licensing gap after partner selection weakens the business case before configuration has even started, and nobody in the room will feel responsible for it.<\/span><\/p>\n

Advanced Shipping and Receiving, or classic delivery-based integration<\/b><\/h3>\n

If SAP EWM is in scope, this fork changes the warehouse-to-transport integration design significantly. Most buyers have never heard of it at RFP stage. Bidders who know it will scope it; bidders who don’t will scope the classic delivery-based flow. Two different projects, one RFP.<\/span><\/p>\n

The symptom:<\/b> three bids with a 2.5x price gap, and nobody in the room can explain why.<\/span><\/p>\n

What to state in your RFP:<\/b><\/p>\n