Rozhodnutí přepsat firemní systém obvykle nevznikne kvůli jeho stáří. Přichází ve chvíli, kdy změny trvají příliš dlouho, aplikace začíná omezovat provoz nebo firma zůstává závislá na jednom člověku či dodavateli.
Kompletní přepis pak působí jako logické řešení: starý systém se nahradí novým a problémy zmizí. V praxi ale může projekt spolknout rozpočet, zaměstnat klíčové lidi na mnoho měsíců a vytvořit nová rizika. Zvlášť pokud firma neví, které části současného řešení skutečně nefungují a které naopak spolehlivě zajišťují každodenní provoz.
Před schválením přepisu je proto vhodné projít následujících 12 otázek. Pomohou rozlišit, zda firma potřebuje nový systém, postupnou modernizaci, nebo nejprve stabilizaci toho stávajícího.
Proč kompletní přepis nemusí být správný krok
Problémy staršího systému jsou často viditelné, jejich příčina ale může být skrytá jinde.
Pomalé nasazování nových funkcí nemusí způsobovat použitý programovací jazyk. Důvodem mohou být chybějící automatické testy, nejasné zadání nebo příliš složitý proces schvalování. Výpadky nemusí vyžadovat přepis aplikace, pokud je způsobuje špatně navržená infrastruktura, databáze nebo jedna nestabilní integrace.
Častou chybou je také přenést původní procesy beze změny do nového systému. Firma zaplatí za modernější technologii, ale zachová ruční práci, duplicity dat a zbytečné kroky, které ji omezovaly už dříve.
Než vývojový tým začne programovat, musí vedení firmy přesně určit, jaký problém chce vyřešit a podle čeho vyhodnotí výsledek.
1. Jaký konkrétní problém má přepis vyřešit?
Firmy často formulují požadavek na nový systém příliš obecně: aplikace je stará, pomalá nebo se špatně rozvíjí. Pro rozhodnutí o investici to nestačí.
Vedení firmy by mělo pojmenovat konkrétní provozní nebo obchodní dopad. Může jít například o dlouhé zpracování objednávek, časté výpadky, vysoké náklady na každou změnu, ruční přepisování dat nebo neschopnost zavést novou službu.
Pokud firma nedokáže problém konkrétně popsat, později jen těžko vyhodnotí, zda nový systém přinesl očekávaný výsledek.
2. Je problém v celém systému, nebo jen v jeho části?
Firemní aplikace může obsahovat desítky modulů, integrací a procesů. Některé jsou problematické, jiné fungují spolehlivě celé roky.
Firma často nemusí měnit celý systém. Technický tým může oddělit přetíženou část aplikace, optimalizovat databázové dotazy, nahradit problémovou integraci nebo vytvořit nové rozhraní nad stávajícími daty.
Úkolem technického posouzení je zjistit, kde přesně vzniká omezení. Bez tohoto rozlišení firma riskuje, že zaplatí i za vývoj částí, jejichž náhrada nepřinese žádný měřitelný přínos.
3. Víme, co současný systém skutečně dělá?
Starší systémy často obsahují pravidla, která původní dodavatel ani interní tým nikdy nezapsali do dokumentace. Často je znají pouze zaměstnanci, kteří se systémem pracují každý den.
Může jít o individuální ceny, výjimky pro konkrétní zákazníky, účetní návaznosti, automatické exporty nebo ruční kroky prováděné mimo aplikaci. Tyto detaily se při návrhu nového řešení snadno přehlédnou.
Před přepisem proto musí firma zmapovat nejen obrazovky a funkce, ale také skutečné pracovní postupy. Jinak může nový systém po spuštění postrádat drobnosti, bez kterých se běžný provoz zastaví.
4. Jaká data musíme převést?
Migrace dat bývá složitější než samotný vývoj nové aplikace. Starší databáze mohou obsahovat duplicity, neúplné záznamy, rozdílné formáty nebo historické údaje, jejichž význam už není jasný.
Firma musí rozhodnout, která data převede, která ponechá v archivu a která už nemají provozní ani zákonnou hodnotu. Odpovědný tým musí po migraci zkontrolovat správnost dat a připravit postup návratu pro případ závažného problému.
Přepis systému bez realistického plánu migrace může skončit moderní aplikací, které uživatelé nevěří, protože v ní chybí data nebo se neshodují se skutečností.
5. Na jaké další systémy je aplikace napojená?
Podnikový software obvykle nefunguje samostatně. Vyměňuje si data s ERP, CRM, účetnictvím, skladem, e-shopem, výrobními zařízeními, dopravci nebo externími partnery.
U některých napojení má firma kvalitní dokumentaci. Jiná vznikla před lety jako jednoduchý export souboru nebo automatická úloha, o které už téměř nikdo neví.
Před přepisem musí technický tým zmapovat všechny datové toky a určit odpovědnost za jednotlivé integrace. Nezdokumentované napojení bývá jedním z nejčastějších důvodů, proč se projekt prodraží nebo zpozdí.
6. Dokážeme popsat, jak má nový systém fungovat?
Nespokojenost se starou aplikací ještě není zadáním pro novou.
Požadavky jako „musí být modernější, rychlejší a jednodušší“ mohou různí lidé chápat odlišně. Firma musí popsat konkrétní procesy, uživatelské role, pravidla, výstupy a očekávané chování systému.
Důležité je také prověřit, zda současné procesy stále dávají smysl. Přepis nabízí příležitost odstranit zbytečné kroky. Pokud se pouze překopírují do nové technologie, vznikne dražší verze stejného problému.
7. Má firma kapacitu se projektu skutečně věnovat?
Externí dodavatel může navrhnout architekturu a vytvořit aplikaci, ale nezná všechny obchodní souvislosti. Bez aktivní účasti firmy se musí rozhodovat na základě neúplných informací.
Projekt potřebuje konkrétní interní vlastníky, kteří budou určovat priority, schvalovat procesy, testovat funkce a řešit sporné situace. Firma jim musí na projekt vyhradit dostatek času.
Pokud budou projekt řídit pouze mezi běžnými pracovními povinnostmi, začnou se odkládat rozhodnutí a měnit požadavky příliš pozdě.
8. Podle čeho změříme úspěch?
Spuštění nové aplikace není samo o sobě obchodním výsledkem.
Úspěch může znamenat rychlejší zpracování zakázky, méně ručního přepisování, nižší počet chyb, stabilnější provoz nebo kratší dobu potřebnou k nasazení nové funkce. Každá firma bude mít jiné priority.
Stanovte měřitelné cíle ještě před zahájením projektu. Pomohou při rozhodování o rozsahu, kontrole rozpočtu i při vyhodnocení, zda má smysl pokračovat další etapou.
9. Lze systém modernizovat postupně?
Kompletní přepis není jedinou cestou. Firma může výrazně snížit riziko, když modernizaci rozdělí do samostatných etap.
První etapa může odstranit největší provozní rizika: doplnit monitoring, automatické testy a zálohování, stabilizovat databázi nebo nahradit problémovou integraci. Dalším krokem může být nové API, uživatelské rozhraní nebo oddělení konkrétního modulu.
Postupná modernizace umožňuje získat první výsledky dříve a ověřit, zda navržený směr funguje. Současně snižuje riziko, že firma investuje celý rozpočet do řešení postaveného na chybných předpokladech.
10. Jak bude probíhat přechod na nové řešení?
Nový systém nelze vždy spustit ze dne na den. Často je nutné určitou dobu provozovat staré i nové řešení současně.
Přechodový plán musí určit, který systém bude hlavním zdrojem dat, jak budou oba systémy synchronizovat změny a kdo schválí vypnutí původní aplikace. Je také potřeba připravit uživatele, podporu a postup pro případ závažné chyby.
Bez přechodového plánu může vzniknout situace, kdy firma dlouhodobě platí provoz dvou systémů a zaměstnanci nevědí, ve kterém z nich jsou správná data.
11. Známe celkové náklady projektu?
Cena vývoje je pouze jedna část nákladů. Rozpočet musí počítat také s analýzou, migrací dat, změnami integrací, testováním, školením uživatelů, infrastrukturou, dokumentací a podporou po spuštění.
Významnou položkou je i čas interních zaměstnanců. Ti se během projektu nemohou naplno věnovat své běžné práci, což může mít přímý dopad na provoz firmy.
Při porovnávání variant proto vedení firmy musí sledovat celkové náklady v horizontu několika let, nikoli jen cenu prvotního vývoje.
12. Kdo bude systém dlouhodobě spravovat?
Technický dluh může v nové aplikaci vznikat od prvního dne. Pokud firma neurčí odpovědnost za architekturu, dokumentaci, testy a pravidelné aktualizace, systém začne rychle ztrácet udržovatelnost.
Ještě před zahájením projektu musí firma určit, kdo převezme odpovědnost za monitoring, bezpečnostní aktualizace, incidenty a další rozvoj. Zároveň je dobré rozdělit znalosti mezi více lidí a průběžně je zapisovat do dokumentace, aby systém nezůstal závislý na jediném dodavateli. U regulovaných služeb musí tento provozní model zohlednit také požadavky NIS2 na bezpečnost a kontinuitu provozu.
Cílem přepisu není jen vytvořit nový software. Firma potřebuje systém, který může bezpečně provozovat, dále rozvíjet a v případě potřeby předat jinému týmu.
Kdy kompletní přepis firemního systému dává smysl
Kompletní přepis dává smysl, pokud výrobce už použitou technologii nepodporuje, firma nedokáže systém bezpečně provozovat nebo současná architektura blokuje další rozvoj.
Přepis může být vhodný také tehdy, když firma zásadně změní svůj obchodní model a většinu původních procesů už nepotřebuje. V takové situaci může technický tým navrhnout nové řešení snáze než přizpůsobovat starou aplikaci současným požadavkům.
Ani tehdy by firma neměla realizovat projekt jako jeden velký celek bez průběžných výstupů. Rozdělení na etapy umožňuje postupně ověřovat funkce, migraci dat i reakce uživatelů, než firma do projektu vloží celý rozpočet.
Kdy je lepší postupná modernizace
Postupná modernizace je obvykle vhodnější, pokud hlavní část systému funguje a problémy se soustředí do několika konkrétních oblastí.
Výhodná je také v situaci, kdy firma nemůže riskovat delší výpadek, nemá přesnou dokumentaci nebo potřebuje rozdělit investici do více období. Nejprve lze stabilizovat provoz a teprve potom nahrazovat jednotlivé části podle jejich skutečné priority.
Tento postup může být pomalejší na pohled, ale často přináší první praktický výsledek dříve než kompletní přepis.
První krok: technické posouzení současného stavu
Před rozhodnutím o přepisu by měla firma znát odpověď na tři základní otázky:
- Které problémy skutečně ohrožují provoz nebo další rozvoj?
- Co lze odstranit bez výměny celého systému?
- Jaký první krok přinese měřitelný výsledek s přijatelným rizikem?
Odpovědi může přinést technický audit aplikace. Ten by neměl skončit pouze seznamem chyb ve zdrojovém kódu. Musí posoudit také architekturu, databázi, integrace, nasazování, monitoring, bezpečnost, dokumentaci a závislost na konkrétních lidech nebo dodavatelích.
Výstupem má být srozumitelný návrh priorit: co je potřeba opravit okamžitě, co lze modernizovat postupně a zda je kompletní přepis ekonomicky i technicky obhajitelný.
Jak může pomoci GoveSoft
GoveSoft přebírá a stabilizuje firemní aplikace, u kterých chybí dokumentace, původní dodavatel už systém nerozvíjí nebo každá změna představuje provozní riziko.
Technický audit používáme jako podklad pro konkrétní rozhodnutí, nikoliv jako obecný popis technologií. Posuzujeme skutečný provoz, zdrojový kód, data, integrace, infrastrukturu i způsob další správy. Na základě zjištěného stavu navrhneme, zda dává smysl stabilizace, modernizace po etapách, nebo vývoj nového řešení.
Pokud zvažujete přepis firemního systému a potřebujete nezávisle posoudit jeho stav, začněte krátkou technickou konzultací. Cílem není prosadit největší projekt, ale najít postup, který sníží provozní rizika a přinese firmě měřitelný výsledek.