Slik skriver du en TMS-forespørsel om tilbud: våre erfaringer [+ 5 gratis maler]

Vi svarer på transportstyringssystem-forespørsler om tilbud (RFP) hver eneste uke. Noen er en fornøyelse å jobbe med. Andre er en leksjon i hva man ikke bør gjøre.

Denne artikkelen er det jeg ville ha bygget om jeg skulle kjøre en TMS-utvelgelsesprosess fra bunnen av i dag. Den bygger på RFP-er vi har svart på, mønstre som gjentar seg på tvers av selskaper og bransjer, hva de fleste inneholder – og hvilke vanlige feil vi ser.

Er du innkjøpsspesialist, vil mye av dette kjennes kjent. Forhåpentligvis sparer det deg for minst én unødvendig avklaringsrunde.

Hva er en TMS-forespørsel om tilbud?

En TMS-forespørsel om tilbud (RFP) er et strukturert dokument du sender til leverandører av transportstyringssystemer. Det beskriver logistikkoperasjonen din og ber hver enkelt leverandør om å foreslå hvordan systemet deres vil håndtere den – mot det samme settet med krav. Hele poenget er sammenlignbarhet. Samme spørsmål, samme format, samme kontekst, slik at svarene kan stilles opp side om side i stedet for å leses som fem separate salgspitcher.

Du trenger ikke alltid en slik prosess. En formell anbudsforespørsel lønner seg når beslutningen er kompleks, eller når du må kunne forsvare den overfor andre internt. Er logistikkoperasjonen din enkel, holder det gjerne med en produktdemo og en samtale med noen få leverandører.

Trenger du egentlig å kjøre en formell TMS-anbudsprosess?

Å ta feil beslutning her er den dyreste feilen i hele TMS-utvelgelsesprosessen. Avklar dette før du gjør noe som helst annet.

Det handler om hvor kompleks logistikken din er – ikke hvor stort selskapet ditt er.

Kjør en strukturert TMS-anbudsprosess hvis du sender fra flere lokasjoner, bruker flere transportmåter og trenger at systemet kobles til ERP-en din. Da trenger du alle leverandørene stilt opp side om side, slik at ingenting viktig faller mellom stolene. Leverandører kobler seg til transportører på svært ulike måter. Én kaller det «innebygd», den neste ruter det stille og rolig gjennom en tredjepart. I en løs prosess oppdager du ikke det før etter at du har signert. Da er det for sent.

Hopp over den formelle anbudsprosessen hvis du driver én lokasjon med et fåtall transportører og allerede vet hva du trenger. Hvorfor? Fordi i det øyeblikket du kjører en RFP, har du plassert deg selv i enterprise-prisnivået. 2–3 gode demoer med presise spørsmål gir deg ofte et bedre system, billigere og raskere. Fortell de 2–3 leverandørene hva du sender og hva du prøver å løse, og be dem vise deg det i sitt live-system. Du vet svaret i løpet av en time. Og sender du mest pakker fremfor paller eller gods, trenger du kanskje ikke et fullverdig TMS i det hele tatt – programvare for forsendelse med flere transportører er en annen og lettere kategori som er bygget nettopp for det.

Vær derfor ærlig med deg selv om hvilken vei du foretrekker, før du begynner. Å kjøre en anbudsprosess du ikke trengte, er den tregeste og dyreste måten å kjøpe et TMS på.

Å kjøre en anbudsprosess du ikke trengte, er den tregeste og dyreste måten å kjøpe et TMS på.

Enda en advarsel hvis du velger den fullstendige anbudsprosessen. En prosess lastet med styringssjargong, metoderammeverk og krav om fastpris tar uker å svare på – og leverandørene som kan absorbere den overheaden, er gjerne de store, etablerte aktørene. Så hvis en slankere og mer moderne plattform faktisk ville tjent deg bedre, kan en altfor byråkratisk prosess stille og rolig filtrere dem ut før du noen gang får se en demo.

Målet er å finne den riktige løsningen for deg. Utform prosessen rundt det – ikke rundt det å administrere prosessen i seg selv.

TMS-anbudsprosessen i 9 steg

En TMS-utvelgelse trenger ikke å være komplisert. Men den trenger en tydelig rekkefølge. Hopper du over steg, betaler du for det senere – som regel under implementeringen, når antakelser som burde ha vært avklart tidlig, blir kostbare overraskelser.

Gjort riktig tar hele prosessen 8 til 12 uker. Mindre for et enkelt omfang, og den trenger sjelden mer.

Her er rekkefølgen som fungerer:

1. Markedskartlegging. Før du skriver et eneste krav, bruk tid på å forstå hva som finnes der ute. TMS-markedet har beveget seg mye de siste fem årene: det finnes gode enterprise-plattformer, gode mellommarkedsplattformer og genuint kapable moderne SaaS-løsninger for transportstyring som ikke eksisterte for fem år siden. Bygg en innledende liste med 5–8 TMS-leverandører som er verdt å kontakte.
2. Taushetserklæring (NDA). Send den tidlig. Du kommer til å dele operasjonelle data som volumer, transportørnavn og interne systemdetaljer – og en signert NDA før forespørselen sendes ut er standard praksis som beskytter begge parter.
3. RFI (valgfritt). En kort forespørsel om informasjon gir mening hvis den innledende listen er bred og du vil filtrere før du investerer i en full anbudsprosess. Hold den til én side: selskapsbakgrunn, nøkkelfunksjoner, omtrentlig prisintervall. Nok til å shortliste uten å be leverandørene skrive romaner.
4. RFP. Hoveddokumentet. Det gir alle leverandører det de trenger for å gi et presist tilbud. Mer om dette i neste kapittel.
5. Spørsmål og svar-vindu. Ta alltid med dette. Leverandørene vil ha spørsmål, og svarene forbedrer ofte hvert eneste tilbud du mottar. Kjør det skriftlig, og del alle spørsmål og svar med alle leverandører samtidig. Det holder prosessen ryddig og sammenlignbar.
6. Shortlisting og presentasjoner. Vurder de skriftlige tilbudene, og inviter deretter 2–3 leverandører til å presentere. En presentasjon bør inkludere en live gjennomgang av systemet basert på dine faktiske bruksscenarier – ikke en generisk demo. Hvis en leverandør ikke kan vise deg ditt scenario i sitt system, er det i seg selv nyttig informasjon.
7. Andre runde (om nødvendig). For en kompleks beslutning er en dypere økt fokusert på spesifikke åpne punkter – som sikkerhet, integrasjon og kommersielle vilkår – verdt tiden. Ikke sett den opp med mindre du har reelle ubesvarte spørsmål.
8. Beslutning og kontrakt. Bli enige internt før du forhandler. Kjenn dine absolutte krav, akseptable kompromisser og grenser for hva du kan godta.
9. Onboarding. Dette slutter ikke ved signaturen. De beste resultatene fra en anbudsprosess har en onboarding-plan som er avtalt før kontrakten signeres.

Tidsplan for TMS-anbudsprosessen – kopi og bruk

Omtrentlig varighet etter omfang:

• Én ukomplisert lokasjon: 6 til 8 uker (du trenger kanskje ikke en full anbudsprosess).
• Flere lokasjoner + ERP-integrasjon: 8 til 12 uker.
• Global utrulling med flere enheter og kompleks integrasjon: 12 til 20 uker, gjerne med to presentasjonsrunder.

Last ned tidsplanmalen for RFP (.docx)

Hva bør TMS-forespørselen inneholde?

RFP-dokumentet er det viktigste verktøyet du har i denne prosessen. Et godt RFP-dokument gjør det meste av evalueringsarbeidet for deg – så hold det fokusert. En stram RFP på 10 sider slår en på 30 sider som prøver å dekke alt.

1. Følgebrev og målbeskrivelse

Én side. Hvem du er, hva du ser etter og hvorfor nå. Hold det saklig. Leverandørene trenger ikke en visjonserklæring – de trenger bare å forstå det operative problemet ditt.

2. Tidsplan

En tydelig fremdriftsplan med reelle datoer: utsendelse av RFP, frist for spørsmål og svar, innleveringsfrist, presentasjonsvindu og beslutning. Leverandørene planlegger responsinnsatsen sin etter dette. Vage tidsplaner gir deg vage tilbud.

3. Selskapsbakgrunn og operativ informasjon

Her svikter de fleste forespørsler, og det er forskjellen mellom sammenlignbare tilbud og en runde med avklaringsspørsmål. Ikke bare beskriv virksomheten din – beskriv logistikkoperasjonen din. Hvor mange lokasjoner. Hvor mange juridiske enheter. Hvilke transportmåter (pakke, LTL, FTL, luft, sjø, jernbane). Hvilke regioner. Omtrentlige volumer. Nåværende systemer. Hva «godt» betyr varierer også etter bransje – kravene for produsenter av elektronikk, maskiner, kjemikalier eller trykk og emballasje er ikke de samme. Dette er konteksten leverandørene trenger for å kunne utforme et presist tilbud. Gir du ikke nok detaljer her, bruker du to uker på å svare på avklaringsspørsmål som kunne vært unngått helt. Dette får sitt eget avsnitt nedenfor, i neste kapittel.

4. Funksjonskrav

En tabell over hva systemet må kunne gjøre, prioritert etter viktighet: must-have / should-have / nice-to-have (Excel fungerer fint). Be leverandørene svare på hvert krav med sitt dekningsnivå: a) innebygd, b) tredjepartsløsning, c) tilpasning eller d) ikke støttet. Det er dette som gjør tilbudene sammenlignbare. Mer om hvordan du bygger denne listen lenger ned.

5. Evalueringskriterier

Fortell leverandørene hvordan du vil ta beslutningen: funksjonalitet, pris, implementeringstilnærming, referanser, sikkerhet og team. Del vektingen hvis du er villig til det. Jo mer transparent du er, desto bedre tilbud får du.

6. Prismodell

Be om en fullstendig oversikt: abonnement, implementering, transaksjonsgebyrer, support og alt annet. Be om en eksempelfaktura hvis mulig. Prisstrukturene varierer mye mellom leverandørene, og de skjulte kostnadene har en tendens til å dukke opp sent. Prøv å avdekke dem tidlig.

7. Svarformat

Fortell leverandørene nøyaktig hvordan du vil at tilbudet skal struktureres, og hvis du gir dem maler, krev at de brukes. Sammenlignbare tilbud sparer deg for dager under evalueringen, og formatet er helt i din kontroll.

Last ned RFP-dokumentmalen for å starte med den fullstendige strukturen ovenfor:

Last ned RFP-dokumentmalen (.docx)

Den operative informasjonen de fleste TMS-forespørsler utelater – og hvorfor det er det viktigste

Dette er kapittelet jeg skulle ønske alle som skriver TMS-forespørsler, leste først.

Vi svarer på mange TMS-anbud. Nesten hvert eneste tilbud vi skriver krever en avklaringsrunde – og det er sjelden fordi kravene var uklare. Det er fordi den operative konteksten manglet: volumer, lokasjonsstruktur, transportørbilde og nåværende systemer.

De forespørslene som krevde en full avklaringsrunde, har nesten alltid én ting til felles:

Vi har sett selskaper bruke uker på å utforme evalueringskriterier og kravlister, for så å sende en forespørsel som ikke nevner hvor mange forsendelser de behandler per måned.

Uten den informasjonen gjetter leverandørene. Og når de gjetter, kommer tilbudene tilbake som generiske, prisingen er ikke endelig, og det er ingenting solid å sammenligne.

En global produsent med 10 lagre og SAP trenger for eksempel et helt annet tilbud enn en enkeltlokasjonsdistributør som styrer logistikken sin i regneark. Hvis en leverandør ikke kan se hvilken av de to du er, sikrer de seg – og du ender opp med tilbud som ikke forplikter seg til noe.

Løsningen tar en ettermiddag. Svar på disse ti spørsmålene i forespørselen før den sendes ut.

1. Organisasjon og omfang. Hvor mange juridiske enheter og lokasjoner er inkludert? Er utrullingen parallell eller faset? Hvor selvstendig opererer lokasjonene – separate transportøravtaler, separate team?
2. Forsendelsesvolumer. Månedlige og daglige forsendelsestall per lokasjon, gjennomsnitt og topp. Eventuell sesongvariasjon. Fordeling mellom innkommende og utgående.
3. Fordeling av transportmåter. Hvilken andel er pakke, LTL, FTL, luft, sjø? Hvilke transportmåter vokser? Hvilke er mest operasjonelt kritiske?
4. Transportørbilde. Hvor mange transportører per lokasjon og per transportmåte? Delt på tvers av lokasjoner eller administrert lokalt? Er det strategiske transportører som må prioriteres, eller kundestyrte transportører du ikke kan bytte ut?
5. Geografi og handelsruter. Hvilke regioner er inkludert? Hvilke ruter er viktigst: innenlands, grenseoverskridende, interkontinentale? Viktige havner eller logistikknutepunkter?
6. Nåværende situasjon. Hvordan planlegges, bestilles og spores forsendelser i dag? I ERP, regneark, transportørportaler, e-post? Hva er de viktigste smertepunktene i den nåværende prosessen?
7. Finansiell oppsett. Hvem betaler for transport – én enhet eller flere? Er det tredjeparts- eller kundekontonumre? Hvordan registreres og valideres fraktkostnader i dag?
8. Forretningsmodell. B2B, B2C? Hvis begge, hvilken fordeling. De operative og systemtekniske kravene er ganske forskjellige.
9. Integrasjonslandskap. Hvilke systemer må kobles til TMS-et: ERP, WMS, CRM? Er det eksisterende transportørintegrasjoner som må videreføres? Hvor automatisert må det være fra dag én?
10. Tidsplan og begrensninger. Er det et mål for go-live? Er det interne milepæler – som regnskapsårsavslutning, høysesong eller systemmigrasjoner – som påvirker fremdriften?

Ingenting av dette er vanskelig å skrive ned. Men det forandrer alt ved det som kommer tilbake.

Last ned sjekklisten for operativ informasjon for å gjøre disse ti spørsmålene om til en utfyllingstabell du kan legge direkte inn i forespørselen:

Last ned sjekklisten for operativ informasjon (.docx)

Slik skriver du funksjonskrav til TMS-et

Funksjonskravene er kjernen i forespørselen. Gjør du dem riktig, får du et tydelig og sammenlignbart bilde av hva hver leverandør kan og ikke kan. Gjør du dem feil, kan du ende opp med å bruke uker på å tyde svar som alle sier «ja».

Målet er ikke den lengste listen. Det er den mest ærlige.

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

Ikke alt du ønsker deg er like viktig. Bruk tre kategorier og hold deg til dem:

1. Must-have (M): ikke til forhandling. En leverandør som ikke kan oppfylle det, er ute – uansett hva annet de bringer til bordet.
2. Should-have (S): viktig, men du kan leve med en midlertidig løsning eller et løfte om nær fremtidig utvikling.
3. Nice-to-have (N): greit å vite om, men det kommer etter alt det ovenstående.

De fleste lister har altfor mange must-have-er. Hvis alt er kritisk, er ingenting det. Vær ærlig om hva som faktisk ville hindret systemet i å fungere for deg, og merk bare disse som must-have.

Be leverandørene klassifisere funksjonell dekning: innebygd / tredjepartsløsning / tilpasning

For hvert krav, be dem svare med ett av disse:

Det er i denne kolonnen tilbud vinner eller taper tilliten din. En leverandør som svarer ærlig og skriver ikke støttet der det stemmer, viser deg hvordan de vil oppføre seg som partner. En leverandør som svarer innebygd på alt, forteller deg noe viktig det også.

Vær konkret i spørsmålet

«Støtter systemet transportørprising?» gir deg et ubrukelig «ja». «Kan systemet beregne fraktprisen for alle transportører – inkludert de uten et pris-API – og vise dem side om side per forsendelse?» gir deg noe du faktisk kan evaluere.

Hvor slutter ERP-et, og hvor begynner TMS-et?

En av de vanligste kildene til forvirring i evalueringer av transportstyringssystemer er hvor TMS-et slutter og ERP-et begynner.

Finansielle prosesser som kontokodering, landingskostnad og fraktrevisjon håndteres ofte på ERP-siden, der TMS-et mater data inn i ERP-et. Det er normalt og ofte den riktige oppsettet. Men det må spesifiseres tydelig. Når en leverandør svarer «håndteres via ERP-integrasjon» på ett av dine must-have-krav, grav deg ned i nøyaktig hva det betyr for implementeringen din – og hvem som bygger det.

Spesifiser målet, ikke den tekniske løsningen

Beskriv hva du trenger å oppnå, ikke hvordan systemet teknisk sett skal oppnå det. Overbeskrivende krav utelukker gode løsninger av feil grunner. Gi leverandørene rom til å vise deg en bedre vei enn den du hadde i tankene – for noen ganger har de det.

En liste med 30 ærlige, prioriterte krav forteller deg mer enn et regneark med 150 linjer der alt er kritisk og alle leverandørene har krysset av på alt.

Et startpunkt for TMS-krav du kan tilpasse

De fleste som kjøper TMS for første gang, ønsker et forsprang på selve listen – her er derfor et eksempelsett fra vår erfaring, allerede kategorisert, som du kan tilpasse din egen drift. Den fullstendige listen kan lastes ned i poengsettingsskjemaet nedenfor; dette er nok til å se formen på det.

Last ned poengsettingsskjemaet for funksjonskrav, allerede bygget med prioriteringer og en dekningskolonne per leverandør:

Last ned poengsettingsskjemaet for funksjonskrav (.docx)

Slik sammenligner du TMS-kostnader (og bygger en treårsmodell)

«Hva koster et TMS?» er spørsmålet kjøpere mest vil ha svar på og leverandørene helst unngår. Men abonnementsavgiften er sjelden den endelige kostnaden. For en mellomstor aktør med flere lokasjoner kan implementering og integrasjon til og med drive totalkostnaden over tre år mer enn den månedlige avgiften – og det er nettopp den posten leverandørene er mest vage om. Kunsten er derfor å strukturere spørsmålet slik at svarene er sammenlignbare og den reelle kostnaden blir synlig.

Som en grov orientering: mellommarkedsbaserte skybaserte TMS-løsninger koster gjerne fra noen hundre til noen tusen euro i måneden, mens tradisjonelle enterprise-systemer koster fra titusener til over en million euro i året, med implementeringskostnader som kan nå seks eller syv sifre. Det er et stort spenn – og det er nettopp derfor en sammenlignbar modell betyr mer enn ett enkelt tall. For et inntrykk av hva reelle TMS-leverandører tar betalt, se vår gjennomgang av de beste TMS-leverandørene.

Priskomponenter i et TMS

Nesten alle TMS-tilbud er en kombinasjon av disse:

Bygg en treårskostnadsmodell før du sammenligner

En TMS-leverandør som ser billig ut på abonnement, kan vise seg å være den dyreste når implementering, transaksjonsgebyrer og transportøronboarding er regnet inn. Kjør alle leverandørene gjennom den samme modellen:

Kostnad over 3 år = implementering + (årsabonnement × 3) + (gebyr per forsendelse × årsvolum × 3) + support + forventede tillegg for transportør- og integrasjonsarbeid.

Bruk dine reelle volumer, ikke et ryddig eksempel fra leverandøren. Den ene tabellen har en tendens til å stokke om på shortlisten.

Følg med på de ulike priskomponentene, ikke bare basisavgiften

Noen leverandører priser lavt på abonnement og tar det igjen på transaksjonsgebyrer eller per-transportør-avgifter. Det er ikke automatisk negativt, men det endrer hvem som er billigst etter hvert som du vokser. Stiger volumet ditt, kan en per-forsendelse-modell raskt overgå en flat modell. Be om en eksempelfaktura og abonnementsvilkårene, slik at du sammenligner det du faktisk vil betale – ikke en overskriftspris.

Et spørsmål det er verdt å stille alle leverandørene: er nye transportørintegrasjoner inkludert, eller faktureres de hver gang? Noen TMS-plattformer tar 5 000–10 000 euro per ny transportørintegrasjon og bruker måneder på det, mens andre bygger nye transportørintegrasjoner uten ekstra kostnad. For en mellomstor aktør som legger til transportører over tid, kan det ene svaret flytte totalkostnaden over tre år mer enn abonnementslinjen noen gang vil.

Slik evaluerer du TMS-tilbud utover pris

Tilbudene er inne. De ser alle fornuftige ut, de fleste sier ja til kravene dine, og prisingen er i et lignende leie. Hva nå?

Dette er punktet der team stille og rolig faller tilbake på pris, fordi alt annet føles vanskeligere å sammenligne. Ikke gjør det. Her er det som faktisk skiller dem.

1. Transportørtilkobling.

For et TMS er transportørtilkoblingen fundamentet. Hvordan kobler leverandøren seg faktisk til transportørene – via direkte API/EDI-integrasjoner, tredjepartsaggregatorer, eller ikke i det hele tatt (e-post og PDF-ordrer uavhengig av IT-kapasitet)? Hva skjer når du trenger en transportør de ikke støtter ennå – hvor lang tid tar det, og hva koster det?

En leverandør med dype, direkte transportørtilkoblinger er noe helt annet enn én som ruter alt gjennom et mellomvarelag. Du merker forskjellen på bestillingspålitelighet, sporingskvalitet og om du kan legge til en transportør uten å åpne en ny kommersiell forhandling hver gang.

2. Harmonisering av transportørenes tjenestenivå – dette betyr mer enn de fleste er klar over.

Transportørene er ikke like i sine digitale muligheter. Noen har sofistikerte API-er som dekker sanntidsprising, ETA-prediksjon, adressevalidering, etikettgenerering og detaljerte sporingshendelser. Andre sender deg en bestillingsbekreftelse på e-post – og det er slutten på samtalen. De fleste transportørnettverk inneholder begge typer på én gang.

Det blir ditt problem i det øyeblikket du kobler ERP-et eller WMS-et til TMS-et. Forventer integrasjonen din et fullstendig datasett tilbake fra alle transportører – bestillingsbekreftelse, sporingslenke, etikett, kostnadsestimat – men noen transportører ikke kan levere det, får du unntak, manuelle omveier og hull i dataene dine. Én svak transportør bryter konsistensen i hele arbeidsflyten.

Det finnes to måter ulike leverandører av transportstyringssystemer håndterer dette på, og det er verdt å bestemme seg for hvilken du vil ha før du leser et eneste tilbud:

• Et tynnere TMS videresender det hver transportør leverer, og det blir ditt problem å håndtere hullene i ERP-et eller manuelt. Enklere integrasjon, men flere unntak å håndtere på din side.
• Et TMS som normaliserer dataene og fyller hullene selv: beregner fraktkostnad fra det opplastede fraktprisarket ditt når det ikke finnes et pris-API; estimerer leveringstid når transportøren ikke gir ETA; genererer fraktetiketter når transportøren ikke kan produsere dem; og når de ikke har sporing, lar det transportørene legge inn sporingsmilepæler manuelt – og mer. Programvaren fyller hullene i transportørenes tekniske kapasitet, og ERP-et ditt ser én konsistent struktur.

Når du evaluerer tilbud, spør leverandørene direkte: hvordan håndterer dere transportører med begrensede digitale muligheter? Svaret forteller deg mye om hvor moden plattformen faktisk er.

3. Ærlighet om integrasjon.

Vær nøye med hvordan leverandørene beskriver integrasjonsomfanget (hvem gjør hva). Et tilbud som sier klart og tydelig «ERP-sideutvikling er ditt ansvar, her er hva vi leverer og hvordan vi støtter det» er mer tillitvekkende enn ett som antyder «sømløs integrasjon» uten å forklare hvilken part som håndterer hvilken del av integrasjonen – deg eller dem. Integrasjonsoverraskelser er en av de vanligste grunnene til at TMS-prosjekter sprekker på tid og budsjett.

4. Implementeringstilnærming.

En faset tilnærming – manuell operasjonell validering først og automatisering etterpå – er vanligvis lavere risiko enn en big-bang-lansering. Du får bekreftet at systemet fungerer for de reelle arbeidsflytene dine før du lener hele driften på det. Fra vår side av bordet: leverandørene som foreslår dette uten å bli bedt om det, har som regel vært gjennom en rotete go-live før. De som pitcher full automatisering fra dag én, har ofte ikke det.

5. Referanser

Be om referanser fra selskaper med lignende drift – ikke bare lignende størrelse eller antall ansatte. En referanse fra en enkeltlokasjonsdistributør er ikke særlig nyttig hvis du driver en flerlokasjonsproduksjon med SAP-integrasjon. Og still de presise spørsmålene: «Hvordan gikk transportøronboardingen?» «Hvordan gikk integrasjonsprosessen?» «Hva skjedde når noe ikke fungerte som forventet?»

6. Selve tilbudet.

Hvordan en TMS-leverandør svarer på forespørselen din, er en forhåndsvisning av hvordan de vil oppføre seg som partner. Svarte de direkte på spørsmålene dine, eller pakket de alt inn i forbehold? Flagget de hullene ærlig, eller hevdet de full dekning på alle krav? Viste de at de forstod driften din, eller sendte de deg en lett modifisert versjon av standardpresentasjonen sin?

Et tilbud som innrømmer ikke støttet på to punkter og forklarer hvorfor, er mer verdt enn ett som sier ja til alt. Du finner ut sannheten uansett. Bedre å finne den under evalueringen enn ved go-live.

Last ned evalueringsmatrisen for leverandører for å gi vektet poengsum på tvers av leverandørene:

Last ned evalueringsmatrisen for leverandører (.docx)

Presentasjonsrunden med TMS-leverandørene

Skriftlige tilbud forteller deg hva en leverandør hevder. Presentasjoner forteller deg om de kan underbygge det.

På dette stadiet bør du ha en shortlist med 2–3 leverandører. Målet med presentasjonsrunden er å sette tilbudet under reelt press og se om systemet fungerer mot dine faktiske scenarier.

Be om en live gjennomgang, ikke en demo

En demo er en innøvd sekvens som viser systemet fra sin beste side. En gjennomgang er deg som sier «vis meg hvordan dere ville håndtert denne forsendelsen, fra lageret vårt i Nederland, med vår transportør, til vår avtalte pris» – og se hva som faktisk skjer.

Forbered 2–3 reelle scenarier fra din egen drift før møtet: en standard utgående bestilling, en forsendelse som trenger et spot-tilbud, og noe vanskelig – som en forsinket forsendelse eller en transportør som ikke leverer sporing. Når en leverandør stadig styrer tilbake til den polerte demoen i stedet for å kjøre scenariet ditt, har du svaret ditt der og da.

Utfordre hullene

Alle TMS-tilbud har dem. Gå rett på de delene der en leverandør svarte delvis eller der du har tvil, og bli der. Ikke la dem gli tilbake til noe som fungerer perfekt. Nøyaktig hvordan fungerer dette? Hvem gjør hva? Hva skjer når det ikke fungerer som forventet?

Få de rette menneskene i rommet

På leverandørsiden bør de som presenterer, være de som faktisk skal jobbe med implementeringen din – ikke bare salgsteamet. Be om det eksplisitt. På din side: ta med noen fra IT (hvis integrasjon er i omfanget), og minst én person som faktisk skal bruke systemet hver dag. De stiller andre spørsmål enn innkjøp gjør, og du vil ha begge settene med spørsmål stilt.

Andre runde – kun om nødvendig

For en kompleks beslutning er en andre økt fokusert på spesifikke temaer verdt tiden. Eksempler på temaer som kan dekkes:

• Sikkerhet og databeskyttelse – be om en pentest-rapport eller sikkerhetsdokumentasjon hvis IT- eller informasjonssikkerhetsteamet ditt krever det
• Integrasjonsarkitektur – en teknisk økt mellom IT-teamet ditt og leverandørens
• Kommersielle vilkår – gå gjennom kontrakten, SOW og forutsetninger linje for linje før du går inn i formelle forhandlinger

Ikke sett den opp bare for å gjenta det første møtet med flere folk i rommet. Enten løser den spesifikke åpne spørsmål, eller så bør den ikke skje.

Bekreft forpliktelser skriftlig

Alt en leverandør forplikter seg til i møtet som ikke er i det skriftlige tilbudet, må bekreftes skriftlig før du går videre. Muntlige forpliktelser overlever ikke kontraktsforhandlinger. Hvis en TMS-leverandør sier «ja, det kan vi gjøre» på noe viktig, følg opp med en e-post samme dag og be dem bekrefte.

TMS-kontrakt og SOW (arbeidsomfangsbeskrivelse): hva du bør sjekke før du signerer

Du har valgt leverandøren din. De fleste team «puster ut» på dette punktet. Jeg anbefaler at du ikke gjør det – for her er det detaljene alle gikk lett over under evalueringen stille og rolig blir ditt problem.

Bli enige internt før du forhandler

Kjenn dine absolutte krav, akseptable kompromisser og grenser for hva du kan godta, før samtalen starter. Å endre krav midt i forhandlingene koster tid, svekker tilliten og kan av og til koste deg den TMS-leverandøren du faktisk ønsket deg. Rydd opp internt først, og forhandle deretter.

Forstå hva du kjøper: SaaS, ikke en lisens

Moderne TMS-plattformer er SaaS-abonnementer, ikke programvarelisenser. Du abonnerer på en tjeneste som leverandøren drifter, vedlikeholder og oppdaterer – du kjøper ikke et system utright. Det forskyver hva kontrakten må dekke: abonnementsvilkår, oppsigelse, dataeierskap og eksportrettigheter, oppetidsforpliktelser og responstider for support. Standard innkjøpsmaler er ikke skrevet for denne modellen, så sørg for at din har hengt med i utviklingen.

SOW-en er like viktig som kontrakten

Arbeidsomfangsbeskrivelsen spesifiserer hva som leveres, av hvem og når: kontokonfigurasjon, transportøronboarding, integrasjonsstøtte, opplæring og akseptansekriteriene som sier at implementeringen faktisk er ferdig. Hvis det ikke er i SOW-en, er det ikke inkludert – uansett hva som ble sagt i et møte eller en e-post. Les forutsetnings-avsnittet spesielt nøye. Det er der omfanget er betinget definert. Viser det seg at transportørlisten din er større enn oppgitt, eller at ERP-en din trenger et ikke-standard integrasjonsformat, er det forutsetningsavsnittet som avgjør om det er en rask prat eller en priset endringsforespørsel.

Vær eksplisitt om hva som er utenfor omfanget

Egendefinert utvikling, opplæring på stedet, datamigrering, integrasjonsarbeid på dine systemer, endringer på transportørsiden. Disse prises vanligvis separat. Å få det på papiret før du signerer fjerner den vanligste – og mest unngåelige – kilden til friksjon under implementeringen: to parter som begge antok at noe annet var inkludert.

Avtal onboarding-planen før du signerer

Ikke etter. Transportørprioritering, konfigurasjonstidsplan, integrasjonsmilepæler, go-live-kriterier – avklar alt mens du fortsatt har forhandlingskraft. En leverandør som ikke kan gi deg en tydelig onboarding-plan på kontraktsstadiet, forteller deg noe du vil vite før du forplikter deg.

Etter signaturen: TMS-implementering og onboarding

Det meste av den reelle risikoen lever etter signaturen. Tre ting avgjør hvordan det går.

1. Datamigrering

Transportøravtaler, prislister, adressebøker, historiske forsendelser. Bestem tidlig hva du trenger å migrere, hva som ryddes opp først og hvem som eier arbeidet. Rotete kildedata er den vanligste grunnen til at go-live-datoen skyves stadig lenger ut. Rydd opp før du migrerer, ikke mens du migrerer.

2. Rekkefølge for transportøronboarding

Du kobler ikke til alle transportørene på dag én. Prioriter etter volum og kritikalitet, få de viktigste live og validert, og utvid deretter derfra. Det er nettopp her den fasede tilnærmingen du spurte om under evalueringen, viser sin verdi.

3. Brukeradopsjon

De som bestiller forsendelser hver dag, må ønske å bruke det nye systemet. Trekk inn minst én av dem fra RFP-stadiet og fremover, gi dem skikkelig opplæring under hypercare (onboarding), og sørg for at den daglige arbeidsflyten er genuint raskere enn det de gjorde før. En teknisk feilfri utrulling som teamet rett og slett ikke bruker, er fortsatt en mislykket utrulling.

10 vanlige feil i TMS-anbudsprosesser

Mønstrene vi ser oftest, samlet på ett sted:

• Ingen operativ kontekst. Den store. Ingen volumer, ingen lokasjonsstruktur, ingen transportørbilde gitt til leverandørene. En avklaringsrunde og generisk prising er garantert.
• Alt er must-have. Når alle krav er kritiske, er prioriteringskolonnen meningsløs og du kan ikke skille dealbreakers fra nice-to-have-er.
• Vag tidsplan. Ingen datoer betyr at leverandørene ikke kan estimere innsatsen sin, og tilbudene kommer tilbake like vage.
• Overspesifisering av løsningen. Å foreskrive den tekniske implementeringen i stedet for det operative resultatet utelukker gode løsninger av feil grunner.
• Å ignorere ERP/TMS-grensen. Å anta at TMS-et eier finansielle prosesser som ERP-et faktisk eier, og så oppdage det midt i implementeringen.
• Å velge på pris alene. Å velge basert på abonnementsoverskriften uten en treårsmodell, eller uten å vekte transportørtilkobling og ærlighet om integrasjon.
• Demo i stedet for gjennomgang. Å se på leverandørens innøvde sekvens i stedet for å la systemet teste dine reelle scenarier.
• Referanser som ikke matcher driften din. Å se på de imponerende logoene, men de selskapene kan ha logistikkoperasjoner som ikke ligner din i det hele tatt. Be om referanser som ligner deg, og spør dem deretter om hvordan onboarding og integrasjon faktisk gikk.
• Å utsette onboarding til etter signaturen. Planen du forhandler frem med forhandlingskraft, slår den du forhandler frem uten.
• En prosess som er for tung for den rette leverandøren. Byråkratisk overhead som kan filtrere ut de moderne plattformene som ville ha tjent deg best.

Gratis maler for TMS-anbudsforespørsler

Vi har bygget fem maler basert på forespørslene vi svarer på, slik at du slipper å starte fra blanke ark:

1. RFP-dokumentmal. Den fullstendige strukturen fra denne guiden.
2. Poengsettingsskjema for funksjonskrav. Prioritert, med en dekningskolonne per leverandør.
3. Sjekkliste for operativ informasjon. De ti spørsmålene som en utfyllingstabell.
4. Evalueringsmatrise for leverandører. Vektet poengsetting på tvers av leverandørene.
5. Tidsplanmal for RFP. Aktiviteter, datoer og ansvarlige.

Last ned pakken – alle fem, gratis, ingen e-post kreves. Ta det som er nyttig, ignorer resten:

Last ned den fullstendige malpakken for TMS-anbudsforespørsler (.zip)

Cargoson er et transportstyringssystem som brukes av mellomstore produsenter og grossister i Europa og Nord-Amerika. Vi svarer på forespørsler som den du er i ferd med å skrive hele tiden – så hvis du heller vil snakke gjennom kravene dine før du begynner å skrive, hjelper vi deg gjerne å tenke det igjennom, helt uforpliktende.

Bestill en gratis 30-minutters konsultasjon her

Kjør prosessen godt, og den er verdt hver eneste time.