Vastaamme kuljetuksenhallintajärjestelmien tarjouspyyntöihin (Request for Proposal) viikoittain. Osa niistä on ilo käsitellä. Osa opettaa, mitä ei kannata tehdä.
Tämä artikkeli on se, mitä itse rakentaisin, jos käynnistäisin TMS-valintaprosessin alusta tänään. Se perustuu tarjouspyyntöihin, joihin olemme vastanneet, eri yrityksissä ja toimialoilla toistuviin kaavoihin, siihen mitä useimmissa tarjouspyynnöissä on – ja mitkä virheet toistuvat.
Jos olet hankinta-asiantuntija, suurin osa tästä tuntuu tutulta. Toivottavasti jokin kohta säästää sinut ainakin yhdeltä turhalta tarkentavalta kierrokselta.
Mikä on TMS-tarjouspyyntö?
TMS-tarjouspyyntö (Request for Proposal) on jäsennelty asiakirja, jonka lähetät kuljetuksenhallintajärjestelmien toimittajille. Se kuvaa logistiikkatoimintasi ja pyytää jokaista toimittajaa esittämään, miten heidän järjestelmänsä vastaisi tarpeisiisi – samojen vaatimusten pohjalta. Koko idea on vertailukelpoisuus: samat kysymykset, sama muoto, sama konteksti, jotta vastaukset voi asettaa rinnakkain sen sijaan, että lukisi viisi erillistä myyntipuhetta.
Tarjouspyyntöä ei aina tarvita. Se kannattaa tehdä silloin, kun päätös on monimutkainen tai kun se on pystyttävä perustelemaan muille sisäisesti. Jos logistiikkatoimintasi on yksinkertaista, tuotedemo ja puhelu muutaman toimittajan kanssa riittävät.
Tarvitsetko todella TMS-kilpailutuksen?
Tämän arvioiminen väärin on koko TMS-valintaprosessin kallein virhe. Päätä tämä ennen kaikkea muuta.
Kyse on logistiikkasi monimutkaisuudesta – ei yrityksesi koosta.
Tee jäsennelty TMS-kilpailutus, jos lähetät tavaraa useista toimipisteistä, käytät useita kuljetusmuotoja ja tarvitset järjestelmän integroitumaan ERP:iisi. Silloin jokainen toimittaja on saatava rinnakkain tarkasteltavaksi, jotta mikään tärkeä ei jää huomaamatta. Kuljetusliikkeet liitetään järjestelmiin hyvin eri tavoin: yksi kutsuu sitä "natiiviksi", toinen reitittää hiljaa kaiken jonkin kolmannen osapuolen kautta. Löysässä prosessissa tämä selviää vasta sopimuksen allekirjoittamisen jälkeen – liian myöhään.
Jätä virallinen kilpailutus väliin, jos sinulla on yksi toimipiste, muutama kuljetusliike ja tiedät jo mitä tarvitset. Miksi? Koska heti kun käynnistät tarjouspyynnön, sijoitat itsesi enterprise-hinnoittelun piiriin. 2–3 hyvää demoa täsmällisillä kysymyksillä tuottavat usein paremman järjestelmän, edullisemmin ja nopeammin. Kerro näille 2–3 toimittajalle, mitä lähetät ja mitä ongelmaa ratkaiset, ja pyydä heitä näyttämään se live-järjestelmässään. Tunnissa tiedät jo vastauksen. Jos lähetät pääasiassa paketteja pikemmin kuin lavoja tai rahtia, täysimittainen TMS ei ehkä ole edes oikea ratkaisu – usean kuljetusliikkeen lähetysohjelmisto on eri, kevyempi kategoria, joka on rakennettu juuri sitä varten.
Ole siis rehellinen itsellesi ennen kuin aloitat. Tarpeettoman tarjouspyynnön käynnistäminen on hitain ja kallein tapa ostaa TMS.
Tarpeettoman tarjouspyynnön käynnistäminen on hitain ja kallein tapa ostaa TMS.
Vielä yksi varoitus, jos päätät silti tehdä täysimittaisen tarjouspyynnön. Prosessi, joka on täynnä hallintokieltä, metodologiakehyksiä ja kiinteän hinnan vaatimuksia, vie toimittajilta viikkoja käsitellä – ja toimittajat, joilla on resursseja siihen, ovat tyypillisesti suuria, vakiintuneita yrityksiä. Jos kevyempi ja modernimpi alusta palvelisi sinua paremmin, liiallinen byrokratia saattaa hiljaisesti suodattaa sen pois ennen kuin näet edes demon.
Tavoitteena on löytää sinulle oikea ratkaisu. Suunnittele prosessi sen mukaan – älä prosessin itsensä hallitsemiseksi.
TMS-tarjouspyyntöprosessin 9 vaihetta
TMS-valinta ei tarvitse olla monimutkainen. Se tarvitsee kuitenkin selkeän järjestyksen. Ohita vaiheita ja maksat siitä myöhemmin – yleensä käyttöönoton aikana, kun oletukset, jotka olisi pitänyt selventää ajoissa, muuttuvat kalliiksi yllätyksiksi.
Hyvin toteutettuna koko prosessi kestää 8–12 viikkoa. Yksinkertaisessa tapauksessa vähemmän, ja harvoin tarvitaan enemmän.
Tässä on toimiva järjestys:
- Markkinakartoitus. Ennen kuin kirjoitat yhtäkään vaatimusta, käytä aikaa ymmärtääksesi, mitä markkinoilla on tarjolla. TMS-markkinat ovat muuttuneet paljon viiden viime vuoden aikana: tarjolla on hyviä enterprise-alustoja, hyviä keskisuuren markkinan alustoja ja aidosti kyvykkäitä moderneja SaaS-kuljetuksenhallintaohjelmistoja, joita ei viisi vuotta sitten ollut olemassa. Kokoa pitkä lista 5–8 lähestymisen arvoisesta TMS-toimittajasta.
- Salassapitosopimus (NDA). Lähetä se ajoissa. Jaat operatiivista dataa – volyymeja, kuljetusliikkeiden nimiä ja sisäisten järjestelmien tietoja – ja allekirjoitettu NDA ennen tarjouspyynnön lähettämistä on vakiintunut käytäntö, joka suojaa molempia osapuolia.
- RFI (valinnainen). Lyhyt tietopyyntö (Request for Information) on järkevä, jos pitkä listasi on laaja ja haluat karsia toimittajia ennen kuin investoit täysimittaiseen tarjouspyyntöprosessiin. Pidä se yhden sivun mittaisena: yrityksen tausta, keskeiset kyvykkyydet, karkea hintahaarukka. Riittävästi lyhytlistauksen tekemiseen ilman, että pyydät toimittajia kirjoittamaan esseitä.
- Tarjouspyyntö (RFP). Prosessin ydinasiakirja. Se antaa jokaiselle toimittajalle tiedot, joita he tarvitsevat tarkan tarjouksen tekemiseen. Lisää tästä seuraavassa luvussa.
- Kysymys- ja vastausikkuna. Sisällytä se aina. Toimittajilla on kysymyksiä, ja vastaukset parantavat usein jokaista saamaasi tarjousta. Hoida se kirjallisesti ja jaa kaikki kysymykset ja vastaukset kaikille toimittajille samanaikaisesti. Pitää prosessin siistinä ja vertailukelpoisena.
- Lyhytlista ja esittelyt. Pisteytä kirjalliset tarjoukset ja kutsu sitten 2–3 toimittajaa esittelemään. Esittelyn tulisi sisältää live-järjestelmän läpikäynti omien todellisten käyttötapauksiesi pohjalta – ei yleinen demo. Jos toimittaja ei pysty näyttämään skenaariosi järjestelmässään, sekin on hyödyllistä tietoa.
- Toinen kierros (tarvittaessa). Monimutkaisessa päätöksessä syvempi istunto, joka keskittyy tiettyihin avoimiin kohtiin kuten tietoturvaan, integraatioon tai kaupallisiin ehtoihin, on ajan arvoinen. Älä aikatauluta sitä, ellei sinulla ole aitoja avoimia kysymyksiä.
- Päätös ja sopimus. Sovi sisäisesti ennen neuvottelujen aloittamista. Tiedä ehdottomat vaatimuksesi, hyväksyttävät kompromissisi ja rajasi.
- Käyttöönotto. Prosessi ei pääty allekirjoitukseen. Parhaissa tarjouspyyntötuloksissa käyttöönottosuunnitelma on sovittu ennen sopimuksen allekirjoittamista.
TMS-tarjouspyynnön aikataulu, jonka voit kopioida
Vaihe | Toimenpide | Tyypillinen aikataulu |
|---|---|---|
Valmistelu | Markkinakartoitus, pitkä lista, NDA:t, tarjouspyyntöasiakirjat valmiiksi | Viikot 1–3 |
Tarjouspyyntöprosessi | Tarjouspyyntö lähetetty, kysymys- ja vastausikkuna, tarjoukset vastaanotettu | Viikot 3–6 |
Arviointi | Tarjousten pisteytys, lyhytlista 2–3 toimittajasta | Viikot 6–8 |
Esittelyt | Ensimmäinen kierros, valinnainen toinen syväsukelluskierros | Viikot 8–10 |
Päätös | Lopullinen pisteytys, sisäinen suositus, päätöksen viestintä | Viikot 10–11 |
Sopimus | Sopimus ja työmääräys (SOW), käyttöönottosuunnitelma sovittu, aloituskokous | Viikot 11–12+ |
Karkea kesto laajuuden mukaan:
- Yksinkertainen yhden toimipisteen tapaus: 6–8 viikkoa (täysimittaista tarjouspyyntöä ei välttämättä tarvita).
- Useita toimipisteitä + ERP-integraatio: 8–12 viikkoa.
- Globaali, moniyksikköinen, monimutkainen integraatio: 12–20 viikkoa, todennäköisesti kaksi esittelykierrosta.
Lataa aikataulumallipohja (.docx)
Mitä TMS-tarjouspyyntöasiakirjan tulisi sisältää
Tarjouspyyntöasiakirja on prosessin tärkein työkalu. Hyvä tarjouspyyntö tekee suurimman osan arviointityöstä puolestasi – pidä se siis tiiviinä. Napakka 10-sivuinen tarjouspyyntö päihittää 30-sivuisen, joka yrittää kattaa kaiken.
1. Saatekirje ja tavoite
Yksi sivu. Kuka olet, mitä etsit ja miksi juuri nyt. Pidä se asiallisena. Toimittajat eivät tarvitse visiojulistusta – he tarvitsevat ymmärryksen operatiivisesta ongelmastasi.
2. Aikataulu
Selkeä aikataulu oikeilla päivämäärillä: tarjouspyynnön lähetyspäivä, kysymysten deadline, tarjousten jättöpäivä, esittelyikkuna ja päätöspäivä. Toimittajat suunnittelevat vastauksensa tämän pohjalta. Epämääräinen aikataulu tuottaa epämääräisiä tarjouksia.
3. Yritys- ja operatiivinen taustatiedot
Tässä useimmat tarjouspyynnöt epäonnistuvat – ja tämä on se ero, joka ratkaisee, saatko vertailukelpoisia tarjouksia vai tarkentavan lisäkierroksen. Älä vain kuvaile liiketoimintaasi, vaan kuvaile logistiikkatoimintasi. Kuinka monta toimipistettä. Kuinka monta oikeushenkilöä. Mitä kuljetusmuotoja (paketti, LTL, FTL, lento, meri, rautatie). Mitkä alueet. Arvioidut volyymit. Nykyiset järjestelmät. Se, mitä "hyvä" tarkoittaa, vaihtelee myös toimialoittain – vaatimukset elektroniikka-, kone-, kemianteollisuuden tai painatus- ja pakkausvalmistajien tarpeisiin eivät ole samat. Tämä on se konteksti, jonka toimittajat tarvitsevat tarjouksensa rajaamiseen. Jos et anna riittävästi tietoja tässä kohdassa, käytät kaksi viikkoa vastaamalla tarkentaviin kysymyksiin, jotka olisi voitu välttää kokonaan. Tästä on oma lukunsa jäljempänä.
4. Toiminnalliset vaatimukset
Taulukko siitä, mitä järjestelmän on tehtävä, priorisoituna tärkeysjärjestykseen: pakollinen / tärkeä / kiva olla (Excel käy hyvin). Pyydä toimittajia vastaamaan jokaiseen vaatimukseen kattavuusluokituksella: a) natiivi, b) kolmas osapuoli, c) räätälöinti tai d) ei tuettu. Tämä tekee tarjouksista vertailukelpoisia. Lisää tästä myöhemmin.
5. Arviointikriteerit
Kerro toimittajille, miten teet päätöksen: toiminnallisuus, hinta, käyttöönottotapa, referenssit, tietoturva, tiimi. Jaa painotukset, jos olet valmis siihen. Mitä läpinäkyvämpi olet, sitä parempia tarjouksia saat.
6. Hinnoittelumalli
Pyydä täydellinen erittely: tilausmaksu, käyttöönotto, transaktiokohtaiset maksut, tuki ja kaikki muu. Pyydä tarvittaessa esimerkkilasku. Hinnoittelurakenteet vaihtelevat toimittajien välillä huomattavasti, ja piilokulut nousevat esiin yleensä myöhään. Selvitä ne ajoissa.
7. Vastausmuoto
Kerro toimittajille täsmälleen, miten haluat tarjouksen jäsenneltävän, ja jos annat mallipohjia, vaadi niiden käyttöä. Vertailukelpoiset tarjoukset säästävät päiviä arvioinnissa, ja muoto on täysin sinun hallinnassasi.
Lataa tarjouspyyntöasiakirjan mallipohja aloittaaksesi yllä olevasta täydestä rakenteesta:
Lataa tarjouspyyntöasiakirjan mallipohja (.docx)
Operatiiviset tiedot, jotka useimmista TMS-tarjouspyynnöistä puuttuvat – ja miksi ne ovat tärkeimpiä
Tämä on luku, jonka toivoisin jokaisen TMS-tarjouspyynnön kirjoittajan lukevan ensin.
Vastaamme moniin TMS-kilpailutuksiin. Lähes jokainen kirjoittamamme tarjous vaatii tarkentavan kierroksen – ja harvoin siksi, että vaatimukset olisivat epäselviä. Syy on se, että operatiivinen konteksti puuttuu: volyymit, toimipisterakenne, kuljetusliikekuvaus, nykyiset järjestelmät.
Tarjouspyynnöillä, jotka vaativat täysimittaisen tarkentavan kierroksen, on lähes aina yksi yhteinen piirre:
Olemme nähneet yritysten käyttävän viikkoja arviointikriteerien ja vaatimuslistojen hiomiseen – ja lähettävän sitten tarjouspyynnön, jossa ei mainita lainkaan, kuinka monta lähetystä he käsittelevät kuukaudessa.
Ilman tätä tietoa toimittajat arvaavat. Ja kun he arvaavat, tarjoukset jäävät yleisluonteisiksi, hinnoittelu ei ole lopullinen eikä mitään ole mahdollista vertailla kunnolla.
Esimerkiksi globaali valmistaja, jolla on 10 varastoa ja SAP, tarvitsee täysin erilaisen tarjouksen kuin yhden toimipisteen jakelija, joka hoitaa logistiikkansa taulukkolaskennan avulla. Jos toimittaja ei pysty päättelemään, kumpi olet, hän varautuu molempiin – ja saat tarjouksia, jotka eivät sitoudu mihinkään.
Korjaus vie yhden iltapäivän. Vastaa näihin kymmeneen kysymykseen tarjouspyynnössä ennen sen lähettämistä.
- Organisaatio ja laajuus. Kuinka monta oikeushenkilöä ja toimipistettä on mukana? Onko käyttöönotto rinnakkainen vai vaiheistettu? Kuinka itsenäisesti toimipisteet toimivat – omat kuljetusliikesopimukset, omat tiimit?
- Lähetysvolyymit. Kuukausittaiset ja päivittäiset lähetysmäärät toimipisteittäin, keskiarvo ja huippu. Mahdollinen kausiluonteisuus. Saapuvien ja lähtevien lähetysten suhde.
- Kuljetusmuotojakauma. Mikä osuus on paketteja, LTL:ää, FTL:ää, lentoa, merikuljetusta? Mitkä kuljetusmuodot kasvavat? Mitkä ovat operatiivisesti kriittisimpiä?
- Kuljetusliikekuvaus. Kuinka monta kuljetusliikettä toimipisteittäin ja kuljetusmuodoittain? Yhteisiä eri toimipisteiden kesken vai paikallisesti hallittuja? Onko strategisia kuljetusliikkeitä, joille on annettava etusija, tai asiakkaan nimeämiä kuljetusliikkeitä, joita ei voi vaihtaa?
- Maantiede ja kuljetusreitit. Mitkä alueet ovat mukana? Mitkä reitit ovat tärkeimpiä: kotimaa, rajat ylittävä, mannertenvälinen? Keskeiset satamat tai logistiikkakeskukset?
- Nykytila. Miten lähetyksiä suunnitellaan, tilataan ja seurataan tänään? ERP:ssä, taulukkolaskennassa, kuljetusliikkeiden portaaleissa, sähköpostilla? Mitkä ovat nykyisen prosessin suurimmat kipupisteet?
- Taloudellinen rakenne. Kuka maksaa kuljetukset – yksi vai useampi yksikkö? Onko kolmannen osapuolen tai asiakkaan tilinumeroita? Miten rahtikustannukset kirjataan ja tarkistetaan tänään?
- Liiketoimintamalli. B2B, B2C? Jos molempia, mikä on jakauma. Operatiiviset ja järjestelmävaatimukset eroavat toisistaan merkittävästi.
- Integraatioympäristö. Mitkä järjestelmät on liitettävä TMS:ään: ERP, WMS, CRM? Onko olemassa olevia kuljetusliike-integraatioita, jotka on säilytettävä? Kuinka automatisoitu prosessin on oltava heti alusta alkaen?
- Aikataulu ja rajoitteet. Onko käyttöönotolle tavoitepäivämäärä? Onko sisäisiä välitavoitteita – kuten tilikauden päättyminen, sesonkihuippu tai järjestelmämigraatiot – jotka vaikuttavat aikatauluun?
Mikään näistä ei ole vaikea kirjoittaa. Mutta ne muuttavat kaiken siinä, mitä saat vastaukseksi.
Lataa operatiivisten tietojen tarkistuslista, joka muuttaa nämä kymmenen kysymystä täytettäväksi taulukoksi suoraan tarjouspyyntöösi:
Lataa operatiivisten tietojen tarkistuslista (.docx)
Kuinka kirjoittaa TMS:n toiminnalliset vaatimukset
Toiminnalliset vaatimukset ovat tarjouspyynnön ydin. Kun ne ovat kunnossa, saat selkeän ja vertailukelpoisen kuvan siitä, mitä kukin toimittaja pystyy ja ei pysty tekemään. Kun ne ovat pielessä, saatat käyttää viikkoja purkamaan vastauksia, joissa kaikki sanovat "kyllä".
Tavoitteena ei ole pisin lista. Tavoitteena on rehellisin lista.
Priorisoi armottomasti: pakollinen, tärkeä, kiva olla
Kaikki haluamasi asiat eivät ole yhtä tärkeitä. Käytä kolmea kategoriaa ja pidä niistä kiinni:
- Pakollinen (P): ei neuvoteltavissa. Toimittaja, joka ei täytä tätä, on poissa pelistä – riippumatta muista ansioistaan.
- Tärkeä (T): merkittävä, mutta voit elää väliaikaisratkaisun tai lähiajan tiekartalupauksen kanssa.
- Kiva olla (K): hyvä tietää, mutta se tulee kaiken muun jälkeen.
Useimmissa listoissa on aivan liian monta pakollista vaatimusta. Jos kaikki on kriittistä, mikään ei ole. Ole rehellinen siitä, mikä todella estäisi järjestelmän toiminnan sinulle – ja merkitse vain ne pakollisiksi.
Pyydä toimittajia luokittelemaan toiminnallisuuden kattavuus: natiivi / kolmas osapuoli / räätälöinti
Jokaisen vaatimuksen kohdalla pyydä heitä vastaamaan yhdellä näistä:
Kattavuus | Mitä se tarkoittaa |
|---|---|
Natiivi | Saatavilla heti käyttöönotosta, ei lisätyötä |
Kolmas osapuoli | Toimitetaan kumppanin tai ulkoisen järjestelmän kautta |
Räätälöinti | Mahdollinen, mutta vaatii kehitystyötä ja lisäkustannuksia |
Ei tuettu | Ei saatavilla |
Tässä sarakkeessa tarjoukset joko ansaitsevat tai menettävät luottamuksesi. Toimittaja, joka vastaa rehellisesti ja kirjoittaa ei tuettu silloin kun se pitää paikkansa, näyttää, miten he käyttäytyvät kumppanina. Toimittaja, joka vastaa natiivi kaikkeen, kertoo myös jotain tärkeää.
Ole täsmällinen kysymyksessä
"Tukeeko järjestelmä kuljetusliikkeiden hinnoittelua?" tuottaa hyödyttömän "kyllä"-vastauksen. "Pystyykö järjestelmä laskemaan rahtihinnan jokaiselle kuljetusliikkeelle – myös niille, joilla ei ole hinnoittelurajapintaa – ja näyttämään ne rinnakkain lähetyskohtaisesti?" tuottaa jotain, mitä voit oikeasti arvioida.
Missä ERP loppuu ja TMS alkaa?
Yksi yleisimmistä sekaannuksen lähteistä kuljetuksenhallintajärjestelmien arvioinnissa on se, missä TMS loppuu ja ERP alkaa.
Taloudelliset prosessit kuten kirjanpitotilikoodaus, maahantulokustannukset ja rahtilaskujen tarkistus hoidetaan usein ERP:n puolella, jolloin TMS syöttää tiedot ERP:iin. Tämä on normaalia ja usein oikea ratkaisu. Se on kuitenkin kirjoitettava auki. Kun toimittaja vastaa "hoidetaan ERP-integraation kautta" johonkin pakolliseen vaatimukseesi, selvitä tarkalleen, mitä se tarkoittaa käyttöönottosi kannalta – ja kuka sen rakentaa.
Määrittele tavoite, ei tekninen ratkaisu
Kuvaile, mitä sinun täytyy saavuttaa – älä sitä, miten järjestelmän pitäisi teknisesti se toteuttaa. Liian yksityiskohtaiset tekniset vaatimukset karsivat hyviä ratkaisuja vääristä syistä. Anna toimittajille tilaa näyttää parempi tapa kuin se, jonka itse keksit – joskus heillä on sellainen.
30 rehellisen, priorisoidun vaatimuksen lista kertoo enemmän kuin 150 rivin taulukko, jossa kaikki on kriittistä ja jokainen toimittaja on rastittanut jokaisen kohdan.
Aloituspaketti TMS-vaatimuksista, jota voit muokata
Useimmat ensikertalaiset haluavat pääsyn alkuun listan kanssa, joten tässä on esimerkkikokoelma kokemuksemme pohjalta, jo kategorisoituna, jonka voit muokata omaan toimintaasi sopivaksi. Täydellinen lista on ladattavissa alla olevassa pisteytyslomakkeessa – tämä riittää antamaan kuvan kokonaisuudesta.
Vaatimus | Prioriteetti |
|---|---|
Suora API-integraatio nykyisten kuljetusliikkeidesi kanssa | Pakollinen |
Sähköpostipohjainen tilaaminen kuljetusliikkeille, joilla ei ole API:a | Pakollinen |
Uuden kuljetusliikkeen lisääminen määritellyn prosessin ja aikataulun mukaisesti | Pakollinen |
Rinnakkainen rahtihintojen vertailu kaikkien kuljetusliikkeiden kesken lähetyskohtaisesti | Pakollinen |
Kuljetustilauksen luominen manuaalisesti ja API:n kautta | Pakollinen |
Kaubaetikettien, CMR:n ja rahtikirjojen luonti – myös toimittajan puolelta, kun kuljetusliike ei pysty siihen | Pakollinen |
Reaaliaikainen seuranta API-yhteensopivilla kuljetusliikkeillä yhtenäisellä tapahtumarakenteella | Pakollinen |
Keskitetty lähetysnäkymä kaikille toimipisteille ja kuljetusliikkeille | Pakollinen |
Yksi yhtenäinen API, joka tarjoaa kaikki kuljetusliikkeet ERP:llesi tai WMS:llesi | Pakollinen |
Kaksisuuntainen ERP-synkronointi: tilaukset sisään, vahvistukset, seuranta ja asiakirjat ulos | Pakollinen |
Roolipohjainen käyttöoikeuksien hallinta ja erilliset työtilat toimipisteittäin tai yksiköittäin | Pakollinen |
Pakollinen | |
Määritelty SLA ja vasteajat | Pakollinen |
Automaattinen kuljetusliikkeen valinta hinnan, toimitusajan tai kuljetusmuodon perusteella | Tärkeä |
ETA-päivitykset ja poikkeamahälytykset (myöhästynyt nouto, viivästynyt toimitus) | Tärkeä |
Kuljetusliikkeiden suorituskyvyn KPI-näkymä ja kustannusraportointi kuljetusliikkeittäin, reiteittäin ja kuljetusmuodoittain | Tärkeä |
Tärkeä | |
Toimittajaportaali ja kertakirjautuminen (SSO) | Tärkeä |
Lähetysten konsolidointi | Kiva olla |
Asiakkaalle näkyvä seurantaportaali | Kiva olla |
Oman kaluston hallinta ulkoisten kuljetusliikkeiden rinnalla | Kiva olla |
Lataa toiminnallisten vaatimusten pisteytyslomake, joka on valmiiksi rakennettu prioriteettiluokitteluineen ja kattavuussarakkeella toimittajakohtaisesti:
Lataa toiminnallisten vaatimusten pisteytyslomake (.docx)
Kuinka vertailla TMS:n kustannuksia (ja rakentaa 3 vuoden malli)
"Paljonko TMS maksaa?" on kysymys, johon ostajat haluavat eniten vastauksen ja jota toimittajat mieluiten välttelevät. Tilausmaksu on kuitenkin harvoin lopullinen kustannuksesi. Keskisuurelle, useamman toimipisteen yritykselle käyttöönotto ja integraatiot voivat jopa ylittää kuukausimaksun kolmen vuoden kokonaiskustannuksessa – ja juuri tästä erästä toimittajat puhuvat epämääräisimmin. Taito on siis muotoilla kysymys niin, että vastaukset ovat vertailukelpoisia ja todelliset kustannukset näkyvät.
Karkeana suuntaviivana: keskimarkkinan pilvipohjaiset kuljetuksenhallintaohjelmistot maksavat tyypillisesti muutamasta sadasta muutamaan tuhanteen euroon kuukaudessa, kun taas perinteiset enterprise-järjestelmät maksavat kymmenistä tuhansista yli miljoonaan euroon vuodessa, ja käyttöönotto voi nousta kuusi- tai seitsennumeroiseksi. Tämä on laaja vaihteluväli – ja juuri siksi vertailukelpoinen malli on tärkeämpi kuin mikään yksittäinen luku. Todellisten TMS-toimittajien hinnoittelusta saat käsityksen tutkimuksestamme parhaista TMS-toimittajista.
TMS-hinnoittelun komponentit
Lähes jokainen TMS-tarjous koostuu jostakin näiden yhdistelmästä:
Komponentti | Mitä se on | Mitä kannattaa tarkkailla |
|---|---|---|
Käyttöönotto / asennus | Kertamaksu konfiguroinnista, käyttöönotosta ja integraatiotuesta | Vaihtelee paljon – tähän voi piiloutua katetta |
Tilausmaksu | Toistuva maksu, usein toimipisteittäin, yksiköittäin tai käyttäjittäin | Tarkista yksikkö. Käyttäjäkohtainen skaalautuu hyvin eri tavalla kuin toimipistekohtainen |
Transaktiokohtaiset maksut | Lähetyskohtainen, etikettikohteinen tai API-kutsukohtainen | Kerro todellisella kuukausittaisella volyymillasi ennen vertailua |
Tuki ja SLA | Porrastettu tuki, vasteajat | Tarkista, mitä perustaso todella sisältää |
Muuttuvat lisät | Uudet kuljetusliike-integraatiot, lisämoduulit, räätälöinti | Kysy, maksavatko uudet kuljetusliikkeet erikseen. Tämä kertyy |
Rakenna kolmen vuoden kustannusmalli ennen vertailua
Tilausmaksultaan edullinen TMS-toimittaja voi osoittautua kalleimmaksi, kun käyttöönotto, transaktiokohtaiset maksut ja kuljetusliikkeiden liittäminen lasketaan mukaan. Aja jokainen toimittaja saman mallin läpi:
3 vuoden kustannus = käyttöönotto + (vuosittainen tilausmaksu × 3) + (lähetyskohtainen maksu × vuosivolyymi × 3) + tuki + odotetut kuljetusliike- ja integraatiolisät.
Käytä todellisia volyymejasi – älä toimittajan siistejä esimerkilukuja. Tämä yksi taulukko muuttaa usein lyhytlistan järjestystä.
Tarkkaile eri hinnoittelukomponentteja, ei vain perusmaksua
Jotkut toimittajat hinnoittelevat tilausmaksun matalaksi ja kattavat sen transaktio- tai kuljetusliikemaksuilla. Se ei ole automaattisesti huono asia, mutta se muuttaa sen, kuka on edullisin kasvun myötä. Jos volyymisi kasvaa, lähetyskohtainen malli voi ohittaa kiinteän hinnan nopeasti. Pyydä esimerkkilasku ja tilausehdot, jotta vertailet sitä, mitä todella maksat – et otsikkohinnoittelua.
Yksi kysymys, joka kannattaa esittää jokaiselle toimittajalle: sisältyvätkö uudet kuljetusliike-integraatiot hintaan vai laskutetaanko ne erikseen? Jotkut TMS-alustat veloittavat 5 000–10 000 euroa uudesta kuljetusliike-integraatiosta ja ne vievät kuukausia, toiset rakentavat uudet integraatiot ilman lisäkustannuksia. Keskisuurelle yritykselle, joka lisää kuljetusliikkeitä vuosien varrella, tämä yksi vastaus voi vaikuttaa kolmen vuoden kokonaiskustannukseen enemmän kuin tilausmaksu koskaan.
Kuinka arvioida TMS-tarjouksia hinnan lisäksi
Tarjoukset ovat saapuneet. Ne kaikki näyttävät kohtuullisilta, useimmat vastaavat myöntävästi vaatimuksiisi ja hinnoittelu on samassa haarukassa. Mitä nyt?
Tässä vaiheessa tiimit ajautuvat hiljaa takaisin hinnan varaan, koska kaiken muun vertailu tuntuu vaikeammalta. Älä tee niin. Tässä on se, mikä todella erottaa toimittajat toisistaan.
1. Kuljetusliikeyhteydet.
TMS:ssä kuljetusliikeyhteydet ovat perusta. Miten toimittaja oikeasti liittää kuljetusliikkeet – suorilla API/EDI-integraatioilla, kolmannen osapuolen aggregaattoreilla vai ei lainkaan (sähköposti ja PDF-tilaukset riippumatta kuljetusliikkeen IT-kyvyistä)? Mitä tapahtuu, kun tarvitset kuljetusliikettä, jota he eivät vielä tue – kauanko se kestää ja mitä se maksaa?
Toimittaja, jolla on syvät, suorat kuljetusliikeyhteydet, on eri asia kuin toimittaja, joka reitittää kaiken välikerroksen kautta. Eron huomaa tilausten luotettavuudessa, seurannan laadussa ja siinä, pystyykö lisäämään kuljetusliikkeen avaamatta uutta kaupallista neuvottelua joka kerta.
2. Kuljetusliikkeiden palvelutason yhtenäistäminen – tämä merkitsee enemmän kuin useimmat ymmärtävät.
Kuljetusliikkeillä on hyvin erilaiset digitaaliset valmiudet. Joillakin on kehittyneet API:t, jotka kattavat reaaliaikaisen hinnoittelun, ETA-ennusteet, osoitevalidoinnin, etikettien luonnin ja yksityiskohtaiset seurantatapahtumat. Toiset lähettävät tilausvahvistuksen sähköpostilla – siinä kaikki. Useimmissa kuljetusliikeverkoissa on molempia samanaikaisesti.
Tämä muuttuu sinun ongelmaksesi heti, kun liität ERP:si tai WMS:si TMS:ään. Jos integraatiosi odottaa täydellistä dataa jokaiselta kuljetusliikkeeltä – tilausvahvistus, seurantalinkki, etiketti, kustannusarvio – mutta jotkut kuljetusliikkeet eivät pysty toimittamaan sitä, syntyy poikkeuksia, manuaalisia väliaikaisratkaisuja ja aukkoja datassasi. Yksi heikko kuljetusliike rikkoo koko työnkulun yhtenäisyyden.
Eri kuljetuksenhallintaohjelmistot käsittelevät tämän kahdella tavalla, ja kannattaa päättää kumman haluat ennen kuin luet yhtäkään tarjousta:
- Ohuempi TMS välittää sen, mitä kukin kuljetusliike tarjoaa, ja sinun tehtäväksesi jää käsitellä aukot ERP:ssäsi tai manuaalisesti. Yksinkertaisempi integraatio, enemmän poikkeuksia hoidettavaksi omalta puoleltasi.
- TMS, joka normalisoi datan ja täyttää aukot itse: laskee rahtihinnan ladatusta hinnastosta, kun hinnoittelurajapintaa ei ole; arvioi toimitusajan, kun kuljetusliike ei tarjoa ETA:a; luo lähetysetiketit, kun kuljetusliike ei pysty siihen; antaa kuljetusliikkeille mahdollisuuden syöttää seurantavälitavoitteet manuaalisesti, kun automaattista seurantaa ei ole – ja paljon muuta. Ohjelmisto täyttää kuljetusliikkeidesi teknisten valmiuksien aukot, ja ERP:si näkee yhtenäisen rakenteen.
Tarjouksia arvioidessasi kysy toimittajilta suoraan: miten käsittelette kuljetusliikkeitä, joilla on rajalliset digitaaliset valmiudet? Vastaus kertoo paljon siitä, kuinka kypsä heidän alustansa todella on.
3. Rehellisyys integraatiosta.
Kiinnitä tarkkaa huomiota siihen, miten toimittajat kuvaavat integraation laajuutta (kuka tekee mitä). Tarjous, jossa sanotaan selvästi "ERP-puolen kehitys on teidän vastuullanne, tässä on mitä me tarjoamme ja miten tuemme sitä", on luotettavampi kuin tarjous, joka vihjaa "saumattomaan integraatioon" selittämättä, kumpi osapuoli hoitaa minkäkin osan. Integraatioyllätykset ovat yksi yleisimmistä syistä, miksi TMS-projektit ylittävät ajan ja budjetin.
4. Käyttöönottotapa.
Vaiheistettu lähestymistapa – ensin manuaalinen operatiivinen validointi, sitten automaatio – on yleensä pienempi riski kuin kertakäyttöönotto. Näin voit varmistaa, että järjestelmä toimii todellisissa työnkuluissasi ennen kuin nojaat koko toimintasi sen varaan. Meidän puoleltamme katsottuna toimittajat, jotka ehdottavat tätä ilman pyyntöä, ovat yleensä kokeneet sekavan käyttöönoton aiemmin. Ne, jotka myyvät täyttä automaatiota heti alusta, eivät usein ole.
5. Referenssit
Pyydä referenssejä yrityksistä, joilla on samankaltainen toiminta – ei vain samankaltainen koko tai henkilöstömäärä. Referenssi yhden toimipisteen jakelijalta ei ole kovin hyödyllinen, jos pyörität useamman toimipisteen valmistustoimintaa SAP-integraatiolla. Ja esitä täsmälliset kysymykset: "Miten kuljetusliikkeiden liittäminen sujui?" "Miten integraatioprosessi eteni?" "Mitä tapahtui, kun jokin ei toiminut odotetusti?"
6. Tarjous itsessään.
Se, miten TMS-toimittaja vastaa tarjouspyyntöösi, on esimakua siitä, miten he käyttäytyvät kumppanina. Vastasiko hän kysymyksiisi suoraan vai käärivätkö he kaiken varauksiin? Myönsikö hän aukot rehellisesti vai väittikö täyttä kattavuutta jokaiseen vaatimukseen? Osoittiko hän ymmärtävänsä toimintasi vai lähettikö hän hieman muokatun version vakioesityksestään?
Tarjous, joka myöntää ei tuettu kahdessa kohdassa ja selittää miksi, on arvokkaampi kuin tarjous, joka sanoo kyllä kaikkeen. Totuus selviää joka tapauksessa. Parempi selvittää se arvioinnin aikana kuin käyttöönotossa.
Lataa toimittajien arviointimatriisi toimittajien pisteytykseen painotetuilla kriteereillä:
Lataa toimittajien arviointimatriisi (.docx)
TMS-toimittajan esittelykierros
Kirjalliset tarjoukset kertovat, mitä toimittaja väittää. Esittelyt kertovat, pystyykö hän lunastamaan sen.
Tässä vaiheessa sinulla pitäisi olla lyhytlista 2–3 toimittajasta. Esittelykierroksen tavoitteena on asettaa tarjous todelliseen paineeseen ja nähdä, toimiiko järjestelmä omien skenaarioidesi pohjalta.
Pyydä live-läpikäyntiä, ei demoa
Demo on harjoiteltu sekvenssi, joka esittää järjestelmän parhaimmillaan. Läpikäynti tarkoittaa, että sanot "näytä, miten käsittelisit tämän lähetyksen Alankomaiden varastostamme, meidän kuljetusliikkeellämme, sovitulla hinnallamme" – ja katsot, mitä oikeasti tapahtuu.
Valmistele 2–3 todellista skenaariota omasta toiminnastasi ennen tapaamista: tavallinen lähtevä tilaus, lähetys, joka tarvitsee spot-tarjouksen, ja jokin hankalampi tapaus – kuten viivästynyt lähetys tai kuljetusliike, joka ei tarjoa seurantaa. Kun toimittaja ohjaa jatkuvasti takaisin kiillotettuun demoon sen sijaan, että ajaisi läpi skenaariosi, se on jo vastaus.
Haasta aukot
Jokaisessa TMS-tarjouksessa niitä on. Mene suoraan niihin kohtiin, joissa toimittaja vastasi osittain tai joissa sinulla on epäilyksiä, ja pysy siellä. Älä anna heidän liukua takaisin johonkin, mikä toimii hienosti. Miten tämä tarkalleen toimii? Kuka tekee mitä? Mitä tapahtuu, kun se ei toimi odotetusti?
Tuo oikeat ihmiset paikalle
TMS-toimittajan puolelta esittelevien henkilöiden pitäisi olla ne, jotka todella työskentelevät käyttöönotossasi – ei pelkästään myyntitiimi. Pyydä tätä nimenomaisesti. Omalta puoleltasi tuo mukaan IT-edustaja (jos integraatio on laajuudessa) ja vähintään yksi henkilö, joka käyttää järjestelmää päivittäin. He esittävät erilaisia kysymyksiä kuin hankinta – ja haluat molemmat kysymyssarjat esitettäviksi.
Toinen kierros vain tarvittaessa
Monimutkaisessa päätöksessä toinen istunto tiettyihin aiheisiin keskittyen on ajan arvoinen. Esimerkkiaiheita:
- Tietoturva ja tietosuoja – pyydä penetraatiotestiraportti tai tietoturvadokumentaatio, jos IT- tai tietoturvatiimisi sitä edellyttää
- Integraatioarkkitehtuuri – tekninen istunto IT-tiimisi ja toimittajan välillä
- Kaupalliset ehdot – käy sopimus, SOW ja oletukset läpi rivi riviltä ennen virallisia neuvotteluja
Älä varaa sitä vain toistaaksesi ensimmäisen kokouksen enemmillä osallistujilla. Joko se ratkaisee tiettyjä avoimia kysymyksiä, tai sitä ei pidä järjestää.
Vahvista sitoumukset kirjallisesti
Kaikki, mihin toimittaja sitoutuu kokouksessa mutta mitä ei ole kirjallisessa tarjouksessa, on vahvistettava kirjallisesti ennen etenemistä. Suulliset sitoumukset eivät selviä sopimusneuvotteluista. Jos TMS-toimittaja sanoo "kyllä, pystymme siihen" jossakin tärkeässä asiassa, lähetä sähköposti samana päivänä ja pyydä vahvistus.
TMS-sopimus ja SOW (työmääräys): mitä tarkistaa ennen allekirjoittamista
Olet valinnut toimittajasi. Useimmat tiimit "hengähtävät" tässä vaiheessa. Suosittelen, ettet tee niin – tässä on se kohta, jossa arvioinnin aikana sivuutetut yksityiskohdat muuttuvat hiljaa sinun ongelmiksesi.
Sovi sisäisesti ennen neuvotteluja
Tiedä ehdottomat vaatimuksesi, hyväksyttävät kompromissisi ja rajasi ennen kuin keskustelu alkaa. Vaatimusten muuttaminen neuvottelujen aikana vie aikaa, kuluttaa luottamusta ja saattaa joskus johtaa siihen, että menetät juuri sen TMS-toimittajan, jonka halusit. Sovi se ensin sisäisesti – sitten neuvottele.
Ymmärrä, mitä ostat: SaaS, ei lisenssi
Modernit TMS-alustat ovat SaaS-tilauksia, eivät ohjelmistolisenssejä. Tilaat palvelun, jota toimittaja isännöi, ylläpitää ja päivittää – et osta järjestelmää omaksesi. Tämä muuttaa sen, mitä sopimuksen on katettava: tilausehdot, irtisanominen, datan omistajuus ja vientioikeudet, käytettävyyssitoumukset, tuen vasteajat. Tavalliset hankintasopimuspohjat eivät ole kirjoitettu tätä mallia varten – varmista, että omasi on ajan tasalla.
SOW on yhtä tärkeä kuin sopimus
Työmääräys (SOW) määrittelee, mitä toimitetaan, kenen toimesta ja milloin: tilin konfigurointi, kuljetusliikkeiden liittäminen, integraatiotuki, koulutus ja hyväksymiskriteerit, jotka osoittavat käyttöönoton todella valmistuneen. Jos se ei ole SOW:ssa, se ei sisälly hintaan – riippumatta siitä, mitä kokouksessa tai sähköpostissa sanottiin. Lue erityisesti oletukset-osio huolellisesti. Siellä laajuus on ehdollisesti määritelty. Jos kuljetusliikkeesi lista osoittautuu ilmoitettua suuremmaksi tai ERP:si tarvitsee epästandardin integraatiomuodon, oletukset-osio ratkaisee, onko kyseessä nopea keskustelu vai hinnoiteltu muutospyyntö.
Määrittele selkeästi, mitä ei sisälly
Räätälöity kehitys, paikan päällä tapahtuva koulutus, datan migraatio, integraatiotyö omissa järjestelmissäsi, kuljetusliikepuolen muutokset. Nämä hinnoitellaan yleensä erikseen. Kun nämä kirjataan paperille ennen allekirjoittamista, poistetaan yleisin ja helpoimmin vältettävissä oleva käyttöönottokitkan lähde: kaksi osapuolta, joista kumpikin oletti eri asioiden sisältyvän hintaan.
Sovi käyttöönottosuunnitelma ennen allekirjoittamista
Ei sen jälkeen. Kuljetusliikkeiden priorisointi, konfigurointiaikataulu, integraatiovälitavoitteet, käyttöönottokriteerit – sovi kaikki silloin, kun sinulla on vielä neuvotteluvoimaa. Toimittaja, joka ei pysty antamaan selkeää käyttöönottosuunnitelmaa sopimusvaiheessa, kertoo sinulle jotain, mitä haluat tietää ennen sitoutumista.
Allekirjoittamisen jälkeen: TMS:n käyttöönotto
Suurin osa todellisesta riskistä on allekirjoittamisen jälkeen. Kolme asiaa ratkaisee, miten se menee.
1. Datan migraatio
Kuljetusliikesopimukset, hinnastot, osoitekirjat, historialliset lähetykset. Päätä ajoissa, mitä sinun täytyy siirtää, mikä siivotaan ensin ja kuka omistaa työn. Epäsiisti lähdedata on yleisin syy siihen, miksi käyttöönottopäivä siirtyy yhä kauemmaksi. Siivoa se ennen migraatiota – ei migraation aikana.
2. Kuljetusliikkeiden liittämisjärjestys
Et liitä kaikkia kuljetusliikkeitä ensimmäisenä päivänä. Priorisoi volyymin ja kriittisyyden mukaan, saa tärkeimmät live ja validoitua, laajenna sitten siitä. Tässä juuri se vaiheistettu lähestymistapa, josta kysyit arvioinnin aikana, osoittaa arvonsa.
3. Käyttäjien omaksuminen
Lähetyksiä päivittäin tilaavien ihmisten on haluttava käyttää uutta järjestelmää. Ota vähintään yksi heistä mukaan jo tarjouspyyntövaiheesta alkaen, kouluta heidät kunnolla käyttöönoton aikana ja varmista, että päivittäinen työnkulku on aidosti nopeampi kuin aiemmin. Teknisesti moitteeton käyttöönotto, jota tiimi ei käytä, on silti epäonnistunut käyttöönotto.
10 yleistä TMS-tarjouspyynnön virhettä
Yleisimmät kaavat, kaikki yhdessä paikassa:
- Ei operatiivista kontekstia. Suurin virhe. Toimittajille ei anneta volyymeja, toimipisterakennetta eikä kuljetusliikekuvausta. Tarkentava kierros ja yleisluonteinen hinnoittelu ovat taattu seuraus.
- Kaikki on pakollista. Kun jokainen vaatimus on kriittinen, prioriteettisarake on turha eikä dealbreakeria erota kivasta lisästä.
- Epämääräinen aikataulu. Ilman päivämääriä toimittajat eivät pysty arvioimaan työmääräänsä, joten tarjouksetkin jäävät yhtä epämääräisiksi.
- Liiallinen tekninen yksityiskohtaisuus. Teknisen toteutuksen määrittely operatiivisen lopputuloksen sijaan karsii hyviä ratkaisuja vääristä syistä.
- ERP/TMS-rajan sivuuttaminen. Oletetaan, että TMS omistaa taloudelliset prosessit, jotka ERP oikeasti omistaa – ja huomataan se vasta käyttöönoton puolivälissä.
- Hinnan varaan turvautuminen. Valitaan tilausmaksun otsikkohinnan perusteella ilman kolmen vuoden mallia tai kuljetusliikeyhteyksien ja integraatiorehellisyyden punnitsemista.
- Demo läpikäynnin sijaan. Katsotaan toimittajan kiillotettu sekvenssi sen sijaan, että järjestelmä testattaisiin omilla todellisilla skenaarioilla.
- Referenssit, jotka eivät vastaa toimintaasi. Katsotaan vaikuttavia logoja, vaikka näiden yritysten logistiikkatoiminta ei muistuta lainkaan omaasi. Pyydä referenssejä, jotka muistuttavat sinua – ja kysy sitten, miten käyttöönotto ja integraatio oikeasti sujuivat.
- Käyttöönoton jättäminen allekirjoittamisen jälkeen. Suunnitelma, jonka neuvottelet neuvotteluvoimalla, on parempi kuin se, jonka neuvottelet ilman sitä.
- Liian raskas prosessi oikealle toimittajalle. Byrokratian ylikuorma saattaa suodattaa pois modernit alustat, jotka olisivat palvelleet sinua parhaiten.
Ilmaiset TMS-tarjouspyynnön mallipohjat
Rakensimme viisi mallipohjaa niiden tarjouspyyntöjen pohjalta, joihin vastaamme – jotta sinun ei tarvitse aloittaa tyhjältä sivulta:
- Tarjouspyyntöasiakirjan mallipohja. Tämän oppaan täydellinen rakenne.
- Toiminnallisten vaatimusten pisteytyslomake. Priorisoitu, kattavuussarakkeella toimittajakohtaisesti.
- Operatiivisten tietojen tarkistuslista. Kymmenen kysymystä täytettävänä taulukkona.
- Toimittajien arviointimatriisi. Painotettu pisteytys toimittajien välillä.
- Aikataulumallipohja. Toimenpiteet, päivämäärät, vastuuhenkilöt.
Lataa kooste – kaikki viisi, ilmaiseksi, ilman sähköpostia. Ota se, mikä on hyödyllistä, jätä muu:
Lataa täydellinen TMS-tarjouspyynnön mallipohjakooste (.zip)
Cargoson on kuljetuksenhallintajärjestelmä, jota käyttävät keskisuuret valmistajat ja tukkukauppiaat ympäri Eurooppaa ja Pohjois-Amerikkaa. Vastaamme jatkuvasti tarjouspyyntöihin, kuten sen, jonka olet kirjoittamassa – joten jos haluat mieluummin käydä vaatimuksesi läpi ennen kirjoittamisen aloittamista, autamme sinua mielellämme ajattelemaan sen läpi, ilman sitoumuksia.
Varaa ilmainen 30 minuutin konsultaatio tästä
Tee prosessi hyvin ja se on jokaisen tunnin arvoinen.
