Je či není OLAP nezbytnou podmínkou k vybudování úspěšného systému pro supply chain management? A je-li, tak jak? Tato otázka je ve skutečnosti otázkou za hodně peněz, protože ovlivňuje několik zásadních strategických rozhodnutí. Než k ní ale přistoupím, začněme vyjasňováním pojmů. I když možná ani nemusíme. Termín Supply Chain Management (SCM) -vžitý název pro širokou oblast problémů kolem logistiky a řízení dodavatelsko-odběratelského řetězce - je podnikovým IT manažerům už velmi dobře znám, protože posledních pár let je žhavou novinkou v marketingovém slovníku všech velkých dodavatelů podnikových aplikací. Termín OLAP (On Line Analytical Processing) - obecně vžitý název pro datové sklady, optimalizované pro multidimenzionální analytické aplikace - je už dnes jako bojové heslo méně skloňován, ovšem hlavně proto, že marketingový tlak na IT manažery zde už není tak nutný: datové sklady jsou dnes masově nasazovány v praxi.

Připomeňme ještě rozdíl mezi logistikou a SCM. Logistika (hospodářská) byla vždy tradičně zaměřena na organizaci a optimalizaci pohybu zboží a informací uvnitř podniku. Naproti tomu termín SCM je zpravidla spojován s celým hodnotovým řetězcem od výrobců materiálu a komponent, až po konečného zákazníka. Zatímco optimalizační a kontrolní funkce vnitropodnikové logistiky a SCM jsou srovnatelné, SCM je na rozdíl od klasické logistiky více strategickou disciplínou, protože sahá až do podnikatelského rozhodování v oblastech, jako je výběr dodavatelů, outsourcing logistických kapacit, nebo optimální dělba práce mezi firmami a jí odpovídající rozmístění výrobních a kompletačních procesů v rámci řetězce. S tím samozřejmě souvisí i zvýšení požadavků na flexibilitu řízení, protože globální charakter problému je spojen s větším množstvím hůře předvídatelných faktorů.

Nedávno jsem zjistil, že jako konzultant v oblasti OLAP jsem profesní výjimka. OLAP není uveden ani ve slovníku cizích slov, ani v osmisvazkové encyklopedii. Můj projektový partner zase hledal SCM a taky nenašel. Mimochodem u logistiky je ve slovníku jako první význam uvedena matematická logika, což sice kdysi bylo správně, ale je to úplně jinak, než jak dnes tomuto termínu rozumíme. Zpozdilost slovníků musíme brát jako životní realitu, ale že se termín OLAP nevyskytuje snad v žádné učebnici logistiky, to už je věc k zamyšlení. Logistika se hraje na mnohorozměrném bitevním poli. Kdo jiný než logistici by měli používat OLAP jako svoji základní křišťálovou kouli?

Skutečně by měli? Dalo by se říci: Dobře navržený logistický systém, to je takový hodinový strojek, jedno kolečko kroutí druhé. Po letech vylepšování vaší podnikové logistiky by se dalo čekat, že při neměnné situaci bude váš hodinový strojek slušně optimalizován. K čemu ještě nějaký OLAP?

Samozřejmě: neměnné situace dnes neexistují. Také praxe fungování logistických řetězců je trochu jiná než teorie: některá kolečka ztrácí zoubky a proklouzávají, jiná se točí rychleji, jiná se zadírají, a zákazníci si navíc hýbou po svém s ručičkami - systém je třeba neustále kontrolovat. Představme si řízení takového neposlušného hodinového strojku v gigantu, jako je třeba Ahold: třista tisíc různých koleček a dvěstě ciferníků. Tento příklad z distribuční odnože logistiky přitom ještě patří k těm "jednodušším" - jedná se o hotové zboží, žádná organizace výroby se složitými závislostmi vstupních komponent (ovšem vzato z jiného úhlu pohledu, konečný produkt - svůj nákup - kompletuje zákazník stochasticky ve svém košíku, tudíž rizika výpadků jsou možná ještě větší).

Ani potřeba kontrolní a signální funkce není ještě zřejmým důvodem, proč by mělo být třeba si pořizovat OLAP. Ten navíc doposud často býval koncipován jako systém pro střednědobé analýzy, do kterého vstupují již agregovaná data. V takových případech by byla jeho použitelnost pro operační controlling omezená. Kontrolní funkce je ostatně klasickou doménou ERP systémů, i když obvykle jen na vlastním podnikovém území. Za kontrolou ale logicky následují další kroky: zjištění problému a jeho náprava.

Sofistikovaný kontrolní systém dnes dokáže informaci o nedošlé zásilce předat ve formě SMS zprávy třeba přímo na uživatelův mobil. Počáteční euforie z podobných libůstek však leckterého nadšeného uživatele přejde, pokud zjistí, že pro přesnější identifikaci problému a jeho vyřešení, stejně jako dříve, potřebuje vzít telefon a někam zavolat. Přitom signál, že nedorazila očekávaná dodávka, ještě nemusí být alarmující. Například záleží na tom, kam byl přesunut termín dodání a zda produkt skutečně chybí tam, kde je potřeba. A pokud skutečně hrozí, že zásoba dojde, rozhodnutí o pasivním čekání nebo o přijetí alternativních řešení (aktuálně dosažitelných) nebo o vyvolání výjimečných, obvykle nákladnějších akcí může být ovlivněno tím, jak bude výpadek dlouhý a co to bude znamenat pro zákazníka. A i tento argument může být ovlivněn skutečností, kdo je zákazník, nebo například znalostí, zda se mu s námi něco podobného v pamatovatelné době už nepřihodilo. Sám zákazník může být dodavatelem a klasifikovat důležitost dodávky podle reálných potřeb svých zákazníků, atd. atd.

Zkusme převést obsah předchozích tří vět na seznam informací, které bychom v daném případě mohli pro efektivní rozhodnutí potřebovat:

. informace o vlastních objednávkách a plánovaných dodávkách
. informace o vlastních zásobách
. informace o objednávkách zákazníků
. informace dodavatele o změněném termínu
. informace o prioritě dodávky pro zákazníka
. informace o zásobách a spotřebě zákazníků
. informace o alternativních řešeních a jejich aktuální dosažitelnosti
. informace o významu zákazníků a rozsahu jim poskytovaných služeb
. informace o předchozích podobných případech a jejich řešení

Zatímco první tři body seznamu jsou běžně obsaženy v jakémkoli ERP, o zbytku už se to říci nedá. Ani výše uvedené informace přitom nejsou pro rozhodnutí dostačující. Nemalou roli může hrát i fakt, kdo je původcem problému a jaká je vzájemná síla partnerů v řetězci. Vznikl-li problém uvnitř řetězce, je pravděpodobné, že dodatečné náklady řešení situace ponese původce sám - pokud ne, tak spolupráce v řetězci zřejmě nefunguje. Pokud je původce problému externí, mohou partneři, kteří na řešení problému z hlediska optimální funkce řetězce jako celku vynaložili dodatečné náklady, požadovat podílnictví na nákladech i výnosech od partnerů, kteří z toho profitovali. Předpokladem přerozdělení nákladů a výnosů je ovšem jejich zveřejnění pro partnery, což někdy může být velmi těžko řešitelný problém. V tomto ohledu lze SCM částečně připodobnit ke společné domácnosti, a na takový prvek spolupráce si někteří méně důvěřiví partneři v řetězci skutečně zatím těžko zvykají, protože popírá historicky vžitá pravidla chování firem.

Z našeho seznamu čiší ještě jedna zřejmá otázka. Je supply-chain manažer neboli logistik tím jediným, kdo správně a efektivně rozhodne? Možná ano, na dílčí operativní úrovni, ale téměř jistě ne v taktickém nebo strategickém měřítku. Polovina bodů ze seznamu podpůrných informací se týká zákazníka a to volá po odborné kompetenci někoho z prodejního a marketingového týmu. Obdobně je často potřebný insight nákupních manažerů. Navíc nemusí být přímo sdílených partnerských informací dostatek a řešení si vyžádá účast partnerů ze strany dodavatele i zákazníka. Tam se mohou odborné kompetence opět rozpadat na různé subjekty. Všichni budou k rozhodování vyžadovat informace ze své odborné domény, ale má-li být rozhodování efektivní, musí být tyto informace soustředěny a uvedeny v souvislost. To znamená nezbytnost současného vidění různých částí a různých procesů řetězce, a to i v různých časových posunech. OLAP analytické aplikace jsou jediné, které takové pohledy efektivně umožňují.

Zatímco u taktického a strategického řízení řetězce je týmový charakter rozhodování přirozenou věcí, na operativní úrovni může podobná nezbytnost negativně poznamenat náklady nebo může být zcela nemožná při požadavku na rychlou realizaci operace, typickém v e-businessu. To znamená, že výměna informací v řetězci by měla být taková, aby na operativní úrovni u často nastávajících případů umožnila globálně optimální, ale lokálně realizované rozhodování. To si vyžaduje organizaci publish/subscribe systémů pro distribuci informací mezi partnery řetězce nebo vytvoření inteligentních aplikací, schopných dotazů do partnerských systémů (a schopných na podobné dotazy od partnerů odpovídat). Jaký způsob poskytování je vhodnější, závisí především na poměru frekvence dotazů a frekvence změn v dotazovaných datech.

Současné ERP systémy se koncepčně nehodí pro vícedimenzionální rozhodování, typické pro globální SCM, ale nakonec nijak moc nevyhovují ani podnikové logistice, která v době krále zákazníka jen těžko obstojí s jednostranným pohledem, zaměřeným na minimalizaci nákladů. Komponenty pro SCM jsou proto budovány nad těmito systémy. Rozsáhlejší SCM aplikace přitom již nejsou pouhou nadstavbou nad databází ERP, ale využívají pro svou funkci technologie OLAP. Způsob implementace se ovšem liší.

Nezávislí výrobci SCM aplikací obvykle nabízí implementaci standardního OLAP jako součást svého analytického balíku, existují ale i ERP systémy s izolovanými data marty, zaměřenými jen na zajištění provozu vlastních SCM modulů.

OLAP nekonkuruje SCM aplikacím, ale je součástí jejich infrastruktury. Pro efektivní rozhodování při operativním řízení SCM systém potřebuje k transakčním datům z ERP i data z OLAP (alternativou je integrace všech těchto dat do jednoho prostředí OLAP s využíváním jeho detailní relační vrstvy (typicky tzv. operační datový sklad), což je ovšem možné jen v případě, že OLAP zachytává změny v transakčním systému v téměř reálném čase). Při rozhodování na strategické úrovni je obvykle OLAP bez ohledu na frekvenci plnění zpravidla jediným dostačujícím zdrojem dat pro analýzu. Je důležité se zeptat, jak je OLAP v SCM aplikaci implementován a zda může fungovat nezávisle na ní. OLAP - datový sklad - je místem, kde se integrují podniková data, nejenom ta, vyžadovaná SCM aplikacemi. Řešení, kde je OLAP, dodávaný se SCM aplikací, využitelný jen pro ni, nelze považovat za optimální. Datový sklad by jako základní integrační prvek informační infrastruktury měl být v podnikové koncepci nezávislou komponentou. V ideálním případě by tedy SCM aplikace měla umožňovat vytvoření interface pro napojení na nezávislý datový sklad a podobně umožňovat i nezávislý rozvoj svého datového skladu, pokud jej nabízí jako součást analytického balíku. Pokud se podnik při nákupu SCM aplikace rozhodne pro tuto poslední variantu, je třeba pečlivě prozkoumat otázku, jaká je koncepce vytváření OLAP databáze v řešení dodavatele SCM. Datové sklady jsou dnes budovány zpravidla na míru podnikovým potřebám, jako komplexní systémy s cílem integrace podnikových dat v analyticky přístupné formě.

Všichni zkušení implementátoři OLAP důsledně varují před vytvářením izolovaných dílčích řešení ve formě tzv. izolovaných data martů, specializovaných například jen pro potřeby dílčí SCM aplikace. Podobná řešení sice stačí pro rychlé nasazení a provoz, nedůslednost a povrchnost koncepce se však brzy vymstí, obvykle jakmile dojde ke změně nebo rozšíření podnikových procesů, je třeba pohledy na některé procesy spojit, nebo jakmile se objeví potřeba nasazení jiných aplikací. Pravděpodobnost podobných změn v oblastech SCM a CRM je velmi vysoká.

Dnes existující SCM řešení mají před sebou ještě dlouhou cestu k dokonalosti. Díky internetu vznikají v oblasti SCM nové příležitosti, které plynou ze šance zrychlit a zkvalitnit komunikaci mezi výrobci, distributory a zákazníky. Realizace těchto příležitostí se však neobejde bez odpovídajících informačních technologií. Informace, které SCM aplikace potřebují pro optimální rozhodnutí, přesahují jak hranice transakčního systému nebo funkčně orientovaných data martů, tak i hranice jedné firmy. OLAP je jedním z článků, které dnes pro získání správných informací hrají klíčovou roli. Je zřejmé, že způsob implementace OLAP - podnikového datového skladu může významně ovlivnit přínos pro SCM. Ze specifických požadavků, které jsou na OLAP kladeny ze strany SCM, jmenujme dva nejdůležitější:

. Srozumitelnost
Jediný metamodel dat pro všechny účastníky řetězce je málo pravděpodobný. Součástí lokálních metamodelů by proto měl být vzájemný interface interního datového modelu na dohodnuté standardní modely komunikace XML. I když první reálné aplikace na bázi XML, např. Biztalk, jsou již na světě, standardy stále nejsou jednotné. Požadavky na použitelnost dat pro externí subjekty se kromě srozumitelnosti metadat dále promítají do potřeb sladění dat jako takových v oblasti kmenových údajů a měrných jednotek.

. Aktuálnost
Stále více převládající e-charakter komunikace účastníků obchodních procesů vyžaduje od OLAP schopnost poskytovat aktuální informace v téměř reálném čase (koncepce tzv. real-time data warehouse). To platí zejména v případě, kdy je OLAP pro externí partnery zdrojem informací o transakcích. Ale i v případě, kdy je OLAP využíván jen jako zdroj podpůrných dat pro rozhodování, může být denní dávkové zpracování vstupů do datového skladu nedostačující, pokud se tato podpůrná data (např. informace o celkové poptávce a vytížení) dynamicky mění v průběhu dne v závislosti na probíhajících obchodních procesech.

Zatímco první požadavek je víceméně organizační, druhý zásadně ovlivňuje architekturu řešení OLAP, zejména z hlediska výstavby ETL systému pro plnění datového skladu daty. Při budování nových datových skladů nebo jejich rozšiřování je proto na místě včas odhadnout budoucí nároky, které mohou na OLAP vznést potřeby podniku v oblastech SCM a CRM.

Pozn: Autor článku pracuje jako Senior Konzultant společnosti ADASTRA, s.r.o.