Podnikový software — provozní kontext před kódem

Moje práce v Rohliku začala u kurýrního provozu a dispečinku. Každodenní práce ukazovala mezery v přehledech a nástrojích: potřebné informace existovaly v různých systémech, ale bylo obtížné spojit je tam, kde se rozhodovalo.

Začal jsem proto nástroj tvořit sám, zatímco kapacita centrálního IT směřovala k jiným prioritám. Blízký kontakt s uživateli přinášel přímou zpětnou vazbu a rychlé úpravy. Z provozního porozumění postupně vyrostly interní nástroje, návrh procesů, mezinárodní rollout a později full-stack vývoj; některé role se překrývaly.

Internal Logistics Data Platform začala jako lokální dispečerský nástroj v C# pro Windows s rozhraním ve stylu Visual Studio Forms. Později jsem ji přepsal do webové podoby v PHP, JavaScriptu, HTML a CSS. Vedle dispečinku ji začali využívat také koordinátoři a management.

Platforma spojovala provozní informace z více systémů, přehled kapacit, výpočty delších tras a soukromých kilometrů odvozených z telematiky. Součástí byla také centrální provozní evidence kurýrních obchodních partnerů. Šlo o nástroje pro spolupráci s těmito partnery, nikoli o personální evidenci zaměstnanců.

Ukázka rozhraní níže zachycuje přehled profilu kvality. Dokládá jednu část produktu, nikoli všechny zde popsané funkce.

Courier Operations Portal jsem dodal po veřejném výběrovém řízení. Produkt zůstal blízko provozu, kde se požadavky rychle měnily a zpětnou vazbu bylo možné přímo zapracovat.

Kurýři měli přístup k denním finančním informacím, registraci pracovních a provozních bloků, hodnocení a výkonu i fakturačním přehledům a výpočtům. Komunikace s managementem, potvrzování prioritních zpráv a nahrávání dokumentů propojovaly administrativní potřeby ve stejném pracovním rozhraní.

Tyto postupy podporovalo vícejazyčné UI. Integrace zahrnovaly interní služby přes REST, starší Google Sheets a externí finanční službu přes REST. Skenování čárových kódů sloužilo pro vratné obaly a editovatelná provozní mapa pro informace o CNG stanicích.

Provozní ověřování certifikátů a QR kódů přineslo formát tokenu kódovaného pomocí Base45. Malá služba v Pythonu přijímala token, dekódovala ho do strukturovaného JSON a předávala výsledek do procesu v portálu. Platnost nebo stav mohly ovlivnit způsobilost; existovala také možnost administrativního přepsání.

Dočasný externí formát tak zůstal za malou integrační hranicí, zatímco PHP portál dál obsluhoval dosavadní pracovní postupy. Kvůli tomuto požadavku nebylo nutné portál přestavět; veřejný příklad končí u technického propojení.

Jeden starší PHP report vytvářel CSV s výpočtem bonusů. Provozní tým potom export ručně zpracovával a bonusy přiděloval. Přesun výpočtu vyžadoval nejprve dohledat skutečné pravidlo, nikoli považovat export jen za další databázový dotaz.

Reprodukoval a ověřil jsem původní výstup, spojil potřebná provozní data a implementoval vyhodnocení pravidla ve službě Java / Spring. Integrace následně bonusy přidělovala automaticky. Porovnání nového výstupu s dosavadním výpočtem bylo základem pro vyřazení právě tohoto reportu po ověření.

Nový tok využíval provozní data o trasách a účasti na práci, vyhodnotil pravidlo a předal výsledek přes integraci k přidělení bonusu. Příklad se týká jednoho automatizovaného procesu, nikoli vyřazení celého staršího systému.

Práce v PHP, Nette a Doctrine zahrnovala dohledávání chování, datových toků a významu existujících pravidel. Ověření shodného výstupu před přesunem pravidla umožnilo využít původní implementaci jako podklad pro novou.

V Rohliku jsem používal Hibernate / JPA a Flyway a také NamedParameterJdbcTemplate tam, kde byla užitečná přesnější kontrola dotazu nebo přímé SQL kvůli výkonovým požadavkům. ORM mělo místo tam, kde odpovídalo modelu; konkrétní dotazy mohly využít nižší úroveň přístupu. Šlo o volbu podle situace, nikoli o tvrzení, že ORM je obecně pomalé.

Součástí integrační práce byly REST a RabbitMQ. Google Cloud, OpenShift, ArgoCD a GitHub Actions tvořily kontext nasazování. Tyto technologie popisují pracovní prostředí, nikoli odpovědnost za celou platformu.

Návrh, optimalizace a zavádění logistických procesů podporovaly mezinárodní expanzi v Česku, Maďarsku, Rakousku, Německu, Itálii a Rumunsku. Provozní požadavky jsem převáděl do potřeb softwaru, reportingu a monitoringu a pokračoval v práci na interních nástrojích.

Tento procesní rozsah přinášel širší znalost domény pro vývoj. Neznamená, že každá aplikace byla nasazena stejným způsobem ve všech šesti zemích.

V Generali České pojišťovně moje role Java / Full-stack vývojáře trvala od května 2025 do října 2026. Online sjednávače ve třech oblastech neživotního pojištění zahrnovaly širší full-stack práci; kampaně se zaměřovaly převážně na frontend.

Implementace využívala Java / Spring Boot, vlastní widgety a portlety v Liferay, REST a integrace přes API Gateway, Hibernate / JPA a Liquibase. Kontext nasazování tvořila prostředí Kubernetes a postupy přes Git a pull requesty. Také jsem implementoval, ladil a testoval integrace Salesforce Marketing Cloud.

Šlo o implementaci a integrace v existujícím podnikovém prostředí, bez tvrzení o odpovědnosti za architekturu API Gateway, Salesforce nebo celého podniku. Kapitola přenáší přístup založený na pochopení kontextu z logistiky do zákaznických pojistných procesů.