Vlastník systému, jako je finanční instituce, telefonní operátor, organizace státní správy či jiná společnost anebo instituce, má mnoho systémů, jejichž údržba a zejména další rozvoj (tedy AMO) jsou nutnou podmínkou rozvoje vlastního byznysu. Tyto činnosti si může vykonávat sám majitel systému, anebo je svěřit externí firmě, která je poskytuje formou služby. Díky tomu se následně může naplno věnovat rozvoji vlastního byznysu, místo úsilí o udržení klíčového systému v chodu nebo o jeho další rozvoj. Samozřejmě nevýhodou je vznik jisté závislosti na třetích stranách, ale té se dá poměrně snadno zabránit tím, že zásadní know-how systému bude mít majitel ve svých rukou a k ostatní věcem bude požadovat dokumentaci, školení a možnost know-how kdykoliv dle potřeby převzít. Vhodným přístupem tak vznikne situace, kdy organizace sice přenechá údržbu systému a rozvoj externí firmě, ale zároveň si uchovává dostatečně volné ruce tuto situaci v budoucnu změnit.

Jak na to?

Nejčastějším začátkem je, že rozvoj a údržbu systému vykonává dodavatel, který systém vyvinul. Tímto získává majitel systému hned od začátku osvědčeného dodavatele, který má schopný tým umožňující systém dále rozvíjet a spravovat. Často jde o naprosto přirozenou cestu vedoucí k oboustranné spokojenosti. Najdou se i výjimky. V některých případech majitel systému nemá jinou možnost, neboť sám systém rozvíjet nedokáže a nedokáže ani poskytnout dostatek informací jinému zájemci, protože je prostě nemá. Toto není ideální cesta. Proto je vhodné, aby se organizace při vývoji softwaru na zakázku snažil do procesu vyvíjeného systému zapojit. Tím získá potřebné znalosti o tom, co a jak systém dělá. Byznys analytici jsou pak nadále klíčovou součástí života systému a pracují s dodavatelem na údržbě a rozvoji systému. Tím se zaručí, že jejich znalosti nezastarají a majitel systému může v noci klidně spát, protože drží klíčové know-how o svém systému. Tedy aspoň část majitele, která se stará o business.

A co udělat proto, aby měli klidné noci i IT technici na straně zákazníka? Třeba zapojit do projektu člověka v roli IT architekta. Jeho klíčovým úkolem je porozumět architektuře systému a dohlížet na to, že bude v rozumné míře ctěna a rozvíjena tak, aby byl systém dlouhodobě dobře udržovatelný a vyhovoval IT architektuře jeho majitele. IT architekt se také stane klíčovou rolí v případě, že vznikne potřeba dodavatel služeb údržby a rozvoje systému změnit.

Změna dodavatele

Pro změnu dodavatele se obvykle majitel systému rozhodne v případě, když dodavatel dlouhodobě nesplňuje jeho požadavky, a tím vážně ohrožuje jeho byznys. Nejčastěji se tak děje z důvodu nízké kvality dodávek, spolehlivosti dodavatele, stability týmu a také třeba degradace původní architektury systému. To jsou všechno velmi vážné důvody.

Změna dodavatele služeb application management outsourcingu není něco, co lze zvládnout za několik dní. Je to náročný krok, který vyžaduje nejen kvalitního dodavatele, ale také výrazné úsilí na straně majitele systému. Při volbě vhodného přístupu je však možné tuto důležitou změnu dobře zvládnout a získat tak kvalitního dodavatele pro údržbu a rozvoj systému.

Metodika přebírání

Přebírání systémů by mělo mít vždy pevně definovanou a strukturovanou metodiku, založenou na zkušenost s přebíráním systémů. Postup je rozdělen na tři fáze, které se dají nazvat: Zhodnocení aktuálního stavu (takeover), definice cílového stavu (full service) a kroky nutné ke změně na stav cílový (transition).

V první fázi je nutné se věnovat analýze aktuálního stavu systému. Provede se revize či definice hranic systému, tedy jaké moduly jsou jeho součástí, jaká jsou využita rozhraní atd. V tomto kroku se provedou také revize všeho, co je k systému k dispozici. Revize dokumentace se věnuje její kompletnosti a aktuálnosti, revize architektury se pak soustředí na kvalitu architektonického návrhu a jeho dodržování. Kontrola zdrojových kódů bývá automatická, s využitím nástrojů pro statickou analýzu kódu, a nahodile manuální. Jejím cílem je zhodnotit technickou kvalitu systému a ohodnotit případný „technický dluh“. Dojde také na revizi prostředí. Na závěr se upřesní očekávaný cílový stav (full service definition) a také naplánuje další fáze (transition), která nás k němu dovede. Tato první fáze je také jedinou, kdy se lze ještě spolupracovat s odcházejícím dodavatelem. Dále by to již nebylo efektivní a péči o systém převezme dodavatel nový. Aby se zajistila schopnost oprav produkčních kritických chyb, je součástí této fáze také dodání nové verze systému do akceptačního prostředí, tzv. testovací dodávka. Tato fáze trvá u běžných systémů několik týdnů.

Přechodová (transition) fáze pak typicky obsahuje dodání vybraných změnových řízení a třeba i nový release s byznys požadavky, aby systém i nadále plnil očekávání majitele. Mimo to jsou provedeny úpravy směřující k umožnění fáze plných služeb. Mezi ně můžou patřit např.:

• Zavedení vhodných optimalizací softwarového procesu
• Částečná či plné zavedení continuous automation
• Zavedení podrobných testovacích scénářů
• Nahrazení proprietárních technologií a frameworků
• Modularizace architektury systému
• Zlepšení dokumentace systému na potřebnou úroveň

Jde již o delší časové období a je nutné zdůraznit, že zavedení jedné či více uvedených úprav je čistě na rozhodnutí majitele systému. Dodavatel vypracuje seznam včetně priorit, odhadovaných pracností a případných dopadů na fázi cílovou, přičemž zákazník se rozhoduje dle priorit a rozpočtu.

Fáze plné služby je již pomyslnou odměnou za dobrou práci na obou stranách. V této době je již systém stabilizován a služby poskytovány dle požadovaných SLA. Majitel systému se může soustředit na svůj byznys a zároveň má systém, o jehož údržbu a rozvoj se stará kvalitní dodavatel. Pokud by se spolupráce mezi subjekty časem přestala odvíjet k oboustranné spokojenosti, tak má majitel systému díky přechodové fázi dostatečné podklady na další změnu dodavatele.

Bohumír Zoubek Autor je ředitelem produktů a služeb ve společnosti Profinit. Dlouhodobě se věnuje softwarovému inženýrství a to jak z pohledu kvality, tak i z pohledu nákladů a možných úspor. Přednáší také softwarové inženýrství na vysokých školách.