SAP TM S/4HANA Implementation RFP/RFQ: Criteria That Decide the Project Before It Starts

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.

At that point, most teams assume the difference sits with the partners. Usually it doesn’t. It sits in the RFP.

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.

Some things a good implementation partner can still fix later. Messy master data, a weak cutover plan, a commercial model that needs renegotiating painful, but survivable.

This article is about the other kind.

What actually decides an SAP TM project’s outcome?

The five RFP decisions that create the most implementation risk are architecture, scope and volumes, partner capability, carrier onboarding ownership, and client-side availability.

None of these are technically impossible to change after signature. But by the time they surface, the architecture is built, the budget is approved and the team is hired  so changing them carries real cost, schedule and contractual consequences. That is what separates them from the gaps you can absorb during delivery.

The bottom five rows are what the rest of this article covers.

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.

Criteria 1 — Have you answered the architecture question, or left it to the bidders?

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

Three decisions hide inside this one question.

Embedded TM or a separate TM deployment

With embedded TM, 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.

A separate TM deployment 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.

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.

Your licence position

Do not assume that the SAP TM functionality described in your RFP is covered by your existing entitlement. Scope items such as optimizer-based planning, charge management and settlement can carry different licensing implications depending on release and edition.

Ask SAP to confirm, in writing, the licence position required for your exact release and your exact scope before 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.

Advanced Shipping and Receiving, or classic delivery-based integration

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.

The symptom: three bids with a 2.5x price gap, and nobody in the room can explain why.

What to state in your RFP:

• The deployment option you have selected  or a clear request for each bidder to recommend one, with reasoning and cost impact for both.
• Your confirmed licence position, plus a requirement that bidders flag any scope item needing entitlement beyond it.
• If SAP EWM is in scope, whether Advanced Shipping and Receiving is in or out.

Criteria 2 — Does your scope describe transport reality, or just module names?

“Transportation planning, freight order management, charge management, settlement” is not a scope. It’s a table of contents. No partner can build an honest estimate from it, which means every number you receive will be a guess with a margin wrapped around it.

Your scope section needs to answer these in the RFP itself:

• Modes. FTL, LTL, parcel, ocean, air, rail, intermodal which are in, and which are explicitly out?
• Direction. Inbound, outbound, stock transfer orders, returns.
• Fleet model. Own fleet, carrier-based, or both? Is driver and vehicle scheduling in scope?
• Volumes. Freight units per day, average items per freight unit, peak-to-average ratio, planning horizon.
• Planning complexity. Time windows, incompatibilities, capacity rules, consolidation logic, number of planning strategies. This matters as much as volume: 4,000 freight units with hard constraints is a harder planning problem than 10,000 simple ones.
• Geography. Countries in scope, and whether the transport process is genuinely the same in each or the same only on the slide.
• Special handling. Dangerous goods, temperature control, customs via SAP GTS, where relevant.

Volume and constraint density together shape the design of cost and planning profiles, optimizer behaviour and run times. Without them, nobody can size the planning work.

The symptom: with no volumes, bidders either pad the price or absorb the risk  and you pay for it later as change requests.

Criteria 3 — Are you testing SAP TM capability, or just SAP S/4HANA credentials?

A partner with 40 SAP S/4HANA projects behind them may have delivered very few genuine SAP TM optimizer builds. These are different skills, held by different people, and most RFP evaluation sheets never separate them.

The optimizer is where SAP TM projects quietly fail

VSR (Vehicle Scheduling and Routing) optimization is not configuration. It’s cost profiles, planning profiles, constraint sets, incompatibility settings, capacity and time windows, planning horizons then tuning all of it against real transport data until the results make sense to people who have been planning loads by hand for fifteen years.

The failure has a pattern. The system goes live. It proposes loads the planners think are wrong. The planners start overriding manually first the odd one, then most of them. Within a few months, an expensive transportation management system is being used as a freight-order printer, and the savings in the business case never appear.

Nobody calls this a failed project. They call it an adoption issue.

Charge management and settlement are often underestimated

Transportation Charge Management is not a small module bolted on at the end. It covers rate tables, scales, calculation sheets, charge types, surcharges, accessorials, multi-currency handling, agreement validity, accruals, freight settlement documents, self-billing and invoice verification with tolerances and dispute handling.

And then there’s the part no RFP mentions: today, those rates often live across hundreds of spreadsheets, in inconsistent formats, with side agreements that were never written down anywhere.

The symptom: when freight accruals don’t reconcile in FI, finance stops trusting the system  and credibility is lost in hypercare, not at go-live.

What to state in your RFP:

• Ask for optimizer references by project, mode profile and volume band  not a slide of company logos.
• Ask bidders to walk through one of your real rate structures during orals, not a prepared demo table.
• Ask which named consultant will own planning design, and which will own charge management design. They are rarely the same person, and both need to be good.

Criteria 4 — Who owns carrier onboarding?

In most RFPs, nobody. It sits in the gap between “customer responsibility” and “partner responsibility” until the week it lands on the critical path.

Do the arithmetic before you publish. Sixty carriers, three message types each typically tendering, status and invoicing  multiplied by how quickly each carrier actually responds to your emails. In practice this means EDI-based messaging in North America, comparable EDIFACT messaging in Europe, or onboarding through SAP Business Network for Logistics.

Then add the mid-sized regional carrier with no EDI capability at all, who takes loads by phone today and has no intention of changing. Multiply by however many of those you have.

That is a project inside your project and it isn’t really a technical project. It’s a supplier management project with a technical component, which is exactly why IT teams underestimate it.

The integration points RFPs also routinely forget: geocoding and map or routing services, toll and transit-time engines, telematics for tracking, customs through SAP GTS, freight audit and pay, and whatever visibility platform the business already uses.

What to state in your RFP:

• The carrier count, split into EDI-capable and not.
• The message types required per carrier tier.
• The named owner of carrier communication — and who chases a carrier that has gone silent for three weeks.
• Whether onboarding is priced per carrier or as a fixed pool, so commercial exposure is visible on both sides.

Criteria 5 — Have you written down your own obligations?

Most RFPs demand named partner resources, CVs, rate cards and replacement clauses — then say nothing at all about the buyer’s own people.

SAP TM design depends on the people who currently do the work: transport planners, dispatchers, freight settlement clerks. These are not project people. They are moving real trucks today, and they will still be moving them throughout your Explore phase.

Fit-to-standard workshops need them in the room. Test cycles need them. Training needs them. When nobody has arranged backfill, the pattern is predictable — workshops get rescheduled, design decisions get taken by people without operational authority, and testing gets thin because the only person who understands the real rate exceptions is on the phone with a carrier.

Then the timeline slips, and it looks like the partner’s fault.

The symptom: a common contributor to missed go-live dates, and almost completely invisible in a standard RFP.

What to state in your RFP:

• Named client-side process owners for planning, execution and settlement.
• The percentage of their time committed, phase by phase across SAP Activate.
• Confirmed backfill arrangements for the operational roles you’re pulling in.
• Who has authority to sign off a design decision, and how quickly.

In our experience, the projects that run smoothly are the ones where this section existed in the RFP — not the ones where it was promised verbally during orals.

How to score the bids so you don’t pick the wrong partner

Don’t let price dominate the scorecard. On a high-complexity SAP TM programme, capability, solution fit, delivery team and stated assumptions should carry substantial weight alongside commercials. Agree the weighting before bids arrive, not after you’ve seen the numbers.

Match references to your reality. Chemicals with dangerous goods is not retail parcel is not automotive milk-runs. Ask for references with your modes, your volume band and your planning complexity — then actually call them.

Demand assumptions in writing. This may be the highest-value question in the whole RFP: don’t only ask what is included, ask what the partner assumes you will provide. “Customer provides clean master data.” “Integration development excluded.” “Customer provides testing resources.” Each of those sentences can move the real project cost significantly, and each is usually buried on page 41.

Demo on your data. A sandbox with five shipments proves nothing. Give shortlisted bidders a small extract of real locations, lanes and rates, and watch what they do with it.

Lock the named team. The A-team presents at orals; the B-team often delivers. Name key roles in the contract, with notice periods and approval rights over any replacement.

Match the commercial model to scope maturity. Fixed price on a vague scope invites a change-request war. A phased model often works better: time-and-materials or capped for Explore and fit-to-standard, fixed price for Realize once the design is frozen and signed.

A quick checklist before you publish your SAP TM RFP

1. Have you stated whether TM will be embedded in SAP S/4HANA or deployed separately?
2. Have you confirmed your licence position with SAP in writing, for your exact release and scope?
3. If SAP EWM is in scope, have you stated whether Advanced Shipping and Receiving is in or out?
4. Have you listed the transport modes in scope, and the ones explicitly excluded?
5. Have you given daily freight unit volumes and your peak-to-average ratio?
6. Have you described your planning constraints, not just your volumes?
7. Have you stated own fleet, 3PL or both — and whether driver scheduling is included?
8. Have you listed every integration point with a named owner beside each one?
9. Have you given the carrier count, split into EDI-capable and not?
10. Have you named who chases a carrier that stops responding?
11. Have you named your own process owners for planning, execution and settlement?
12. Have you confirmed backfill for the operational staff you’re pulling into workshops?
13. Have you asked each bidder to identify their assumptions, exclusions and likely change-request triggers?

If more than three of these are unanswered, the RFP isn’t ready to go out.

Frequently asked questions

What is the difference between embedded TM and sidecar TM in SAP S/4HANA? Embedded TM runs inside the same SAP S/4HANA system as sales, purchasing and finance, so integration stays within one landscape. A separate (sidecar) deployment runs as its own system with independent sizing and lifecycle, which can suit complex landscapes or multiple source systems — but you then own the integration between them.

Do we need a full SAP TM licence, or is Basic Shipping enough? Don’t assume your existing entitlement covers the scope in your RFP. Licensing implications for planning, charge management and settlement can vary by release and edition. Ask SAP to confirm the required licence position in writing for your exact release and scope before the RFP is issued.

How long does an SAP TM S/4HANA implementation usually take? It depends far more on scope than on company size. A single-country, single-mode rollout with straightforward charge management runs considerably faster than a multi-country, multi-mode programme with optimizer tuning, EWM integration and large-scale carrier onboarding. Any timeline quoted without volumes and modes is a guess.

What should an SAP TM implementation RFP include at minimum? The deployment option, your confirmed licence position, modes and directions in scope, daily freight unit volumes with peak ratio, planning constraints, a full integration list with named owners, carrier counts and message types, your named client-side team with backfill confirmed, and a requirement for bidders to state assumptions in writing.

How should you compare SAP TM implementation partner proposals? Compare on the same eight dimensions for every bidder: scope in and out, architecture assumptions, priced interfaces, carrier onboarding ownership, named delivery resources, timeline assumptions, stated assumptions and exclusions, and what is fixed versus variable commercially. Comparing on price alone compares different projects.

What should an SAP TM RFP say about carrier onboarding? State the total carrier count split by EDI capability, the message types required per carrier tier — typically tendering, status and invoicing, such as EDI 204/214/210 or EDIFACT IFTMIN/IFTSTA/INVOIC — the named owner on each side, the escalation route for unresponsive carriers, and whether onboarding is priced per carrier or as a pool.

The one thing worth remembering

A good implementation partner can rescue dirty master data. They can rebuild a weak cutover plan. They can absorb a difficult commercial model and still deliver.

What they can’t do cheaply is undo an architecture chosen without the facts, an estimate built on missing volumes, a capability gap in optimizer or settlement design, carrier onboarding that nobody owned, or a client team that was never actually available. Those decisions are all made before the project starts — which is precisely why they decide it.

How SCM Champs Helps Before You Issue the RFP

Almost everything in this article has to be decided before an implementation partner is formally involved. That’s an awkward moment for most teams: the decisions are technical, the consequences are commercial, and the people best placed to advise you are often the same people who will later bid for the work.

SCM Champs works with supply chain and IT teams at exactly that stage. We review the inputs that shape the bids — architecture and licence position, scope and volumes, planning complexity, the integration landscape, carrier onboarding ownership, the capability you’re actually testing for, your own side’s responsibilities, and where the commercial exposure sits.

The aim isn’t to write the RFP for you. It’s to make the requirements clear before you ask anyone to price them, so hidden assumptions surface early and the proposals you receive are genuinely comparable.

Preparing an SAP TM S/4HANA RFP? An independent review before it goes to market is a short exercise — and the last point at which anything can still be changed cheaply.