Případová studie: Automatizace evidence jízd u servisní flotily pomocí LLM

Jak se z ruční práce po řádcích stal poloautomatický proces s konstantní časovou náročností

Ještě nedávno vznikala evidence jízd služebních vozidel ručně – řádek po řádku, dohledáváním začátků a konců tras, přiřazováním zakázek a kontrolou každého pohybu. Zdlouhavý a monotónní proces, který se dal zvládnout jen díky trpělivosti a přesnosti, se s rostoucím počtem aut stával neudržitelným.

Nasazení velkého jazykového modelu (LLM) přineslo zásadní změnu: párování a kontrola pohybů probíhají automaticky, čas zpracování zůstal téměř stejný bez ohledu na objem dat, a lidská práce se omezila jen na namátkovou kontrolu.

Cíl projektu automatizace evidence jízd

Hlavním cílem bylo nahradit ruční párování záznamů procesem, který:

• minimalizuje nutnost ručních zásahů,

• zvládne zpracovat rostoucí počet záznamů při zachování přibližně stejné doby výstupu,

• pracuje s různými formáty vstupních dat (CSV, XLSX),

• nevyžaduje žádnou investici do nového hardwaru ani integraci s jinými systémy (např. čipové karty nebo GPS jednotky napojené na ERP software).

Cílem bylo vytvořit řešení, které bude nasaditelné okamžitě a bez IT oddělení – pouze s využitím existujících exportů z provozních systémů.

Původní stav

Evidence jízd vznikala ručně – doslova řádek po řádku. Dispečer musel z exportu GPS pohybu vozidla vyhledat, kdy a kam auto jelo, rozdělit jednotlivé trasy podle servisních zakázek a přiřadit je ke konkrétním technikům.

Tento proces byl časově náročný a monotónní. Zpracování jedné knihy jízd pro jedno vozidlo zabralo přibližně 2–4 hodiny podle počtu záznamů. Každý měsíc bylo nutné vytvořit tři knihy jízd a s očekávaným nárůstem vozidel by se ruční přístup stal zcela neudržitelným.

Datové zdroje a hlavní výzvy

Evidence kombinovala dva zdroje dat – telematické záznamy o pohybu vozidel a záznamy o přidělení zakázek jednotlivým technikům.

Největšími problémy byly:

• rozdílné struktury tabulek (CSV a XLSX),

• nejednotné názvy sloupců a formáty času,

• chybějící jednoznačný identifikátor pro propojení pohybu a zakázky,

• nutnost správně rozpoznat, který pohyb patří ke které zakázce, a kde jízda začíná a končí.

Šlo o typický příklad úkolu, kde běžné tabulkové funkce selhávají, protože vyžadují interpretaci kontextu, nikoli jen přesnou shodu.

Nasazení umělé inteligence

Po několika pokusech s klasickými vzorci se přistoupilo k využití velkého jazykového modelu (LLM), který umožnil přirozeným jazykem popsat, co má výstup obsahovat a jak má chápat data.

Model byl postupně „naučen“ detekovat strukturu tabulek, porovnávat časová okna, identifikovat hranice jízd a párovat je se správnými zakázkami. Například pokud měla zakázka přidělený čas 13:00–14:00 a telematický záznam pohybu vozidla probíhal od 13:05 do 13:55, model ji správně přiřadil k této zakázce.

Celý proces vývoje zabral přibližně pět hodin práce – včetně ladění promptu, testování a manuální kontroly výsledků. Každá úprava promptu byla testována na reálných datech, dokud model nedosáhl stabilního chování.

Iterativní vývoj a workflow

Vývoj probíhal ve více než deseti iteracích. Zpočátku bylo nutné kontrolovat každý výstupní sloupec, ověřovat časové rozsahy a ručně opravovat chybějící přiřazení. Dnes už probíhá pouze namátková kontrola – typicky několika řádků z celého souboru – a ručně se řeší jen hraniční případy.

Proces se nyní spouští měsíčně pro každé vozidlo zvlášť a výsledkem je přehledná tabulka v Excelu. Kontrolu provádí dispečer, výstup slouží účetní i manažerům vedení pro reporting.

Výsledek a dopad

Zpracování jedné evidence jízd, které dříve zabralo 3–4 hodiny, dnes trvá 30–45 minut – bez ohledu na počet záznamů.Časová náročnost zůstává prakticky konstantní i při růstu flotily nebo počtu zakázek.

Ukazatel	Před AI	Po AI	Výsledek
Doba zpracování jedné evidence	3–4 h	0,5–1 h	až –85 % času
Ruční zásahy	desítky	jednotky	výrazné snížení
Riziko chyb	vyšší (únavové přehlédnutí)	minimální	vyšší spolehlivost
Počet vozidel	1	3+	možnost škálování

Projekt měl okamžitou návratnost. Už první měsíc se ušetřil čas odpovídající práci několika hodin – prakticky stejný čas, jaký zabralo samotné vytvoření promptu.

Dispečer i vedení oceňují především konzistenci výstupů a fakt, že proces je opakovatelný a nezávislý na tom, kdo ho spouští.Jak uvedl autor řešení:

„Nejvíc mě překvapilo, že model skutečně chápe, co po něm chci. Dřív jsem nad tím strávil celé odpoledne, teď to zvládnu po kávě.“

Přínos oproti klasické automatizaci

Zatímco tradiční datové nástroje (např. makra, Power Query či skripty) vyžadují přesné technické definice, LLM zvládá interpretovat záměr. Dokáže pochopit logiku dat a pracovat s výjimkami, které by běžný skript musel mít výslovně definované.

Výhodou je i rychlá přenositelnost – prompt lze upravit během minut a aplikovat na jiný dataset, bez nutnosti programování.

Další rozvoj

Cílem do budoucna je plná automatizace – tedy rozšíření modelu o schopnost rozpoznat a správně přiřadit i krajní situace bez nutnosti manuálního zásahu.Plánuje se také doplnění kontrolního mechanismu přímo do promptu, který bude porovnávat časové rozsahy a upozorňovat na neúplná nebo sporná data.

I po úplném automatickém zpracování zůstane zachována namátková kontrola člověkem, která slouží jako finální validace.

Co si z toho odnést

Tento projekt ukazuje, že umělá inteligence nemusí nahrazovat lidi – stačí, když převezme rutinu. LLM se v praxi osvědčuje právě tam, kde je potřeba propojit různé datové zdroje a zachovat přehlednost výstupu, aniž by bylo nutné investovat do drahého softwaru nebo integrací.

Správně definovaný prompt může v takových případech fungovat jako „chytrý most“ mezi daty a člověkem – a ušetřit desítky hodin práce měsíčně.