V tomto článku si přiblížíme oblast IT, která se nazývá Master Data Management (MDM). Řekneme si, čím jsou Master Data specifická, kde bývají oblasti pro zlepšení a jak je řešit.
Master Data (česky také kmenová data nebo referenční data/číselníky, což je ale užší pojem – viz níže) se někdy definují jako data o zákaznících, dodavatelích, obchodních partnerech, majetku, lidských zdrojích, produktech, materiálech, projektech a dalších věcech. To jsou však pouze příklady. Pro pochopení toho, co jsou Master Data je mnohem důležitější si uvědomit, že jde o data sdílená napříč různými systémy. Pokud bychom si představili organizaci, která všechna data bude mít v jednom systému (aplikaci), téma kmenových dat by se jí netýkalo. Realita každé větší firmy je ale jiná. Různé business procesy používají různé aplikace, které byly nasazovány postupně, jak organizace rostla a začínala si uvědomovat potřeby podpory různých oblastí. Je pravda, že právě informace o obchodních partnerech, vlastních pracovnících, produktech, projektech atd. jsou jasnými příklady master dat. Pracuje se s nimi, jak v aplikacích front office (obchodníci, lidé na přepážkách...), tak back office (účetnictví a finance, logistika atd.).
Master Data jsou relativně statická (nemění se příliš často) a netransakční. Objednávky, faktury, účetní zápisy do této oblasti nespadají.
Zvláštní oblastí master dat jsou referenční data (česky číselníky). Referenční data představují povolené hodnoty v polích jiných dat. Například stav objednávky, typ zákazníka, kategorie produktu atd. Při přenosech dat mezi systémy tak nepřenášíme pouze primární datové entity, jako jsou zákazníci, produkty apod., ale množství dalších entit, které definují jejich vlastnosti.
Pokud jsou data na více místech, nutně se objevuje otázka konzistence. Co když založím zákazníka v jednom systému, ale ve druhém to zapomenu udělat? Může se stát, že v jednom systému mám jeden ceník a v druhém jiný? Mám všude stejné názvy zákazníků? Mám všude stejné stavy, typy, kategorie atd. zákazníků, produktů, materiálů…
Pokud ve vás předchozí otázky rezonují, uvědomujete si asi význam oblasti Master Data Management, kmenových dat a číselníků. Pokud dnes data pořizujete v různých systémech, s různou kvalitou a nekonzistentními atributy, pak vám Master Data Management pomůže data sjednotit a zajistit jejich propagaci napříč organizací.
Postup řešení
Pokud se této oblasti ve firmě chceme věnovat, budeme řešit postupně tyto oblasti:
- Identifikace zdrojů kmenových dat
- Klasifikace zdrojů
- Zmapování toků dat
- Stanovení zodpovědností
- Vytvoření datového modelu kmenových dat
- Architektura master dat, pravidla a plán jejího naplňování, proces práce s master daty
- Výběr technologií
- Přechod k cílové architektuře master dat a každodenní správa
Podívejme se nyní na dané oblasti detailněji.
1. Identifikace zdrojů kmenových dat
Začneme sběrem informací. Sepíšeme si jednotlivé aplikace, které s těmito daty pracují. Například data zákazníků můžeme mít v ERP systému, CRM, marketingové aplikaci, datovém skladu apod. Tyto informace dost možná už někde dostupné máte. Vyjděte ze seznamu vašich aplikací, pohovořte si s jejich správci a začněte informace o master datech organizovat.
2. Klasifikace zdrojů
Pro jednotlivé datové entity si aplikace rozdělíme na producenty (data v nich vznikají) a konzumenty (data získávají odjinud a pouze je používají). Například zákazníci vznikají v systému CRM a ERP a Datový sklad je pouze používají. Každá aplikace může být pro některá master data producentem, pro jiná konzumentem a jiná data se jí netýkají.
Obrázek 1: Rozdělení systémů na producenty a konzumenty (vždy z pohledu konkrétní datové entity)
3. Zmapování toků dat
Zmapujeme si přenosy dat. Z jakého zdrojového systému do jakého cílového systému přenášíme jaká data, jak často, jakou technologií, v jakém formátu. Například data o zákaznících se přenášejí ze systému CRM do systému ERP každých deset minut prostřednictvím XML souboru na sdíleném disku. Ve chvíli, kdy budeme mít zmapovaný stávající stav, budeme schopni formulovat možnosti zlepšení a způsob přechodu na cílový stav.
4. Stanovení zodpovědností
Je třeba stanovit, kdo je zodpovědný za jaká data. Zde je dobré rozlišit vlastníka dat a datového stevarda. Vlastník dat je zodpovědný za kvalitu dat a měl by to být někdo z managementu společnosti. Datový stevard spravuje data, jejich strukturu a pravidla dle rozhodnutí vlastníka. Různá data mohou mít vlastníky a datové stevardy v různých týmech. Postupy správy master dat, role a zodpovědnosti by měli být popsány ve směrnicích, které jsou všem dostupné a všichni zainteresovaní by se s nimi měli prokazatelně seznámit.
5. Vytvoření datového modelu kmenových dat
Kmenová data mají vzájemné závislosti. Například zákazník má vazbu na číselník typů zákazníků, odebírá určité produkty a starají se o něj určití pracovníci. Produkty mají vlastní hierarchii kategorií a typů produktů, používají určité materiály atd. Datový model ve formě Entity Relationship Diagramu nám všechny tyto vztahy přehledně zachytí.
Obrázek 2: Příklad Entity Relationship Diagramu
6. Architektura master dat, pravidla a plán jejího naplňování, proces práce s master daty
Stávající toky master dat, tak jak jsme je zmapovali v bodu 3, nemusí být ideální a mohou být příčinou problémů. Pokud udržujete seznam produktů a jejich hierarchii ve více systémech, budete se asi potýkat s problémy způsobenými tím, že v jednom systému jste data neaktualizovali nebo to provedli jen částečně. Existuje několik konceptů práce s master daty. Jedním z nich je pořizování a správa všech master dat v jednom k tomu určeném systému a distribuce dat do všech dalších. Tento koncept jednoho místa pravdy nám totiž krásně řeší předchozí problém. Z pragmatických důvodů ale volíme různé přístupy. Přechod na tento systém vyžaduje úpravu aplikací, v nichž data nebudou zadávána, ale které je nyní budou odebírat z centrálního systému. Některé aplikace však toto nebudou umět, jejich úprava by byla velmi náročná, a tak budeme muset akceptovat, že například některá data budou i nadále pořizována v ERP a do MDM systému se budou dostávat až ve druhém kroku. Jednotlivé přístupy bychom si měli popsat, stanovit pravidla jejich uplatňování a naplánovat postupný přechod na nový systém.
7. Výběr technologií
Podle zvolené architektury a strategie vybereme konkrétní technologie, které nám práci s master daty usnadní.
8. Přechod k cílové architektuře master dat a každodenní správa
Přechod k cílové architektuře závisí na vstupních podmínkách firmy. Organizace, která si důležitost master dat uvědomuje na začátku budování systémů, je na tom jinak než firma, v níž docházelo k překotnému rozvoji informačních systémů a která má v této oblasti určitý dluh. Pokud začínáme s Master Data Managementem a používáme již množství aplikací, může být přechod k cílovému stavu zcela reálně záležitostí několika let, kdy v rámci jiných projektů upravujících aplikační architekturu budeme aplikovat i náš přístup ke kmenovým datům. Postupnou aplikací pravidel postupně začneme data zkvalitňovat a řešit stávající problémy. To, že to bude v případě již rozvinutého informačního systému běh na delší trať, je třeba brát jako realitu a nezaleknout se toho. Přínosy začneme vidět již brzy a hlavně začneme pokládat základy zdravého systému a toto úsilí se nám v budoucnosti vrátí.
Jaké bude mít výše popsané řešení přínosy?
- Správná a přesná data umožní správná rozhodování.
- Data konzistentní napříč systémy budou mít potřebnou věrohodnost a uživatelé tak s nimi budou ochotni pracovat.
- Pokud nebudete mít problémy s daty, zvýší se efektivita a rychlost procesů. Uživatelé už nebudou muset čekat, až IT opraví data.
- Sníží se náklady na další IT projekty i každodenní provoz IT, protože už nebude třeba řešit opravy dat a složité napojování na nekonsolidovaná data.
Počáteční situace při zavádění mater data management
MDM projekt může být třeba spustit ve chvíli akvizice určité firmy. Konsolidace informačních systémů s mateřskou společností může být příliš drahý a náročný projekt. Někdy systémy ani není cílem sjednotit např. z legislativních důvodů nebo proto, že daná firma může být výhledově opět prodána, a potřebuje si tedy zachovat své informační systémy. Data je přesto třeba sdílet pro podporu business procesů. Dalším případem je provoz legacy systémů, které nesdílejí data s ostatními aplikacemi. Udržování dat zadávaných paralelně do několika systémů je pak už neudržitelné kvůli ustavičnému řešení nekonzistencí.
Pokud se bavíme o CRM nebo ERP, vždy si takovou oblast spojujeme s konkrétním informačním systémem, který firma provozuje. U MDM jde ale především o zvolenou architekturu, přístup k vytváření, udržování a distribuci dat, tak jak jsme si to nastínili výše v bodě 6. Přesto nám konkrétní technologie práci s master daty velmi usnadní.
Firma začínající s Master Data Management často řeší, ve kterém systému Master Data udržovat. Někdy se rozhodne vytvářet nová Master Data v existujícím systému, ve kterém se již některá Master Data pořizují. Může se to zdát jako logický krok, ale zároveň to může být velmi špatným rozhodnutím, pokud je takovým systém např. ERP systém. ERP systém nemusí být jednoduché přenastavit tak, aby data o zákaznících přebíral z centrálního úložiště master dat, a tak data o zákaznících budeme i nadále primárně pořizovat v ERP a naopak je přenášet do centrálního systému master dat jakožto sekundárního systému pro zákaznická data. Neměl by to být ale argument, proč všechny další číselníky zřizovat v ERP. Proč? Je pro to několik důvodů.
- ERP systémy pokrývají komplexní business procesy a jakékoli změnové požadavky pak často procházejí složitým změnovým řízením. Nasazení nového číselníku pak může být velmi složité. Uživatelské rozhraní ERP systémů také obvykle bývá méně uživatelsky přívětivé.
- S ERP systémem většinou pracuje jen část uživatelů. Pro datové stevardy bychom pak museli pořizovat licence systému, aniž by potřebovali pracovat s ERP jako takovým.
- ERP také nepodporuje specifickou funkcionalitu Master dat.
Co by naopak Master Data systém měl umět?
Řekli jsme si, že Master Data jsou netransakční a jsou relativně statická, tzn., nemění se často. Přesto nebo spíše právě proto je změna kritickou vlastností master dat. Pokud pořídíme záznam transakčního typu (např. faktura), již tento záznam neměníme. Pokud později zjistíme, že faktura by měla být pro jiného zákazníka nebo by měla být vystavena jinou entitou v holdingu firem, fakturu buď zcela zrušíme, nebo vytvoříme další transakci (dobropis), který ji efektivně ruší.
U master dat máme jinou situaci. Pokud například měníme složení produktu, naplánujeme jeho platnost pomocí vlastností Platnost od a Platnost do. Podobný princip použijeme pro kurzy měn, kdy si stanovíme od kdy do kdy má pro nás určitá měna určitou hodnotou. Pokud dáváme našim zákazníkům na výběr z několika barev a interně provádíme změnu dodavatele a lehkou změnu odstínu barev, měli bychom v master datech určit, že např. červená barva byla do 20. 4. 2019 od dodavatele A a odstínu X a od 21. 4. 2019 od dodavatele B a odstínu Y. Master Data systém by nám pak měl zajistit, že nebude docházet k nekonzistencím daným např. tím, že se nám časové intervaly překrývají nebo naopak máme období, pro kterou není známa hodnota.
Obrázek 3: Časová platnost Červené barvy – změna dodavatele v průběhu času.
Tuto funkcionalitu v ERP systému asi mít nebudeme, a zajištění konzistence dat tak bude na datových stevardech s vysokým rizikem chyby daným lidským faktorem. Strukturu master dat, datová pravidla, obrazovky pro zadavatele, interface pro aplikace posílající nebo odebírající data u specializovaného nástroje mohou zajistit datoví stevardi, protože systém je na toto připraven. U ERP systému budeme muset toto nechat na externích nebo interních vývojářích, což nám vše prodraží a prodlouží. Pořízení specializovaného nástroje na podporu master dat tak může být rozhodnutím, které se nám vyplatí, usnadní práci s master daty a v architektuře bude mít své pevné místo. Navíc nás takový nástroj nemusí vyjít příliš draho.
V příštím článku si ukážeme, jak konkrétně můžeme Master Data začít ve firmě řešit a jak se dobrat ke konkrétním výsledkům.