Architekt nebo matematik?

Když firma vybírá CRM, dřív nebo později vznikne tabulka. Řádky jsou funkce, sloupce dodavatelé, v buňkách fajfky a body. Vypadá to objektivně a matematicky — sečteš, vynásobíš vahami, vyhraje nejvyšší číslo.

Má to jeden problém: nejdražší rozhodnutí projektu v té tabulce vůbec nejsou.

Proč ta tabulka vždycky vznikne

Začnu tím, co se o srovnávacích tabulkách obvykle neříká: nevznikají z hlouposti. Vznikají z potřeby, která je naprosto legitimní.

Někdo ten výběr musí podepsat. A ten člověk potřebuje umět doložit, že rozhodl objektivně — před vedením, před nákupem, někdy před auditem. Tabulka to umí jako nic jiného. Převede složité rozhodnutí na číslo, číslo se dá obhájit a odpovědnost se rozdělí mezi všechny, kdo do ní přispěli řádkem.

To je taky důvod, proč tabulka přežije, i když všichni v místnosti vědí, že je neúplná. Neplní roli rozhodovacího nástroje. Plní roli dokladu o rozhodnutí. Když si tenhle rozdíl nepojmenujete, budete se hádat o váhy a body, místo abyste se hádali o to, co v tabulce chybí.

Nejednou jsem k tomuhle vedl workshop o volbě mezi jednou a více instancemi — a to hlavní zjištění nebylo technické. Bylo v tom, že u téhle otázky rozhoduje firemní politika minimálně stejně silně jako architektura. Kdo vlastní systém. Kdo platí provoz. Kdo musí čekat na cizí release. Tabulka tyhle otázky nepoloží, protože na ně nemá sloupec.

Rozhodnutí, které v tabulce nenajdete

Konkrétní příklad z praxe. Pro mezinárodní bankovní skupinu jsem navrhoval platformu pro komunikaci s dlužníky — e-mail, SMS a fyzické dopisy s QR kódem, orchestrované z Marketing Cloudu, data přes Kafka. Než se napsala první řádka konfigurace, museli jsme rozhodnout otázku, kterou žádná srovnávací tabulka nepoloží: jedna sdílená instance pro všechny země, nebo samostatná instance pro každou?

Obě varianty "mají všechny funkce". Obě dostanou v tabulce stejné body. A přitom tohle jediné rozhodnutí určilo bezpečnostní model (DPIA, šifrování, BYOK), náklady na provoz na roky dopředu a to, jak rychle půjde řešení rozšířit do další země.

Zajímavější než odpověď je to, podle čeho se rozhodovala. Žádné z těch kritérií není funkce:

• Kde leží regulatorní hranice. Co smí opustit zemi, co ne, a kdo je za to odpovědný v každé jurisdikci.
• Jak moc se liší proces. Vymáhací strategie — akcelerované ukončení, dohledávání dlužníka, inkaso — se mezi zeměmi lišily. Otázka byla, jestli jsou to varianty jednoho procesu, nebo tři různé procesy, které si jsou náhodou podobné.
• Kdo komu blokuje release. Ve sdílené instanci čeká jedna země na druhou. To není technický detail, to je provozní model na roky.
• Kdo to platí. Sdílený provoz znamená sdílený rozpočet, a tím i spor o priority. Každý rok znovu.

Navrhli jsme to jako řešení určené k opakovanému použití napříč skupinou a dodali první entitu. To rozhodnutí by z porovnávací tabulky nevypadlo, protože tabulka porovnává dodavatele. Tady se rozhodovalo o firmě.

Proč se to nedá sečíst

Matematika v tabulce funguje, když jsou položky nezávislé a srovnatelné. Architektura je přesný opak: samá závislost.

Datový model omezuje reporting — a to zjistíte až za rok, kdy chce vedení číslo, které ve zvoleném modelu nejde spočítat bez přepočtu historie. Model viditelnosti dat určuje, kdo smí co vidět; v bance s tisíci bankéři je to větší téma než všechny funkce dohromady, protože se od něj odvíjí i to, co půjde reportovat po segmentech. Integrační vzor určuje, co se stane, když jeden systém spadne — jestli se transakce zařadí do frontu a dojede, nebo tiše zmizí.

Žádnou z těch tří věcí nejde ohodnotit body, protože jejich hodnota neexistuje samostatně. Existuje jen ve vazbě na ostatní dvě. Práce architekta tady není nakreslit diagram. Je rozhodnout trade-offy, které nejdou sečíst, a nést je.

Proto se taková rozhodnutí neschvalují výpočtem, ale obhajobou. Na projektu v největší české bance jsem dva roky obhajoval každé podstatné rozhodnutí před interním architecture boardem, bezpečností i byznysem. Ne proto, že by banka milovala byrokracii, ale protože věděla, že tahle rozhodnutí se zpětně opravují nejhůř.

Proč se špatná volba opravuje novým projektem

Tuhle větu používám často a stojí za to ji rozepsat, protože sama o sobě zní jako strašení. Nejde o to, že by se architektura nedala změnit. Jde o to, co se na ni mezitím navěsí.

Za rok provozu máte pod původním rozhodnutím čtyři vrstvy. Data, která už jsou zapsaná v té struktuře, včetně historie, kterou nikdo nechce ztratit. Oprávnění, která jsou z modelu odvozená, často ručně a nedokumentovaně. Integrace, které mají to rozhodnutí zapečené v kontraktu — a na druhém konci systém, který se kvůli vám nepředělá. A zvyky lidí plus reporty, které na tom stojí.

Změna architektury proto není migrace. Je to změna všech čtyř vrstev naráz, se zachováním provozu. Proto to vypadá jako nový projekt. Protože to nový projekt je.

Praktický důsledek pro výběrové řízení: u každého kritéria v tabulce si zkuste odpovědět, jak drahé by bylo to za dva roky změnit. Kritéria, u kterých je odpověď "levně", si nezaslouží váhu, kterou jim dáváte. A ta, u kterých je odpověď "novým projektem", v tabulce většinou vůbec nejsou.

Co vidím ve většině výběrových řízení

Tři vzorce, které se opakují nezávisle na odvětví.

Tabulku staví ti, kdo systém budou používat. To je správně a zároveň je to důvod, proč obsahuje funkce a ne architekturu. Uživatel dokáže precizně popsat, co potřebuje vidět na obrazovce. Nedokáže popsat, jaký datový model to unese, a nemá to v popisu práce.

Váhy se často dolaďují po prvním kole bodování. Málokdy z nekalých pohnutek — spíš proto, že první výsledek "nevypadá správně" a všichni cítí, že něco chybí. Chybí ale kritérium, ne váha.

Vágní požadavek vyhraje dodavatel, který na něj napíše nejlepší odpověď. Ne ten, který ho splní nejlíp. Rozdíl mezi tím, co bylo v tabulce, a tím, co se pak reálně stavělo, se vyfakturuje jako změnové požadavky. Tohle vidím z obou stran: v poradenské roli sedím na straně klienta, ale nabídky na dodávku Salesforce také naceňuji — a proto vím, kolik prostoru vágní zadání dodavateli otevírá.

Co má být rozhodnuté, než tabulka vznikne

Aby tabulka fungovala, musí porovnávat srovnatelné věci. To znamená, že tyhle věci jsou rozhodnuté předem, ne během vyhodnocení:

1. Datový model v hrubých rysech a vlastnictví entit. Které entity systém vlastní a které jen zobrazuje z jiného zdroje.
2. Strategie instancí. Jedna, nebo víc. Včetně důvodu, který obstojí i před tím, kdo bude platit provoz.
3. Model viditelnosti dat. Kdo vidí co a z čeho se to odvozuje. Ne seznam rolí — princip.
4. Integrační vzor a chování při výpadku. Synchronně, nebo asynchronně, a co se stane s daty, když protistrana neodpoví.
5. Rozsah prvního nasazení. Co je v MVP a co je v druhé vlně, s cenou obojího.

Když tohle máte, tabulka konečně dělá to, na co je dobrá: srovnává cenu, licenční model a zralost dodavatele nad stejným zadáním. Když to nemáte, každý dodavatel si ta rozhodnutí udělá po svém, nabídky přestanou být srovnatelné a tabulka to zamaskuje tím, že z nich udělá čísla.

Kdy tabulku použít

Aby bylo jasno: srovnávací tabulka má své místo. Je užitečná na konci — když máte hotovou architekturu, jasné zadání a porovnáváte dvě tři řešení, která už prošla hrubým sítem. Tam poctivě odliší cenu, licenční model a zralost dodavatele.

Kde tenhle přístup selhává

Aby to nebylo jednostranné. Architektura před výběrem se dá přehnat a viděl jsem to i u sebe.

První způsob je navrhnout na rozsah, který nikdy nepřijde. Vícejazyčný, víceentitní, víceměnový model pro firmu, která za pět let působí pořád v jedné zemi. Zaplatíte složitost, ze které nikdy nic nevytěžíte.

Druhý je nechat architekturu zdržet rozhodnutí. Existuje bod, kdy další analýza už nezmenšuje riziko, jen odkládá zahájení — a odklad má taky cenu, jen ji nikdo nevykazuje.

Rozdíl mezi dobrou a přehnanou architekturou před výběrem není v hloubce. Je v tom, jestli řešíte rozhodnutí, která se opravují novým projektem, nebo ta, která se dají změnit ve druhém sprintu. Těch prvních je pět, možná osm. Zbytek počká.

Nejdřív architektura, pak matematika

Obráceně to nefunguje. Tabulka není špatný nástroj — je to nástroj na poslední krok, který se používá jako nástroj na první. A protože vypadá objektivně, nikdo se neptá, co v ní není.

O tom, čím výběr CRM začít místo výběru systému, jsem psal v textu Jak začít s CRM? Ne výběrem systému.

Řešíte podobné rozhodnutí — single vs. multi-org, výběr platformy, integrační architekturu? Domluvme si konzultaci na tvadvisory.cz/kontakt.