Různá pojetí architektury informačních systémů

 

Ondřej Šlapák

slapak@vse.cz

slapak@slapak.cz

 

Katedra informačních technologií

Vysoká škola ekonomická v Praze

 

Abstrakt: Tento článek se zabývá architekturou informačních systémů podniků. Zprostředkovává různé typy pohledů na architekturu IS s ohledem na potřeby globální informační společnosti. V závěru je předložen jiný pohled na architekturu IS, a to pohled procesní, který vychází z principů procesního řízení a odbourává tak hranice mezi funkčními bloky informačních systémů, jako je CRM, ERP apod.

Klíčová slova: architektura informačních systémů, informační systém, globální informační společnost, podnik, proces, procesní řízení, e-business, EAI, systémová integrace

 

 

Architektura IS

Architektura informačního systému (IS) založeného na informačních a komunikačních technologiích (ICT) je v [DOHJ97-01] chápána „jako schéma zohledňující všechny podstatné dimenze návrhu informačního systému“. Umožňuje řídit integraci komponent IS podniku v určitém duchu, stylu. Podle [DOHJ97-01] lze dále celkovou architekturu IS považovat za významnou z těchto důvodů (vedle jiných):

·         vytváří relativně stabilní rámec, do něhož se v průběhu doby vývoje IS začleňují jednotlivé aplikace a prostředky,

·         zajišťuje stabilitu vývoje IS i při rychlém technologickém vývoji,

·         umožňuje využít hotových produktů a reagovat na jejich heterogenitu.

Architekturu IS tak lze považovat za nástroj systémové integrace. Odráží jak integraci vnitropodnikovou, tak integraci podniku s jeho okolím.

Pojďme se nyní podívat na některá pojetí architektury IS.

Typická obecná architektura IS podniku

Typickou obecnou aplikační architekturu podniku ukazuje obrázek 1 (převzato z [KALR99‑01]). Jediné, co se tomuto schématu dá vytknout, je absence subsystémů pro interakci se státní správou, bankovními subjekty a dalšími partnery, které nelze typicky zařadit do dodavatelského řetězce.

[KALR99-01] dále uvádí podrobnější cesty integrace. Řízení vztahů se zákazníky (CRM), jak je naznačeno, integruje dosavadní aplikace pro řízení marketingu, prodeje a služeb zákazníkům. Integrované řízení výroby (ERP) zahrnuje aplikace pro odhady a plánování výroby, řízení materiálového zabezpečení, řízení skladů, distribuce hotové výroby a účetnictví s financemi. Řízení dodavatelských řetězců (SCM) zahrnuje aplikace pro analýzu tržní poptávky, sledování omezení zdrojů a kapacit a aplikace pro plánování v reálném čase. Efektivní řízení prodejních řetězců je umožněno integrací individualizace produktů, řízením cenové a smluvní politiky, automatizovaným řízením nabídky, řízením vztahů se zprostředkovateli a řízením propagace. V samém centru podnikové architektury nalezneme řízení znalostí a systém pro integraci všech podnikových aplikací (EAI). Řízení znalostí (označováno jako KM – knowledge Management či BI – Business Inteligence) je v těsné souvislosti s integrací podnikových aplikací. EAI totiž logicky umožňuje shrnout data ze všech „koutů“ podniku. Aplikace BI pak nabídne analýzy a syntézy dat, předpovědi vývoje. Slouží jako základna pro rozhodování na poli CRM, SCM i ERP.

obrázek 1 – obecná architektura podniku

Integrace stávajících aplikací

Jiný pohled na architekturu podniku nabízí Vitria (obrázek 2). V rámci této architektury lze rozlišit stávající podnikové aplikace, integrující řešení a interaktivní okolí podniku.

Komponenta řízení podnikových procesů zajišťuje modelování, automatizaci, monitorování a analýzu relací mezi interními ICT a externími partnery. B2B slouží přímo pro řízení vztahů s externími partnery přes elektronické komunikační kanály. EAI zde představuje prostředek hladké integrace stávajícího programového vybavení navzájem a s novými komponentami. Komponenta analýzy v reálném čase poskytuje manažerům pohled na aktuální stav podnikových procesů a informuje je o nestandardních situacích.

obrázek 2 – Vitria: BusinessWare platforma pro e-buisness

 

 

obrázek 3 – e-business integration road map, ebizq.net

Aplikační architektura a úrovně integrace

Další pohled na architekturu podniku pochází z portálu pro EAI ebizq.net. Ve skutečnosti schéma (obrázek 3) nepředstavuje čistě architekturu podniku. Jde spíše o hybridní pojetí architektury a schématu integrace.

Směrem vzhůru se dostáváme od úrovně, která vůbec fyzicky integraci umožňuje, na úroveň aplikací, jež zajišťují integraci z pohledu obsahu. Dále nastupují aplikace integrující podnik z pohledu procesu. V další vrstvě pak jde o aplikace integrující jednotlivá řešení z oblasti e‑business. Tato řešení vytvářejí prostředí připravené vhodně reagovat na okolí podniku. Konečně vrstva nejvyšší je reprezentována aplikacemi určenými přímo pro proaktivní kontakt s prvky okolí podniku. Všechny tyto úrovně integrace a/nebo aplikací jsou lemovány řízením bezpečnosti a v neposlední řadě celkovým koncepčním řízením.

Model řízení e-business

Model řízení e-business podle AMR (obrázek 4) je pracovním rámcem pro vytváření e‑business strategií a výběr vhodných aplikací a technologií. Sympatické na tomto modelu (či spíše schématu) je, že v samém jeho srdci je umístěna podniková strategie a od ní odvozená e‑business strategie. Od ní se pak odvíjí vývoj a řízení produktů, přístupů k trhu, řízení prodeje, komunikačních kanálů, zákaznických požadavků, dále identifikace vůči konkurenci, určování priorit, organizační struktury a plán růstu. Tři sektory vymezují tři základní orientace řízení podniku – CRM, SCM a operativní podnikové řízení. Pro každou orientaci model dále podrobněji uvádí typy aplikací, které mají vést k dosažení strategických cílů. Na rozhraní řízení dodavatelských řetězců a řízení vztahů se zákazníky nalezneme formování B2B tržní strategie, jejímž obsahem je integrace trhů vzniklých díky B2B s globální podnikovou strategií. Osobně si myslím, že umístění této komponenty řízení na tomto místě není z dlouhodobého hlediska vhodné a že se musí posouvat stále k podnikové strategii až s ní splynout, přičemž tento posun by měl trvat co nejkratší dobu.

Portálová řešení

Slovo portál podle [KLIL83-01] označuje architektonicky upravený vchod nebo vjezd do význačné budovy. Původ slova lze nalézt např. ve francouzském la porte – dveře. Taktéž slovo port, rovněž z francouzštiny nebo angličtiny, které v češtině znamená přístav, má příznačný význam. V každém případě jde o termín označující místo vstupu – do budovy či do města. Portál v prostředí Internetu je z pohledu uživatele místo, či spíše adresa, přes kterou má přístup k informacím a aplikacím zpřístupněným provozovatelem portálu. Z jeho pohledu je portálem nejen zmíněná adresa, ale také veškerý hardware a software, jenž chod portálu umožňuje.

Při návrhu portálu pro podnik je nezbytné identifikovat skupiny uživatelů portálu a činnosti, které těmto skupinám portál umožní provádět. KnowledgeTrack navrhuje rozdělení uživatelů do skupin podle vztahové vzdálenosti od podniku (obrázek 5).

V samém centru portálového řešení se nachází fyzický podnik, zdroj veškerého dění. Zde dochází k tvorbě přidané hodnoty, zpracování informací a jejich distribuce. Další vrstvu tvoří zaměstnanci podniku. Portály pro zaměstnance mají podpořit zaměstnance na obchodních cestách i stále rozšiřující se teleworking. Na tvorbě přidané hodnoty kromě zaměstnanců se podílejí také partneři podniku, kteří tvoří další skupinu uživatelů portálu. Poslední vrstvu tzv. rozšířeného podniku tvoří přímí zákazníci. Ti jsou přímými uživateli informačního systému podniku. Za hranicemi rozšířeného podniku se v přímé souvislosti s poskytovaným produktem nacházejí partneři přímých zákazníků, zákazníci našich zákazníků a zbylá veřejnost.

 

obrázek 4 – model řízení e-business podle AMR

 

obrázek 5 – skupiny uživatelů portálu podle KnowledgeTrack

Z pohledu systémové integrace jde o řešení založené jak na vytváření aplikací front‑office (FO), tak na integraci FO a back‑office (BO). Webové stránky samy o sobě rozhodně netvoří portál. Slouží pouze jako uživatelské rozhraní k podnikovým aplikacím. Celkové portálové řešení kombinuje řízení znalostí, integraci aplikací, spolupráci a komunity a umožňuje tak vlastně fungování e‑businessu (obrázek 6).

obrázek 6 – portálová architektura podle KnowledgeTrack

E-business komunity představují cílovou populaci a zdroj příjmů. Jde jak o zákazníky, tak partnery (přímé i nepřímé). Obsah je to, co nese přidanou hodnotu – produkt či služba a informace. Je předmětem příjmů. Řízená i spontánní spolupráce pak zefektivňuje a umocňuje obchodní vztahy, jež je pro dosažení synergického efektu vhodné navzájem integrovat. Druhou stranu mince tvoří prostředky pro tvorbu a komunikaci přidané hodnoty. Jde o podnikové aplikace, aplikace na podporu spolupráce, lokální aplikace každého zaměstnance a webové aplikace. Vše je nutné integrovat v prostředí, které je snadno rozšiřitelné, bezpečné, vyhovuje obecně platným standardům i požadavkům jednotlivce, je vždy připravené a konsistentní.

Portály jsou tedy konkrétní multiaplikací systémové integrace v globální informační společnosti.

Procesní pohled na architekturu IS

Podívejme se však na architekturu IS podniku ještě jinak. Dosud je architektura IS podniků konstruována podobným způsobem jako funkční organizace. Schémata většinou obsahují bloky software zaměřující se na CRM, ERP, SCM apod. Z hlediska trendu EAI a procesního řízení by bylo mnohem logičtější přizpůsobit přirozeným procesům nejen organizaci podniku, ale také řízení informačních systémů. To samozřejmě vyžaduje i procesní pohled na architekturu podnikového IS.

Pro úplnost je zde potřeba vysvětlit pojem proces a procesní řízení. Proces je sled konkrétních činností (aktivit), které zpracovávají určitý požadavek, vstup. Výsledkem takového řetězce činností je přesně definovaný výstup, produkt/služba. Každá činnost vytváří určitou přidanou hodnotu, díky které hodnota produktu/služby průběžně roste. Procesní řízení je řízení zdrojů (lidé, znalosti, finance…) podniku tak, aby co nejefektněji a nejefektivněji přispívaly k dosažení cílů procesu a tím i cílů podniku. Procesní řízení umožní nalézt neefektivní aktivity, jejich transformaci a tedy ozdravení činnosti celého podniku a udržování podniku ve stavu, který podporuje dosažení stanovených cílů, případně jej podle změněných cílů (kterékoliv úrovně) upravit. Umožňuje cíleně řídit jednotlivé činnosti směrem k jejich výstupu a přesně určit odpovědnost za kvalitu výstupu a tedy i odpovídající ohodnocení těch, kteří se na výstupu podíleli. Procesní řízení je trend, o čemž se lze přesvědčit v [HAMM02-01].

Nyní zpět k architektuře IS. Na trhu podnikového SW ještě panuje atmosféra nenasycené poptávky, i když obchodníci se mnou nebudou souhlasit, protože mají mnoho práce prodat právě ten svůj produkt. Výrobci SW se specializovali na určitou funkční oblast podnikového SW. Nemají totiž dostatečnou kapacitu, aby obsáhli celé podnikové dění, i když některé firmy se tomuto stavu blíží[1]. Snaží se o to samé, o co se snažili předchůdci, průkopníci v industriální společnosti, tj. prodat pokud možno stejný výrobek co největšímu počtu zákazníků[2]. V tvorbě SW tato myšlenka vychází přímo od kořenů – maximalizace využití kódu, tvorba knihoven objektů atd. Výroba SW na zakázku je ale relativně drahá. Kde je hranice softwarového atomu[3]? Ačkoliv jde o téma skutečně vážné, v tomto článku se mu dále nevěnuji, neboť se orientuji na úroveň globální architektury IS.

Schémata architektur IS podniků uvedená výše odráží podnik, jeho okolí i úrovně řízení. Neříkají však nic o konkrétních procesech. Jestliže do architektury IS zahrnu procesy, obecná architektura IS podniku by mohla velmi zjednodušeně vypadat, jak znázorňuje obrázek 7. Na první pohled jde vlastně o schéma podniku. Podle mého názoru architektura informačního systému skutečně splývá se schématem podniku. Informační systém totiž není schéma SW balíků. Tomuto pojetí odpovídají právě vybraná schémata prezentovaná výše. Informační systém je o tvorbě a využití informací a znalostí a o jejich přeměně do dlouhodobé prosperity. Právě z tohoto pohledu jsem se snažil architekturu informačního systému podniku zachytit.

Podstatou podnikání je uspokojení potřeb zákazníka a na základě této činnosti tvořit dlouhodobý zisk. Vynechávám další podrobnosti, neboť nejsou pro popis architektury IS podniku dále důležité. Proces tedy lze z hlediska globální architektury podniku definovat jako základní jednotku činnosti podniku a tvorby zisku. Tak je to znázorněno i na diskutovaném obrázku:

Podnik na každý požadavek zákazníka reaguje spuštěním určitého procesu, který končí vyřízením požadavku zákazníka. Proces tak reaguje na určitou událost. Má stanovený cíl, který je konsistentní složkou strategických cílů. Na základě spouštěcí události proces zpracovává vstupy a transformuje je do výstupů. Vstupy velmi často pocházejí od externích dodavatelů. K transformaci vstupů na výstupy jsou spotřebovávány a využívány podnikové zdroje, jako jsou znalosti, dovednosti a čas zaměstnanců, různá zařízení a spotřební materiál, HW, SW, pravidla činností atd. Procesů (a jejich variant) v podniku je definováno tolik, kolik je odhaleno typů zákaznických požadavků[4]. Vedle zákazníků v okolí podniku jsou i další relevantní subjekty. Interakce s nimi je integrována podobným způsobem.

obrázek 7 – architektura IS podniku podle procesů

Procesy samozřejmě nemohou existovat izolovaně. Zde přichází ke slovu integrace procesů. Procesy produkují kromě výstupu pro zákazníka mnoho dalších výstupů. Jsou to vstupy dalších procesů. Tyto procesy jsem do schématu nezařadil, neboť nejsou zdrojem zisku (netvoří přidanou hodnotu pro zákazníka). Navíc je možné je outsourcovat. Dalším výstupem procesů jsou hodnoty popisující průběh procesů – metriky procesů. Tyto hodnoty jsou předmětem zájmu vedení podniku (na všech úrovních). Spolu s hodnotami metrik z činnosti procesů plynou data, která je nutné uschovávat, zpracovávat, využívat pro rozhodování (jak operativní hledisko, tak hledisko řízení znalostí) a sdílet. Konečně, procesy jsou zajišťovány společnými zdroji. Jeden zaměstnanec se může podílet na zpracování požadavku zákazníka v různých procesech. Jedno zařízení může být využíváno více procesy, stejně tak jako programové vybavení atd.

Vrátím-li se k zajištění informačního systému podniku programovými prostředky, dodavatelé SW podle tohoto konceptu by měli podniku nabídnout řešení, které mu umožní zajistit běh celého procesu. Nasazení takového SW s sebou nese nutnost integrace s ostatními procesy přes sdílené zdroje (zde především SW, HW, data). Dnes dodavatel SW odpovídá za funkčnost daného balíku SW. Procesy procházejí několika takovými balíky. Za společnou funkčnost všech balíků (aby správně podporovaly podnikové procesy) si odpovídá sám podnik, nebo najatý systémový integrátor. Pokud by výrobce SW podniku dodal SW řešení pro celý proces, musel by automaticky zajistit, aby toto řešení bylo konsistentní s ostatními procesy. Musel by být sám systémovým integrátorem, nebo se za tímto účelem spojit se systémovým integrátorem podniku. Takový přístup ovšem znamená ještě větší důraz na aplikaci široce používaných standardů a/nebo zvýšení tvorby či kompletace SW na míru, což odpovídá trendům v oblasti běžné výroby a služeb.

Méně radikální přístup vzniká propojením procesní architektury IS podniku a SW balíků současnosti. V podstatě a ve zjednodušení jde pouze o změnu znázornění architektury IS podniku podle uvedeného schématu (obrázek 7), výběr funkcí jednotlivých balíků a jejich namapování na procesy a vzájemná integrace, což je ve skutečnosti EAI. Použití navrženého schématu má pomoci lépe zachytit podporu procesů a strategických cílů SW balíky.

Doba ukáže, jestli v oblasti tvorby SW zvítězí specializace na funkční oblasti a jejich následná integrace, nebo zda dojde k procesní orientaci a tvůrci podnikového SW budou ostatním podnikům nabízet SW produkty, které zajišťují obsluhu či realizaci vůbec celého procesu. Systémoví integrátoři nepřijdou o své postavení, neboť bude potřeba integrovat SW zajišťující jednotlivé procesy.

Summary

In this article, information systems architecture is discussed. First, several contemporary approaches to architecture are presented: a typical general IS architecture, integration of existing applications, application architecture and different levels of intra- and interbusiness integration, a model of e-business management, and portal solutions. Next, a new concept is introduced. This new concept is based on processes and process management. The principle is that an information system is not a scheme of blocks of software. IS is about creating and using information and knowledge, and transforming them to long term prosperity. Hence, the IS architecture must correspond to business architecture. A new scheme of IS process architecture is shown in the article to illustrate the main idea. Also, task of systems integrators is rethought.

Literatura:

[DOHJ97-01]	Dohnal, J., Pour, J.: „Architektury informačních systémů“, EKOPRESS, Praha, 1997, ISBN 80-86119-02-5
[HAMM02-01]	Hammer, M.: „Agenda 21, co musí každý podnik udělat pro úspěch v 21. století“, Management Press, Praha, 2002, ISBN 80-7261-074-0
[KALR99-01]	Kalakota, R., Robinson, M.: “e-Business: Roadmap for Success”, Addison Wesley Longman, Inc., 1999, ISBN 0-201-60480-9
[KLIL83-01]	Klimeš, L.: „Slovník cizích slov“, Státní pedagogické nakladatelství, Praha, 1983, publ. č. 1‑54‑13/2

http://ebizq.net