Kdy se vyplatí vlastní firemní aplikace a jak zůstat nezávislí na jejím autorovi

Kdy už krabicový program firmě nestačí

Máte skladový nebo jiný provozní program, ale skutečná práce se odehrává také v Excelu, e-mailech a pomocných evidencích? Právě tam může být ukrytá významná část nákladů vašeho systému. Platíte licenci a vedle ní ještě čas lidí, kteří doplňují to, co aplikace neumí.

Vlastní aplikace může tyto postupy spojit, zjednodušit a automatizovat. Má ale smysl jen tehdy, když přínos převáží cenu jejího vytvoření, přechodu a další péče. A firma musí být schopná pokračovat i v okamžiku, kdy původní programátor přestane být dostupný.

O řešení na míru stojí za to uvažovat, když:

• stejné údaje opakovaně přepisujete mezi programem, tabulkami a e-maily;
• schvalování, výjimky a interní pravidla aplikace neumí, takže je lidé obcházejí ručně;
• každý měsíc pracně sestavujete stejné přehledy;
• dodavatelské úpravy jsou drahé, pomalé nebo se nevejdou do možností produktu;
• zbytečné kroky v programu zdržují zaměstnance a komplikují zaučení;
• vaše specifické postupy jsou stabilní, srozumitelné a umíte popsat, jak mají fungovat.

Počet nevyužitých funkcí sám o sobě není důvod k přepisu. Podstatné je, zda vám program práci prodražuje. Nejdříve také prověřte, jestli nepomůže lepší nastavení, dostupný doplněk nebo jiný hotový produkt. Někdy stačí vlastní menší aplikace napojená na dosavadní systém.

Účetnictví a legislativně náročné agendy sem nepatří

Tento postup není určen k náhradě účetnictví, mezd, daňových systémů ani jiných aplikací silně závislých na průběžných změnách zákonů. U nich je soustavné sledování legislativy a ověřování správnosti významnou součástí služby specializovaného dodavatele.

Vhodnějšími kandidáty jsou interní evidence, oběh požadavků, rezervace vybavení, řízení zakázek nebo ohraničená skladová logistika. I zde je třeba vymezit hranici: evidence pohybu zboží může být vlastní, účetní ocenění zásob může zůstat v účetním systému.

Podobně lze na míru řešit plánování a schvalování služebních cest, přidělení vozidla nebo přiřazení k zakázce. Zákonné výpočty cestovních náhrad tento článek z návrhu vlastní náhrady vylučuje. U docházky oddělte provozní evidenci od mzdových a pracovněprávních výpočtů. Pokud je nelze rozumně oddělit, nepoužívejte pro takový projekt zde uvedený jednoduchý odhad.

Vyloučení legislativně náročné agendy neznamená, že ostatní aplikace nemají žádné povinnosti. Oprávnění, ochrana údajů a odpovídající provozní pravidla patří do zadání i u malé evidence.

Jak si sami spočítáte cenu práce mimo aplikaci

Začněte dvěma až čtyřmi týdny pozorování. Zapojte lidi, kteří práci skutečně vykonávají, a doplňte také měsíční, čtvrtletní a roční uzávěrky. Vyberte běžné i komplikované případy; nejrychlejší ukázka není průměr.

1. Sepište jednotlivé činnosti. Například přepis požadavku, dohledání schválení, kontrolu rozdílů nebo sestavení přehledu. Zaznamenejte také důvod, proč se dělají mimo systém.
2. Změřte aktivní pracovní čas. Uveďte počet případů za měsíc a součet minut všech zapojených osob na jeden případ. Den čekání na schválení není osm hodin práce; jeho dopad případně vyčíslete zvlášť.
3. Odhadněte čas po změně. Automatizace obvykle neodstraní odborné rozhodnutí ani všechny výjimky. Počítejte s kontrolou výsledku a s případy, které zůstanou ruční.
4. Přiřaďte cenu hodiny a využití kapacity. Použijte interní plný hodinový náklad, ne čistou mzdu. Ušetřený čas oceňte jen v rozsahu, v jakém jej dokážete využít.
5. Zapište podklad a vlastníka odhadu. U každé položky má být jasné, kdo ji změřil, na kolika případech a co má nová aplikace změnit.

Následující příklad je modelový. U jedné firmy by pracovní tabulka mohla vypadat takto:

Při nákladu 450 Kč za hodinu představuje 38 hodin kapacitu za 17 100 Kč měsíčně. Pokud firma smysluplně využije 70 %, započte 11 970 Kč měsíčně. Hotovostní úspory, například zrušené externí zpracování, sledujte odděleně.

Každou minutu počítejte jen jednou. Pokud čas na opravy zahrnujete do první činnosti, nepřidávejte jej znovu jako úsporu chyb. U sezónního provozu odhad sestavte za celý rok. Zlepšení rychlosti odezvy započtěte jen tehdy, když skutečně zkrátí práci nebo přinese jiný doložitelný přínos.

Jak poznat, jak složitou aplikaci potřebujete

Nemusíte odhadovat velikost celého programu, který dnes používáte. Potřebujete popsat rozsah jeho náhrady: funkce, které skutečně využíváte, a práci, kterou dnes děláte vedle něj. Napište si tři seznamy: „nezbytné pro spuštění“, „později“ a „nepotřebujeme“. Nezapomeňte na málo časté, ale důležité úkony, například inventuru či opravu uzavřeného záznamu.

Pro každou agendu si na jednu stránku poznamenejte:

• Data: co evidujete, jak spolu údaje souvisejí a kolik záznamů přibývá.
• Postup: kdo záznam vytvoří, schválí, změní, zruší a co se stane při chybě.
• Pravidla: podmínky, výpočty, výjimky a příklady správných výsledků.
• Uživatelé: počet současně pracujících lidí, role, pobočky a rozdílná oprávnění.
• Napojení: každý import, export, jiný systém nebo zařízení; dostupný popis rozhraní a případné poplatky.
• Historie: co převést, co stačí archivovat a v jaké kvalitě lze data získat.
• Provoz: požadovaná dostupnost, přípustná ztráta dat, rychlost obnovy a práce bez připojení.

Počet obrazovek je jen pomocný údaj. Formulář se třemi poli může spouštět složitý výpočet. Jeden sklad se základní evidencí je jiný projekt než několik skladů se šaržemi, rezervacemi, čtečkami a souběžnými výdeji.

Jde o hrubá plánovací pásma, nikoli ceník, statistiku trhu ani příslib ceny. Zahrnují analýzu, implementaci s AI, ověření, přiměřený převod dat, nasazení a dokumentaci. Předpokládají známá pravidla, dostupná data a běžné technologie. Celý projekt zařaďte podle náročnějších požadavků, nikoli podle průměru. Pásma jednotlivých agend mechanicky nesčítejte: sdílejí přihlašování a další části, ale přibývají vazby mezi nimi.

K odhadu přidejte 20–30 % rozpočtové rezervy, vlastní čas firmy na zadání, testy a školení, případná zařízení a licence a náklady souběžného provozu. Rezerva nenahrazuje analýzu zásadních neznámých. Nezdokumentované napojení, poškozená data, provoz bez výpadku nebo práce offline vyžadují samostatné posouzení.

Pokud rozsah teprve hledáte, použijte pro finanční rozhodnutí horní mez pásma. U investice blížící se milionu už krátká placená analýza obvykle poskytne lepší podklad než další zpřesňování odhadu svépomocí.

Co na ceně mění AI

Z mé zkušenosti mohu při dostatečné znalosti problému a konkrétním zadání vyprodukovat funkční kód za čtvrtinu i méně času oproti ručnímu psaní. To posouvá ekonomiku menších aplikací na míru. Neznamená to ale čtvrtinovou cenu každé zakázky: součástí dodání je i pochopení procesu, kontrola správnosti, převod dat a předání.

Pokud by psaní kódu tvořilo 60 % původní pracnosti a zkrátilo se na čtvrtinu, při nezměněných ostatních činnostech klesne celková pracnost o 45 %. Přesný výsledek závisí na projektu. Výše uvedená pásma už práci s AI předpokládají; nedělte je znovu čtyřmi.

Očekávám další zlepšování produktivity. Rozhodnutí o dnešní investici však musí vycházet z dnešního odhadu. Přesnější podklady od firmy mohou cenu ovlivnit už nyní: méně času se spotřebuje na dohledávání pravidel a předělávání nejasného zadání.

Kde leží bod zlomu

Sečtěte jen náklady starého řešení, které po přechodu opravdu zmizí, a využitelný přínos změny procesů. Odečtěte celý provoz nového řešení: hosting, zálohy, případné licence, podporu, bezpečnostní aktualizace i průběžné úpravy. Údržba vlastními lidmi má také svou cenu.

Navážeme na model s přínosem procesů 11 970 Kč měsíčně. Předpokládejme zrušené licence a podporu za 5 000 Kč a nové provozní náklady včetně údržby 6 000 Kč měsíčně. Čistý přínos je 10 970 Kč měsíčně. Celková investice 300 000 Kč se vrátí přibližně za 27 měsíců. Všechny částky jsou ilustrativní; provozní rozpočet není nabídka servisního paušálu.

Tabulka je zaokrouhlená nahoru a nepočítá cenu kapitálu. Návratnost se vztahuje k plně dosaženému měsíčnímu přínosu; dobu vývoje a postupný náběh je nutné zohlednit v kalendáři peněžních toků. Pro rozhodnutí počítejte alespoň tři roky provozu, u delšího horizontu také hodnotu peněz v čase. Používejte stejný režim DPH u všech částek.

Prověřte i horší variantu: při investici vyšší o 30 % a čistém přínosu nižším o 20 % se modelových 27 měsíců prodlouží přibližně na 44 měsíců. Pokud vám takový výsledek nevyhovuje, zmenšete první etapu nebo hledejte levnější cestu.

Licence za celý balík nemusí zlevnit, když nahradíte jediný modul. Dříve zaplacený vývoj už rozhodnutí nezmění, ale výpovědní doba, nevyhnutelné další platby, export dat a souběh obou systémů ano. Přínos porovnávejte také s úpravou stávající aplikace nebo dostupným doplňkem. Při nulovém či záporném čistém přínosu se investice tímto způsobem nevrátí.

Co když původní programátor odejde?

Je to oprávněná otázka. Týká se interního vývojáře, samostatného dodavatele i klíčového člověka v softwarové firmě. Slib osobní dostupnosti nezajistí životnost aplikace. Kontinuita musí stát na domluveném servisu a současně na možnosti systém skutečně převzít.

Před zahájením projektu si vyjasněte, co zahrnuje odstranění vady proti schválenému zadání, co je běžná údržba a co placený další rozvoj. Servisní dohoda má určit dobu pokrytí, reakci podle závažnosti problému, eskalaci, plán při nepřítomnosti a podmínky ukončení spolupráce. Reakce do určité doby není totéž jako zaručené vyřešení každé závady v téže lhůtě.

Konkrétní rozsah podpory a dostupnosti musí být předmětem dohody. Nepřetržitý kritický provoz vyžaduje odpovídající zastupitelnost a rozpočet; nelze jej založit jen na dostupnosti jednoho člověka.

Pro nezávislost na autorovi požadujte a průběžně udržujte:

• Zdrojový kód a možnost jej upravovat. Firma má mít přístup k aktuální historii změn a vyjasněná oprávnění pro sebe i dalšího dodavatele, včetně přehledu cizích komponent.
• Kontrolu nad provozem. Přístupy k hostingu, databázi, doméně, zálohám a potřebným účtům musí být dostupné určeným lidem ve firmě. Citlivé přístupové údaje patří do zabezpečené správy, ne do veřejné dokumentace.
• Návod k sestavení, nasazení a obnově. Má zahrnovat verze nástrojů, konfiguraci, zálohy, ověření obnovy a návrat k předchozí verzi.
• Popis pravidel a ověřovací příklady. Další vývojář potřebuje vědět nejen to, kde kód je, ale i proč se systém chová určitým způsobem. Kritická pravidla mají mít automatické testy.
• Popis dat a napojení. Včetně exportu, importu a podmínek služeb třetích stran.
• Postup dalších změn. Oddělené testovací prostředí, kontrola změny, schválení a bezpečné nasazení; také instrukce pro práci s AI a hranice vhodných svépomocných úprav.

Dobrou přejímací zkouškou je, když jiný vývojář podle podkladů aplikaci zprovozní v čistém prostředí, obnoví zkušební zálohu, spustí kontroly a provede drobnou změnu. Čas na tuto zkoušku i odstranění zjištěných mezer zahrňte do rozpočtu. Dokumentaci a postupy je potřeba aktualizovat s každou významnou změnou.

Moje nabídka počítá s předáním plného zdrojového kódu a základního návodu k dalším úpravám pomocí AI. Konkrétní rozsah dokumentace, testů, podpory a případného ověření převzetí domluvíme podle důležitosti aplikace. Cílem je, abyste mohli pokračovat se mnou, vlastními lidmi nebo jiným odborníkem. Nový správce bude vždy potřebovat čas na orientaci; kvalitní předání jej může podstatně zkrátit.

Svépomocí lze dobře řešit nastavení a po ověření některé menší změny. U zásahů do oprávnění, datových struktur nebo zásadních výpočtů počítejte s odbornou kontrolou. AI je při údržbě užitečná, ale dokumentace ani nástroj samy nepřebírají odpovědnost za správnost změny.

Co si připravit před prvním kontaktem

Nemusíte sepsat technickou specifikaci. Pro smysluplnou první domluvu postačí:

1. Jaký program používáte, co vám chybí a kterou ohraničenou agendu chcete změnit.
2. Seznam nezbytných funkcí, pravidel a typických výjimek, ideálně s anonymizovanými příklady.
3. Tabulka ručních činností: četnost, čas nyní a po změně, náklad hodiny a využitelný podíl úspory.
4. Počty uživatelů, role, napojení, zařízení, objemy dat a možnosti exportu historie.
5. Požadovaný termín, dostupnost systému a představa, kdo se bude starat o další provoz.
6. Rozpočtové rozpětí a očekávaná návratnost, včetně horší varianty.

Citlivá provozní data pro úvodní popis neposílejte; stačí anonymizované ukázky. Společně pak ověříme hranice řešení, nejasnosti a cenu první etapy. Přechod lze navrhnout postupně, s porovnáním výsledků obou systémů a předem určeným postupem návratu.

Vlastní aplikace dává smysl tam, kde dokáže prokazatelně zjednodušit práci a kde má firma prostředky na její další život. Součástí hodnoty je i možnost změnit správce bez nutnosti psát celý systém znovu.