Praktický sprievodca architektúrou dátovej rezidencie

Na vytvorenie finančnej správy jeden kolega stiahne tabuľku z cloudu, druhý požiada o údaje z ERP a tretí kopíruje údaje z portálu externého partnera. Proces funguje - až kým nevznikne otázka: kde presne sú tieto údaje, kto k nim má prístup a čo sa stane, ak systém alebo poskytovateľ vypadne?

Praktický sprievodca architektúrou rezidencie údajov sa netýka primárne umiestnenia serverov podľa krajín. Ide o to, aby bolo možné kontrolovať ukladanie, spracovanie, prenos a obnovu informácií dôležitých pre podnik. V spoločnosti s 20-500 zamestnancami to priamo ovplyvňuje kontinuitu prevádzky, spoľahlivosť správ, dôveru partnerov a riziká súladu.

Čo je to rezidencia údajov?

Rezidencia údajov sa týka toho, v akom geografickom, právnom a prevádzkovom prostredí sa údaje fyzicky a logicky nachádzajú. Nestačí vedieť, že aplikácia „beží v cloude“. Je dôležité objasniť, v ktorom regióne sú uložené primárne údaje, kde sa robia zálohy, kam smerujú integračné správy a v ktorej krajine pracuje podporný personál, ktorý môže v prípade potreby pristúpiť k systému.

Otázka sa stáva zvlášť hmatateľnou, keď e-shop posiela objednávkové údaje do ERP, ERP odovzdáva informácie fakturácii a logistický partner dostáva údaje potrebné na doručenie. Údaje jednej objednávky sa môžu objaviť v niekoľkých systémoch, v niekoľkých kópiách a dokonca v niekoľkých krajinách. Ak to nikto vedome neplánoval, spoločnosť v skutočnosti nevie s úplnou istotou, kde spravuje svoje údaje.

Preto rezidencia údajov nie je len právna alebo IT otázka. Je to aj prevádzková otázka. Ak nie je jasné, kde sa nachádza kritická informácia, kto ju vlastní alebo ako sa obnovuje, denná prevádzka sa opiera o skrytú závislosť.

Architektúra rezidencie údajov: najprv zmapujte cestu údajov

Častou chybou je, že organizácia si vyberie poskytovateľa alebo cloudovú platformu predtým, ako preskúma tok údajov. Je to ako postaviť nový sklad bez toho, aby vedeli, aký tovar, ako často a odkiaľ tam prichádza.

Dobrým východiskovým bodom je niekoľko kľúčových obchodných procesov. Môže to byť plnenie objednávok, správa výrobných pracovných listov, fakturácia, prenos údajov súvisiacich s mzdami alebo tvorba manažérskych správ. Pri každom procese je potrebné pochopiť, odkiaľ údaje pochádzajú, kto ich upravuje, ktoré systémy z nich dostávajú kópie a kde zostávajú dlhodobo.

Nie všetky údaje vyžadujú rovnakú ochranu alebo rovnaké geografické zaobchádzanie. Verejný produktový katalóg, interná správa o zásobách, zmluva a dokumenty HR obsahujúce osobné údaje predstavujú rôzne riziká. Príliš prísna regulácia môže zbytočne zdražiť a spomaliť prevádzku. Príliš voľný prístup však môže viesť k nekontrolovaným prístupom a ťažko zvládnuteľným situáciám súladu.

Vytvorte inventár údajov s obchodným zodpovedným

Inventár údajov nie je technická tabuľka vyplnená IT oddelením. Každá dôležitá skupina údajov potrebuje obchodného zodpovedného, ktorý vie povedať, prečo sú údaje potrebné, ako dlho ich treba uchovávať, aká chyba by spôsobila obchodný problém a kto ich môže používať.

Je vhodné zaznamenať typ údajov, primárny systém, cieľové systémy integrácií, región ukladania, miesto zálohovania, dobu uchovávania a prístupové role. Ak informácia existuje v rovnakej forme v troch-štyroch systémoch, aj to treba zaznamenať. Duplikácia nie je vždy chyba: môže byť potrebná pre dostupnosť, výkon alebo zákonné uchovávanie. Ale každá kópia by mala mať dôvod a vlastníka.

Rozhodnutia by mali byť vedené rizikom a prevádzkovými potrebami

Pri rozhodovaní o rezidencii údajov zriedka existuje jedno univerzálne riešenie. Pre spoločnosť fungujúcu výlučne s domácimi systémami môže byť odôvodnené, aby určité údaje zostali na infraštruktúre v Slovensku. E-commerce spoločnosť predávajúca v niekoľkých krajinách však môže z výkonnostných, zákazníckych alebo partnerských dôvodov potrebovať spracovanie vo viacerých regiónoch.

Podstatné je, aby rozhodnutie bolo zdokumentované. Vedenie musí rozumieť, pre ktoré údaje je požiadavka na určený geografický región, pre ktoré je prijateľné iné umiestnenie a aké kontroly znižujú riziko. Takou kontrolou môže byť šifrovanie, prísny prístup založený na rolách, logovanie, pravidelná revízia oprávnení a testovaný plán obnovy.

Geografická poloha sama o sebe neposkytuje bezpečnosť. Miestne uložený systém môže byť rizikový, ak jeden administrátorský účet používa viac ľudí, neexistujú záložné skúšky alebo sú prístupové logy neinterpretovateľné. Rovnako tak správne navrhnuté a regulované cloudové prostredie môže byť kontrolovaným riešením, ak organizácia rozumie hraniciam zodpovednosti.

Oddelte primárne údaje, kópiu a zálohu

Mnoho problémov s prevádzkovou bezpečnosťou pochádza z neschopnosti spoločnosti rozlíšiť tieto tri pojmy. Primárne údaje sú autentickým zdrojom, z ktorého vychádza denná prevádzka. Kópia môže byť vytvorená kvôli integrácii v inom systéme. Záloha neslúži na dennú prácu, ale na obnovu.

Ak sú finančné údaje považované za autentické v ERP, ale manažérska správa sa pripravuje z ručne aktualizovanej tabuľky, tabuľka sa nesmie ticho stať druhým zdrojom pravdy. V takom prípade je potrebné najprv upraviť proces tvorby správy: prečo je potrebné manuálne kopírovanie, aké údaje chýbajú v ERP a z ktorého systému by mala správa automaticky vzniknúť?

Toto je jedna z menej viditeľných, ale dôležitých častí architektúry rezidencie údajov. Nielenže určuje, kde sú údaje, ale aj ktorým údajom sa dá dôverovať.

Integrácie sú často skryté cesty údajov

Na zozname systémov spoločnosti sa zvyčajne nachádza ERP, CRM, e-shop, fakturačný a skladový systém. Menej viditeľné sú kritické medzistupne z hľadiska toku údajov: integračné služby, e-mailové exporty, automatizované prenosy súborov, externé nástroje na reportovanie a vývojové testovacie prostredia.

Napríklad údaje objednávky prichádzajúcej z e-shopu môžu prejsť cez integračnú platformu, byť zaznamenané v denníku chýb a objaviť sa aj v e-mailovom oznámení. Ak objednávka obsahuje osobné alebo obchodne citlivé údaje, tieto cesty sú súčasťou architektúry. Nestačí skontrolovať, kde beží e-shop a ERP.

Preto je vhodné preskúmať pri každom dôležitom rozhraní, aké údaje cez ne prechádzajú, či sa dočasne ukladajú, ako dlho zostávajú, aké je riešenie chýb a kto vidí logy. Zle nastavená správa chýb môže uchovávať údaje roky, ktoré už nie sú potrebné pre operácie.

Plánujte na výpadky, nielen na normálnu prevádzku

Skutočná hodnota rozhodnutí o rezidencii údajov sa prejaví v prípade chýb. Čo sa stane, ak primárny región nie je dostupný? Koľko straty údajov je prijateľné? Ako rýchlo sa musí obnoviť spracovanie objednávok, výrobné údaje alebo fakturácia?

Tieto otázky nie sú len technické. Ak sklad štyri hodiny nevidí objednávky na plnenie, aké oneskorenie, nadčasy alebo sťažnosti zákazníkov to spôsobí? Ak výroba jeden deň nemá prístup k technickej dokumentácii, môže bezpečne pracovať? Ciele obnovy by mali byť odvodené z takýchto obchodných dôsledkov.

Záloha poskytuje ochranu len vtedy, ak je obnoviteľná. Pravidelná skúška obnovy preto nie je administratívna záťaž, ale validácia. Ukazuje, či je dokumentácia reálna, či sú oprávnenia k dispozícii a či je spoločnosť skutočne schopná uviesť kritické systémy do prevádzky.

Nepovažujte to za jednorazový projekt

Nový partner, nová krajina, nový e-shop, akvizícia alebo výmena starého systému môžu všetky zmeniť cestu údajov. Architektúra vytvorená raz preto rýchlo zastará, ak za ňou nie je riadenie zmien.

Pred každým významným zavedením systému alebo integráciou by mal existovať jednoduchý, ale povinný kontrolný bod: aké údaje nový systém spracováva, kde ich ukladá, komu poskytuje prístup, akí ďalší poskytovatelia sa zúčastňujú a ako zapadá do zálohovacieho, logovacieho a obnovovacieho plánu. To nemusí nevyhnutne spomaliť vývoj. Predchádza to neskorším prekvapeniam, manuálnym obchádzkam a nákladným úpravám.

Dobrú architektúru rezidencie údajov nie je vidieť podľa množstva dokumentov o nej. Vidieť ju podľa toho, že vedúci rýchlo dostane odpoveď na kritickú skupinu údajov: kde sú, kto za ne zodpovedá, kto má k nim prístup, čo s nimi súvisí a čo sa stane, ak primárny systém nie je dostupný. Ak dnes odpoveď prichádza len po konzultácii s viacerými ľuďmi, viacerými tabuľkami a dlhými e-mailovými výmenami, je vhodné začať mapovaním cesty údajov.