Platíte za systém, nebo za cizí předpoklady?

Nebudeme psát o porovnávání dodavatelů a nákladových kalkulačkách. Budeme psát o tom, kde tenhle výběr rozhoduje o tom, jak vaše firma funguje za tři roky.

Věci jako:

• proč SaaS na zkoušku vydrží rok, pak přestane stačit a výměna stojí víc než stavba od začátku
• kde je hranice mezi ohýbáme procesy na nástroj a nástroj nám brzdí provoz
• jak klient z fintechu ušetřil přechodem na vlastní systém a jak medical firma naopak zrychlila koupí SaaS
• proč pojišťovny a banky dělají Make vs. Buy dvakrát: jednou pro core systém, jednou pro vše kolem něj
• co na tomhle rozhodnutí závisí víc: cena vývoje, nebo cena přizpůsobení?
• jak to otestovat předtím, než podepíšete smlouvu nebo spustíte projekt
•  

Většina firem tohle rozhodnutí neřeší dopředu. Řeší ho reaktivně, až když SaaS přestane stačit nebo vývoj překročí rozpočet.

Jeden klient z fintechu platil za SaaS pro správu interních operačních procesů: schvalovací workflow, reporty, napojení na regulátora. Systém pokrýval standardní případy, ale jejich provoz standardní nebyl. Každý regulatorní požadavek znamenal úpravu na straně dodavatele. Každá změna workflow čekala na cizí release cyklus.

Rozhodli se postavit vlastní nástroj. V prvním roce bylo dražší než pokračovat v licenci. Za dva roky přestali platit za čekání na dodavatele a začali měnit procesy vlastním tempem, bez ticketu a bez fronty.

Klient z medical segmentu šel opačnou cestou. Potřeboval CRM. Jejich prodejní procesy byly standardní, žádná specifická logika, žádný provoz, který by se lišil od desítek podobných firem. Navíc regulatorní a bezpečnostní požadavky v medical jsou vysoké. Stavět vlastní by znamenalo certifikace a audity navíc, bez reálné výhody. Koupili SaaS, spustili za měsíce.

Obě rozhodnutí byla správná. Protože obě firmy věděly, kde mají specifický provoz a kde ne.

Build přitom není automaticky lepší volba. Záleží na tom, jestli máte technologického partnera nebo interní tým. Bez toho může samotný výběr a rozjezd dodavatele trvat déle než SaaS implementace, a vývoj na míru snadno přesáhne tříletou licenci dřív, než se vrátí. Kalkulace se obrátí ve chvíli, kdy SaaS přestane stačit, nebo kdy specifický provoz začíná brzdit rychlost firmy.

Je ale ještě třetí scénář, který bývá nejsložitější. Pojišťovny a firmy s regulovaným prostředím si kupují core systém, což je jejich Buy rozhodnutí, a dává smysl. Ale kolem core systému je celá vrstva: klientský portál, integrace na CRM, digitální kanály, procesní aplikace pro interní týmy. Tuhle vrstvu core vendor nedodá, nebo ji dodá genericky. A právě tady se rozhoduje, jak rychle firma dokáže měnit produkty, zapojovat partnery a digitalizovat provoz.

Firmy v tomhle scénáři dělají Make vs. Buy dvakrát a zaměňují je. Core systém koupí, ale pak čekají, že vendor dodá i digitální vrstvu. Nebo naopak začnou buildovat vlastní core, protože se bojí vendor locku, a ignorují, co to stojí.

Jednoduchý test: kde se ohýbáte vy?

Projděte tři až pět klíčových procesů, kde používáte externího dodavatele nebo platformu. U každého odpovězte na tři otázky:

Přizpůsobujeme proces nástroji, nebo nástroj procesu?

Je tenhle proces součástí toho, čím se lišíme od konkurence, nebo je to věc, kterou dělá každý stejně?

Vodítko: kdyby konkurence koupila stejný systém a nastavila ho stejně, fungovala by úplně jako vy? Pokud ano, je to komodita.

Je to jedno rozhodnutí, nebo dvě? Kde končí core systém a kde začíná vrstva, kterou potřebujeme na míru?

Pokud přizpůsobujete proces a zároveň je to váš specifický provoz, platíte za cizí předpoklady. Pokud si myslíte, že máte jedno rozhodnutí, ale ve skutečnosti máte dvě, platíte za oboje špatně.

Co se typicky ukáže

Firmy mají tři typy situací naráz:

• Jedno rozhodnutí, správná volba: komoditní proces, SaaS stačí, tým ho udržuje. HR systém, základní účetnictví, standardní CRM pro neregulovaný segment.
• Jedno rozhodnutí, špatná volba: specifický provoz koupený jako SaaS. Firma se přizpůsobuje, platí za obcházení limitů a nemá to v číslech.
• Dvě rozhodnutí zaměněná za jedno: core systém koupený správně, ale digitální vrstva kolem něj taky koupená od stejného vendora, i když ji vendor neumí. Nebo naopak: firma builduje od základu, protože se bojí koupit core.

Třetí případ je nejdražší. Nevidí se hned, objeví se za dva roky, když firma potřebuje spustit nový produkt a zjistí, že to trvá půl roku, protože digitální vrstva je pevně svázaná s core systémem.

Co s tím bez porovnávání dodavatelů a bez tenderového procesu

Tenhle seznam zabere hodinu. Většina firem ho nikdy neudělala.

• Napište seznam procesů, kde platíte externímu dodavateli.
• U každého označte: je tenhle proces specifický pro váš provoz, nebo je to komodita?
• U specifických procesů: spočítejte, kolik hodin měsíčně váš tým tráví obcházením limitů nástroje. Pak se ptejte, co by stálo tříměsíční vývoj na míru.
• U komoditních procesů: zajímá vás bezpečnost, cena a rychlost nasazení. Nic víc.
• Tam, kde máte core systém od vendora: explicitně rozhodněte, co patří do core a co je digitální vrstva kolem. Tato dvě rozhodnutí se dělají nezávisle a mají jiné odpovědi.

Výsledek ukáže, kde platíte za cizí předpoklady a kde zaměňujete dvě rozhodnutí za jedno.

Pohled za byznys Jakub Stengl

Klient z fintechu měl provoz, který vypadal standardně: schvalování, reporty, napojení na regulátora. Ale detail byl v tom, jak rychle potřeboval měnit pravidla. SaaS to nedovoloval vlastním tempem. Až když jsme spočítali, kolik hodin týdně lidé tráví obcházením limitů systému, bylo jasné, že platí za cizí předpoklady o tom, jak jejich procesy mají fungovat.

Medical klient to měl jednodušší. Věděl, že prodejní proces není jeho výhoda, výhoda je produkt a vztah s klientem. Systém, který to administruje, má být rychlý, bezpečný a splňovat regulaci. SaaS splňoval všechny tři. Vývoj by přidal odpovědnost bez hodnoty.

Například pojišťoven je tohle složitější, protože tam jsou vždy dvě rozhodnutí naráz. Core systém (pojistné výpočty, kmenová data, likvidace) je legitimní Buy. Ale klientský portál, digitální kanály, integrace na partnery a procesní aplikace pro interní týmy jsou jiné rozhodnutí. Vendor core systému je nedodá dobře, nebo je dodá genericky a firma bude rok čekat na každou změnu. Tady platí Build, ne proto, že by firma chtěla vyvíjet software, ale proto, že tato vrstva rozhoduje o tom, jak rychle se firma dokáže měnit.

Tahle otázka nepatří do IT. Patří na byznys stranu stolu, kde někdo ví, kde firma skutečně vydělává a kde potřebuje mít kontrolu.

Pohled za technologie Jakub Inger

Vendor lock není o tom, že nemůžeš odejít, ale o tom, jak rychle dokážeš tu závislost změnit. U core systému ti rychlost obvykle stačí, pojistné výpočty a kmenová data se nemění každý týden, ale digitální vrstva kolem se mění pořád. Klientský portál, nový kanál, integrace na partnera. Když tahle vrstva visí na release cyklu core vendora, čekáš na cizí roadmapu pokaždé, když chceš změnit vlastní produkt.

U každého specifického procesu se neptej umíme to postavit? To dneska skoro vždycky ano. Ptej se kolikrát za rok to budeme chtít měnit?. Když je odpověď víc než dvakrát a sedíš na cizí vrstvě, ten lock-in tě bude stát řádově víc než ten vývoj a uvidíš to až za dva roky, ne teď.