UPS-seuranta-API vai OMS-integraatio: kumman sinun pitäisi valita?
Jos tarvitset vain lähetyksen tilan, valitse UPS-seuranta-API. Jos sinun on koordinoitava tilauksia, varastoa, toimituksia, reititystä, peruutuksia ja palautuksia useiden kanavien kautta, valitse OMS-integraatio. Monissa verkkokaupan toiminnoissa käytännön vastaus ei ole joko–tai: OMS hallinnoi tilauksen elinkaarta, kun taas kuljetusyhtiön tai usean kuljetusyhtiön seuranta-API toimittaa toimitustapahtumat.
Oikea päätös riippuu toimesta, jonka tiimisi tarvitsee tehdä. Seurantasivua rakentavalla kehittäjällä on erilainen vaatimus kuin operatiivisella tiimillä, joka yhdistää markkinapaikan, varaston, 3PL-kumppanin ja asiakaspalvelujärjestelmän. UPS-seuranta-APIn ja OMS:n käsitteleminen keskenään vaihdettavina voi aiheuttaa tarpeetonta kehitystyötä tai jättää tärkeitä operatiivisia aukkoja.
Ero yhdellä lauseella
UPS-seuranta-API on yhteys kuljetusyhtiön tietoihin. OMS-integraatio on yhteys tilausprosessiin.
Seuranta-API auttaa yleensä sovellusta hakemaan tai näyttämään seurantatietoja, jotka liittyvät seurantatunnukseen. Näitä tietoja voidaan käyttää asiakasilmoituksiin, brändättyyn seurantasivuun, sisäiseen lähetysten valvontaan tai poikkeamien käsittelyyn. Sen pääasiallinen laajuus on lähetysten näkyvyys.
Tilaustenhallintajärjestelmä toimii laajemmalla prosessitasolla. Se voi koordinoida useiden myyntikanavien tilauksia, kohdentaa varastoa, viestiä toimituspisteiden kanssa, lähettää tilauksia varastoihin tai 3PL-kumppaneille sekä synkronoida tilan takaisin verkkokauppoihin tai markkinapaikoille. Tarkka ominaisuusjoukko vaihtelee OMS-järjestelmän mukaan, joten sen ominaisuudet tulee varmistaa tuotteen dokumentaatiosta eikä olettaa pelkän nimikkeen perusteella.
Milloin UPS-seuranta-API on parempi valinta
Valitse suora UPS-seuranta-integraatio, kun pääasiallinen liiketoimintaongelma on tietää, missä UPS-lähetykset ovat, ja tehdä nämä tiedot saataville toisessa sovelluksessa.
- Asiakkaille suunnattu seuranta: Verkkosivustosi tai sovelluksesi on näytettävä lähetyksen eteneminen ilman, että asiakkaiden tarvitsee poistua palvelusta.
- Tukiprosessit: Asiakaspalvelijoiden on nähtävä ajantasaiset seurantatapahtumat help deskissä, CRM-järjestelmässä tai tilausnäkymässä.
- Toimitusilmoitukset: Järjestelmäsi tarvitsee lähetystapahtumia sähköposti-, SMS- tai muun asiakasviestinnän syötteeksi.
- Poikkeamien valvonta: Operatiivisen henkilöstön on tunnistettava viivästykset, toimitusyritykset tai muut tapahtumat, jotka edellyttävät jatkotoimia.
- Yhden kuljetusyhtiön toiminta: UPS käsittelee suurimman osan tai kaikki olennaiset lähetykset, joten kuljetusyhtiökohtainen integraatio on toiminnallisesti järkevä.
Tämä lähestymistapa on yleensä rajatumpi ja helpompi määritellä kuin täysimittainen OMS-projekti. Tiimi voi määritellä tarvittavat seurantatunnusmuodot, tapahtumakentät, todennusmenetelmän, päivityskäyttäytymisen, virheenkäsittelyn ja asiakkaille näytettävien tilojen kielen. Yrityksen ei tarvitse suunnitella tilauskohdistuksen tai varastoprosessien kokonaisuutta uudelleen.
Seuranta-APIa ei kuitenkaan pidä käsitellä tilaustenhallintajärjestelmänä. Seurantatiedot voivat kertoa, mitä lähetykselle tapahtui, mutta ne eivät yksin päätä, minkä varaston tulisi käsitellä tilaus, varata varastoa, jakaa tilausta, hyväksyä peruutusta tai luoda palautusprosessia.
Milloin OMS-integraatio on parempi valinta
Valitse OMS-integraatio, kun ongelma alkaa ennen lähetyksen luomista tai jatkuu kuljetusyhtiön näkyvyyttä pidemmälle.
OMS on olennaisempi, kun yrityksen on koordinoitava useita seuraavista:
- Tilaukset useista verkkokaupoista, markkinapaikoista tai myyntikanavista
- Varaston saatavuus myymälöissä, varastoissa ja toimituskumppaneilla
- Tilauksen reititys sijainnin, varaston, palvelutason tai operatiivisten sääntöjen perusteella
- Osatoimitukset, jälkitoimitukset, peruutukset ja tilausten muutokset
- Varastoille tai 3PL-järjestelmille lähetettävät toimitusohjeet
- Tilan synkronointi OMS:n ja myyntikanavien välillä
- Palautukset, hyvitykset tai oston jälkeiset prosessit, joihin liittyy muutakin kuin kuljetusyhtiön tila
Tässä mallissa UPS on yksi mahdollinen kuljetusyhtiöyhteys suuremmassa prosessissa. OMS voi luoda tai vastaanottaa toimitustietueita, kun taas kuljetusyhtiöintegraatio toimittaa kuljetustiedot. OMS voi tämän jälkeen käyttää lähetyksen virstanpylväitä tilauksen elinkaaren päivittämiseen, mutta tarkka toiminta riippuu järjestelmistä ja käytössä olevista määrityssäännöistä.
OMS-integraatio on siis laajempi toteutuspäätös. Se voi sisältää tietojen omistajuuden, varaston synkronoinnin, tilakokonaisuuksien määritelmät, varastoprosessit, poikkeamajonot ja täsmäytyksen. Yrityksen ei pitäisi hankkia tai rakentaa OMS-yhteyttä vain siksi, että se haluaa paremman seurantasivun.
UPS-seuranta-API verrattuna OMS-integraatioon
| Päätösalue | UPS-seuranta-API | OMS-integraatio |
|---|---|---|
| Ensisijainen tarkoitus | UPS-lähetyksen tilan näyttäminen tai käsittely | Tilauksen elinkaaren ja toimitustoimintojen koordinointi |
| Tärkein tieto-objekti | Seurantatunnus, paketti, lähetystapahtumat | Tilaus, rivit, varasto, toimitus, lähetys ja mahdollisesti palautukset |
| Tyypillinen omistaja | Tuotekehitys, asiakaskokemus tai tukijärjestelmät | Verkkokaupan operatiivinen toiminta, toimitukset, yritysarkkitehtuuri ja tuotekehitys |
| Tyypillinen laajuus | Yksi kuljetusyhtiö tai seurantapalvelu | Useita kanavia, toimipaikkoja, järjestelmiä ja toimituskumppaneita |
| Mitä se ei ratkaise automaattisesti | Varaston kohdentamista, reititystä tai tilausten orkestrointia | Kuljetusyhtiön tapahtumien tarkkaa normalisointia, ellei integraatio tarjoa sitä |
| Toteutusriski | Kenttien määritykset, todennus, kyselyt tai tapahtumien käsittely sekä tilojen tulkinta | Tietojen omistajuus, tilojen synkronointi, varaston tarkkuus ja järjestelmien välinen täsmäytys |
Tämä taulukko kuvaa tavanomaista arkkitehtuurieroavaisuutta, ei jokaisen toimittajan takuuta. Jotkin alustat yhdistävät tilaustenhallinnan ja lähetysten näkyvyyden, kun taas jotkin seurantapalvelut tukevat useita kuljetusyhtiöitä. Vahvista kyseinen dokumentaatio ennen integraatiomallin valintaa.
Vaihtoehto, jota monet kasvavat yritykset tarvitsevat: OMS ja usean kuljetusyhtiön seuranta
Yritykset, jotka käyttävät UPS:ää muiden kuljetusyhtiöiden rinnalla, tarvitsevat usein UPS-yhteyttä laajemman seurantakerroksen. Usean kuljetusyhtiön seurantapalvelu voi normalisoida lähetystapahtumat eri kuljetusyhtiöiden välillä, kun taas OMS vastaa edelleen tilaus- ja toimitusprosesseista.
17TRACK tarjoaa seuranta-APIn ja julkaisee kehittäjädokumentaation yrityksille, jotka tarvitsevat ohjelmallisen seuranta-integraation. Tämä on olennaista, kun vaatimus koskee lähetysten näkyvyyttä useiden kuljetusyhtiöiden välillä eikä vain UPS:ää koskevaa työnkulkua. Virallisesta dokumentaatiosta tulee varmistaa tietyn projektin nykyinen API:n laajuus, tuetut toiminnot, todennusvaatimukset ja toteutuksen yksityiskohdat.
Tämä arkkitehtuuri voi olla hyödyllinen jälleenmyyjälle, jolla on useita toimituskumppaneita, tai rajat ylittävälle toiminnalle, jossa viimeisen kilometrin kuljetusyhtiö vaihtelee määränpään mukaan. OMS voi säilyttää tilaus- ja toimitustilan, kun taas seurantakerros voi toimittaa lähetyspäivityksiä asiakkaille suunnattuihin tai sisäisiin sovelluksiin. Järjestelmillä tulee silti olla selkeät omistajuussäännöt. Määrittele esimerkiksi, mikä järjestelmä on auktoritatiivinen tilauksen tilan osalta, mikä järjestelmä on auktoritatiivinen kuljetusyhtiön tapahtumien osalta ja miten ristiriitaiset päivitykset ratkaistaan.
Yksinkertaiselle vain UPS:ää käyttävälle kaupalle sekä OMS:n että usean kuljetusyhtiön seurantapalvelun lisääminen voi olla tarpeetonta. Useita kuljetusyhtiöitä ja kanavia käyttävälle yritykselle normalisoidun seurantakerroksen välttäminen voi puolestaan johtaa erillisiin integraatioihin, epäyhtenäisiin tilan nimikkeisiin ja suurempaan ylläpitotarpeeseen.
Kuinka valita ilman ylimitoitettua toteutusta
1. Aloita liiketoimintatapahtumasta
Kirjoita tapahtuma, jonka on käynnistettävä toiminto. ”Näytä uusin UPS:n tila tilaussivulla” viittaa seuranta-APIin. ”Lähetä jokainen maksettu tilaus parhaaseen toimituspaikkaan ja pidä varasto synkronoituna” viittaa OMS:ään. ”Päivitä asiakas paketin lähdettyä 3PL-kumppanilta” voi edellyttää molempia.
2. Kartoita järjestelmät, jotka jo omistavat tiedot
Luettele verkkokauppa, markkinapaikka, ERP, varastonhallintajärjestelmä, 3PL-kumppani, asiakaspalvelualusta, OMS ja kuljetusyhtiöyhteydet. Tunnista jokaisen kohdalla, luoko, muuttaako vai ainoastaan lukeeko se tilauksia, varastoa, toimitustietueita ja seurantatapahtumia. Näin uusi integraatio ei luo kahta kilpailevaa totuuden lähdettä.
3. Tarkista kuljetusyhtiöiden moninaisuus ja maantiede
Jos laajuuteen kuuluu vain UPS, suora UPS-yhteys voi riittää. Jos toiminta käyttää useita kuljetusyhtiöitä, postipalveluja tai määränpääkohtaisia viimeisen kilometrin kumppaneita, arvioi, voisiko laajempi seuranta-API vähentää erillisiä integraatioita. Älä oleta, että palveluntarjoaja tukee jokaista kuljetusyhtiötä, maata tai tapahtumatyyppiä, vaan varmista oman lähetysprofiilisi kannalta olennainen kattavuus.
4. Määrittele vähimmäistilamalli
Kuljetusyhtiöiden tapahtumat ovat usein yksityiskohtaisempia kuin asiakkaille näytettävät tilat. Yhdistä raakatapahtumat ennen kehitystyötä liiketoimintatiloihin, kuten osoite luotu, kuljetuksessa, jakelussa, toimitettu, poikkeama ja palautettu. Määrittele, mitä tapahtuu, kun tapahtuma viivästyy, tulee kahdesti, puuttuu tai vastaanotetaan väärässä järjestyksessä. Tämä työ vaaditaan riippumatta siitä, tulevatko tiedot suoraan UPS:ltä vai seurantapalvelun kautta.
5. Testaa operatiiviset poikkeamat
Onnistunut esittely seuraa yleensä normaalia toimitusta. Hyödyllisessä konseptitestissä tulee testata myös virheellinen seurantatunnus, lähetys ilman tapahtumia, viivästynyt skannaus, toimituspoikkeama, osatoimitus, korvaava tilaus ja palautus. OMS-projektissa lisää testaukseen jaetut tilaukset, varastopuutteet, peruutusyritykset ja päällekkäiset tilausviestit.
6. Vertaa kokonaisoperointityötä
Älä vertaa vain alkuperäistä integraatiotyötä. Ota mukaan valvonta, API-muutokset, tukityökalut, täsmäytys, kuljetusyhtiöiden käyttöönotto, tietojen säilytys, käyttöoikeuksien hallinta ja vikatilanteista palautuminen. Rajattu API voi olla pieniriskisin valinta rajattuun ongelmaan. Laajempi alusta voi olla ylläpidettävämpi, kun yrityksellä on jo useita kuljetusyhtiöitä ja toimitusjärjestelmiä.
Käytännön päätössääntö
Käytä UPS-seuranta-APIa, kun haluttu lopputulos on luotettava UPS-lähetysten näkyvyys olemassa olevassa sovelluksessa. Käytä OMS-integraatiota, kun haluttu lopputulos on koordinoitu tilausten ja toimitusten toteutus eri kanavissa tai sijainneissa. Käytä molempia, kun OMS:n on hallinnoitava tilauksia ja erillisen seurantakerroksen on yhdistettävä lähetystapahtumat asiakaspalvelua tai oston jälkeisiä kokemuksia varten.
Vaihtoehtoja arvioivan yrityksen seuraavan askeleen tulisi olla pieni, dokumentoitu integraatiotesti laajan teknisen sitoumuksen sijaan. Valitse edustavat tilaukset, määrittele odotetut kentät ja tilat, testaa normaalit ja poikkeustapaukset sekä kirjaa, mikä järjestelmä omistaa kunkin päätöksen. Jos projekti myöhemmin laajenee muihin kuljetusyhtiöihin, arvioi uudelleen, olisiko usean kuljetusyhtiön seuranta-API tarkoituksenmukaisempi kuin erillisten kuljetusyhtiöyhteyksien lisääminen yksi kerrallaan.
Paras valinta on pienin arkkitehtuuri, joka ratkaisee nykyisen operatiivisen ongelman estämättä seuraavaa todennäköistä vaatimusta. Seuranta-APIa ei pidä myydä OMS:nä, eikä OMS:ää pidä ottaa käyttöön vain seurantasivun näyttämistä varten.
Usein kysytyt kysymykset
Onko UPS-seuranta-API sama asia kuin OMS?
Ei. UPS-seuranta-API keskittyy UPS:n lähetystietoihin. OMS koordinoi laajempia tilaus- ja toimitusprosesseja, joihin voivat kuulua varasto, reititys, toimitukset, peruutukset ja palautukset. Yritys voi käyttää seuranta-APIa OMS-vetoisessa arkkitehtuurissa.
Voiko OMS seurata UPS-lähetyksiä?
Se voi, jos OMS:llä on UPS-integraatio tai se muodostaa yhteyden erilliseen seurantapalveluun. Ominaisuus on tuotekohtainen, ja se tulee varmistaa OMS:n dokumentaatiosta. Pelkkä OMS-nimike ei osoita, että järjestelmä tukee tarvittavia UPS-tapahtumia tai työnkulkuja.
Tarvitsenko OMS:n brändätyn seurantasivun luomiseen?
Yleensä et. Brändätty seurantasivu tarvitsee yleensä sovelluksen tai seurantapalvelun, joka voi vastaanottaa lähetystietoja ja näyttää ne asiakkaalle. OMS voi tarjota tilauskontekstin, mutta se ei ole automaattisesti tarpeellinen itse sivua varten.
Milloin minun tulisi käyttää usean kuljetusyhtiön seuranta-APIa?
Harkitse sitä, kun lähetyksissä käytetään useita kuljetusyhtiöitä ja sovelluksesi tarvitsevat yhdenmukaisen tavan hakea tai näyttää toimitustapahtumia. Varmista palveluntarjoajan kuljetusyhtiökattavuus, tapahtumamalli, dokumentaatio, palvelurajoitukset ja poikkeamien käsittely niillä reiteillä, joita todella käytät.
Mitä kehittäjien tulee selvittää ennen integraatiota?
Selvitä todennus, pyyntö- ja vastauskentät, tilamääritelmät, päivitystiheys, virheenkäsittely, päällekkäiset tapahtumat, seurantatunnuksen validointi, säilytys, tietoturva ja järjestelmien omistajuus. Dokumentoi myös, miten seurantatapahtuma muuttaa asiakkaalle näytettävää tilauksen tilaa.
Lähteet
- UPS Developer Portal — UPS:n APIen ja integraatioresurssien virallinen kehittäjäportaali.
- 17TRACK Tracking API — ohjelmallisen seuranta-integraation virallinen tuotesivu.
- 17TRACK API Documentation — virallinen kehittäjädokumentaatio toteutuksen viitteeksi.
