Odpověď hned: Software pro revizní techniky vybírejte podle toho, jestli zvládne celý cyklus zakázky — zařízení, termín, práci technika v terénu, zprávu, závadu, předání zákazníkovi a další naplánovaný úkon — ne podle toho, jak vypadá formulář zprávy. Před podpisem si vyžádejte pilot na vlastních datech a zkuste v něm i odchylky: opravu už schváleného dokumentu, práci bez signálu, dvě provozovny jednoho zákazníka. Funkci, kterou dodavatel nepředvede na konkrétním postupu, zatím nepovažujte za existující.

Dvě různé věci pod jedním názvem

„Software pro revizní techniky" znamená v praxi dvě odlišné kategorie, které se prodávají pod stejným heslem.

První je generátor zpráv: vyplníte formulář, vypadne PDF. Druhá je provozní systém, který drží zákazníky, provozovny, zařízení, termíny, závady, dokumenty a předání výsledků a pohlídá, aby na sebe navazovaly.

Ani jedna varianta není lepší sama o sobě. Samostatnému technikovi s dvaceti stálými zákazníky může rychlá tvorba zpráv stačit. Majitel firmy se třemi techniky ale řeší úplně jinou otázku: co se má udělat příští týden, kdo to má přidělené a jestli má zákazník poslední platnou verzi dokumentu, nebo tu, kterou jste v březnu opravovali.

Na tuhle otázku formulář neodpovídá.

Co si nechat ukázat na demu — jeden souvislý průchod

Nenechte si předvádět jednotlivé obrazovky. Vyžádejte si jeden nepřerušený průchod od začátku do konce:

  1. Založení zákazníka a jeho provozovny.
  2. Evidence konkrétního zařízení včetně identifikátoru, který na něm reálně je.
  3. Naplánování úkonu a přidělení technikovi.
  4. Zápis výsledku a nalezené závady přímo v terénu.
  5. Vytvoření a schválení dokumentu.
  6. Předání zákazníkovi.
  7. Naplánování dalšího termínu.

Když dodavatel ukazuje jen krok 5, vidíte tiskopis — ne řízení zakázky.

Jednu věc si vyjasněme hned: tenhle článek neřeší, jaká lhůta pro které zařízení platí. To je věc předpisů a norem a patří do odborných přehledů lhůt. Tady jde o to, jestli software zvolenou lhůtu umí správně evidovat, vysvětlit a řídit.

1. Řídí systém lhůty, nebo jen posílá připomínky?

Kalendářová připomínka říká, že nastalo nějaké datum. Neřekne, proč zrovna tohle datum, ke kterému zařízení patří a kdo ho naposledy měnil.

U každého termínu by měl systém držet celý řetězec:

zákazník → provozovna → zařízení → předchozí úkon → použitá lhůta → příští termín

Ptejte se na jednu konkrétní věc, kterou většina demo dat schová: od čeho se další termín počítá? Od data provedení úkonu, od data vystavení zprávy, nebo od data předání zákazníkovi? U jedné zakázky to klidně jsou tři různé dny a tři různé příští termíny. Systém musí umět říct, které pravidlo použil.

Druhá otázka: co se stane, když někdo datum přepíše ručně. Měla by zůstat dohledatelná původní hodnota, autor změny, čas a důvod. Přepsané datum bez historie je mina — za rok nezjistíte, jestli šlo o opravu chyby, dohodnutou výjimku, nebo omyl.

Přehled lhůt má odpovědět aspoň na tohle:

  • Co je po termínu?
  • Co spadne v příštích čtyřech až šesti týdnech?
  • Které zařízení nemá další termín vypočtený vůbec?
  • Kdo má kterou zakázku přidělenou?
  • Kde se termín blíží, ale zakázka ještě není se zákazníkem potvrzená?
  • Kde chybí podklad pro určení dalšího termínu (třeba předchozí zpráva)?

Nejnebezpečnější položka v tom seznamu není „po termínu". Je to „termín nevypočten". Ta zařízení se totiž v žádné připomínce neobjeví — vypadla z evidence tiše.

A ještě: nechte si ukázat pohled napříč všemi zákazníky, filtrovatelný podle technika, typu zařízení a regionu. Přehled otevřený uvnitř jedné provozovny je hezký pro technika a nepoužitelný pro plánování kapacity firmy.

Tuhle část — řízení lhůt a předávání výsledků na straně dodavatele revizí — děláme v InvoAIM; jak v něm vypadá cyklus návrhu a potvrzení, rozebírá samostatný článek o tom, co InvoAIM je. Jestli si to chcete zkusit rovnou na svém portfoliu, revizním firmám pouštíme systém na 14 dní — stačí mail na miroslav.jaros@ithope.cz a domluvíme, na jakých datech to rozjedeme.

2. Datová struktura: kde se evidence rozpadá

Slabinou evidence bývá zřídka formulář. Bývá to datový model.

Použitelný systém musí rozlišovat aspoň: zákazníka, provozovnu nebo objekt, konkrétní zařízení, kontaktní osoby, jednotlivé úkony, zjištěné závady a související dokumenty. A musí umět, aby zařízení mělo víc identifikátorů najednou — výrobní číslo od výrobce, vaše evidenční číslo na štítku a inventární číslo zákazníka jsou tři různá čísla a hledat se bude podle všech tří.

Na demu udělejte tři změny, které v provozu opravdu nastávají:

  • Zařízení se přesune z jedné provozovny do druhé. Zůstane historie u zařízení, nebo se rozpadne podle objektů?
  • Zákazník vymění správce budovy. Přepíše se kontakt, nebo zůstane dohledatelné, komu jste zprávu předali loni?
  • Dva záznamy patří jednomu zařízení. Umí je systém sloučit a nechat historii pohromadě? Když ne, ponesete si dvě poloviny pravdy tak dlouho, dokud budete zákazníka mít.

Pro majitele firmy je pak podstatný souhrn portfolia: kolik práce čeká u kterého zákazníka, kde se hromadí neodstraněné závady, kde je dokumentace neúplná. Technik potřebuje detail zařízení. Majitel potřebuje vidět kapacitu a riziko napříč firmou. To jsou dvě různé obrazovky, ne jedna.

3. Terén: co technik zvládne bez návratu k počítači

Mobilní aplikace není užitečná tím, že se otevře na malém displeji. Je užitečná tím, že technik dokončí běžný úkon na místě a nic pak nepřepisuje podruhé.

Na pilotu ověřte, jestli jde:

  • najít zařízení podle štítku, QR/NFC kódu, výrobního čísla i umístění,
  • otevřít předchozí zprávu k témuž zařízení,
  • vyfotit závadu a přiřadit fotku ke konkrétní závadě, ne na jednu hromadu u zakázky,
  • uložit rozpracovaný zápis tak, že přežije zavření aplikace i restart telefonu,
  • pracovat bez signálu,
  • po obnovení připojení data bezpečně sloučit,
  • předat rozpracovanou zakázku kolegovi.

Offline režim si nenechte odkývat — vyzkoušejte ho. Zapněte režim letadlo, upravte záznam, přidejte dvě fotky, vraťte signál a sledujte synchronizaci. Hledáte dvě konkrétní selhání: vznik duplicity (offline založený záznam se po připojení vytvoří podruhé, protože nemá stabilní identifikátor) a tiché přepsání (novější uložení přepíše práci kolegy bez upozornění).

Zeptejte se na to přímo: „Co se stane, když dva technici upraví stejný záznam offline?" Odpověď „vyhrává poslední uložení" znamená, že se práce jednoho z nich beze stopy ztratí. Slušný systém takový konflikt ukáže a nechá ho rozhodnout člověka.

4. Zprávy, verze a závady

Revizní zpráva není osamocené PDF. Je to výstup navázaný na zařízení, zakázku, závady a další úkony.

Ptejte se, jestli systém rozlišuje stav rozpracovaná / schválená / předaná. Po schválení nesmí jít dokument tiše přepsat. Oprava má vzniknout jako nová verze, s dohledatelnou předchozí podobou a autorem změny. Důvod je praktický: zákazník má v ruce konkrétní soubor. Když se pod stejným označením v systému objeví jiný obsah, přestanou si obě strany odpovídat — a při kontrole se to pozná.

U závad si nechte ukázat celý životní cyklus zvlášť:

  • Lze závadě přidělit odpovědnou osobu, stav a termín odstranění?
  • Může zákazník doložit odstranění (foto, doklad o opravě)?
  • Zůstane původní popis a fotka zachovaná i po uzavření?
  • Jde vytáhnout přehled otevřených závad napříč všemi provozovnami?

A exporty. PDF je pro člověka; pro migraci a další zpracování nestačí. Chtějte strukturovaný export evidenčních dat (CSV nebo XLSX), export příloh a hlavně export vazeb — které zařízení patří ke které provozovně, který dokument ke kterému úkonu. Plochá tabulka bez vazeb se do jiného systému nedostane.

Dvě drobnosti, které rozhodnou o použitelnosti exportu: kódování (CSV v jiném kódování než UTF-8 vám v Excelu rozseká diakritiku) a vedoucí nuly u evidenčních čísel, které tabulkový editor rád spolkne. Vyžádejte si vzorový export a otevřete si ho — ne screenshot. Pro dlouhodobé uložení dokumentů se ptejte na PDF/A. Pro napojení na účetnictví nebo helpdesk se ptejte na API a jeho dokumentaci.

5. Zákaznický portál: pracovní nástroj, nebo sdílená složka?

Portál nemá být adresář s PDF. Zákazník v něm má poznat, které dokumenty jsou aktuální, co čeká na jeho reakci a které závady zůstávají otevřené. Když to umí, přestanete rozesílat přílohy mailem a dohledávat, kdo dostal jakou verzi.

Vyžádejte si ukázku očima zákazníka, ne administrátora. A prověřte:

  • vidí zákazník jenom svoje objekty,
  • jde přístup omezit na jednu provozovnu,
  • jak se odebere přístup zaměstnanci, který od zákazníka odešel (tohle je nejčastější díra),
  • eviduje se, kdo a kdy si dokument stáhl nebo potvrdil převzetí,
  • jde stáhnout víc dokumentů najednou,
  • jak portál upozorní na novou závadu nebo blížící se úkon.

Poslední test je nejjednodušší: pokud zákazník potřebuje k pochopení portálu školení od dodavatele, budete ho školit vy.

6. Co přesně dělá AI a kdo výsledek potvrzuje

V roce 2026 už „s AI" není popis funkce. Dodavatel musí umět říct, jaká data se zpracovávají, co z nich vzniká a kdo za výsledek odpovídá.

AI dává smysl na přípravě: vytěží údaje z došlého dokumentu, předvyplní hlavičku, navrhne popis závady podle předchozích záznamů u téhož typu zařízení, navrhne, kam přílohu zařadit. Nemá vydat revizní zprávu, uzavřít závadu ani sama posunout termín.

Bezpečný postup má tři zřetelné kroky:

náhled návrhu → potvrzení oprávněným člověkem → auditní stopa

Pravidlo, na kterém stavíme my, zní jednoduše: citlivá změna se nezapíše bez vědomého potvrzení uživatele. V rozhraní musí být poznat, co navrhl systém a co pak upravil technik — a v auditní stopě musí zůstat obojí, včetně toho, kdo a kdy potvrdil.

Tři otázky navíc, které se často zapomínají:

  • Kde zpracování probíhá a komu data odcházejí. Zjistěte, kteří další zpracovatelé se zapojují a jak vás dodavatel informuje o jejich změnách. Čl. 28 GDPR (nařízení 2016/679) vyžaduje předchozí konkrétní nebo obecné písemné povolení správce.
  • Trénink na vašich datech. Chtějte to vyloučené písemně, ne ústně.
  • Oddělení zákazníků platí i pro AI. Dokument jednoho zákazníka se nesmí objevit v návrhu, vyhledávání ani kontextu u jiného. Zkuste to na pilotu s dvěma testovacími zákazníky.

7. Otázky, které se ptají nepříjemně

Prezentace na připravených datech ukáže ideální průchod. Rozhodnutí ale stojí na tom, co se stane, když je něco jinak.

Do pilotu proto zaraďte odchylky: chybějící předchozí zprávu, ruční změnu termínu s důvodem, zákazníka se dvěma provozovnami, opakující se závadu a opravu už schváleného dokumentu.

A dodavateli položte tyhle otázky:

  • Jak se do systému dostanou stávající zákazníci, zařízení a dokumenty?
  • Které vazby se při importu nepřenesou automaticky?
  • Jak poznáme chyby importu — kontrolní počty, vzorek k ruční kontrole?
  • Jak často vznikají zálohy a kdy naposledy se zkoušela obnova? (Záloha, jejíž obnova se nikdy netestovala, není záloha, ale naděje.)
  • Jak dostaneme všechna data i přílohy při ukončení služby, v jakém formátu a do kdy?
  • Kdo může měnit role a oprávnění a kde uvidíme historii těch změn?
  • Jak se hlásí incident a do kdy dostaneme reakci?
  • Co funguje při výpadku internetu nebo služby?

Výsledkem pilotu není hezké PDF. Výsledkem je projitý cyklus od naplánování přes práci technika po předání zákazníkovi a stažení vlastních dat. Funkci, kterou dodavatel nedokáže ukázat na konkrétním postupu, nepočítejte mezi vyřešené.

8. Jednoúčelový nástroj, nebo provozní platforma?

Jednoúčelový software dává smysl, když potřebujete hlavně vytvářet určitý typ zprávy a zbytek agendy spolehlivě zvládáte jinde. Menší rozsah často znamená kratší zavedení a méně funkcí, které tým stejně nepoužije.

Provozní platforma začne dávat smysl ve chvíli, kdy stejný údaj přepisujete mezi kalendářem, tabulkou, dokumenty a e-mailem. Přínos není v počtu modulů — je v tom, že vazba mezi zákazníkem, zařízením, termínem, dokumentem a závadou vydrží i po roce provozu a po odchodu člověka, který ji držel v hlavě.

Praktický postup před nákupem: sepište si tři situace, které vás dnes stojí nejvíc ruční práce nebo představují největší riziko. Každou nechte v nabízeném systému skutečně provést. Ne popsat — provést.

Když si zprávy přebírá škola nebo úřad

Stojí za to vědět, co se s vaší zprávou děje na druhé straně stolu. U škol, obcí a příspěvkových organizací nekončí v šuplíku, ale v evidenci dokumentů, která má vlastní pravidla pro příjem, ukládání i skartaci. Když víte, co po nich pravidla chtějí, ušetříte si dohadování o formátech, předávacích protokolech a tom, proč zákazník chce zprávu „ještě jednou, ale jinak".

Rozebíráme to zvlášť: elektronická spisová služba pro školy a co má obsahovat spisový a skartační řád.

Co si z toho odnést

Rozhodujte podle tří vlastností, ne podle délky seznamu funkcí:

  1. Pokryje systém práci od začátku do konce — od naplánování po předání a další termín?
  2. Dostanete svoje data zpět — kompletně, i s přílohami a vazbami?
  3. Dohledáte odpovědnost za změnu — kdo, kdy, co a proč?

Chcete to vidět na svém portfoliu? Revizním firmám pouštíme InvoAIM na 14 dní na jejich vlastních datech, školám a veřejným organizacím nabízíme úvodní audit spisovny po individuální domluvě. Napište na miroslav.jaros@ithope.cz nebo zavolejte na +420 724 689 762 — Miroslav Jaroš.

Časté dotazy

Stačí reviznímu technikovi Excel a kalendář?

Samostatnému technikovi se stabilním portfoliem mohou stačit dlouho. Slabé místo je propojení: termín v kalendáři neví, ke kterému zařízení patří a z jakého podkladu vznikl. Jakmile do dat sáhne víc lidí, přibude riziko duplicit a tichého přepsání novějšího údaje — a to se pozná až ve chvíli, kdy je potřeba něco doložit.

Jaký je rozdíl mezi programem na revizní zprávy a provozním systémem?

Program na zprávy řeší vznik výsledného dokumentu. Provozní systém navíc řídí zákazníky, provozovny, zařízení, plánování práce, závady, verze dokumentů, oprávnění a předání zákazníkovi. Poznáte to podle jediné otázky: umí vám software říct, co se má udělat příští týden a kdo to má přidělené?

Jaké exporty by měl software podporovat?

Čitelné dokumenty pro zákazníka (PDF, pro dlouhodobé uložení se ptejte na PDF/A) a zároveň strukturovaný export evidenčních dat — CSV nebo XLSX, včetně příloh a vazeb mezi záznamy. Pro napojení na další systémy ověřte, jestli existuje API a jestli je zdokumentované. Vzorový export si nechte poslat a otevřete si ho, než podepíšete.

Je AI v softwaru pro revize bezpečná?

Záleží na tom, kde v procesu stojí. Bezpečné použití znamená, že AI připraví návrh, oprávněný člověk ho zkontroluje a potvrdí a v systému zůstane auditní stopa. Dodavatel má umět vysvětlit, kde se data zpracovávají, kdo je dalším zpracovatelem a že se nepoužívají k tréninku modelu. Co AI zapíše bez potvrzení, to za vás bude muset někdo obhájit.

Co si nechat ukázat na předváděcí schůzce?

Souvislý průchod: založení zákazníka a zařízení, naplánování úkonu, zápis v terénu, evidenci závady, schválení dokumentu, předání přes portál a export všech vzniklých dat. Pak přidejte dvě odchylky — opravu už schváleného dokumentu a práci bez připojení. Právě na odchylkách se pozná, jestli je systém dodělaný.