V předchozím článku o tom, zda se vedení firmy může opřít o data, šlo o nalezení příčiny nedůvěry v reporting. Teď je diagnóza hotová. Víte, proč report přichází pozdě, kdo ho potřebuje a co v něm mají čísla znamenat. Na stole leží návrh nové datové platformy. Než ho schválíte, vyplatí se zmenšit otázku: kterou konkrétní část práce potřebujete změnit a co má po změně fungovat jinak?
Pro první rozhodnutí vyberte jeden ucelený tok dat. Může vést od objednávek přes výpočet tržeb až k rannímu dashboardu a exportu pro finance. U takto vymezeného toku můžete porovnat různé způsoby provozu, ověřit výsledek a určit, kdo za něj odpovídá. Samotná tabulka je příliš úzká, pokud nevíte, kdo ji plní a kdo z ní čte. Celá platforma zase může zahrnout spoustu práce, pro kterou zatím nemáte důvod ke změně.
Tři možnosti pro stejný požadavek
Ponechání současného řešení si zaslouží stejné posouzení jako migrace. Pokud řešení plní potřebný účel, má zajištěnou podporu a někdo odpovídá za jeho rizika, může být rozumné ho zachovat. Cílená oprava dává smysl tam, kde lze odstranit konkrétní příčinu uvnitř stávajícího toku. Přesun přichází na řadu, když důležitý požadavek zůstává nesplněný a dovedete vymezit část, kterou ověříte v jiném prostředí.
Následující příklad je celý hypotetický. Jeho omezení i časy jsou zvolené pro vysvětlení rozhodnutí; nejde o klientskou zkušenost, výsledky migrace ani obecně doporučené limity.
Firma potřebuje každý pracovní den do 8:00 ve svém dohodnutém časovém pásmu přehled prodeje za předchozí pracovní den. Definice prodeje je už vyjasněná. Problém spočívá v tom, že výpočet sdílí provozní okno s jinými úlohami, a za současných podmínek proto nelze ranní termín spolehlivě dodržet. Pro tento příklad předpokládejme, že samotná úprava dotazu ani změna rozvrhu toto omezení neodstraní.
| Možnost | Co by v tomto příkladu znamenala | Rozhodnutí a důvod |
|---|---|---|
| Ponechat | Dál používat současný výpočet i jeho provozní okno. | Nevyhovuje požadavku na ranní dostupnost. |
| Cíleně opravit | Upravit dotaz nebo čas spouštění uvnitř současného řešení. | Za uvedených předpokladů neodstraní společné omezení. Pokud se ho podaří odstranit, má se tato možnost znovu posoudit. |
| Přesunout tento tok | Počítat přehled v samostatném reportingovém prostředí. | Ověřit jako kandidáta, protože může oddělit jeho provozní rozvrh. Přepnutí zatím není schválené. |
Výsledkem je rozhodnutí ověřit přesun reportingu prodeje. Objednávkový systém dál přijímá objednávky a zůstává autoritativním zdrojem. Ostatní části datové platformy zůstávají mimo tento záměr. Výměna celé platformy by vyžadovala další důvody, které tento příklad neposkytuje.
Za ranním dashboardem se může skrývat čtvrtletní export
Rozsah přesunu určuje i to, co ze stejných dat vzniká méně často. V našem příkladu finance používají čtvrtletní export ze stejných prodejních podkladů. V logu za běžný týden se nemusí objevit ani jednou. Přesto se na něj musí myslet při testování i při vypínání původních úloh.
Proto vedle logů projděte také rozvrh exportů a ověřte jejich použití s odpovědnými lidmi. Na tabulky používané jen jednou za tři nebo šest měsíců výslovně upozorňuje také dokumentace migračního posouzení Google Cloud. Klid v krátkém pozorovaném období není důkaz, že už data nikdo nepotřebuje.
Do posuzovaného toku tak patří výpočet prodeje, ranní dashboard a čtvrtletní export. Při přesunu musíte zajistit i přístupová práva, spouštění úloh a odpovědnost za řešení neúspěšné aktualizace. Přesun souborů a tabulek bez těchto vazeb by ještě nezajistil fungující reporting.
Co musí nové řešení prokázat
Stejný počet řádků je užitečná kontrola, ale neříká, zda report stále znamená totéž. Dvě tabulky mohou mít shodnou velikost a přitom jinak započítávat storna nebo přiřazovat objednávky ke dni.
V příkladu proto obě cesty dostanou stejný uzavřený snímek zdrojových dat. Tým porovná klíče a duplicity i prodeje po dnech a prodejních kanálech, se stejnou přesností měnových částek a stejnou hranicí pracovního dne. Zvlášť ověří vratky, zrušené objednávky a dodatečné opravy. Vedoucí financí potvrdí zahrnuté stavy objednávek, význam výsledku a zachování formátu čtvrtletního exportu. Finance tak ověří, že se po přesunu mohou podle reportu rozhodovat stejně jako před ním.
Před přepnutím musí projít i běžný provoz: oprávněný člověk report otevře, nepovolená role se k němu nedostane a neúspěšná aktualizace je viditelná. Report nesmí vydávat včerejší úspěšné načtení za dnešní čerstvá data.
Pro ukázku si tým stanoví pět po sobě jdoucích denních aktualizací dokončených do 8:00 a úspěšné zkušební zpracování reprezentativních dat z konce čtvrtletí. Pět běhů je zde konkrétní podmínka rozhodnutí, nikoli univerzální důkaz spolehlivosti. A zkouška čtvrtletního zpracování ještě není skutečná čtvrtletní uzávěrka.
Do stejného rozhodnutí patří náklady. U všech tří variant porovnávejte stejný tok, objem dat a období. Zvlášť zapište pravidelný provoz a jednorázovou práci. Pokud původní platforma dál obsluhuje jiné úlohy, přesun jednoho reportu nemusí snížit její účet; takovou částku nelze celou započítat jako úsporu.
Vedle budoucího provozu počítejte dočasný souběh obou cest, dvojí načítání a ukládání dat, přenosy, ověřování, podporu a následné odstranění nepotřebných částí. V příkladu zadavatel požaduje, aby pravidelný provoz po dohodnutém vypnutí původních částí nebyl dražší než doložený současný provoz tohoto reportingu. Rozpočet přechodného souběhu schvaluje zvlášť. Dokud tyto částky a podmínky nejsou známé, přepnutí čeká. Změna prostředí sama o sobě úsporu nedokládá.
Návrat musí fungovat i s novými daty
Přepnutí schvaluje CTO na základě výsledků předložených datovým týmem a souhlasu vedoucího financí s výsledky. Obě cesty musí mít zpracovaný tentýž dokončený zdrojový snímek; tým zaznamená jeho identifikátor i verze připojení. Potom přesměruje pouze čtenáře reportu. Zápis objednávek se nemění. Nesplněná podmínka znamená, že se nepřepíná.
Pro případ chyby zůstane původní reporting v našem příkladu deset pracovních dnů dál aktualizovaný ze stejných autoritativních podkladů. Při závažné chybě ve výpočtu, oprávněních nebo čerstvosti dat tým pozastaví zveřejňování výsledků. Návrat schvaluje CTO na základě ověření datového týmu. Čtenáře vrátí na původní cestu teprve poté, co ověří, že i původní cesta zpracovala poslední přijatý zdrojový snímek. Musí v ní být zahrnuté také nové objednávky a opravy až do hranice tohoto snímku.
Tento návrat je možný díky důležitému omezení: nové prostředí slouží jen pro odvozený reporting. Nevznikají v něm samostatné obchodní zápisy ani ruční opravy, které by jinde neexistovaly. Kdyby takové změny přibyly, samotné přepnutí připojení by je mohlo ztratit. Nejdřív by bylo nutné vyřešit jejich přenos a sladění. Podobně AWS rozlišuje návrat beze změny dat a návrat po nových zápisech, při kterém už původní kopie může být zastaralá.
Tým si návrat vyzkouší před přepnutím. Když původní cestu nedokáže ověřit, zveřejňování zůstane pozastavené; neověřený report není náhradní řešení. Deset pracovních dnů je v tomto příkladu zvolené pozorovací období. Neznamená, že během něj automaticky nastane čtvrtletní uzávěrka nebo že po jeho uplynutí lze původní reporting bez dalšího vypnout.
Vypnutí má vlastní podmínky
Po deseti pracovních dnech proběhne kontrola provozu. Původní úlohu a pohled pro denní report lze odstranit až po přijetí výsledků, ověření návratu, kontrole zbývajících závislostí a zachování potřebných definic a podkladů pro obnovu. Pokud některou tabulku dál čte jiná úloha, tabulka zůstává.
Původní cesta čtvrtletního exportu zůstane v provozu déle: do chvíle, kdy vedoucí financí přijme skutečný čtvrtletní běh nové cesty. Dřívější zkouška připravila podklady pro přepnutí denního reportu, ale sama nestačí k odstranění této závislosti. Z rozhodnutí „přesuneme reporting prodeje“ tak může vzejít několik různých termínů vypnutí. Pro celý datový sklad z něj žádný termín neplyne.
Jak zapsat rozhodnutí, ke kterému se dá vrátit
Zápis by měl uchovat důvod volby a podmínky, za kterých ještě platí. Princip rozhodnutí s vlastníkem, kontextem a důsledky používají i architektonické rozhodovací záznamy, ADR. Pro tento příklad může stručná verze vypadat takto:
SALES-01 — schváleno k omezenému ověření, přepnutí zatím čeká. Ověříme samostatný reporting prodeje, protože ponechání ani posuzovaná oprava za daných předpokladů nesplní ranní termín. Objednávkový systém a ostatní úlohy nepřesouváme. Za technické rozhodnutí odpovídá CTO; význam výsledků a čtvrtletní export přijímá vedoucí financí. Přepnutí vyžaduje splnění datových, provozních a nákladových podmínek a vyzkoušený návrat k aktuální původní cestě. Kontrola nastane deset pracovních dnů po skutečném přepnutí. Původní cestu čtvrtletního exportu odstraníme až po přijetí skutečného čtvrtletního běhu v novém prostředí. Rozhodnutí znovu otevřeme při překročení schválených nákladů, nesplnění ranního termínu, vzniku samostatných zápisů v novém prostředí nebo překážce plánovaného vypnutí.
To je hotové rozhodnutí o dalším kroku. Výsledky ověření ani úspěšnou migraci nepředjímá. Pro vlastní použití je k dispozici vyplněný příklad a prázdný pracovní list, kde lze rozepsat odpovědnosti, důkazy a podmínky bez zkracování.
Pokud už znáte příčinu problému a potřebujete porovnat varianty i rozsah změny, můžeme je projít v rámci architektury datových a AI systémů. Pokud zatím není jasné, proč číslům nebo reportům nelze věřit, vhodným prvním krokem je datový audit.