Mnoho firem stále používá model jedna objednávka = jedna jízda. Na první pohled je jednoduchý. V praxi ale přestává fungovat, jakmile se objeví noční přejezdy, rozdělené nakládky nebo 2-3 změny řidiče a soupravy během realizace.
Série článků: Dispečink → Cash flow
Definice
Definice: Životní cyklus rezervace (reservation lifecycle)
Sada stavů a přechodů, která určuje, co znamená „hotovo“ v čase a kdy se z položky stává výjimka. Minimální praktická sada:
Draft → Confirmed → Planned → In-Execution → Completed → Invoice-ready → Settled
Každý přechod má vstupní podmínky (např. povinná data / doklad / schválení) a pokud podmínky nejsou splněny v termínu, položka přechází do Overdue/Exception .
Proč starý model nestačí
Jedna objednávka často představuje obchodní závazek, ne jednu konkrétní jízdu. Když systém neumožní vazbu rezervace -> více jízd, dispečink improvizuje mimo systém a historie přestává být spolehlivá.
Nejčastější dopady:
nepřesné plánování kapacit, typicky odchylka 10-20 %
komplikované dělení výkonu mezi řidiče
horší dohledatelnost změn
slabší podklady pro fakturaci a reporting
Návrh funkčního modelu
Základní jednotkou je rezervace. Ta obsahuje:
Realizace probíhá přes více jízd, které se mohou měnit podle reality provozu. Tím zůstává obchodní závazek stabilní, ale operativa má flexibilitu.
Implementační checklist
Oddělte obchodní vrstvu (rezervace) od operativní vrstvy (jízdy).
Definujte pravidla, kdy je potřeba nová jízda a kdy úprava stávající.
Zavěste finanční logiku na rezervaci i jízdy, ne jen na jeden záznam.
Sledujte verze změn, aby historie byla auditovatelná.
Kde pomůže vývoj na míru
Právě tady standardní TMS často narazí. Pomáháme hlavně s:
návrhem datového modelu rezervace/jízdy
migrací ze staré logiky bez ztráty historie
integrací na finance, aby se výkon i doklady párovaly konzistentně
Operační takeaway
Když obchodní závazek není datově oddělený od konkrétní jízdy, systém bude lidi tlačit do improvizace. Rezervační model tento tlak snižuje a zvyšuje predikovatelnost.
Implementační úskalí
příliš rychlé mapování starých objednávek na novou rezervaci bez pravidel verzování
nejasná hranice, kdy vzniká nová jízda a kdy jen změna existující
chybějící vazba mezi změnou v dispečinku a dopadem do finanční logiky
podcenění školení role dispatch lead, která rozhoduje výjimky
Ve firmách s 200-500 jízdami denně se tyto chyby projeví během prvních 2-3 týdnů. Vyplatí se proto mít předem definovaný "stabilizační režim" s denní kontrolou.
Doporučená sekvence zavádění
Zafixujte datový slovník pro rezervaci, jízdu a jejich stavové přechody.
Zaveďte pravidla split/merge jízd včetně auditní stopy.
Připojte pricing a settlement logiku až po ověření provozní konzistence.
Migrujte historická data po vlnách, například po týdnech nebo regionech.
Praktické scénáře
Scénář A, noční přejezd mezi depy
Jedna rezervace pokrývá obchodní závazek, ale systém vytvoří dvě navazující jízdy. Každá má vlastního řidiče, čas a náklad. Výkon se rozdělí správně bez ručního přepisování.
Scénář B, změna nakládky v den realizace
Původní jízda se neanuluje bez historie. Vznikne nová verze nebo nová jízda podle pravidla. Reporting i finance vidí důvod změny.
Rozhodovací kritéria
podíl rezervací se dvěma a více jízdami podle segmentu služby
přesnost plánované vs reálné kapacity po zavedení modelu
počet změn bez auditní stopy (cílově nulový stav)
čas potřebný na přípravu podkladů pro fakturaci u multi-ride rezervací
Doporučené další čtení
Řešíte podobný problém v plánování? Domluvte si workshop nad datovým modelem rezervací.