Když finance a operativa pracují odděleně, firma zpravidla platí dvakrát. Jednou časem, podruhé chybami. Tento case popisuje, co se zlepšilo po narovnání procesu mezi dispečinkem, doklady a fakturací.
Série článků: Dispečink → Cash flow
Co jsme dodali
Tento case vychází z reálného projektu, který jsme dodali. Neuvádíme název firmy ani přesná čísla, ale logika a dopady jsou 1:1.
V dodávce byly:
propojení stavů realizace a fakturační připravenosti (invoice-ready)
fronta výjimek s důvodovými kódy, vlastníkem a SLA
napojení dokladů (POD) na pravidla blokace pro payout/invoice krok
sjednocení slovníku stavů a metrik pro finance i operativu
Výchozí problémy
Nejčastější potíže:
finance čekají na data, která jsou roztříštěná v provozu
operativa nevidí, jak její zpoždění ovlivňuje cash flow
výjimky nemají jasného vlastníka
reporting je pozdní a těžko ověřitelný, někdy se zpožděním 3-5 dní
Co se změnilo v procesu
stav realizace a stav fakturační připravenosti se propojily
výjimky dostaly frontu, důvod a odpovědnou roli
standardní případy se začaly zpracovávat automaticky
management dostal konzistentní report plan-vs-realizace-výnos
Praktické dopady
Po sjednocení procesu (v našem dodání často během 1–2 měsíčních cyklů) jsme viděli:
rychlost přípravy podkladů pro fakturaci, často o 20-40 %
transparentnost, proč nejde něco fakturovat
schopnost finančního týmu plánovat bez ručního dohledávání
kvalita měsíčního reportingu
Co doporučujeme nevynechat
Bez jasného vlastnictví výjimek se problém vrátí. Technické propojení je nutné, ale samo o sobě nestačí. Role, SLA a pravidla eskalace mají stejnou váhu.
Omezení, se kterými jsme pracovali
finance a operativa zůstaly v různých nástrojích, sjednotili jsme procesní logiku
rollout musel být postupný bez „velkého přepnutí“
definice stavů musely být auditovatelné a vysvětlitelné pro obě strany
Service bridge
Custom projekt v této oblasti obvykle zahrnuje:
návrh jednotného finance-ops workflow
integrace mezi TMS, ERP a účetnictvím
AI podporu pro detekci odchylek a doporučení dalšího kroku
Operační takeaway
Finance a operativa nemusí sdílet stejný nástroj, ale musí sdílet stejnou procesní logiku. Bez ní nebude řízený reporting ani cash flow.
Implementační úskalí
technická integrace bez sjednocení definic stavů mezi týmy
chybějící SLA pro výjimky s vyšším finančním dopadem
reporting postavený na pozdním batch exportu místo průběžné aktualizace
nejasná odpovědnost za blokované položky mezi dispečinkem a financemi
U projektů tohoto typu se často vyplatí zavést společný "finance-ops control board" aspoň na 6-8 týdnů po spuštění.
Artefakty, které v takovém projektu vzniknou
definice „invoice-ready“ + kontrolní body dokladů (dodací list a další evidence)
katalog výjimek (reason codes) + vlastník + SLA + eskalace
společný slovník stavů mezi provozem a financemi (včetně vstupních podmínek)
Doporučená sekvence nasazení
Sjednotit slovník stavů, kódů a metrik kvality.
Zavést frontu výjimek s prioritou podle dopadu do cash flow.
Nastavit automatické zpracování standardních scénářů.
Stabilizovat management reporting na jednom datovém pohledu.
Praktické scénáře
Scénář A, položka blokovaná kvůli chybějícímu potvrzenému dodacímu listu
Operativa vidí, co doplnit, finance vidí odhad dopadu do fakturace. Blokace má vlastníka i termín.
Scénář B, výkon potvrzen, cena nesedí
Systém přiřadí reason code "pricing mismatch" a eskaluje na odpovědnou roli. Není potřeba hledat problém v e-mailech.
Rozhodovací kritéria
čas od realizace do invoice-ready stavu
podíl výjimek vyřešených v dohodnutém SLA
počet položek blokovaných déle než 48 hodin
rozdíl mezi provozním reportem a finanční uzávěrkou
Doporučené další čtení
Chcete odhalit největší tření mezi operativou a financemi? Pojďme se na to společně podívat.