Sådan skriver du en TMS-udbudsskrivelse: vores erfaringer [+ 5 gratis skabeloner]

Vi besvarer transportstyringssystem-udbud (Request for Proposal) hver uge. Nogle er en fornøjelse at arbejde med. Andre er en lektion i, hvad man ikke bør gøre.

Denne artikel er, hvad jeg ville bygge, hvis jeg skulle gennemføre en TMS-udvælgelsesproces fra bunden i dag. Den bygger på de udbudsskrivelser, vi har besvaret, de mønstre, der går igen på tværs af virksomheder og brancher, hvad de fleste indeholder – og hvilke fejl vi ser igen og igen.

Er du indkøbsspecialist, vil meget af dette føles velkendt. Forhåbentlig sparer det dig for mindst én unødvendig afklaringsrunde.

Hvad er en TMS-udbudsskrivelse?

En TMS-udbudsskrivelse (Request for Proposal) er et struktureret dokument, du sender til leverandører af transportstyringssystemer. Det beskriver din logistikdrift og beder hver leverandør om at foreslå, hvordan deres system vil håndtere den – ud fra de samme krav. Hele pointen er sammenlignelighed. Samme spørgsmål, samme format, samme kontekst, så det, der kommer tilbage, kan stilles op side om side i stedet for at blive læst som fem separate salgspræsentationer.

Du har ikke altid brug for en. En udbudsskrivelse er sin møje værd, når beslutningen er kompleks, eller når du skal kunne forsvare den over for andre internt. Er din logistikdrift enkel, er en produktdemo og en snak med et par leverandører som regel tilstrækkeligt.

Har du egentlig brug for at gennemføre et TMS-udbud?

At tage fejl her er den dyreste fejl i hele TMS-udvælgelsesprocessen. Afklar dette, inden du gør noget som helst andet.

Det handler om, hvor kompleks din logistik er – ikke om, hvor stor din virksomhed er.

Gennemfør et struktureret TMS-udbud, hvis du afsender fra flere lokationer, bruger flere transportformer og har brug for, at systemet kobler sig til dit ERP. Det er i de situationer, du har brug for at stille alle leverandører op side om side, så intet vigtigt glider igennem. Transportører forbindes på meget forskellige måder. Én kalder det "native", den næste ruter det stille og roligt igennem en tredjepart. I en løs proces opdager du det ikke, før du har skrevet under. Og så er det for sent.

Spring det formelle udbud over, hvis du driver én lokation med et håndfuld transportører og allerede ved, hvad du har brug for. Hvorfor? Fordi du placerer dig selv i enterprise-prisniveauet, i det øjeblik du igangsætter et udbud. 2-3 gode demoer med præcise spørgsmål giver dig ofte et bedre system, billigere og hurtigere. Fortæl de 2-3 leverandører, hvad du sender, og hvad du forsøger at løse – og bed dem vise det i deres live-system. Du ved det inden for en time. Og sender du primært pakker frem for paller eller fragt, behøver du måske slet ikke et fuldt TMS – software til forsendelse med flere transportører er en anden og lettere kategori, der er bygget til netop det.

Vær derfor ærlig over for dig selv om, hvad du foretrækker, inden du begynder. At gennemføre et udbud, du ikke havde brug for, er den langsommeste og dyreste måde at købe et TMS på.

At gennemføre et udbud, du ikke havde brug for, er den langsommeste og dyreste måde at købe et TMS på.

En advarsel mere, hvis du alligevel vælger det fulde udbudsforløb. En proces fyldt med styringsformuleringer, metoderammer og krav om fastpris tager uger at besvare, og de leverandører, der kan absorbere den administrative byrde, er typisk de store, etablerede aktører. Så hvis en slankere og mere moderne platform reelt ville tjene dig bedre, kan en alt for bureaukratisk proces stille og roligt filtrere dem fra, inden du overhovedet ser en demo.

Målet er at finde den rigtige løsning for dig. Tilrettelæg processen ud fra det – ikke ud fra at styre processen i sig selv.

TMS-udbudsprocessen i 9 trin

Et TMS-valg behøver ikke være kompliceret. Men det kræver en klar rækkefølge. Spring trin over, og du betaler for det senere – typisk under implementeringen, når antagelser, der burde være afklaret tidligt, bliver til dyre overraskelser.

Gennemføres det ordentligt, tager hele forløbet 8 til 12 uger. Mindre ved et enkelt og afgrænset scope, og det behøver sjældent mere.

Her er den rækkefølge, der virker:

1. Markedsscanning. Inden du skriver et eneste krav, brug tid på at forstå, hvad der findes derude. TMS-markedet har bevæget sig meget de seneste fem år: der er gode enterprise-platforme, gode mid-market-platforme og genuint kompetente moderne SaaS-løsninger til transportstyring, som ikke eksisterede for fem år siden. Byg en langliste med 5-8 TMS-leverandører, der er værd at kontakte.
2. NDA. Send den tidligt. Du vil dele driftsdata som volumener, transportørnavne og interne systemdetaljer, og en underskrevet fortrolighedsaftale, inden udbudsskrivelsen sendes ud, er standardpraksis, der beskytter begge parter.
3. RFI (valgfrit). Et kort Request for Information giver mening, hvis din langliste er bred, og du vil filtrere, inden du investerer i et fuldt udbudsforløb. Hold det til én side: virksomhedsbaggrund, centrale kompetencer, omtrentligt prisniveau. Nok til at shortliste uden at bede leverandørerne om at skrive afhandlinger.
4. Udbudsskrivelse. Hoveddokumentet. Det giver alle leverandører det, de har brug for, for at kunne give et præcist tilbud. Mere om dette i næste kapitel.
5. Spørgsmålsvindue. Inkluder altid et. Leverandørerne vil have spørgsmål, og svarene forbedrer ofte hvert eneste tilbud, du modtager. Kør det skriftligt, og del alle spørgsmål og svar med alle leverandører samtidigt. Det holder processen ren og sammenlignelig.
6. Shortliste og præsentationer. Scorer de skriftlige tilbud, og inviter derefter 2-3 leverandører til at præsentere. En præsentation bør indeholde en live gennemgang af systemet baseret på dine faktiske use cases – ikke en generisk demo. Kan en leverandør ikke vise dit scenarie i deres system, er det i sig selv nyttig information.
7. Anden runde (om nødvendigt). Ved en kompleks beslutning er en dybere session med fokus på specifikke huller – sikkerhed, integration, kommercielle vilkår – tiden værd. Planlæg den ikke, medmindre du har reelle ubesvarede spørgsmål.
8. Beslutning og kontrakt. Bliv enige internt, inden du forhandler. Kend dine ufravigelige krav, dine acceptable kompromiser og dine grænser.
9. Onboarding. Det slutter ikke ved underskriften. De bedste udbudsresultater har en onboardingplan aftalt inden kontrakten underskrives.

TMS-udbudstidsplan, du kan kopiere

Omtrentlig varighed efter scope:

• Enkelt, afgrænset lokation: 6 til 8 uger (du behøver måske ikke et fuldt udbud).
• Flere lokationer + ERP-integration: 8 til 12 uger.
• Global, multi-enhed, kompleks integration: 12 til 20 uger, sandsynligvis med to præsentationsrunder.

Download tidsplansskabelonen (.docx)

Hvad skal din TMS-udbudsskrivelse indeholde?

Udbudsskrivelsen er dit vigtigste redskab i hele processen. En god udbudsskrivelse gør det meste af evalueringsarbejdet for dig – så hold den fokuseret. En stram udbudsskrivelse på 10 sider slår en på 30 sider, der forsøger at dække alt.

1. Følgebrev og målsætning

Én side. Hvem du er, hvad du søger, og hvorfor nu. Hold det faktabaseret. Leverandørerne har ikke brug for en visionserklæring – de har brug for at forstå dit driftsmæssige problem.

2. Tidsplan

En klar tidsplan med reelle datoer: udsendelse af udbudsskrivelse, frist for spørgsmål, indsendelse, præsentationsvindue, beslutning. Leverandørerne planlægger deres svarsats ud fra dette. Vage tidsplaner giver dig vage tilbud.

3. Virksomheds- og driftsmæssig baggrund

Her fejler de fleste udbudsskrivelser, og det er forskellen på sammenlignelige tilbud og en afklaringsrunde. Beskriv ikke blot din virksomhed – beskriv din logistikdrift. Hvor mange lokationer. Hvor mange juridiske enheder. Hvilke transportformer (pakke, LTL, FTL, luft, sø, jernbane). Hvilke regioner. Omtrentlige volumener. Nuværende systemer. Hvad "godt" ser ud som varierer også fra branche til branche – kravene for producenter inden for elektronik, maskiner, kemi eller tryk og emballage er ikke de samme. Det er den kontekst, leverandørerne har brug for for at kunne scope deres tilbud præcist. Giver du ikke nok detaljer her, bruger du to uger på at besvare afklaringsspørgsmål, der kunne have været undgået helt. Dette afsnit får sit eget kapitel nedenfor.

4. Funktionskrav

En tabel over hvad systemet skal kunne, prioriteret efter vigtighed: must-have / should-have / nice-to-have (Excel er fint). Bed leverandørerne besvare hvert krav med deres dækningsniveau: a) native, b) tredjepart, c) tilpasning eller d) ikke understøttet. Det er det, der gør tilbuddene sammenlignelige. Mere om, hvordan du bygger denne liste, længere nede.

5. Evalueringskriterier

Fortæl leverandørerne hvordan du vil træffe beslutningen: funktionalitet, pris, implementeringstilgang, referencer, sikkerhed, team. Del vægtningen, hvis du er villig til det. Jo mere transparent du er, desto bedre tilbud får du.

6. Prismodel

Bed om en fuld specifikation: abonnement, implementering, transaktionsgebyrer, support og alt andet. Bed om en eksempelfaktura, hvis muligt. Prisstrukturer varierer meget mellem leverandørerne, og de skjulte omkostninger har en tendens til at dukke op sent. Forsøg at afdække dem tidligt.

7. Svarformat

Fortæl leverandørerne præcis, hvordan du ønsker tilbuddet struktureret, og kræv brug af dine skabeloner, hvis du stiller dem til rådighed. Sammenlignelige tilbud sparer dig dage under evalueringen, og formatet er helt og holdent i din kontrol.

Download skabelonen til udbudsskrivelsen og start med den fulde struktur ovenfor:

Download skabelonen til udbudsskrivelsen (.docx)

Den driftsmæssige information, de fleste TMS-udbudsskrivelser udelader – og hvorfor det er den vigtigste

Dette er det kapitel, jeg ønsker, at enhver forfatter af en TMS-udbudsskrivelse ville læse først.

Vi besvarer mange TMS-udbud. Næsten hvert eneste tilbud, vi skriver, kræver en afklaringsrunde – og det skyldes sjældent, at kravene var uklare. Det skyldes, at den driftsmæssige kontekst manglede: volumener, lokationsstruktur, transportørbillede, nuværende systemer.

De udbudsskrivelser, der krævede en fuld afklaringsrunde, har næsten altid ét til fælles:

Vi har set virksomheder bruge uger på at udforme evalueringskriterier og kravlister og derefter sende en udbudsskrivelse, der ikke nævner hvor mange forsendelser de behandler om måneden.

Uden den information gætter leverandørerne. Og når de gætter, kommer tilbuddene tilbage som generiske svar, priserne er ikke endelige, og der er intet solidt at sammenligne.

En global producent med 10 lagre og SAP har brug for et helt andet tilbud end en enkelt-lokations-distributør, der kører sin logistik på regneark. Kan en leverandør ikke se forskel på de to, sætter de sig selv i sikkerhed – og du ender med tilbud, der ikke forpligter sig til noget.

Løsningen tager en eftermiddag. Besvar disse ti spørgsmål i udbudsskrivelsen, inden den sendes ud.

1. Organisation og scope. Hvor mange juridiske enheder og lokationer er i scope? Er udrulningen parallel eller faseopdelt? Hvor selvstændigt opererer lokationerne – separate transportørkontrakter, separate teams?
2. Forsendelsesvolumener. Månedlige og daglige forsendelsesantal pr. lokation, gennemsnit og spidsbelastning. Eventuel sæsonvariation. Fordeling mellem indgående og udgående.
3. Fordeling på transportformer. Hvilken andel er pakke, LTL, FTL, luft, sø? Hvilke transportformer vokser? Hvilke er driftsmæssigt mest kritiske?
4. Transportørbillede. Hvor mange transportører pr. lokation og pr. transportform? Delt på tværs af lokationer eller styret lokalt? Er der strategiske transportører, der skal prioriteres, eller kundeudpegede transportører, du ikke kan ændre?
5. Geografi og handelsruter. Hvilke regioner er i scope? Hvilke ruter er vigtigst: indenlandske, grænseoverskridende, interkontinentale? Centrale havne eller logistikhubs?
6. Nuværende situation. Hvordan planlægges, bestilles og spores forsendelser i dag? I ERP, regneark, transportørportaler, e-mail? Hvad er de største smertepunkter i den nuværende proces?
7. Finansiel opsætning. Hvem betaler for transport – én enhed eller flere? Er der tredjeparts- eller kundekontonumre? Hvordan registreres og valideres fragtomkostninger i dag?
8. Forretningsmodel. B2B, B2C? Hvis begge, fordelingen. De driftsmæssige og systemmæssige krav adskiller sig ganske betydeligt.
9. Integrationslandskab. Hvilke systemer skal forbindes til TMS'et: ERP, WMS, CRM? Er der eksisterende transportørintegrationer, der skal opretholdes? Hvor automatiseret skal det være fra dag ét?
10. Tidsplan og begrænsninger. Er der en go-live-dato? Er der interne milepæle – regnskabsårsafslutning, spidsbelastningssæson, systemmigration – der påvirker tidsplanen?

Intet af dette er svært at skrive ned. Men det ændrer alt ved, hvad der kommer tilbage.

Download tjeklisten for driftsmæssig information og gør disse ti spørgsmål til en udfyldningstabel, du kan indsætte direkte i din udbudsskrivelse:

Download tjeklisten for driftsmæssig information (.docx)

Sådan skriver du funktionskrav til TMS

Funktionskravene er kernen i udbudsskrivelsen. Gør du det rigtigt, får du et klart og sammenligneligtbillede af, hvad hver leverandør kan og ikke kan. Gør du det forkert, kan du ende med at bruge uger på at afkode svar, der alle siger "ja".

Målet er ikke den længste liste. Det er den mest ærlige.

Prioriter nådesløst: must-have, should-have, nice-to-have

Ikke alt, du ønsker, er lige vigtigt. Brug tre kategorier og hold dig til dem:

1. Must-have (M): ikke til forhandling. En leverandør, der ikke kan opfylde det, er ude – uanset hvad de ellers bringer.
2. Should-have (S): vigtigt, men du kan leve med en workaround eller et løfte om en nær fremtidig løsning.
3. Nice-to-have (N): godt at vide om, men det rangerer under alt ovenstående.

De fleste lister har alt for mange must-haves. Er alt kritisk, er intet det. Vær ærlig over for dig selv om, hvad der reelt ville forhindre systemet i at fungere for dig, og markér kun det som must-have.

Bed leverandørerne klassificere funktionsdækning: native / tredjepart / tilpasning

For hvert krav skal de svare med én af disse:

Det er i denne kolonne, tilbud vinder eller mister din tillid. En leverandør, der svarer ærligt og skriver ikke understøttet, hvor det er sandt, viser dig, hvordan de vil opføre sig som partner. En leverandør, der svarer native på alt, fortæller dig også noget vigtigt.

Vær specifik i spørgsmålet

"Understøtter systemet transportørprissætning?" giver dig et ubrugeligt "ja". "Kan systemet beregne fragtprisen for alle transportører, herunder dem uden en prissætnings-API, og vise dem side om side pr. forsendelse?" giver dig noget, du faktisk kan evaluere.

Hvor slutter ERP, og hvor begynder TMS?

En af de hyppigste kilder til forvirring ved evaluering af transportstyringssystemer er hvor TMS'et slutter, og ERP'et begynder.

Finansielle processer som GL-kodning, landede omkostninger og fragtrevision håndteres ofte på ERP-siden, hvor TMS'et sender data til ERP'et. Det er normalt og ofte den rigtige opsætning. Men det skal specificeres. Når en leverandør svarer "håndteres via ERP-integration" på et af dine must-haves, skal du grave i, hvad det præcist betyder for din implementering – og hvem der bygger den.

Specificer målet, ikke den tekniske løsning

Beskriv, hvad du har brug for at opnå – ikke hvordan systemet teknisk skal opnå det. Overpræskriptive krav eliminerer gode løsninger af de forkerte årsager. Giv leverandørerne plads til at vise dig en bedre vej end den, du havde i tankerne – for nogle gange har de én.

En ærlig, prioriteret liste på 30 punkter fortæller dig mere end et regneark på 150 linjer, hvor alt er kritisk, og alle leverandører har sat kryds i alle felter.

Et startsæt af TMS-krav, du kan tilpasse

De fleste førstegangskøbere ønsker et forspring på selve listen, så her er et eksempelsæt fra vores erfaring, allerede kategoriseret, som du kan tilpasse til din drift. Den fulde liste kan downloades i scoringsarket nedenfor – dette er nok til at se formen på det.

Download scoringsarket for funktionskrav, allerede bygget med prioriteter og en dækningskolonne pr. leverandør:

Download scoringsarket for funktionskrav (.docx)

Sådan sammenligner du TMS-omkostninger (og bygger en treårsmodel)

"Hvad koster et TMS?" er det spørgsmål, købere mest ønsker besvaret, og som leverandørerne helst undgår. Men abonnementsgebyret er sjældent din endelige omkostning. For en mellemstor virksomhed med flere lokationer kan implementering og integration endda drive de samlede treårsomkostninger mere end det månedlige gebyr – og det er netop den post, leverandørerne er mest vage om. Kunsten er derfor at strukturere spørgsmålet, så svarene er sammenlignelige, og de reelle omkostninger er synlige.

Som en grov orientering koster cloud-baseret TMS til mid-market typisk fra et par hundrede til et par tusinde euro om måneden, mens traditionelle enterprise-systemer koster fra titusinder til over en million om året med en implementering, der kan nå seks eller syv cifre. Det er et bredt interval – og det er præcis derfor, en sammenlignelig model er vigtigere end ét enkelt tal. For et indblik i, hvad reelle TMS-leverandører opkræver, se vores undersøgelse af de bedste TMS-leverandører.

Priskomponenter i et TMS

Næsten alle TMS-tilbud er en kombination af disse:

Byg en treårsmodel, inden du sammenligner

En TMS-leverandør, der ser billig ud på abonnementet, kan vise sig at være den dyreste, når implementering, pr.-transaktionsgebyrer og transportøronboarding er medregnet. Kør alle leverandører igennem den samme model:

Treårsomkostning = implementering + (årligt abonnement × 3) + (pr.-forsendelsesgebyr × årligt volumen × 3) + support + forventede transportør- og integrationstillæg.

Brug dine reelle volumener – ikke en leverandørs pæne eksempel. Den ene tabel har en tendens til at omrokere shortlisten.

Hold øje med de forskellige priskomponenter, ikke kun basisgebyret

Nogle leverandører prissætter lavt på abonnementet og henter det hjem på transaktionsgebyrer eller pr.-transportørgebyrer. Det er ikke nødvendigvis et problem, men det ændrer, hvem der er billigst, efterhånden som du vokser. Stiger dit volumen, kan en pr.-forsendelsesmodel hurtigt overhale en fast model. Bed om en eksempelfaktura og abonnementsvilkårene, så du sammenligner, hvad du reelt kommer til at betale – ikke en overskriftspris.

Et spørgsmål, der er værd at stille alle leverandører: er nye transportørintegrationer inkluderet, eller faktureres de hver gang? Nogle TMS-platforme opkræver 5.000-10.000 € pr. ny transportørintegration og bruger måneder på det, mens andre bygger nye transportørintegrationer uden ekstra omkostning. For en mellemstor virksomhed, der tilføjer transportører over tid, kan det ene svar flytte treårstotalen mere end abonnementslinjen nogensinde vil.

Sådan evaluerer du TMS-tilbud ud over prisen

Tilbuddene er kommet ind. De ser alle fornuftige ud, de fleste siger ja til dine krav, og priserne ligger i et lignende leje. Hvad nu?

Det er her, teams stille og roligt falder tilbage på prisen, fordi alt andet føles sværere at sammenligne. Lad være. Her er, hvad der reelt adskiller dem.

1. Transportørforbindelser.

For et TMS er transportørforbindelser fundamentet. Hvordan forbinder leverandøren sig faktisk til transportørerne – via direkte API/EDI-integrationer, tredjepartsaggregatorer eller slet ikke (e-mail + PDF-ordrer uanset transportørernes IT-kapacitet)? Hvad sker der, når du har brug for en transportør, de endnu ikke understøtter – hvor lang tid tager det, og hvad koster det?

En leverandør med dybe, direkte transportørforbindelser er en helt anden størrelse end én, der ruter alt igennem et mellemlag. Du mærker forskellen i bestillingspålidelighed, i sporingskvalitet og i, om du kan tilføje en transportør uden at indlede en ny kommerciel forhandling hver gang.

2. Harmonisering af transportørernes serviceniveau – dette betyder mere, end de fleste er klar over.

Transportørerne er ikke ens i deres digitale kapacitet. Nogle har sofistikerede API'er, der dækker realtidsprissætning, ETA-forudsigelse, adressevalidering, labelgenerering og detaljerede sporingshændelser. Andre sender dig en bestillingsbekræftelse på e-mail – og det er det. De fleste transportørnetværk indeholder begge typer på én gang.

Det bliver dit problem, i det øjeblik du forbinder dit ERP eller WMS til TMS'et. Forventer din integration et fuldt datasæt tilbage fra alle transportører – bestillingsbekræftelse, sporingslink, label, prisestimat – men nogle transportører ikke kan levere det, får du undtagelser, manuelle workarounds og huller i dine data. Én svag transportør bryder konsistensen i hele arbejdsgangen.

Der er to måder, som forskellige leverandører af transportstyringssoftware håndterer dette på, og det er værd at beslutte, hvilken du ønsker, inden du læser et eneste tilbud:

• Et tyndere TMS videresender, hvad den enkelte transportør leverer, og det bliver dit problem at håndtere hullerne i dit ERP eller manuelt. Enklere integration, men flere undtagelser at håndtere på din side.
• Et TMS, der normaliserer data og udfylder hullerne selv: beregner fragtomkostningen fra dit uploadede fragtprisark, når der ikke er nogen prissætnings-API; estimerer leveringstid, når der ikke er nogen transportør-leveret ETA; genererer forsendelseslabels, når transportøren ikke kan producere dem; og når de ikke har sporing, lader det dine transportører indtaste sporingsmilepæle manuelt – og mere til. Softwaren udfylder hullerne i dine transportørers tekniske kapacitet, og dit ERP ser én ensartet struktur.

Når du evaluerer tilbud, spørg leverandørerne direkte: hvordan håndterer I transportører med begrænsede digitale muligheder? Svaret fortæller dig meget om, hvor moden deres platform reelt er.

3. Ærlighed om integration.

Vær meget opmærksom på, hvordan leverandørerne beskriver integrationsomfanget (hvem gør hvad). Et tilbud, der klart siger "ERP-siden er jeres ansvar, her er hvad vi leverer og hvordan vi understøtter det", er mere troværdigt end ét, der antyder "problemfri integration" uden at forklare, hvilken part der håndterer hvilken del af integrationen – jer eller dem. Overraskelser i forbindelse med integration er en af de hyppigste årsager til, at TMS-projekter sprænger tids- og budgetrammer.

4. Implementeringstilgang.

En faseopdelt tilgang – manuel driftsvalidering først og automatisering bagefter – er typisk lavere risiko end en big-bang-lancering. Du får mulighed for at bekræfte, at systemet fungerer for dine reelle arbejdsgange, inden du lægger hele driften op ad det. Fra vores side af bordet har de leverandører, der foreslår dette uden at blive bedt om det, typisk prøvet en rodet go-live før. Dem, der pitcher fuld automatisering fra dag ét, har ofte ikke.

5. Referencer

Bed om referencer fra virksomheder med lignende drift – ikke blot lignende størrelse eller medarbejderantal. En reference fra en enkelt-lokations-distributør er ikke særlig nyttig, hvis du driver en multi-lokations-produktionsvirksomhed med SAP-integration. Og stil de præcise spørgsmål: "Hvordan gik transportøronboardingen?" "Hvordan gik integrationsprocessen?" "Hvad skete der, når noget ikke fungerede som forventet?"

6. Tilbuddet i sig selv.

Måden en TMS-leverandør besvarer din udbudsskrivelse på, er en forhåndsvisning af, hvordan de vil opføre sig som din partner. Besvarede de dine spørgsmål direkte, eller indpakkede de alt i forbehold? Pegede de ærligt på hullerne, eller påstod de fuld dækning på alle krav? Viste de, at de forstod din drift, eller sendte de dig en let modificeret udgave af deres standardpræsentation?

Et tilbud, der indrømmer ikke understøttet to steder og forklarer hvorfor, er mere værd end ét, der siger ja til alt. Du finder sandheden ud på den ene eller anden måde. Bedre at finde den under evalueringen end ved go-live.

Download evalueringsmatrixen for leverandører og scorer dem på vægtede kriterier:

Download evalueringsmatrixen for leverandører (.docx)

Præsentationsrunden med TMS-leverandørerne

Skriftlige tilbud fortæller dig, hvad en leverandør påstår. Præsentationer fortæller dig, om de kan bakke det op.

På dette tidspunkt bør du have en shortliste med 2-3 leverandører. Målet med præsentationsrunden er at sætte tilbuddet under reelt pres og se, om systemet fungerer i dine faktiske scenarier.

Bed om en live gennemgang, ikke en demo

En demo er en indøvet sekvens, der viser systemet på sit bedste. En gennemgang er, når du siger "vis mig, hvordan I ville håndtere denne forsendelse, fra vores lager i Nederlandene, med vores transportør, til vores aftalte pris" – og ser, hvad der faktisk sker.

Forbered 2-3 reelle scenarier fra din egen drift inden mødet: en standard udgående bestilling, en forsendelse, der kræver et spot-tilbud, og noget besværligt som en forsinket forsendelse eller en transportør, der ikke leverer sporing. Når en leverandør bliver ved med at styre tilbage mod den polerede demo i stedet for at køre dit scenarie, er det dit svar.

Udfordre hullerne

Alle TMS-tilbud har dem. Gå direkte til de dele, hvor en leverandør svarede delvist, eller hvor du har tvivl – og bliv der. Lad dem ikke glide tilbage til noget, der fungerer smukt. Hvordan fungerer det præcist? Hvem gør hvad? Hvad sker der, når det ikke fungerer som forventet?

Få de rette mennesker i rummet

På TMS-leverandørens side bør de præsenterende være dem, der faktisk vil arbejde på din implementering – ikke blot salgsteamet. Bed eksplicit om det. På din side, tag nogen fra IT med (hvis integration er i scope), og mindst én person, der faktisk vil bruge systemet hver dag. De stiller andre spørgsmål end indkøb gør, og du vil have begge sæt spørgsmål stillet.

Anden runde, kun hvis nødvendigt

Ved en kompleks beslutning er en anden session med fokus på specifikke emner tiden værd. Eksempler på emner, der kan dækkes:

• Sikkerhed og databeskyttelse – anmod om en pentest-rapport eller sikkerhedsdokumentation, hvis dit IT- eller informationssikkerhedsteam kræver det
• Integrationsarkitektur – en teknisk session mellem dit IT-team og leverandørens
• Kommercielle vilkår – gennemgå kontrakt, SOW og antagelser linje for linje, inden du går ind i formelle forhandlinger

Book den ikke blot for at gentage det første møde med flere mennesker i rummet. Enten løser den specifikke åbne spørgsmål, eller den bør ikke finde sted.

Bekræft tilsagn skriftligt

Alt, en leverandør forpligter sig til i mødet, som ikke fremgår af det skriftlige tilbud, skal bekræftes skriftligt, inden du går videre. Mundtlige tilsagn overlever ikke kontraktforhandlinger. Siger en TMS-leverandør "ja, det kan vi" på noget vigtigt, følg op med en e-mail samme dag og bed dem bekræfte.

TMS-kontrakt og SOW (Statement of Work): hvad du skal tjekke, inden du skriver under

Du har valgt din leverandør. De fleste teams "ånder lettet op" på dette tidspunkt. Det anbefaler jeg ikke, for det er her, de detaljer, alle gik let hen over under evalueringen, stille og roligt bliver dit problem.

Bliv enige internt, inden du forhandler

Kend dine ufravigelige krav, dine acceptable kompromiser og dine grænser, inden samtalen begynder. At ændre krav midt i forhandlingen koster tid, svækker tilliden og kan lejlighedsvis koste dig den TMS-leverandør, du faktisk ønskede. Afklar det internt først, og forhandl derefter.

Forstå, hvad du køber: SaaS, ikke en licens

Moderne TMS-platforme er SaaS-abonnementer, ikke softwarelicenser. Du abonnerer på en tjeneste, som leverandøren hoster, vedligeholder og opdaterer – du køber ikke et system direkte. Det ændrer, hvad kontrakten skal dække: abonnementsvilkår, opsigelse, dataejerskab og eksportrettigheder, oppetidsforpligtelser, svartider for support. Standard indkøbsskabeloner er ikke skrevet til denne model, så sørg for, at din er opdateret.

SOW'en er lige så vigtig som kontrakten

Statement of Work specificerer, hvad der leveres, af hvem og hvornår: kontokonfiguration, transportøronboarding, integrationsunderstøttelse, oplæring og de acceptkriterier, der fastslår, at implementeringen faktisk er færdig. Er det ikke i SOW'en, er det ikke inkluderet – uanset hvad der blev sagt i et møde eller en e-mail. Læs afsnittet om antagelser særligt grundigt. Det er her, scopet er betinget defineret. Viser din transportørliste sig at være større end angivet, eller kræver dit ERP et ikke-standardiseret integrationsformat, afgør antagelsesafsnittet, om det er en hurtig snak eller en prissatanmodning om ændring.

Vær eksplicit om, hvad der er uden for scope

Tilpasset udvikling, oplæring på stedet, datamigrering, integrationsarbejde på dine systemer, ændringer på transportørsiden. Disse prissættes typisk separat. At få det på papir, inden du skriver under, fjerner den hyppigste – og mest undgåelige – kilde til implementeringsfriktioner: to parter, der hver især antog, at noget andet var inkluderet.

Aftal onboardingplanen, inden du skriver under

Ikke efter. Transportørprioritering, konfigurationstidsplan, integrationsmilepæle, go-live-kriterier – afklar det hele, mens du stadig har forhandlingsstyrke. En leverandør, der ikke kan give dig en klar onboardingplan på kontraktstadiet, fortæller dig noget, du gerne vil vide, inden du forpligter dig.

Efter underskriften: TMS-implementering og onboarding

Det meste af den reelle risiko lever efter underskriften. Tre ting afgør, hvordan det går.

1. Datamigrering

Transportørkontrakter, prislister, adressebøger, historiske forsendelser. Beslut tidligt, hvad du skal migrere, hvad der renses først, og hvem der ejer arbejdet. Rodet kildedata er den hyppigste årsag til, at go-live-datoen skubbes og skubbes. Rens det inden du migrerer – ikke mens du migrerer.

2. Rækkefølge for transportøronboarding

Du forbinder ikke alle transportører på dag ét. Prioriter efter volumen og kritikalitet, få de vigtigste live og valideret, og udvid derefter derfra. Det er præcis her, den faseopdelte tilgang, du spurgte om under evalueringen, viser sin værdi.

3. Brugeradoption

De mennesker, der bestiller forsendelser hver dag, skal have lyst til at bruge det nye system. Træk mindst én af dem ind fra udbudsstadiet og fremefter, oplær dem ordentligt under hypercare (onboarding), og sørg for, at den daglige arbejdsgang reelt er hurtigere end det, de gjorde før. En teknisk fejlfri udrulning, som teamet bare ikke bruger, er stadig en mislykket udrulning.

10 hyppige fejl i TMS-udbudsskrivelser

De mønstre, vi ser oftest, samlet ét sted:

• Ingen driftsmæssig kontekst. Den store. Ingen volumener, ingen lokationsstruktur, intet transportørbillede leveret til leverandørerne. En afklaringsrunde og generiske priser er garanteret.
• Alt er must-have. Når alle krav er kritiske, er prioriteringskolonnen død vægt, og du kan ikke skelne et dealbreaker fra et nice-to-have.
• Vag tidsplan. Ingen datoer betyder, at leverandørerne ikke kan estimere deres indsats, og tilbuddene kommer tilbage lige så vage.
• Overspecificering af hvordan. At foreskrive den tekniske implementering i stedet for det driftsmæssige resultat eliminerer gode løsninger af de forkerte årsager.
• At ignorere ERP/TMS-grænsen. At antage, at TMS'et ejer finansielle processer, som ERP'et faktisk ejer – og så opdage det midt i implementeringen.
• At falde tilbage på prisen. At vælge ud fra abonnementsoverskriften uden en treårsmodel eller uden at vægte transportørforbindelser og integrationsærlighed.
• En demo i stedet for en gennemgang. At se leverandørens indøvede sekvens i stedet for at lade systemet teste dine reelle scenarier.
• Referencer, der ikke matcher din drift. At kigge på de imponerende logoer, men de virksomheder kan have logistikdrift, der ikke ligner din overhovedet. Bed om referencer, der ligner dig, og spørg dem derefter, hvordan onboarding og integration faktisk gik.
• At lade onboarding vente til efter underskriften. Den plan, du forhandler med forhandlingsstyrke, slår den, du forhandler uden.
• En proces, der er for tung til den rette leverandør. Bureaukratisk overhead, der kan filtrere de moderne platforme fra, som ville have tjent dig bedst.

Gratis TMS-skabeloner

Vi har bygget fem skabeloner ud fra de udbudsskrivelser, vi besvarer, så du ikke behøver at starte fra en blank side:

1. Skabelon til udbudsskrivelse. Den fulde struktur fra denne guide.
2. Scoringsark for funktionskrav. Prioriteret, med en dækningskolonne pr. leverandør.
3. Tjekliste for driftsmæssig information. De ti spørgsmål som udfyldningstabel.
4. Evalueringsmatrix for leverandører. Vægtet scoring på tværs af leverandørerne.
5. Tidsplansskabelon. Aktiviteter, datoer, ansvarlige.

Download pakken – alle fem, gratis, ingen e-mail kræves. Tag det, der er nyttigt, og ignorer resten:

Download den fulde TMS-skabelonpakke (.zip)

Cargoson er et transportstyringssystem brugt af mellemstore producenter og grossister i Europa og Nordamerika. Vi besvarer udbudsskrivelser som den, du er ved at skrive, hele tiden – så hvis du hellere vil tale dine krav igennem, inden du begynder at skrive, hjælper vi gerne med at tænke det igennem, uden forpligtelse.

Book en gratis konsultation på 30 minutter her

Gennemfør processen ordentligt, og den er hver time værd.