Motto: „Kdo má jednu nohu v kánoi a druhou ve člunu, spadne do řeky," úsloví Indiánů z kmene Tuscarora.

Před časem jsem napsal článek inspirovaný indiánským úslovím o jízdě na mrtvém koni, věnovaný malým firmám (mluvím o firmách až do 50 zaměstnanců a až do 10 mil. obratu) užívajícím starý nedostačující informační systém. Dnes se budu zabývat situací, kdy je ve firmě provozováno několik různých, třeba i nových informačních systémů – jiná situace, jiné úsloví, avšak obdobné ponaučení.

Kvalita informací – předpoklad užitečnosti IS, neboli k čemu je nám plavidlo?

Pokud hovoříme o podnikové informatice, je nutné si uvědomit, že vlastně jen představuje určitou část infrastruktury, která podporuje firemní procesy směřující k naplnění poslání a cílů podniku. Informační systémy jsou jen nástrojem, který by měl zvyšovat (nebo alespoň udržovat) efektivitu firemních procesů. I v tomto kontextu se pokusíme nahlédnout na řešení pomocí jednotného komplexního IS a na řešení pomocí integrace několika různých systémů (či elementárních programů).

Aby IS skutečně podporoval firemní procesy, musí být poskytované informace kvalitní, zejména tedy:

• Přesné a jednoznačné pro všechny kompetentní účastníky procesu.
• Komplexní, tj. v souvislostech s celým průběhem procesu.
• Relevantní.
• Dostupné včas.
• Dostupné bezpečně.
• Manažersky vyhodnotitelné.

Ten, kdo si vybral, pořídil a implementoval komplexní procesní firemní informační systém správně, má výše zmíněnou kvalitu informací zajištěnu a vnímá ji jako samozřejmou. V případě integrace více nástrojů (informačních systémů), a to i vysoce kvalitních, není kvalita výsledných informací samozřejmostí, naopak její dosažení je obvykle netriviální. Paradoxem je, že i „nekvalita" informací (z výše uvedeného pohledu – tedy nejednoznačnost, duplicita, nedostupnost atd.) je uživatelem často rovněž vnímána jako samozřejmá a nevyhnutelná.

Co to je vlastně integrace?

Integraci několika informačních systémů lze provádět celou řadou metod, které se liší mírou naplnění jednotlivých požadavků na kvalitu informací. Nicméně pokaždé při integraci usilujeme jen o to, abychom se přiblížili stavu, který představuje komplexní procesně orientovaný IS.

Objekty sledované (využívané) v rámci firemních procesů lze je rozdělit do dvou skupin. V první jsou ty „sdílené", které potřebuje celá řada procesů různého typu (mnohdy ve všech organizačních útvarech), například adresář, katalog výrobků, organizační jednotky, stav procesu, některé dokumenty, ... Ve druhé skupině jsou ty objekty, které jsou zapotřebí jen v rámci určitých procesů, například stroj (ve výrobě), auto (v expedici) apod.
Je zřejmé, že v případě integrace více IS je základním problémem, jak a s jakou mírou důslednosti zajistit, aby „sdílené" objekty byly identické ve všech systémech. Pokud toto není řešeno, pak se ani nejedná o integraci IS a je zřejmé, že došlo k totální rezignaci na přesnost a jednoznačnost informací – jedná se tedy jen o užívání informačních systémů v kategorii „nutné zlo", které sice umožní nějakou elektronickou evidenci, ale jinak nic nepřináší.

Při volbě způsobu integrace dvou či více IS se bude přihlížet k těmto základním aspektům:

• Jak budou sdílené objekty „duplikovány" do všech IS? Tj. od maximální (úplná duplikace všech údajů) po minimální (převodní tabulka identifikátorů).
• Bude komunikace mezi IS (duplikace nově vstoupených dat) probíhat online anebo offline? V této souvislosti je třeba rozhodnout:
  • Zda v případě offline proběhne automaticky, či ji musí realizovat obsluha.
  • Zda online proběhne v rámci jediné transakce, aby při havárii jednoho IS nedošlo k porušení principu jednoznačnosti informace.
  • Budou údaje o jednom objektu aktualizované jen v jednom IS, anebo se musí změny duplikovat obousměrně? Jak bude zabráněno kolizi při obousměrné aplikaci?
• Bude uživatel k údajům v jednotlivých IS přistupovat přes jediné standardizované rozhraní, anebo musí zvládnout individuální rozhraní každého systému?
• Jak bude poskytována/získávána komplexní informace? Uživatel si sám získá elementární údaje z více IS a složí si je k sobě „na papíru" (v Excelu), nebo jeden ze systémů bude schopen komplexní informaci složit?
• Jak bude zajištěna integrace při/po instalaci nové verze některého IS?

Již při letmém pohledu na základní aspekty integrace se ven dere otázka „Opravdu je integrace správná cesta? Lze vůbec z integrovaných IS získávat kvalitní informace, a pokud ano, tak za jakou cenu?", a to každý aspekt má řadu dílčích problémů, které se vzájemně ovlivňují.

Nyní se podíváme na tři modelové případy integrace s různou mírou kvality informací.

1. Nulová integrace (neboli vyrážíme na řeku, ono to nějak pojede)

Máme firemní proces, ve kterém se přijímá objednávka, pro každou její položku se zakládá výrobní zakázka, nakonec se výrobky dle objednávky fakturují a prodávají. Provozován je ERP systém, ve kterém se evidují objednávky a vystavují dodací listy a faktury, a výrobní systém, kde se evidují zakázky. Pokud se pracovníkům obchodu jeví, že již přijali hodně objednávek, exportují je do tabulky v MS Excel, kterou uloží na domluvené místo na síťovém disku. Zde si tuto tabulku převezme výroba a dle ní si založí výrobní zakázky, přičemž do poznámky si poznamenají číslo objednávky. Podobně si předávají údaje o tom, že výrobky dle dané objednávky byly vyrobeny. Vzhledem k tomu, že uvedené systémy byly zprovozněny nekoordinovaně, má každý svůj vlastní číselník výrobků – vzájemně se identifikují dle popisu. Z pohledu kvality informace „stav objednávky" je to samozřejmě katastrofa. Navíc se mnohdy může stát:

• Při exportu objednávek obsluha nějakou omylem vynechá, což se zjistí až v okamžiku, kdy odběratel urguje dodávku.
• Při exportu objednávek obsluha některou předá dvakrát, čehož si ve výrobě nevšimnou, tedy se i vyrobí dvakrát.
• Odběratel si vyžádá změnu množství, což obsluha v objednávce změní, ale do výroby informaci neposkytne, takže bude vyrobeno původní množství.
• Výroba chybně určí výrobek z objednávky a vyrobí jiné výrobky.
• Výroba si chybně převzala číslo objednávky a při realizaci zakázky neinformuje, že je připravena k expedici.
• Mnoho dalších problémů (rozsah článku je omezen, rozsah možných problémů v tomto případě nikoli).

2. Něco jako integrace (neboli svážeme člun a kanoi k sobě provázkem)

Máme firemní proces, který zahrnuje přijetí objednávky, jí odpovídající výrobní zakázku a následnou dodávku s fakturací. Z historických důvodů obchodníci používají svůj systém, kde si evidují přijaté objednávky včetně informace, na kdy je naplánována výroba a kdy byla uskutečněna dodávka. Na používání tohoto systému obchodníci trvají – přece se nebudou učit něco nového. Vše ostatní je zpracováváno v procesním firemním ERP systému, tedy verifikace objednávky technologem, výrobou, z hlediska dostupnosti materiálu, plánování výroby, příprava expedice, dodávka, fakurace, ...

Integraci online obchodní systém po stránce technické neumožňuje, takže si ERP každou hodinu načítá automaticky nové objednávky přímo z obchodního systému a duplikuje je k sobě, současně do obchodního systému přímo zapisuje informace o jejich převzetí a také o realizaci odpovídající dodávky.

Na první pohled se jeví, že by takováto synchronizace dat mohla docela dobře fungovat, ale po prvotní naivní realizaci se objevují problémy:

• Odběratelé – jejich přesné názvy a dodací adresy v obchodním systému nejsou zcela identické s údaji v ERP – synchronizaci je nutno doplnit o synchronizaci odběratelů, což si vyžaduje i úpravy ve struktuře dat obchodního systému.
• Obchodní systém používá jiný číselník měn a států – synchronizaci je nutné doplnit o převodník mezi nimi.
• Správa ceníku probíhá v ERP a obchodníci si změny někdy zapomenou převzít – synchronizaci je nutno doplnit o ceník.
• V obchodním systému je validace objednávek mírnější než v ERP, takže se jejich automatický přenos zasekává – synchronizaci je nutno doplnit o vynechání problémových objednávek a o odeslání chybového protokolu. Při synchronizaci těchto objednávek navíc dochází k významnému zpoždění, takže každý systém poskytuje odlišné údaje, např. v ERP se jeví, že objednané výrobky ze všech přijatých objednávek budou včas vyrobeny a dodány; to, že jsou v obchodním systému ještě další objednávky, ví jen pár zasvěcených, a jen pokud si přečetli protokol.
• Obchodní systém umožňuje opravu množství na objednávce, každý obchodník vždy rád vyjde odběrateli vstříc. To ovšem není možné, pokud se již na zakázce začalo pracovat – synchronizaci je nutno doplnit o plánovaný termín zahájení výroby, který se velmi často ovšem mění díky optimalizaci průchodnosti zakázek výrobou.
• Ukazuje se, že náklady na takovouto integraci často mnohonásobně překračují náklady, které by byly vynaloženy na zprovoznění funkčnosti obchodního systému přímo v ERP. Navíc je nutno konstatovat, že zdaleka nejsou k dispozici kvalitní informace.

3. Plná integrace (neboli naložíme člun a kanoi na vor)

Máme technicky vyspělé dva IS (ERP i CRM). Připusťme, že CRM dále disponuje určitou funkčností, kterou v ERP není možné nastavit, tedy je důvod se pokusit o integraci. Zde se zaměříme na jediný firemní proces:
• V rámci CRM se realizuje marketingová akce, ze které vyplývají konkrétní nabídky zboží s individuálním slevovým kuponem pro dané potenciální odběratele (adresáty).
• Uskutečněná objednávka se přijme v ERP (včetně slevového kuponu), zboží se prodá (evidují se relevantní náklady) a odběratel (adresát) zaplatí.
• Na závěr se provádí celkové ekonomické vyhodnocení marketingové akce.

Je patrné, že uvedené IS musí nějakým způsobem sdílet při určitém zjednodušení nejméně tyto objekty: Odběratel (adresát), nabídka včetně specifikace zboží a slevového kuponu, marketingová akce, indikace realizovaného nákupu (ukončení kampaně pro konkrétního adresáta). Oba IS disponují technikou webových služeb, a lze tedy zvolit duplikaci objektů online, aby se zajistila včasnost informace. Též lze pro oba systémy nastavit, že obsluha bude pracovat v jednotném rozhraní (nemusí se učit různá ovládání), navíc je možné současně získávat komplexní informaci složenou z údajů obou systémů. Díky vysoké technické kvalitě obou IS bylo možné zvolit minimální duplikaci sdílených objektů, čímž jsme se vyhnuli situaci, že by se údaje z jednotlivých systémů mohly lišit (třeba díky odlišnému zaokrouhlování nebo jinému významu stejnojmenného údaje apod.).

Na první pohled se jeví, že jsme dosáhli optimálního stavu – jako kdybychom provozovali systém jediný (fakticky jsme v jednotném rozhraní vybudovali kompletní nový systém). Ovšem náklady na integraci touto cestou (dosažení skutečně kvalitních informací) jsou obvykle tak vysoké, že v segmentu středních a malých firem to zkusí málokdo. Navíc je zde i tak riziko, že se nové verze jednotlivých systémů budou muset integrovat znovu, že výpadek (zpomalení) jednoho systému významně ovlivní druhý, apod.

Závěr

Stejně jako nelze cválat po cestě businessu na mrtvém koni, je nebezpečné plout jeho bouřlivými vodami s jednou nohou ve člunu a s druhou v kanoi. Funkční propojení odlišných plavidel – skutečná integrace – je mnohem dražší než pořízení lodi odpovídající plánované cestě a nákladu – komplexního procesně orientovaného informačního systému. Balancování nad hlubinou levné integrace, která si svůj název ani nezaslouží, vede k pádu do řeky. Ostatně i Francouzi říkají: „Kdo chce plout na dvou lodích, ten se utopí." Pravda, která platí napříč kontinenty.

Ing. Jaroslav Janda Autor článku je ředitelem společnosti BM Servis, s. r. o.