Není to tak dávno, co jsem psal, že přínosy digitalizace vznikají používáním digitálního řešení. Dnes na tuto myšlenku navážu jejím logickým důsledkem: pokud má digitalizace přinášet hodnotu, musí být software k dispozici ve chvíli, kdy ho uživatelé potřebují.

V těchto měsících pracujeme v MoroSystems na uvedení do produkčního nasazení dva nové mission critical systémy. Jejich dostupnost, provoz, řešení nenadálých situací a způsob spolupráce a údržby je téma pro nás i pro naše zákazníky.

Možná o provozu IT řešení víte vše. Následující text pro vás může být opakováním či inspirací, jak se dá o věcech přemýšlet. Pro naše zákazníky, a tím i pro nás, je to aktuální téma, proto jsem se o tom rozhodl napsat dnešní číslo mého newsletteru Software jako investice.

A nyní zpět do problematiky.

My v MoroSystems i naši zákazníci si uvědomujeme, že samotným dokončením vývoje totiž hodnota softwaru nevzniká.

Vzniká až jeho používáním.

Nový klientský portál má hodnotu, když přes něj zákazníci dokáží řešit své životní situace. Automatizace procesu tehdy, když díky ní zaměstnanci šetří čas. Transakční systém tehdy, když přes něj probíhají transakce.

Z toho ale plyne ještě jedna poměrně zásadní věc.

S rostoucím přínosem digitalizace roste i závislost na ní

„Firmy digitalizovat potřebují. Digitalizace firmám šetří čas, peníze a naplňuje očekávání moderních zaměstnanců i klientů, kteří vše chtějí hned, na jeden klik, z domova nebo mobilu. Kdykoli, „ říká Radek Teichmann, CTO MoroSystems.

Pokud přes zákaznický portál pouze zobrazujeme informace, jeho krátký výpadek může být nepříjemný. Pokud je stejný portál hlavním prodejním kanálem firmy, jeho výpadek už přímo zasahuje do tržeb.

Podobné je to s interními aplikacemi. Nefunkční systém může omezit několik zaměstnanců. Jiný může zastavit logistiku, fakturaci nebo důležitou část provozu celé firmy.

Software se tak postupně přesouvá z kategorie „nástroj, který používáme“ do kategorie „infrastruktura, na které stojí náš byznys“.

Nejpozději v tuto chvíli se musí změnit způsob, jakým přemýšlíme o jeho provozu.

U kritických aplikací nestačí mít kontakt na známého „Ajťáka“, kterému zavoláme, když se něco pokazí.

Provoz kritických aplikací vyžaduje systém, tým, zastupitelnost, znalosti, nástroje. A software, který se dá jako mission critical provozovat a podporovat.

Nejprve byznysový dopad. Potom SLA

O provozu se často začíná debatou o technických parametrech.

Potřebujeme dostupnost 99,5 %, nebo 99,9 %? Reakci do hodiny, nebo do třiceti minut? Podporu v pracovní době, nebo 24/7?

Podle mě je to obráceně.

První otázka by měla znít:

Co se stane s naším byznysem, když tento systém nebude fungovat?

Až z odpovědi bychom měli odvodit provozní model.

Jiří Bartoš, Head of Operations v MoroSystems, doplňuje: „Pokud výpadek systému způsobí razantní omezení fungování interně nebo vůči zákazníkům a z toho plynoucí nemalé škody, potom je profesionální provozní podpora nutnost.“

Právě to je podle mě správná optika.

Profesionální provoz není položka, kterou potřebuje každý software automaticky. Je to řízení konkrétního podnikatelského rizika.

Pokud aplikace není kritická a její oprava může bez větších následků počkat týdny, nedává smysl platit za nepřetržitou pohotovost.

Pokud ale přes systém tečou peníze, obsluhuje zákazníky nebo bez něj přestává fungovat důležitá část firmy, náklady na provoz musíme porovnávat s úplně jinou veličinou: s náklady na nedostupnost.

Výpadek totiž nestojí jen ušlé tržby

Při výpočtu dopadu výpadku se často díváme pouze na přímou finanční ztrátu.

Kolik objednávek neproběhne za hodinu? Kolik plateb se neuskuteční?

To je vskutku velmi důležité. Jenže skutečný dopad bývá širší.

Někdy zákazník transakci provede později, takže o celou tržbu nepřijdeme. Přesto mohl stát u pokladny s nefunkční platbou, musel nákup přerušit nebo zaplatit jinak. Finančně se škoda těžko vyčísluje, ale zákaznická zkušenost a reputace dostaly zásah.

K tomu připočítejme zaměstnance, kteří incident řeší, možné ruční workaroundy, navazující problémy v dalších systémech a v regulovaných odvětvích také bezpečnostní a regulatorní povinnosti.

Profesionální podpora je drahá. Co si zákazník kupuje?

Ne service desk.

Ne monitoring.

Ne telefonní pohotovost.

To jsou pouze prostředky.

Zákazník si provozní službou kupuje především předvídatelnost a odpovědnost.

Všichni ví, jaké provozní parametry má systém plnit. Ví, kam se obrátit. Ví, kdo začne problém řešit. Ví, jak probíhá eskalace. Atd. Atd.

Jirka Bartoš pro to používá jednoduché pojmenování: „Zákazník si zde kupuje klidné spaní.“

Neznamená to samozřejmě příslib, že nikdy žádný incident nenastane. U složitých systémů něco takového slíbit nelze.

Znamená to něco podle mě realističtějšího a cennějšího: když problém nastane, existuje profesionální tým, který ho začne řešit a vyřeší.

SLA nemá být katalogová položka

„Každý systém je jiný. Každý zákazník má jiné potřeby. Potřebují jiný provozní model a služby s tím související, “ doplňuje Jiří Bartoš, Head of Operations, MoroSystems.

U každého systému nejprve potřebujeme pochopit jeho význam pro byznys, architekturu a očekávání zákazníka. Teprve potom lze rozumně nastavit dostupnost, reakční dobu, priority incidentů nebo režim pohotovosti.

U některých systémů se bavíme o 24/7 režimu a reakci v desítkách minut. U jiných je správným řešením podpora během pracovní doby.

Smyslem není nastavit nejvyšší možné SLA.

Smyslem je nastavit takové SLA, které odpovídá reálnému riziku.

To má mimochodem zásadní dopad také na cenu služby. Profesionální provoz aplikací není zdarma. Vyžaduje lidi, zastupitelnost, monitoring, infrastrukturu, procesy a připravenost.

Proto musí být provoz stejně jako samotný vývoj součástí business case. Zákazníci s ní musí počítat a typicky tří či pětiletý provoz zahrnovat do ROI.

Jedna otázka, kterou bych položil každému CIO

Pokud máte ve firmě systém, o kterém říkáte, že je „kritický“, zkuste si položit jednoduchou otázku:

Co přesně se stane, když dnes ve dvě ráno přestane fungovat?

Kdo se to dozví jako první?

Kdo bude problém řešit?

Za jak dlouho?

Bude ten člověk systém znát?

Bude mít správné přístupy?

A bude vědět, koho zapojit, pokud příčina neleží přímo v aplikaci?

Pokud jsou odpovědi jasné, máte pravděpodobně provoz postavený dobře.

Pokud odpovědí je „někomu zavoláme“, stojí za to se tématu věnovat dřív, než nastane první vážný incident.

V minulém čísle jsem psal, že přínosy digitalizace vznikají až v provozu.

Dnes bych k tomu přidal druhou část:

Dostupnost systému není technický parametr. Je to jedna z podmínek, aby se investice do softwaru vůbec mohla vracet.

A v příštím čísle se podíváme prakticky na to, co podle našich zkušeností musí být připravené, aby provoz kritického systému skutečně fungoval — od monitoringu a provozních postupů až po pohotovosti, zálohy a řešení incidentů.

Děkuji, že čtete, Tomáš