Správa dat se navrhuje do orgu

🌐 K dispozici také v 29 jazycích

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Obrázek vytvořený pomocí AI

Přeloženo pomocí AI. Komunita překlad zatím nezkontrolovala. Číst anglicky

Modul 1 z 6 kapitoly Kvalita dat a správa dat, kapitoly 5 kurzu Data Architect. Každý modul stojí sám o sobě. Další: Nepouštějte dovnitř špatná data

Otázka, na kterou tento modul odpovídá: Co znamená správa dat pro architekta a kdo dělá co?

Když lidé slyší správa dat (data governance), myslí na schůzky: výbory, zásady, standardy, dokument, který vysvětluje, kdo má s daty co dělat. To všechno může být součástí programu správy dat. Mě jako architekta zajímá jiná otázka: kde se zásada vynucuje?

Pokud zásada říká, že pole smí měnit jen Finance, co to vynucuje? Pokud říká, že právní záznam zákazníka vlastní ERP, co někomu v Salesforce zabrání ho změnit? Pokud říká, že posádky vidí adresu příjemce jen u svých vlastních zastávek a jen v daný den, co to skutečně zajistí? Pokud říká uchovávat sedm let, co to po sedmi letech archivuje nebo odstraní? Zásada bez místa vynucení je většinou jen přání. Správa dat se stává architekturou, když jsou tato rozhodnutí zabudovaná do systému.

Správa dat nikdy nekončí

Řeknu to hned na začátku: správu dat nedokončíte. Viděl jsem, jak přichází v přílivech a odlivech. Firma věnuje kvalitě dat skutečnou pozornost a věci se zlepší. Pozornost se přesune jinam a kvalita klesne. Spustí se nová integrace, obchodní jednotka změní proces, někdo naimportuje soubor, firma koupí jinou, agent začne zapisovat záznamy, a problém se zase změní. Cílem není bájný stav, kdy je každý záznam navždy dokonalý. Je to udržet data dost důvěryhodná pro byznys a nepustit dovnitř to nejhorší ze špatných dat. To je průběžná práce.

Když Salesforce stojí víceméně sám, znamená správa dat čištění dat na jednom místě. Když je to jeden uzel v krajině z kapitoly 4, je to těžší a potřebnější. Teď zákazník žije v Salesforce, v ERP, v datovém skladu, v systémech partnerů, v Data 360. Kdo ho vlastní? Kdo ho může měnit? Která kopie je autoritativní, které atributy se smějí přesouvat, jak dlouho se uchovávají a kdo odpovídá, když jsou špatně? To nejsou otázky konfigurace. Jsou to otázky správy dat, které se stávají konfigurací.

Vlastník záznamu není vlastník dat

Začněte slovem vlastník, protože ho Salesforce dělá matoucím. Otevřete účet a vidíte Owner: třeba obchodníka. Vlastní ten obchodník zákaznická data? Ne nutně. V Salesforce je záznam na objektu s vlastníkem vlastněn uživatelem nebo frontou; vlastník dostane plný přístup a řídí přiřazení a sdílení přes hierarchii rolí a pravidla sdílení (Sharing and Record Access Features (otevře se v nové kartě)). To je vlastnictví záznamu: mechanismus platformy.

Vlastník dat (data owner) je něco jiného: osoba nebo funkce, která za data odpovídá jako za obchodní aktivum. Finance mohou vlastnit právní informace o zákaznících, provoz stav doručení, personální oddělení data zaměstnanců. Salesforce vám dokonce dává, kam to zaznamenat: klasifikační pole Data Owner u každého pole (Data Classification Metadata Fields (otevře se v nové kartě)).

Ve Steve Trucking může účet maloobchodního partnera vlastnit obchodní ředitel, který o partnera pečuje. Právní identitu partnera ale řídí Finance a spravuje ji finanční ERP. Obchod, servis, provoz i partnerský portál účet potřebují; nic z toho neznamená, že by obchodní ředitel měl měnit právní identitu partnera, jakmile ji Finance stanovily. Viděl jsem týmy dívat se na pole Owner a předpokládat, že vyřešily vlastnictví dat. Nevyřešily. Přiřazení záznamu není obchodní odpovědnost.

Vlastník, správce, technický správce

Tři role správy dat, tři různé práce.

Vlastník dat stanovuje zásady. Odpovídá na to, co data znamenají, kdo je smí vytvářet a měnit, jak přesná musí být, jak dlouho se uchovávají, kdo je smí vidět, který systém je autoritativní a co se stane, když jsou špatně. Architekt by si ty odpovědi neměl vymýšlet. To je jeden z mých nejpevnějších postojů: vlastníci stanovují zásady; architekti je vynucují. Pokud Finance říkají, že oficiální název se u aktivního zákazníka smí měnit jen přes proces v ERP, je to rozhodnutí správy dat. Zajistit, aby to mechanicky platilo, je moje práce.

Datový správce (data steward) udržuje data v chodu. Správce má blízko ke každodennímu zdraví dat: sleduje signály kvality, vyšetřuje duplicity, řeší výjimky, koordinuje opravy, udržuje definice, odhaluje proces, který pořád produkuje špatná data. Se správcem souvisejí ještě dvě práce. Když se dva týmy neshodnou, co pole znamená, kdo ho vlastní nebo kdo ho smí vidět, správce donese spor k vlastníkovi a dotáhne rozhodnutí. A správce buduje datovou gramotnost: pomáhá lidem, kteří data zadávají a používají, pochopit, co znamenají a proč pravidla existují. Správce potřebuje víc než jméno v organizačním schématu. Potřebuje čas, viditelnost, proces a pravomoc zajistit opravu problémů. Jinak se „datový správce“ stane něčí osmou odpovědností, na kterou se podívá jednou za čtvrtletí.

Technický správce (custodian) provozuje systém. Administrátoři, platformní týmy, bezpečnostní týmy: kdokoli provozuje technologii, která data ukládá a zpracovává. Vlastník řekne, že je smějí vidět jen tyto role; technický správce provozuje kontroly, které to zajistí. Na názvech záleží méně než na tom, aby byla každá odpovědnost jasná, a v malé organizaci může jeden člověk nosit dva klobouky.

Jak program běží

Programy správy dat mívají tři podoby. Centralizovaný: jeden tým píše zásady a standardy pro všechny domény. Je konzistentní a může se stát úzkým hrdlem, daleko od lidí, kteří dělají práci. Federovaný (decentralizovaný): každá doména, jako finance, obchod nebo provoz, spravuje svá vlastní data v rámci několika sdílených pravidel. Má blízko k práci a definice se mezi doménami rozcházejí. Hybridní: malý centrální tým vlastní standardy a sdílené definice a vlastníci a správci domén řídí svá vlastní data. Většina podniků, které jsem viděl, skončí někde v hybridu. Pro architekta podoba odpovídá na jednu praktickou otázku: kdo zásadu schválí, než ji začnu vynucovat, a kde žijí sdílené definice?

Ke zkoušce. Znejte tři způsoby, jak vést program správy dat, centralizovaný, federovaný (decentralizovaný) a hybridní, a co každý znamená pro to, kdo stanovuje zásady a kde žijí sdílené definice.

Ať si RACI zaslouží své místo

RACI (kdo je Responsible, Accountable, Consulted a Informed) pomáhá, ale ne jako obří tabulka vytvořená proto, že ji správa dat „vyžaduje“. Chci, aby odpovídala na architektonické otázky, počínaje třemi z kapitoly 4 (Čtyři otázky za kategoriemi): kde se data vytvářejí, kde se upravují a kde se na ně odkazuje? To jsou často různé systémy. Vezměte produkt: ERP ho vytváří, Salesforce na něj odkazuje, portál ho ukazuje, datový sklad ho analyzuje. Teď byznys změní, co znamená „aktivní produkt“. Kde změna začíná, kdo ji schvaluje, jak se šíří a které kopie jsou jen pro čtení? Pokud na to neumíte odpovědět, ještě nemáte správu dat. Máte kopie. Dobrá RACI odhalí přesně tuto nejasnost.

Správa dat se musí stát mechanickou

Byznys říká, že oficiální název zákazníka smějí měnit jen Finance. Nechci, aby architektonická odpověď zněla „pokryjeme to školením“. Školení pomáhá; není to vynucení. Možná je to přístup na úrovni polí, ověřovací pravidlo, pole, do kterého zapisuje jen integrace, nebo řízený proces místo přímých úprav. Mechanismus závisí na požadavku, ale nějaký tam být musí:

Zásada správy dat	Rozhoduje vlastník	Možné místo vynucení
Právní identitu zákazníka vlastní ERP	Finance	Pole jen pro integraci, oprávnění, ověřování
Osobní údaje vidí jen lidé, kteří je potřebují	Ochrana soukromí, bezpečnost	Sdílení, oprávnění, přístup k polím
Identifikátory zákazníků jsou jedinečné	Obchodní vlastník	Jedinečné External ID, pravidla duplicit
Řízené záznamy se nevytvářejí ručně	Vlastník dat	Oprávnění, automatizace, integrace
Citlivá data mají stanovenou dobu uchovávání	Ochrana soukromí, právo	Proces uchovávání nebo mazání
Důležité změny musí být prokazatelné	Compliance	Historie polí, auditní stopa
Zdroj dat zůstává identifikovatelný	Vlastník dat	Pole zdroje, metadata původu dat

Říkám možné místo vynucení záměrně. Tohle není tabulka na vybírání funkcí. Je to pořadí myšlení: jaká je zásada, kdo ji vlastní a co v architektuře zajistí, že platí?

Kliknutím zvětšíte

Vlastníci stanovují zásady; architekti je vynucují.

Nespoléhejte na dobré chování

„Nikdy neměňte zákaznické ID z ERP.“ Všichni to vědí, dokud to někdo neudělá: omylem, přes nahrávání dat, přes automatizaci, přes integraci, přes agenta. Pokud by jeho změna poškodila podniková data, „prosím, nedělejte to“ není kontrola. Postavte kontrolu. Důvěřuj, ale prověřuj. Lidé, integrace, automatizace i AI dělají chyby, takže architektura by měla předpokládat, že se jednou něco pokusí o to, co zásada zakazuje. Co se pak stane?

Správa dat překračuje hranice systémů

Zpátky ke krajině. Zákazníka vlastní ERP; Salesforce, datový sklad a platforma zákaznických dat drží kopie; partner dostává část. Na který systém se zásada vztahuje? Na všechny. Salesforce může správně zablokovat změnu oficiálního názvu, zatímco integrace nechá systém po proudu ho přepsat. Salesforce může smazat osobní údaje, které datový sklad pořád drží. Pole klasifikované v Salesforce jako citlivé může jinde přistát v neklasifikovaném textovém poli. Správa dat se nemůže zastavit na hranici orgu, protože data se tam nezastaví. Proto přišla kapitola 4 první: krajina vám řekne, jak daleko musí správa dat sahat.

Spravujte dost, ne všechno

Opačné selhání je stejně skutečné. Zjistíme, že na správě dat záleží, a tak všechno zamkneme: nikdo nemůže vytvářet, každá změna potřebuje schválení. Data jsou spravovaná a nikdo nemůže dělat svou práci. Správa dat znamená přiměřenou kontrolu pro data: přísnou pro některá, lehkou pro jiná. Některé záznamy lze vytvářet volně, některé potřebují schválení; některá pole může upravovat skoro kdokoli, některá jen integrace. Další modul se k tomu dostane prakticky.

A protože správa dat nikdy nekončí, vynucování potřebuje zpětnou vazbu. Přibývá duplicit? Plní se povinná pole nesmysly? Selhávají integrace, hledají uživatelé obezličky, přibývá výjimek, tráví správci celý den jedním problémem? Tyto signály vám říkají, jestli návrh funguje, a někdy i to, že kontrola, nebo zásada, se musí změnit.

Nad rámec zkoušky: co mění AI. Správa dat má nového spotřebitele: agenta. Vlastník dat pořád rozhoduje, co se smí použít a k čemu; architekt to pořád dělá vynutitelným. Mění se rychlost a měřítko. Agent čte, kombinuje a jedná podle řízených dat mnohem rychleji než člověk, takže zásada, která existuje jen v dokumentu, chrání ještě méně.

Co tady rozhoduje architekt

• Kdo odpovídá za každou důležitou datovou doménu a jak se to liší od vlastnictví záznamů.
• Kdo data spravuje jako datový správce a kdo je provozuje jako technický správce.
• Kde se důležitá data napříč krajinou vytvářejí, upravují, odkazují a spravují jako kmenová.
• Jaké místo vynucení zajistí, že každá důležitá zásada mechanicky platí.
• Jak architektura ukazuje, jestli správa dat funguje, nebo jestli začíná sklouzávat.

Když slyším požadavek správy dat, překládám ho. „Tohle vlastní ERP.“ „Tohle smějí vidět jen tito lidé.“ „Potřebujeme prokázat, kdo to změnil.“ „Uchovávejte to sedm let.“ Pokaždé: ukažte mi místo vynucení. Architekt nerozhoduje o zásadě. Navrhujeme systém, který ji vynucuje. Tam přestává být správa dat dokumentem a stává se architekturou.

K prozkoumání

• Salesforce Help, Sharing and Record Access Features (otevře se v nové kartě), ověřeno 2026-10-17.
• Salesforce Help, Data Classification Metadata Fields (otevře se v nové kartě), ověřeno 2026-10-17.