--- title: "KARO EXPORT-IMPORT: čtyři role, jedna databáze" description: "Agenda odborných zkoušek BOZP běžela na šesti nástrojích, které dohromady nestačily. Dnes má uchazeč, komisař, účetní i administrátor vlastní pohled na stejná data — a web se na mobilu posunul z Lighthouse skóre 76 na 90." url: https://buildify.cz/blog/pripadova-studie-karoei-system-odbornych-zkousek source: https://buildify.cz/blog/pripadova-studie-karoei-system-odbornych-zkousek.md language: cs-CZ publisher: Buildify (Buildify Digital s.r.o.) datePublished: 2026-07-27 dateModified: 2026-08-13 keywords: ["KARO EXPORT-IMPORT", "případová studie", "zakázkový vývoj", "informační systém na míru", "BOZP", "koordinátor BOZP", "technik prevence rizik", ".NET 9", "React", "PostgreSQL", "Lighthouse"] license: "Volně citovatelné s uvedením zdroje / freely quotable with attribution" --- # KARO EXPORT-IMPORT: čtyři role, jedna databáze Agenda odborných zkoušek BOZP běžela na šesti nástrojích, které dohromady nestačily. Dnes má uchazeč, komisař, účetní i administrátor vlastní pohled na stejná data — a web se na mobilu posunul z Lighthouse skóre 76 na 90. Kategorie: Případová studie · Publikováno: 2026-07-27 · 9 min čtení · Autor: Buildify ## Klient a výchozí situace Společnost **KARO EXPORT-IMPORT, spol. s r.o.** sídlí v Ostravě-Bartovicích a na trhu působí **od roku 1997**. Vedle své hlavní činnosti provozuje agendu odborných zkoušek v oblasti **BOZP** — bezpečnosti a ochrany zdraví při práci. Konkrétně připravuje a administruje uchazeče o autorizaci ve dvou specializacích: **technik prevence rizik (PRE)** a **koordinátor BOZP (KOO)**. Každá z nich má vlastní požadavky na písemné práce i vlastní hodnoticí kritéria. Samotná ostrá zkouška probíhá akreditovaně a mimo jakýkoli firemní systém. Všechno okolo ní — přihlášení uchazeče, sběr dokumentů, zadání a hodnocení písemné práce, příprava na test, platby, termíny — ale zůstávalo na straně klienta. A právě tato část agendy přestala v dosavadní podobě stačit. ## Problém: šest nástrojů, které dohromady nedávaly systém Původní řešení nebylo jedním systémem. Byla to **sestava šesti různých nástrojů**, které vedle sebe vznikaly postupně, jak se agenda rozrůstala. Část z nich přitom byla původně určená k něčemu úplně jinému a k evidenci zkoušek se jen ohnula, protože zrovna byla po ruce. Výsledek: ani po sečtení všech šesti nepokrývaly to, co provoz denně potřeboval. Jedna zakázka žila na několika místech současně a nikde nebyl kompletní obraz. - **Evidence uchazečů** — Vedla se v tabulkách. Aktuální verze existovala vždy jen na jednom počítači. - **Písemné práce** — Chodily jako přílohy e-mailů. Komisař je musel dohledat ve vlákně, stáhnout, ohodnotit a odpověď poslat zpět — a v systému po tom nezůstala žádná stopa. - **Doklady a faktury** — Párovaly se ručně. Zjistit, zda konkrétní uchazeč zaplatil, znamenalo projít bankovní výpis a e-mailovou schránku. - **Příprava uchazečů** — Stála na tištěných materiálech. Uchazeč neměl kde si ověřit, zda látku umí, dokud ho neprověřila ostrá zkouška. - **Termíny a obsazenost** — Řešily se telefonicky. Odpověď na otázku „kolik je ještě volných míst" vyžadovala ruční přepočet. Sedmým dílem skládačky byl tehdejší web. Uměl říct, co firma nabízí, ale každá cesta na něm končila stejně — odkazem „Zjistit více" a telefonním číslem. Pointa není v tom, že to nefungovalo. Fungovalo — jen za cenu, kterou nikdo nevykazoval. Každá informace se zadávala vícekrát, každý dotaz uchazeče znamenal ruční dohledávání a každá chyba v evidenci se odhalila až ve chvíli, kdy už něco chybělo. Administrativa se tak stala nejdražší částí procesu, aniž by uchazeči přinášela jakoukoli hodnotu. ## Řešení: jeden systém pro čtyři role Zadání nebylo „udělejte nám aplikaci". Zadání bylo srovnat proces tak, aby každý účastník viděl přesně to, co potřebuje ke své práci — a nic navíc. Výsledkem je jedna aplikace nad **jednou databází**, která se čtyřem skupinám uživatelů ukazuje ve čtyřech různých podobách. Stejný záznam o uchazeči je pro komisaře podkladem k hodnocení, pro účetní podkladem k platbě a pro uchazeče přehledem jeho vlastního postupu. - **Uchazeč** — Registrace, profil, nahrávání dokumentů, výchozí materiály, cvičné testy, režim opakování chyb, chat s komisařem a přehled plateb. - **Komisař** — Přehled přiřazených uchazečů, kontrola písemných prací s rozhodnutím, poznámkou a přílohou, plánování termínu zkoušky, chat. - **Účetní** — Přehled plateb, změna stavu platby, nahrávání faktur a dokladů k uchazeči. Bez přístupu k hodnocení písemných prací. - **Administrátor** — Správa uživatelů a rolí, přiřazování komisařů, přidělování písemných prací, výchozí soubory, banka otázek, aktuality, nabídky práce, poptávky. Zásadní změna je v tom, že uchazeč se přestal ptát. Odpovědi na otázky typu „přišla moje práce?", „mám zaplaceno?" nebo „co se ode mě ještě čeká?" má k dispozici bez telefonátu. A hodnocení komisaře zůstává u záznamu, nikoli v osobní poště jednoho člověka. Tohle je jádro celého řešení: **oddělení pohledů při zachování jednoho zdroje dat**. Účetní nevidí hodnocení, komisař nevidí faktury, uchazeč vidí jen sebe — ale všichni pracují nad stejným, aktuálním záznamem. ## Klíčové moduly ### Dokumenty a písemné práce Dokumenty se nahrávají přímo k profilu uchazeče. Administrátor přiděluje písemné práce, komisař je hodnotí s rozhodnutím, poznámkou a případnou přílohou. Vedle toho systém spravuje **výchozí soubory** — studijní podklady, které se uchazečům zpřístupňují centrálně, ne rozesíláním e-mailem. ### Zkoušková příprava a banka otázek Systém obsahuje banku **934 otázek**, z toho **44 obrázkových**, členěnou do kategorií. Uchazeč má k dispozici dva režimy: **cvičný test** sestavený podle jeho specializace a **režim opakování chyb**, ve kterém mu systém znovu předloží právě ty otázky, ve kterých chyboval. Vyhodnocení pracuje s **celkovými i kategoriálními prahy**, a to zvlášť pro PRE a zvlášť pro KOO. Uchazeč tedy nevidí jen „prošel / neprošel", ale i to, ve které kategorii má mezeru. Klíčové rozhodnutí se ale týká údržby. Otázky se do systému **importují z právních podkladů generátorem**. Když se změní legislativa — a v BOZP se mění pravidelně — neznamená to ruční přepisování stovek otázek, ale řízený import. To je rozdíl mezi agendou, která se udržuje, a agendou, která zastarává. ### Platby a účetní agenda Stav platby je součástí záznamu uchazeče. Účetní ho mění, nahrává faktury a doklady, a všichni oprávnění uživatelé vidí aktuální stav bez dotazu do banky nebo do e-mailu. ### Komunikace a veřejný web Chat mezi uchazečem a komisařem je vedený u konkrétního uchazeče, takže historie komunikace zůstává tam, kam patří. Veřejná část webu přitom není samostatná prezentace — je to vstupní brána do stejného systému: - aktuality, semináře a **termíny zkoušek včetně obsazenosti**, - přihlášení k **přípravnému kurzu** přímo u konkrétního termínu, - pracovní nabídky s veřejným podáním a následným schválením administrátorem, - kontaktní formulář, jehož poptávky se ukládají do systému. Poptávka podaná na webu tedy nekončí v e-mailové schránce, ale jako záznam, který má někdo přiřazený. - Řešíte podobnou agendu — hodně rolí, hodně dokumentů a žádný společný systém? Napište nám na kluch@buildify.cz. Rádi se podíváme na to, co by ve vašem případě dávalo smysl udělat jako první. ## Technické řešení Systém stojí na **.NET 9 / ASP.NET Core Web API** ve vrstvené architektuře (API / Application / Domain / Infrastructure) s knihovnami **MediatR** a **FluentValidation**. Data ukládá **Entity Framework Core 9** do databáze **PostgreSQL**. Pro netechnického čtenáře přeloženo: aplikace je rozdělená do vrstev, které o sobě vědí jen tolik, kolik musí. Změna v jedné části proto neznamená přepsání celku — a to je u agendy navázané na legislativu podstatné. Přihlašování řeší **JWT tokeny s obnovovacími (refresh) tokeny** a přístup podle rolí je vynucený **na úrovni API i uživatelského rozhraní**. Tedy nejen že účetní nevidí v menu položku s hodnocením — server jí příslušná data neposkytne, ani kdyby si o ně řekla přímo. Frontend (uživatelské rozhraní běžící v prohlížeči) je postavený na **React 18 + TypeScript**, sestavovaný nástrojem **Vite**, s komponentami **Material UI** a animacemi **Framer Motion**. Drobnost, která ale hodně vypovídá o přístupu: než se aplikace v prohlížeči rozběhne, uživatel nekouká na bílou plochu. Vidí značku klienta a odpočítávání, které dává najevo, že se něco děje. Za pozornost stojí práce se soubory. Ukládání je schované za abstrakcí **IBlobStorage** — aplikace tedy neví, kde soubor fyzicky leží. Díky tomu šlo v průběhu projektu vyměnit celou úložnou infrastrukturu bez zásahu do aplikační logiky. - **Provoz a nasazení** — Kontejnery (Docker) s CI/CD pipeline — automatizované sestavení a nasazení. Frontend na Firebase Hosting, backend a databáze na vlastním VPS s úložištěm kompatibilním s S3. - **Ochrana veřejných endpointů** — Rate limiting (omezení počtu požadavků z jednoho zdroje), honeypot proti robotům a hashování IP adres u veřejných formulářů — kontaktní formulář nedrží IP adresy v čitelné podobě. ## Výsledky Nejrychlejší způsob, jak ukázat posun, je postavit obě verze vedle sebe. Vlevo původní web, vpravo dnešní stav. Rozdíl není jen v grafice. Původní web byl vizitka — návštěvník si přečetl, co firma dělá, a pak musel zvednout telefon. Dnešní web je vstupní bod do systému: uchazeč se registruje, vidí volná místa na termínech a přihlásí se na přípravný kurz, aniž by kohokoli kontaktoval. Kvalitu webové části jde ale na rozdíl od vnitřní agendy změřit i nezávisle. Použili jsme **Google Lighthouse** — bezplatný nástroj, který web automaticky projde a ohodnotí ve čtyřech oblastech na stupnici 0–100. Nejde o názor, ale o opakovatelné měření, které si může kdokoli spustit sám. Uvádíme hodnoty z **mobilního profilu**. Je to výchozí nastavení Lighthouse, simuluje pomalejší připojení i slabší telefon — a odpovídá tomu, jak dnes lidé weby skutečně otevírají. Co jednotlivé oblasti znamenají v praxi: - **Výkon** — jak rychle se stránka načte a kdy s ní jde skutečně pracovat. Nízké skóre znamená, že návštěvník čeká. - **Přístupnost** — jestli web zvládne používat i člověk se zrakovým nebo pohybovým omezením: kontrast písma, popisky u obrázků, ovládání klávesnicí. - **Osvědčené postupy** — technická kvalita a bezpečnost: zabezpečené spojení, aktuální knihovny, žádné chyby v prohlížeči. - **Dohledatelnost (SEO)** — jestli stránce rozumí vyhledávače, a najdou ji tedy lidé, kteří hledají. Největší posun je u **výkonu: ze 46 na 69**. Čtyřicet šest je v Lighthouse červené pásmo — na běžném telefonu a průměrném připojení to znamenalo, že návštěvník na obsah čekal. Druhý nejvýraznější skok je u **osvědčených postupů (79 → 100)**, tedy u části skóre, kterou uživatel nevidí, ale která rozhoduje o tom, jestli web stárne bezpečně: zabezpečené spojení, aktuální knihovny, žádné chyby v prohlížeči. Přiznejme i to, co ještě není hotové. **Výkon 69 pořád není v zelené** a je to jedno z míst, kde má smysl pokračovat — mobilní profil Lighthouse simuluje pomalé připojení a slabší procesor a je k webům postaveným na Reactu přísný. Přístupnost, osvědčené postupy i dohledatelnost už zelené jsou. ### Systém v číslech - **934** — otázek v bance, z toho 44 obrázkových - **2** — specializace s vlastními prahy hodnocení — PRE a KOO - **4** — role v jedné aplikaci nad jednou databází - **90** — Lighthouse skóre nového webu — mobil, průměr ze čtyř oblastí A jedno číslo, které bývá u zakázkového vývoje překvapením: celá dodávka — čtyři role, zkoušková příprava, platební agenda i veřejný web — proběhla **v rozpočtu do 200 tisíc korun**. V tomto projektu tedy kompletní systém na míru vyšel levněji než roční licence krabicového řešení srovnatelného rozsahu. - **do 200 tis. Kč** — celá dodávka — čtyři role, zkoušková příprava, platební agenda i veřejný web > „Výborná a profesionální spolupráce, výsledek předčil moje očekávání. Čas dodání byl kratší než původní předpoklad a rozpočet byl dodržen." > — Ing. Eva Grenová, Ph.D., KARO EXPORT-IMPORT, spol. s r.o. ## Co bude dál Systém je v provozu a spolupráce pokračuje. Na společné roadmapě jsou tyto kroky: - **E-mailové notifikace** — Upozornění na přidělenou práci, hodnocení nebo změnu stavu platby, aby uživatel nemusel systém kontrolovat. - **PDF exporty** — Hodnoticí protokoly a přehledy uchazečů ve formátu, který jde založit i předat. - **Realtime chat** — Okamžité doručování zpráv mezi uchazečem a komisařem bez obnovení stránky. - **Migrace infrastruktury** — Postupné sjednocení provozu; díky abstrakci IBlobStorage a kontejnerizaci jde o infrastrukturní krok, ne o přepis aplikace. Pořadí určuje klient podle toho, co mu v provozu nejvíc pomůže. Systém byl od začátku navržený tak, aby se dal rozšiřovat po částech — ne aby se každá novinka platila přepsáním základů. ## Závěr KARO EXPORT-IMPORT nepotřebovalo digitalizaci jako pojem. Potřebovalo, aby písemná práce neležela v e-mailu, aby se stav platby dal zjistit za dvě vteřiny a aby uchazeč měl kde zjistit, jak si stojí. To se povedlo díky jedné věci: **čtyři role, čtyři pohledy, jedna databáze**. Ze šesti nástrojů, z nichž některé k téhle práci nikdy nebyly určené, se stal jeden systém. A ten systém nesjednotil lidi do jednoho rozhraní — dal každému to jeho, ale nad společnými daty. - Řešíte podobnou agendu? Ozvěte se na kluch@buildify.cz a projdeme si, co by šlo srovnat do jednoho systému u vás. ## Související stránky - [Buildify](https://buildify.cz/) — Markdown: https://buildify.cz/index.md - [Buildify Conexium](https://buildify.cz/cde) — Markdown: https://buildify.cz/cde.md - [bim-pulse CDE Connector](https://buildify.cz/cde-connector) — Markdown: https://buildify.cz/cde-connector.md - [BIM Budgeting](https://buildify.cz/bim-budgeting) — Markdown: https://buildify.cz/bim-budgeting.md - [CDE security & compliance](https://buildify.cz/cde/bezpecnost) — Markdown: https://buildify.cz/cde/bezpecnost.md - [Blog](https://buildify.cz/blog) — Markdown: https://buildify.cz/blog.md --- Zdroj / Source: https://buildify.cz/blog/pripadova-studie-karoei-system-odbornych-zkousek · Kontakt: kluch@buildify.cz · Buildify Digital s.r.o., IČO 29541743, Korunní 2569/108, 101 00 Praha 10, Česká republika.