Jak jsme přestavěli 30 let starý systém pro údržbu, aniž bychom zastavili ten původní

Kdo je náš klient a komu prodává

Náš klient je softwarová firma se sídlem v EU. Jejich produkt kupují výrobní závody a průmyslové skupiny a od 90. let je to systém, ve kterém si tyto provozy hlídají údržbu svých zařízení.

Představte si závod s dvěma sty stroji. U jednoho je potřeba vyměnit olej každých pět set provozních hodin. Druhý čeká čtvrtletní revize. Třetí stojí a padá s náhradním dílem, který musí být na skladě dřív, než se porouchá. Stačí jedno opomenutí a linka se zastaví uprostřed směny. Produkt našeho klienta tomu předchází: drží strukturu hal, linek a strojů, plánuje opakované úkony, vystavuje pracovní příkazy, podle kterých technici zasahují, eviduje náhradní díly a čte počítadla — provozní hodiny, kilometry — podle kterých se pozná, že je zásah na řadě.

Závody, které si ho kupují, sahají od jediného pracoviště až po průmyslové skupiny s několika právnickými osobami pod jednou střechou.

Otázka, která se v obchodních jednáních vracela

Starší produkt je desktopová aplikace pro Windows, napsaná v Delphi nad MS SQL a nainstalovaná na serveru v každém závodě. Takový tvar odpovídal době, ve které vznikl, a určuje, jak se produkt dostává ke kupujícímu: abyste mu ho ukázali, pošlete spustitelný soubor, který někdo nainstaluje. Nový závod znamená další instalaci a další databázi, o kterou je potřeba se starat. Nová verze znamená soubor, který se musí dostat na každý počítač, kde produkt běží.

Než jsme se potkali, začala tahle matematika pracovat proti nim. Kupující se ptali na verzi v prohlížeči a nebylo co ukázat. Jeden velký zájemce dal jasně najevo, že verze v prohlížeči je podmínka, a tím dostal problém svůj termín. Přepsat produkt uvnitř staré technologie by spolklo roky kapacity interního týmu, zatímco stejná otázka by se v obchodních jednáních vracela dál. A porozumění tomu, jak celek do sebe zapadá, drželi lidé, kteří u produktu byli nejdéle.

Než jsme napsali vlastní řádek kódu, přečetli jsme třicet let cizího

Než jsme cokoli navrhli, zdokumentovali jsme to, co už existovalo. Nad starým zdrojovým kódem jsme pustili AI nástroje a vytvořili interní wiki produktu: každý modul a tabulku, co dělá, proč existuje a přesné místo v kódu, které to dokládá. Z třiceti let rozhodnutí se stalo něco, co si nový člověk přečte za odpoledne.

Pak jsme se posadili s majiteli a několik hodin procházeli reálný produkt. Právě tam jsme narazili na věc, kterou stojí za to zapsat. Obě strany používaly slova firma, oddělení, lokalita a zákazník v jiném významu a na hovorech to už dělalo zmatek. Klient nabídl, že sepíše společný slovníček, včetně ukázkových uspořádání závodů od nejjednoduššího po nejčlenitější. Měli jsme ho v ruce dřív, než se ustálil datový model, a ušetřil nám odbočky, jejichž náprava by byla drahá.

Co jsme postavili, aby to mohli prodávat

Webovou platformu, která nese stejnou práci s údržbou, na kterou bylo na starý produkt spolehnutí: strukturu zařízení, definice úkonů, opakované i jednorázové zásahy, pracovní příkazy a reporty. Rozhodnutí, na kterých majitelům záleželo:

• Jedna kódová základna, dva způsoby provozu. Platforma běží jako cloudová služba, nebo na vlastním serveru závodu — kupující, jejichž pravidla nechávají data uvnitř budovy, si je uvnitř nechají.

• Data každého závodu jsou oddělená na úrovni databáze. Byla to první věc, na kterou se majitelé ptali. Při smlouvách, které jejich kupující dnes podepisují, je únik dat událost, ze které se firma jejich velikosti nezvedne, a architektura na to musela odpovědět dřív než na cokoli jiného.

• Zakládání zákazníků se přesunulo do administrátorské konzole. Nastavení nového závodu trvá pár minut a neobnáší žádnou instalaci. Dřív to znamenalo postavit server.

• Zdrojový kód je v rukou klienta, s plným přístupem do repozitáře i k historii a bez licence držené na naší straně.

• Práce se odhadovala v malých balíčcích, schvalovala se předem a fakturovala až po dodání.

Jejich interní tým na Delphi zůstal. Vedli jsme s ním pracovní setkání k vývoji s podporou AI a dnes se ve starém produktu pohybuje rychleji, zatímco nová platforma roste vedle něj. Ta spolupráce zároveň pomohla jejich týmu přistupovat ke staršímu produktu s větší jistotou.

Člověk, který platformu stavěl, byl na jeden telefonát

Platformu vedl Aleksey Andruschenko, náš senior developer, se zbytkem týmu po boku. Majitelé nemuseli žádnou otázku posílat přes prostředníka. Když jim něco kolem jejich byznysu nebylo jasné, zavolali Alekseymu a vyřešili to v jednom hovoru.

Ten přístup má stejnou cenu jako to, co do spolupráce vložil on sám. Aleksey šel do hloubky v tom, jak byznys klienta doopravdy funguje: jak je závod uspořádaný, co dělá plánovač údržby v úterý ráno, kterých částí starého produktu by se závody nikdy nevzdaly. Do takové hloubky, aby dokázal oponovat požadavku, který by produktu — a tomu, jak ho klient musí prodat — neposloužil. Rozhodnutí, která by jinak čekala na další cyklus, padla rovnou na místě.

Co se změnilo pro byznys

• 3 týdny od schválené architektury k první funkční verzi hlavního workflow, předvedené na obrazovce.

• 78 evidovaných změn dodaných v jednom odsouhlaseném balíčku práce, v rámci odhadu.

• Interní tým klienta zůstal soustředěný na starší produkt, zatímco nová platforma vznikala vedle něj.

• Založení nového závodu se z instalace vyhrazeného serveru a databáze zkrátilo na vytvoření účtu v konzoli, na pár minut.

• Provozní náklady v cloudu se u celé platformy pohybují v nižších stovkách eur měsíčně.

• Starý produkt zůstal celou dobu v provozu a žádný závod se nepřesouval dřív, než byl připravený.

Kde jsme upravili směr

Když jsme tvarovali první verzi, klient nám pomohl udržet produkt u toho, jak většina jejich zákazníků doopravdy pracuje. Začali jsme tím, že jsme se podrobně dívali na nejsložitější uspořádání v jejich portfoliu, protože právě u nich se chyby napravují nejhůř. Majitelé debatu vrátili k běžnému případu: většina závodů, kterým prodávají, má jediné pracoviště a první verze musela zůstat dost jednoduchá na to, aby si ji tihle zákazníci nastavili a používali bez tření. Členitější strukturu jsme si nechali v plánu, ale odstěhovali jsme ji ze základů. Díky tomu se produkt snáz prodává i nasazuje.

Zároveň jsme s rostoucím tempem upravili rytmus dodávek. Rychlé iterace daly klientovi funkční obrazovky brzy, ale zároveň bylo potřeba mezi releasy hlídat kvalitu. Přidali jsme proto do každého cyklu stabilizační den — ruční kontrola, úklid a automatizované testy — a udělali z něj běžnou součást každého balíčku, ne něco, co se řeší až na konci.

Brzdí váš produkt technologie, ve které vznikl?

Vzorec za tímto případem je u zavedených softwarových produktů běžný. Byznys roste, očekávání zákazníků se mění a původní technologie začne omezovat, co produkt zvládne dál. V tu chvíli není otázka, jestli je interní tým schopný. Otázka je, jestli je tohle nejlepší využití jeho času.

Náš pohled je takový, že silné interní týmy mají zůstat u znalosti produktu, kterou nikdo jiný nemá: u zákazníků, procesů, výjimek a toho, co produkt dělá cenným. Když další krok vyžaduje jiný technologický stack, může tuhle část práce unést externí tým, zatímco lidé klienta zůstanou u produktu a udrží stávající systém v chodu.

Pokud je váš produkt v tomhle bodě, přiberte tým, který už s technologiemi vaší příští verze pracoval. Podívejte se, jak přistupujeme k modernizaci starších systémů a k vývoji webových platforem na míru, nebo si s námi domluvte hovor.

Snímky obrazovek byly upraveny v souladu s NDA klienta. Rozhraní softwaru zůstává beze změny.