Modernizace vs. výměna ERP: jak se rozhodnout
Máte ERP systém, který běží deset nebo patnáct let. Funguje, ale bolí. Lidé nadávají na pomalé rozhraní, integrace s novými systémy se dělají přes exporty do CSV, a poslední člověk, co rozuměl kódu, odešel do důchodu. Co teď?
Máte dvě základní cesty: postupnou modernizaci toho, co máte, nebo kompletní výměnu za nový systém. Obě mají svá rizika. A někdy je správná odpověď: zatím nedělat nic.
Kdy dává smysl postupná modernizace
Modernizace je správná volba, když je jádro systému v pořádku, ale obálka kolem něj zastarala. Konkrétně:
Datový model stále odpovídá realitě. Vaše tabulky a vztahy mezi nimi popisují to, jak firma funguje. Faktura má řádky, řádky odkazují na produkty, produkty mají ceny a sklady. Pokud tohle sedí, máte na čem stavět.
Architektura je oddělitelná. Systém má nějakou formu API nebo aspoň databázi, ke které se dá připojit zvenku. Nemusí to být REST API — stačí, že dokážete číst a zapisovat data bez toho, abyste museli procházet uživatelským rozhraním.
Problém je hlavně v UI a integracích. Lidé nadávají na to, jak systém vypadá a jak pomalu reaguje. Ale obchodní logika uvnitř dělá to, co má. V tomhle případě můžete přidat moderní webové rozhraní nad stávající databázi, napojit nové integrační vrstvy a nechat jádro běžet.
Příklad z praxe: Výrobní firma měla ERP postavený na Oracle Forms z konce 90. let. Datový model byl solidní — zakázky, materiály, výrobní postupy, expedice. Problém byl, že Oracle Forms klient běžel jen na Windows XP a integrace s e-shopem neexistovala. Řešení: nové webové rozhraní nad stejnou Oracle databází, REST API pro e-shop, postupná migrace obrazovka po obrazovce. Trvalo 14 měsíců, ale firma ani den nepřestala fungovat.
Kdy je výměna jedinou cestou
Někdy modernizace nedává smysl. Poznáte to podle těchto signálů:
Technologie je mrtvá. Systém běží na Visual FoxPro, Delphi 5/6, PowerBuilderu nebo starém Clipper/dBase. Nenajdete vývojáře. Kompilátor neběží na moderním OS. Bezpečnostní záplaty neexistují. Tohle se nedá modernizovat — můžete jen přepisovat.
Datový model je špatně od základu. Všechno je v jedné tabulce. Zákazník je zároveň dodavatel a zaměstnanec, protože "tak to tehdy bylo jednodušší". Ceny jsou natvrdo v kódu. Měny neexistují. Tohle se neopraví přidáním nového UI.
Systém je monolitický bez jakéhokoli rozhraní. Jediný způsob, jak dostat data ven, je screenshot nebo ruční export. Žádné API, žádný přístup k databázi, binární formát dat. Modernizace by stála víc než nový systém.
Dodavatel neexistuje. Firma, co systém vyvinula, zkrachovala. Zdrojový kód nemáte, nebo ho máte, ale nikdo mu nerozumí. Dokumentace neexistuje.
Příklad z praxe: Distribuční firma s ERP v Clipper/FoxPro. 25 let stará aplikace, běží na jednom serveru s Windows Server 2003 (ano, v roce 2024). Žádné API, žádná dokumentace, žádný zdrojový kód. Jediný člověk, co systém udržoval, odešel. Nezbývá než nahradit celý systém — a to rychle, protože server může každý den umřít.
5 otázek, které vám pomohou rozhodnout
Než se pustíte do čehokoli, odpovězte si upřímně na těchto pět otázek:
1. Je datový model použitelný?
Podívejte se na databázové schéma. Dávají tabulky a vztahy smysl? Odpovídají tomu, jak firma dnes funguje? Pokud ano, máte základ pro modernizaci. Pokud ne, směřujete k výměně.
2. Seženete vývojáře na tuhle technologii?
Zkuste si dát inzerát. Pokud hledáte Delphi 6 programátora a za měsíc se nikdo neozve, máte odpověď. Pokud je systém v Javě, C# nebo Pythonu, vývojáře najdete.
3. Kolik má systém integrací?
Spočítejte, kolik dalších systémů je napojených — účetnictví, e-shop, CRM, sklady, dopravci, banky. Každá integrace, kterou při výměně musíte předělat, zvyšuje riziko a cenu. Deset a více integrací = pečlivě zvažte postupnou modernizaci.
4. Jak kritický je nepřetržitý provoz?
Pokud je váš ERP srdce firmy a výpadek na den znamená milionové ztráty, velká migrace je extrémně riziková. Postupná modernizace vám umožní měnit systém za běhu.
5. Jaký máte časový tlak?
Končí podpora operačního systému? Odchází poslední správce? Blíží se regulatorní změna? Časový tlak mění rovnici — někdy musíte jít do výměny, i když by modernizace byla levnější, protože na ni není čas.
Rizika obou přístupů
Rizika modernizace
- "Nekonečný projekt" — modernizace po kouskách může trvat roky bez jasného konce
- Skrytá komplexita — začnete měnit jednu část a zjistíte, že je propletená se vším ostatním
- Dva systémy najednou — po dobu přechodu musíte udržovat starý i nový kód
Rizika výměny
- Big bang selhání — nový systém se spustí a nefunguje, ale starý už je vypnutý
- Ztráta know-how — v starém systému jsou roky zakódovaných business pravidel, která nikdo nedokumentoval
- Podcenění rozsahu — "za půl roku to bude hotové" se změní na dva roky a trojnásobek rozpočtu
Strangler Fig Pattern: nejlepší z obou světů
Pokud nechcete ani riskantní velký třesk, ani nekonečnou modernizaci, existuje třetí cesta: strangler fig pattern.
Pojmenovaný podle fíkusu, který obroste strom a postupně ho nahradí. Funguje takto:
- Nové funkce stavíte v novém systému
- Starý systém běží dál — nic na něm neměníte
- Postupně přesouváte funkci po funkci ze starého do nového
- Když je starý systém prázdný, vypnete ho
Klíčové je postavit integrační vrstvu (API gateway, message bus, sdílená databáze), přes kterou spolu starý a nový systém komunikují. Navenek to vypadá jako jeden systém. Uvnitř postupně měníte komponenty.
Tenhle přístup funguje skvěle, když máte čas a chcete minimalizovat riziko. Nefunguje, když je starý systém tak uzavřený, že na něj nelze nic napojit.
Někdy je správná odpověď: zatím nedělat nic
Upřímná rada, kterou vám většina dodavatelů neřekne: pokud systém funguje, lidé s ním umí pracovat a nepřichází žádný vnější tlak (konec podpory, bezpečnostní riziko, regulace), nemusíte nic měnit.
Modernizace pro modernizaci je vyhozené peníze. "Systém vypadá staře" není důvod na roční projekt za miliony.
Změnu dělejte tehdy, když:
- Systém brzdí růst firmy (nemůžete přidat nový prodejní kanál, vstoupit na nový trh)
- Vzniká bezpečnostní nebo provozní riziko (nepodporovaný OS, žádný správce)
- Regulace si to vyžaduje (GDPR, účetní standardy, oborové normy)
- Náklady na údržbu překračují náklady na výměnu
Shrnutí
| Situace | Doporučení |
|---|---|
| Dobrý datový model, špatné UI | Modernizace |
| Mrtvá technologie, žádní vývojáři | Výměna |
| Hodně integrací, kritický provoz | Strangler fig pattern |
| Systém funguje, žádný tlak | Zatím nic nedělejte |
| Časový tlak + špatný základ | Výměna s paralelním provozem |
Každá situace je jiná. Pokud si nejste jistí, nechte si udělat nezávislý audit systému — ne od firmy, která vám chce prodat nový ERP, ale od někoho, kdo nemá problém říct "nechte to být".