Předpoklady úspěšné implementace podnikové architektury

Předpoklady úspěšné implementace podnikové architektury Martin Hladík Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií nám. W. Churchilla 4 130 67 Praha 3 e-mail: [email protected]

Abstrakt: Práce analyzuje různé metodiky o podnikové architektuře (enterprise architecture) s cílem identifikovat důvody pro realizaci podnikové architektury, předpoklady úspěšné implementace podnikové architektury a související podpůrné nástroje. Zjištěné závěry jsou diskutovány v praxi českých podniků. Výchozím zdrojem analýzy je metodika TOGAF, dále Extended Enterprise Architecture Framework a Federal Enterprise Architecture využívaná americkými státními organizacemi. V některých aspektech podnikové architektury jsou využity další zdroje, například systém hodnocení vyspělosti organizace z hlediska podnikové architektury – NASCIO, či srovnání výše uvedených přístupů s metodikou MMDIS. Přínos práce spočívá v poskytnutí základní orientace v plánování implementace podnikové architektury. Práce poskytuje informace o koncepci předních metodik, identifikuje předpoklady úspěšné realizace EA a poskytuje pohled a názor českých podniků na problematiku EA. Klíčová slova: Podniková architektura, metodika, kritické předpoklady úspěšné realizace, postup realizace, hodnocení vyspělosti Abstract: This study explores enterprise architecture frameworks to identify reasons for enterprise architecture usage, assumptions of successfull enterprise architecture implementation, and related supporting tools. Its findings are compared with Czech organizations’ experience. A base of the exploration is TOGAF framework, then Extended Enterprise Architecture Framework and Federal Enterprise Architecture, that is used by U. S. administration. For specific reasons, it analyzes the other resources, i.e. an enterprise architecture maturity model – NASCIO, or MMDIS method comparison. The study provides an initial overview in the area of enterprise architecture planning. It resumes information about main frameworks’ concepts, lists success factors of the enterprise architecture implementation, and shares Czech organizations’s experience in enterprise architecture. Key words: Enterprise architecture, framework, critical success factors of the implementation, development process, maturity assessment

28

SYSTÉMOVÁ INTEGRACE 2/2011

Předpoklady úspěšné implementace podnikové architektury

1. Definice cíle práce a uvedení problematiky v širším kontextu Z průzkumů řady renomovaných agentur i reálné situace v organizacích je zřejmé, že neúspěchy rozsáhlých IT projektů spouští úvahy o rozvoji podnikové architektury (angl. enterprise architecture, dále jen „EA“). Za hlavní příčinu neúspěchů je označována nedostatečná flexibilita IT systémů, která neumožňuje rychlé, bezproblémové a nákladově efektivní provádění změn. Řada organizací je v současné době natolik závislá na IT, že tento problém způsobuje významné riziko pro jejich budoucí vývoj. Smyslem podnikové architektury je zajištění takového uspořádání IT systémů, které odpovídají potřebám byznysu, poskytují dostatečnou flexibilitu pro realizaci změn a současně konzumují přijatelné náklady. Na základě studia vybraných zdrojů věnujících se problematice EA (viz níže Seznam zdrojů) a současně zkušeností z praxe několika organizací vnímám problém v nedostatečném poznání problematiky zavádění EA. Odborné zdroje poskytují obvykle pouze generická doporučení, v praxi však chybí konkrétní postupy pro zdůvodnění investice do EA a naplánování implementace EA. Cílem práce je zjistit, jaké jsou předpoklady úspěšné implementace EA do organizace, a to na straně organizace samotné (např. podpora od managementu, relevantní znalosti a schopnosti klíčových lidí, identifikace problému k řešení pomocí EA atp.) i z hlediska EA (výběr vhodné metodiky, východiska pro implementaci, organizace a kompetence týmu EA v podniku atd.). Podrobně se budu věnovat těmto otázkám:  Odborné publikace nabízejí řadu metodik či doporučení k EA – jaké jsou všeobecně doporučované postupy pro zdůvodnění a implementaci EA? Existují významné rozdíly mezi jednotlivými metodikami či standardy v tomto ohledu?  Existují nástroje pro zhodnocení situace konkrétního podniku, které umožní zdůvodnění a naplánování implementace EA (např. výběr problému k řešení, vyhodnocení přínosů EA, naplánování implementace EA atd.)?  Jaké existují zkušenosti s využitím těchto nástrojů v podnikové praxi?

2. Metodika zpracování práce Základním krokem pro dosažení cíle je výběr relevantních zdrojů, které komplexně pokrývají zkoumanou problematiku. Za výchozí zdroj považuji v současné době často citovaný a v praxi využívaný TOGAF 9 [The Open Group, 2009]. Další materiály jsem získal pomocí informačních zdrojů VŠE, Google Scholar a IBM (podrobně viz Seznam zdrojů). Pro odvození všeobecných zkušeností z metodiky TOGAF jsem zvolil Extended Enterprise Architecture Framework [IFEAD, 2006/1] a Federal Enterprise Architecture [US FGO, 2007], vytvořené pro potřeby státních organizací v USA. Obě metodiky patří mezi nejčastěji citované (viz např. [Schekkerman, 2003]). Uvedené zdroje obsahují komplexní popis EA a přístupů k její realizaci. Dílčími cíli jejich studia je vymezení EA v kontextu organizace, identifikace předpokladů pro úspěšnou implementaci EA a výběr souvisejících nástrojů.


29

Martin Hladík

Vzhledem k tomu, že se realizace EA neobejde bez vyhodnocení ekonomických přínosů, analyzuji v další části zdroje zabývající se touto problematikou, konkrétně [van den Berg, 2006], [Schelp, 2007], [Bhagwat, 2007], [Brown, 2004]. Následným krokem je vydání doporučení pro implementaci EA, tedy zejména identifikace problému, výpočet přínosů řešení problému pomocí EA, výběr vhodné metodiky EA, naplánování projektu EA a vyhodnocení skutečných přínosů v průběhu a po ukončení implementace EA. Tato doporučení jsou diskutována s představiteli tří významných českých podniků, kteří se problematikou EA zabývají.

3. Vymezení EA a smysl EA v organizaci Pojem podniková architektura (EA) není v praxi vnímán jednoznačně, proto je nezbytné jej vymezit. Současně je toto vymezení důležité pro pochopení případných rozdílů zkoumaných metodik EA. TOGAF [The Open Group, 2009, strany 5 až 7] definuje podnikovou architekturu jako soubor všech informačních a technologických služeb, procesů a infrastruktury a to v kontextu organizace, její části, nebo i skupiny organizací existujících za daným účelem. Zdůrazňuje nutnost definování rozsahu organizace pro potřeby řešení podnikové architektury. Podle TOGAF je smyslem podnikové architektury integrovat fragmentované podnikové procesy tak, aby podporovaly byznys strategii a realizaci souvisejících strategických změn v organizaci. Rovněž zdůrazňuje, že EA umožňuje optimální rozvoj IT v souladu s byznys strategií prostřednictvím nastavení rovnováhy mezi cenou IT a flexibilitou IT. Zajímavě jmenuje příspěvky EA k finanční i nefinanční výkonnosti organizace:  Vyšší efektivita provozu IT: Nižší náklady na vývoj, podporu a údržbu software Vyšší flexibilita aplikací Lepší kompatibilita aplikací a efektivní system a network management Jednodušší řešení kritických problémů (např. bezpečnost) Jednodušší upgrade nebo výměna systémových komponent  Vyšší návratnost investic, snížení rizika budoucích investic: Nižší komplexita infrastruktury IT Maximalizace návratnosti investice ve stávající infrastruktuře Flexibilita v interním vytvoření, pořízení (nákupu) nebo outsourcing IT řešení Redukce rizika investic a tím nižší TCO (angl. total cost of ownership)  Rychlejší, jednodušší a levnější pořízení IT (angl. procurement): Rozhodnutí o nákupu jsou jednodušší, protože nákup IT má k dispozici dlouhodobý plán vycházející z EA Nákupní proces je rychlejší, neboť není třeba řešit složité architektonické problémy (s ohledem na integraci nových IT řešení) Snížení ceny pořízení díky vyšší otevřenosti IT a možnosti zapojit do výběru více dodavatelů Přestože TOGAF akcentuje, že EA nemůže existovat bez současného řešení byznys problematiky (např. standardizace podnikových procesů, jejich automatizace, digitalizace atp.), výše uvádí výhradně IT přínosy (přitom například standardizace 30



podnikových procesů zrychluje či snižuje chybovost manuální práce a tím snižuje související provozní náklady). TOGAF je také kritizován pro nedostatečné řešení některých dalších oblastí, které s implementací EA souvisí – např. problematika plánování [Urbaczewski, 2006], či zaměření na byznys [Pragmatic EA, 2010]. Extended Enterprise Architecture Framework (E2AF) [IFEAD, 2006/1, strany 2 až 4] ve své definici více zdůrazňuje EA jako nástroj pro pochopení vnitřního fungování organizace, resp. jejích jednotlivých částí individuálně i navzájem. Cíl EA spatřuje v usnadnění řízení změn v organizaci, tedy: – identifikaci problému v konkrétní situaci, – návrhu řešení problému coby cílového (požadovaného) stavu, – návrhu realizace řešení včetně provedení změny ve stávající organizaci. Naopak neexistence EA (tedy fragmentovanost organizace ve smyslu EA) způsobuje vyšší náklady a časové nároky prováděných změn. Federal Enterprise Architecture (FEA) [US FGO, 2007] je metodika vyvinutá pro potřeby institucí státní správy ve Spojených státech. Od předchozích se liší zejména tím, že se zaměřuje na konkrétní typ organizace. To jí umožňuje poskytnout řadu detailních postupů a nástrojů, jedná o velmi komplexní zdroj. FEA je přesto využitelný i v jiných (vč. komerčních) organizacích. Na tuto skutečnost upozorňuje například TOGAF [The Open Group, 2009, strana 75]. FEA považuje EA za manažerský nástroj umožňující maximalizovat kontribuci zdrojů organizace, investic do IT a souvisejících rozvojových aktivit pro splnění strategických cílů organizace. S ohledem na to zdůrazňuje provázanost strategických cílů organizace, řešení (nejen IT) a investic do měřitelných výsledků (v kontextu výkonnosti organizace). Rovněž považuje za důležité, aby EA byla plně integrována s ostatními strategickými a manažerskými postupy (např. strategické plánování, řízení investic, programový a projektový management). Cíle FEA jsou primárně stanoveny jako příspěvek k výkonnosti organizace, konkrétně:  Odstranění výkonnostních problémů identifikovaných pomocí koordinované spolupráce strategického plánování a řízení výkonnosti organizace  Úspora nákladů prostřednictvím eliminace redundancí, znovupoužitelnosti a zvýšení produktivity  Vyšší kvalita investičního portfólia díky snížení rizikovosti investic do rozvoje organizace  Zlepšení kvality, dostupnosti a sdílení dat  Zvýšení transparentnosti organizace Výše uvedené metodiky vymezují EA jako vnitřní uspořádání organizace z různých hledisek (např. podnikové procesy, informační systémy). Cílem EA je zajištění takového uspořádání organizace, které odpovídá byznys strategii, poskytuje dostatečný prostor pro realizaci strategických změn (flexibilita) a zamezuje plýtvání zdrojů organizace (provozní efektivita). Přestože EA pokrývá problematiku organizace komplexně, jednotlivé metodiky se zaměřují především na oblast IT (zejména z hlediska nabídky detailních postupů a nástrojů). Zajímavý pohled na EA nabízí také metodika MMDIS [Voříšek, 2008]. Tato metodika, původně vyvinutá pro vývoj informačních systémů, je v současnosti profilována jako nástroj pro řízení informatiky. Vlastní definicí (viz [Voříšek, 2008, strana 129] však adresuje shodné cíle jako výše charakterizované metodiky EA – tedy zajištění takové


31

Martin Hladík

IT, které optimálně využívá potenciálu dostupných informačních technologií a informatických služeb k maximální podpoře podnikových cílů. Domnívám se, že v definici EA a jejích přínosů pro organizaci se jednotlivé metodiky neliší (např. z dalších textu TOGAF lze odvodit i „více“ byznysové přínosy, byť nejsou v úvodní části uvedeny). Významné rozdíly jsou v nabídce postupů a nástrojů, které usnadní přípravu implementace a realizaci EA. Odhaduji, že další vývoj metodik bude přinášet právě tyto postupy a nástroje, a patrně také vyšší provázanost na jiné strategické či manažerské postupy. EA v kontextu výše uvedeném je především popisem vnitřního uspořádání organizace. Takový popis sám o sobě pomůže v návrhu či rozhodování o změnách v organizaci. Některé metodiky se zabývají i touto problematikou, tj. vytvořením a správou EA na straně jedné a využitím EA pro návrh a realizaci změn organizace (angl. change management). Cílem této práce je zkoumat problematiku vzniku EA v organizaci a proto se tímto tématem zabývá i další text.

4. Předpoklady úspěšného zavedení EA do organizace Součástí TOGAF je iterativní přístup k implementaci EA – Architecture Development Method (ADM), podrobněji viz [The Open Group, 2009, strany 49 až 210]. ADM věnuje přípravě implementace EA první dvě fáze. První z těchto fází – tzv. Preliminary – identifikuje základní přístupy k řešení EA na základě specifické situace organizace. Druhá fáze – Architecture Vision – slouží pro vymezení zadání EA a kalkulaci přínosů, včetně naplánování projektu EA a získání souhlasu s implementací. Jak je již konstatováno výše, TOGAF doporučuje iterativní přístup k implementaci EA a to z důvodu rozumné realizovatelnosti jednotlivých kroků (projektů) implementace EA. Nelze tedy předpokládat, že první iterace (projekt) zajistí veškeré očekávané přínosy, nicméně je možné upřednostnit vybrané prioritní řešení. Vymezení těchto přínosů zajišťuje fáze Architecture Vision. S ohledem na tuto skutečnost je třeba rozlišovat předpoklady úspěšné realizace EA z pohledu jediné iterace a celkového řešení EA. Samozřejmým předpokladem úspěšné implementace EA podle TOGAF je znalost klíčových částí TOGAF (přibližné informace o mandatorních znalostech TOGAF lze získat v [The Open Group, 2009, strany 18 až 22]. Jedná se o vysvětlení základních principů TOGAF (tzv. Core Concepts), již zmíněný doporučený postup implementace (Architecture Development Method) včetně souvisejících návodů a nástrojů, dále pak obsahové části EA (např. Architecture Content Framework – součásti EA, koncepce referenčního modelu EA atd.). TOGAF je generický nástroj pro implementaci EA, díky tomu umožňuje významnou část přizpůsobit potřebám organizace (z důvodu existence vlastní specifické metodiky nebo využití jiného standardu). TOGAF vymezuje následující předpoklady úspěšné implementace EA:  Konkrétní identifikace problémů organizace, které má EA řešit (je obvyklé, že EA nevyřeší veškeré problémy po první iteraci implementace, ale lze na tomto základě stanovit priority a lépe vymezit rozsah implementace – viz dále).  Jasné vymezení rozsahu implementace EA – z hlediska dopadu na organizaci/její část (TOGAF používá výraz „segment“), z hlediska detailu v jednotlivých „domén“ EA (konkrétně v případě TOGAFu: business, datová, 32



aplikační a technologická doména), z hlediska času a disponibilních zdrojů atp.).  Podpora implementace EA z úrovně vrcholového managementu a strategie firmy (EA je nástroj pro zajištění efektivity provozu organizace a současně její flexibility pro realizaci změn vyplývajících ze strategie).  Dostatečné poznání organizace, počínaje strategií, porozuměním fungování organizace (včetně např. organizační kultury) a konče zmapovaním současného stavu v oblasti EA (především již využívané standardy, metody a nástroje); tento krok je obvykle realizován formálně, např. na základě metod Capability Maturity Model (TOGAF doporučuje např. NASCIO Enterprise Architecture Maturity Model [NASCIO, 2003]).  Stanovený rozpočet pro implementaci EA (kterou lze vnímat jako několik navazujících projektů s jasně vymezenými cíly).  Zkušený implementační tým a relevantní odbornost i na straně sponzorů (TOGAF podrobně popisuje požadavky na odbornost jednotlivých členů týmů v [The Open Group, 2009, strany 694 až 699]. V průběhu samotné implementace je nezbytné kontrolovat (jedná se o další předpoklady úspěšné implementace EA):  Správné stanovení priorit organizace (na strategické úrovni).  Odpovídající návrh cílového řešení EA.  S tím související identifikace klíčových problémů (resp. rozdílů mezi současným stavem a cílovým řešením v kontextu priorit organizace).  Opakovaná využitelnost vybraných částí EA (TOGAF tuto problematiku řeší v rámci konceptu Enterprise Continuum).  Systematické řízení rizik. Vzhledem k tomu, že implementace EA se dotýká všech domén organizace, bude se obvykle jednat o významný zásah do organizace (změnu). Proto je namístě věnovat pozornost i zdrojům zaměřujících se na problematiku řízení změn v organizaci, např. [Kotter, 2004], nebo projektové řízení, např. [PMI, 2000]. Kotter shrnuje svá doporučení v následujících osmi bodech: 1. Vyvolání vědomí naléhavosti uskutečnit změny. 2. Sestavení koalice prosazující změny. 3. Vytvoření vize a strategie. 4. Komunikace transformační vize. 5. Posílení pravomocí zaměstnanců v širokém měřítku. 6. Vytváření krátkodobých vítězství. 7. Využití výsledků a podpora dalších změn. 8. Zakotvení nových přístupů do organizační kultury. TOGAF tyto aspekty víceméně řeší také, vyjma kladení důrazu na specifické řízení komunikace v rámci organizace a zabývání se dopady na organizační kulturu. Přitom Kotter upozorňuje na vysokou pravděpodobnost neúspěchu realizace změny při nedodržení byť jediného aspektu z výše uvedených. Extended Enterprise Architecture Framework (E2AF) [IFEAD, 2006/1] vnímá předpoklady úspěšné realizace EA shodně. Jmenuje především jasné vymezení cílů EA (proč má být EA realizována, k jakým business cílům má přispět), existenci SYSTÉMOVÁ INTEGRACE 2/2011

33

Martin Hladík

business strategie (východisko EA), zřetelně vymezený rozsah projektu EA, zkušený realizační tým, odlišení jednotlivých domén EA (podobně jako TOGAF), realizační plán (E2AF doporučuje ADM) atd. Federal Enterprise Architecture (FEA) [US FGO, 2007] se rovněž v předpokladech úspěšné realizace EA neliší. Za výchozí považuje porozumění business strategie, zejména pak současného a budoucího stavu (plánu). Právě z plánu změny organizace je extrahováno zadání pro EA. Specificky FEA zdůrazňuje potřebu soustavného měření přínosů EA. Zajímavý pohled na benefity EA uvádí také Schelpův příspěvek [Schelp, 2007], ve kterém je diskutována problematika měření ekonomických přínosů EA pomocí koncepce Balanced Scorecard (totéž např. [de Vries, 2008]). Alternativní způsob nabízí rovněž [Brown, 2004]. MMDIS [Voříšek, 2008] také identifikuje předpoklady úspěšné implementace IT (přeneseně tedy také EA), přičemž za klíčové s ohledem na zde diskutované téma považuji:  Neopomenutí žádného faktoru, který ovlivňuje úspěch IT (princip multidimenzionality) – z pohledu EA se jedná o komplexní přístup k řešení, současně však také rozlišení jednotlivých pohledů na řešení pro zjednodušení úlohy (MMDIS rovněž definuje základní typy architektur potřebných k vytváření IT – konkrétně: byznys architektura, globální architektura IS/ICT, dílčí architektury IS/ICT)  Zdůvodnění existence komponent IT na základě identifikace jejího byznys přínosu (princip integrace mezi tzv. obsahovými dimenzemi IT) – mnohokrát uváděný tzv. business – IT alignment  Zajištění optimální flexibility řešení – jeden z hlavních cílů EA (zajištění takové flexibility IT, které je ekonomicky zdůvodnitelné)  Schopnost zajistit efektivní zdroje IT např. prostřednictvím partnerů (princip kooperace)  Princip měřitelnosti zajišťující schopnost vyhodnotit výsledky vybrané strategie či přístupu k řešení problému Předpoklady úspěšné implementace EA (resp. kritické faktory úspěchu) vymezují analyzované metodiky bez významných rozdílů. Za klíčové faktory považuji porozumění motivace pro realizaci EA (důvody na straně byznysu vyplývající ze strategie), zkušený tým zajišťující realizaci a podporu managementu organizace. Obtížnost realizace EA je ovlivněna připraveností organizace z hlediska EA (v kontextu výše jmenovaných předpokladů úspěchu) a složitostí organizace samotné.

5. Doporučený postup implementace EA Součástí metodiky TOGAF je iterativní metoda realizace EA – tzv. Architecture Development Method (ADM). Postup vznikl na základě praktických zkušeností s implementací EA. Primárním cílem ADM je budovat EA v organizaci, nicméně souběžně je tím také vytvářena tzv. Architecture Repository – knihovna opakovaně využitelných částí organizace (např. procesní model, normy organizace, IT architektura segmentu atp.).

34



Konkrétní postup ADM závisí na stanovených cílech jednotlivých iterací. Rozhodnutí o specifickém postupu je vhodné učinit na základě disponibilních zdrojů, zkušeností a očekávaných přínosů. Cíle implementace EA jsou stanoveny na základě:  Šíře pokrytí organizace (např. celá organizace, případně vybrané segmenty).  Detail zpracování.  Časové omezení.  Výstupy EA včetně disponibility existujících artefaktů EA vně i uvnitř organizace. Každá iterace ADM obsahuje osm fází, přičemž první iteraci předchází fáze „Preliminary“. TOGAF umožňuje přizpůsobení implementačního postupu potřebám organizace. Fáze Preliminary zajišťuje přípravu první iterace implementace EA. Cílem této fáze je vymezení organizace (resp. segmentu organizace), která bude zasažena implementací EA, včetně identifikace motivace pro implementaci EA, preferovaných hlavních principů EA, implementačního týmu a podpůrných nástrojů. Fáze Architecture Vision reviduje rámec implementace EA vytvořený v předchozí fázi, na tomto základě stanoví cíle a výstupy první iterace a připraví detailní realizační plán (ve smyslu projektového plánu). Pro jednotlivé domény EA jsou vytvořeny koncepční popisy současného i cílového stavu včetně jasného vymezení přínosů. V závěru je vyžadován formální souhlas sponzorů projektu. Další fáze – Business Architecture, Information Systems Architecture a Technology Architecture zajišťují detailní zpracování jednotlivých domén EA v kontextu cílů iterace, v současném i požadovaném pohledu. Na základě porovnání obou pohledů jsou identifikovány úkoly implementace EA a navrženy priority. Fáze Opportunities & Solutions vyhodnotí dílčí návrhy předchozích fází a navrhne konkrétní realizační kroky (např. projekty, programy). Současně analyzuje schopnosti organizace absorbovat změnu definovanou těmito realizačními kroky a navrhuje rámec migračního plánu. V některých případech, kdy není možné okamžitě dosáhnout cílového stavu, navrhuje tzv. přechodnou architekturu. V další fázi – Migration Planning – dochází k finalizaci implementačního a migračního plánu. TOGAF upozorňuje na nezbytnost sladění s dalšími manažerskými postupy (např. business planning, portfolio/project management) a nastavení jasných přínosů pro každý projekt v rámci implementačního a migračního plánu EA. Následující fáze – Implementation Governance a Change Management – řeší problematiku samotné implementace, především, jak již z názvů fází vyplývá, dohled nad implementací (včetně zajištění „kontraktu“ implementace) a změnové řízení. Součástí ADM je také podpůrný proces Requirements Management, který zajišťuje řízení požadavků na EA napříč celým cyklem ADM. ADM poskytuje značnou flexibilitu využití dle potřeb v konkrétní situaci. Jednotlivé fáze jsou pak různě zastoupeny v iteracích (např. první iterace se soustředí na fáze Preliminary a Architecture Vision). V rozsáhlých organizacích není obvyklé možné obsáhnout implementaci EA v jediném projektu (byť skládajícího se z více iterací), ale je nezbytné přistupovat k řešení v několika rovinách, např. strategické na úrovni celé organizace (výsledkem je tzv. strategická architektura), dílčí na úrovni obchodní jednotky (tzv. segmentová architektura) a detailní na úrovni např. architektonických SYSTÉMOVÁ INTEGRACE 2/2011

35

Martin Hladík

domén. ADM se v takovém případě může věnovat strategické úrovni ve fázi Architecture Vision, segmentové architektury mohou být rozpracovány ve fázích Business -, Information Systems – a Technology Architecture, fáze Opportunities & Solutions řeší detailní návrh jednotlivých architektur. Řešení rozsáhlých úloh vyžaduje věnovat větší úsilí koordinaci dílčích architektur z důvodu jejich vzájemné propojitelnosti a znovupoužitelnosti. Extended Enterprise Architecture Framework (E2AF) nenabízí specifický proces realizace EA, hovoří pouze o obvyklých fázích Příprava, Analýza, Návrh a Transformace. Součástí E2AF je soubor předpokladů a principů úspěšné realizace EA (podrobně viz výše). Jako vhodný postup doporučuje ADM. Federal Enterprise Architecture (FEA) poskytuje vlastní třífázový realizační cyklus. První fáze Architect se zabývá analýzou požadavků na EA a jejich prioritizací, návrhem konceptuální architektury. Následující fáze Invest připravuje realizační strategii a rozpočet. Fáze Implement začíná vytvořením implementačního plánu a pokračuje samotnou realizací s následným vyhodnocením přínosů. FEA poskytuje rovněž detailní plány pro jednotlivé fáze a řadu vzorů, referenčních modelů a jiných nástrojů pro podporu realizace EA. MMDIS neposkytuje návod pro implementaci EA. Nicméně doporučovaný postup vývoje integrovaného informačního systému (tzv. Model tvorby a dalšího rozvoje IS/ICT podniku) se v principu shoduje s výše uvedenými postupy. Poskytuje obvyklý postup odvození strategie IT na základě byznys strategie a na základě definovaných priorit realizaci dílčích projektů. Výše uvedené metodiky se více či méně věnují postupu realizace EA, nicméně zřídka poskytují konkrétní návody pro provedení návrhu konkrétní architektury, odvození souvisejících architektur atd. Schekkerman [Schekkerman, 2003, strany 40 až 45] upozorňuje na riziko nedostatečné vazby mezi businessem a IT právě z důvodu volby nevhodných návrhových technik. Za inspirativní považuji využití techniky tzv. chování businessu, která popisuje činnosti prováděné pro zajištění hodnoty, namísto tradičního modelování procesů, případně techniky tzv. mapování sad řešení na úrovni businessu a následně IT, namísto aplikační architektury. Často uváděným výchozím bodem pro realizaci EA je poznání současného stavu organizace, což kromě charakteristiky znamená i zhodnocení tzv. vyspělosti (připravenosti) organizace z hlediska EA. Nejen TOGAF doporučuje pro tento účel metodu NASCIO Enterprise Architecture Maturity Model (EAMM) [NASCIO, 2003]. EAMM nahlíží na EA z těchto pohledů (které jsou dále rozlišeny to tzv. elementů):  Architecture Governance – metody pro zajištění správné realizace EA včetně vedení a řízení, organizační struktury, nastavení procesů pro implementaci a kontrolu implementace EA, řízení rizik a využití zdrojů.  Business Architecture – popisuje motivaci pro realizaci EA, součástí je definice poslání, pravidel, cílů a strategií byznysu. Cílem je vytvořit jasné zadání pro ostatní „vrstvy“ architektury.  Technology Architecture – poskytuje procesy a vzory k dokumentování kritérií pro posouzení shody jednotlivých (IT) řešení s požadavky stanovenými na úrovni Business Architecture. Poskytuje technologické standardy a principy migrace stávajících IT řešení.

36



EAMM hodnotí vyspělost organizace z hlediska EA v šesti úrovňové stupnici: 0 – žádná EA, 1 – neformální EA, až 5 – kontinuálně řízené zlepšování EA. Hodnocení vychází z posouzení tří hlavních stavebních kamenů EA, resp. jejich elementů (každý element je hodnocen samostatně a může nabýt různé úrovně). Vyhodnocení je sestaveno na základě analýzy těchto hledisek:  Administration – role a odpovědnosti pro řízení a kontrolu EA (angl. governance)  Planning – plán realizace EA (celkově i na úrovni jednotlivých projektů)  Framework – procesy a vzory pro budovaní EA  Blueprint – aktuální standardy a specifikace pro řešení  Communication – vzdělávání a distribuce informací souvisejících s EA  Compliance – dodržování standardů, procesů a dalších pravidel EA (včetně možnosti ověření)  Integration – propojení manažerských technik a nástrojů s EA  Involvement – dostatečná podpora EA z organizace EA je komplexní problematikou, především z hlediska mnoha funkčních domén v organizacích a současně jejich individuálních specifik, ale také z hlediska složitosti samotných IT řešení. Realizace projektu EA vyžaduje tým, který tuto komplexní problematiku expertně pokryje (viz např. [The Open Group, 2009, strany 694 až 699]). Řízení takového projektu předpokládá předem definovaný a strukturovaný přístup, který např. ADM poskytuje. Jsem názoru, že reálná znalost ADM či podobného přístupu k realizace EA v českých podmínkách chybí. Poznání stávající situace v organizaci je jistě klíčové pro zahájení realizace EA. Doporučovaná metoda hodnocení EAMM však poskytuje z mého pohledu pouze velmi obecný model hodnocení, který nemůže zajistit identifikaci priorit pro plánování realizace EA. Odhaduji tedy, že v praxi existují i podrobnější modely hodnocení, které jsou navržené např. pro konkrétní typy organizací (odvětví) nebo funkční domény (např. výroba).

6. Nástroje EA Problematika nástrojů pro realizaci EA není zcela jasně vymezená. Některé zdroje popisující konkrétní frameworky EA (např. [The Open Group, 2009], [US FGO, 2007]) jsou sami o sobě nástroji – metodickými postupy, jak realizovat EA. Jiné zdroje (např. [Bhagwat, 2007], [US FGO, 2009]) poskytují nástroje pro měření vyspělosti EA a tak vlastně identifikaci priorit pro další řešení EA jako takové. Generický charakter těchto nástrojů však omezuje jejich okamžité nasazení v praxi. Navíc studované zdroje neposkytují ucelený přehled pro vlastní realizaci EA, nebo dokonce doporučení pro integraci EA s jinými disciplínami, například strategickými a manažerskými postupy (viz také kap. 3). V praxi českých podniků se nástrojem EA rozumí pouze modelovací aplikace typu Enterprise Architect nebo ARIS (podrobně viz následující kapitola). S ohledem na absenci komplexní informace o nástrojích EA jsem sestavil přehled potřebných nástrojů na základě vlastní úvahy a praxe. Hlavním předpokladem je identifikace klíčových rolí EA v organizaci, konkrétně: SYSTÉMOVÁ INTEGRACE 2/2011

37

Martin Hladík

Podpora při vytváření byznysové strategie organizace, zejména identifikace optimálních řešení v souladu se strategickými cíli;  Popis stávajícího a budoucího (požadovaného) stavu organizace, což umožňuje zajištění předchozí role; součástí je identifikace standardů, které ve svém důsledku zvyšují flexibilitu organizace a efektivitu budoucích změn;  Definice postupů pro realizaci a využívání EA, včetně organizace samotné EA. Na základě takto specifikovaných rolí EA (podrobně viz také sloupce Proces, Činnost v níže uvedené tabulce) je možné identifikovat potřebné metody resp. nástroje. 

Proces Strategické plánování

Transformace

Činnost

Metody měření výkonnosti

Identifikace řešení k naplnění strategických cílů

Současný a žádoucí model organizace, analýza dopadu, business case, atp.

Plánování

Především metody programového, projektové či změnového řízení Analytické a návrhové metody na různých úrovních (např. byznysová, aplikační, datová atp. vrstva)

Analýza a návrh

Realizace

Podpora EA

38

Metody obecně

Identifikace oblastí s potenciálem zlepšení

Různé metody řízení (včetně změnového), řízení kvality

-

-

-

-

-

-

Metody EA Standardy pro aplikaci vybraných metod měření výkonnosti (např. monitorování výkonnosti procesů) Popis současného a žádoucího modelu organizace, metody pro analýzu dopadu, nákladů, rizik atp. Lze diskutovat, zda by EA měla stanovit standard pro použití uvedených nástrojů Standardy pro provádění analýzy a návrhu (včetně nástrojů), kontrola kvality z hlediska EA, posuzování nových koncepcí mimo stávající standardy Standardy pro provádění kontroly kvality, samotná kontrola kvality v případě změnového řízení Vytváření stávajícího a žádoucího modelu organizace včetně metod jeho využívání Definice standardů pro různé oblasti (zejm. architektura a její komponenty, používané nástroje a metody) Definice postupů pro využívání EA v organizaci (viz výše) a rozvoj samotné EA



Za hlavní nástroj EA považuji model současného a žádoucího stavu organizace (často se používá angl. výraz targe operating model). Zjednodušeně takový model popisuje strukturu organizace (např. z hlediska funkcí, procesů) a jejich vazbu na IT prostředí (např. aplikace, služby). Součástí jsou informace o výkonnosti jednotlivých částí organizace (např. podíl na nákladech). Model současné organizace pomáhá identifikovat oblasti ke zlepšení a provádět tzv. analýzy dopadu. Model budoucí organizace usměrňuje návrhy konkrétních změn. Standardy a vzory, které je nanejvýš vhodné aplikovat při realizaci změn, jsou dalším klíčovým produktem EA. Součástí jsou například identifikace technologií, které lze využít pro realizaci nových aplikací, metody jejich využití (např. použití UML pro analýzu a návrh), ale také například často opomíjený jednotný slovník organizace. Výhodou mohou být i tzv. architektonické vzory pokrývající jak byznysovou architekturu (např. referenční odvětvové modely, které pomáhají vytvořit tzv. žádoucí model organizace), tak problematiku IT (např. logický model datového skladu). Součástí jsou samozřejmě i technické nástroje pro vytváření modelů, vývoj a správu aplikací atd. Samostatnou a neméně důležitou součástí nástrojů EA jsou postupy nebo metody pro rozvoj a integraci EA v rámci organizace (jedná z klíčových rolí je např. design authority – zajišťující dohled nad dodržováním architektonických standardů). V zásadě se jedná o vytvoření jasné role a zapojení EA v rámci výše uvedených procesů (zejména strategické plánování a provádění změn) a to na úrovní celé organizace i oddělení IT. Zde lze přiměřeně aplikovat také nástroje pro měření vyspělosti EA (viz výše).

7. Diskuse poznatků v praxi Nabyté znalosti a názory jsem diskutoval se zástupci tří významných organizací ze sektoru finančních služeb. Dále uvádím stručné shrnutí diskuse strukturované do čtyř základních dotazů a odpovědí (odpovědi jednotlivých organizací jsou odlišeny pod písmeny a) až c)). 1. Zabývá se vaše organizace EA? Jak hodnotíte současnou vyspělost vaší organizace z hlediska EA (podle EAMM)? Používáte nějaké metody/nástroje pro hodnocení vyspělosti organizace? a)

b)

c)

EA rozumím implementaci nového (ve smyslu správně strukturovaného) uspořádání podniku na úrovni byznysu i IT. EA tedy musí být součástí podnikové strategie. V tomto smyslu se EA nezabýváme, vyspělost odhaduji na úrovni 0 až 1 (žádná až velmi neformální). EA vnímáme (používáme) jako model IS, zejména jednotlivých systémů a vazeb mezi nimi. Využívá se pro vyhodnocení dopadů změn IS. Přestože EA v tomto smyslu nepokrývá všechny vrstvy (např. Business Architecture), lze považovat její vyspělost na úrovni 2 (opakovatelný program). Model IS je zdokumentován v nástroji Enterprise Architect, ostatní vzory v dalších nástrojích dle zvyklostí. Ano, zabývá, nicméně až v poslední době. Vyspělost je pravděpodobně na úrovni 1 (neformální), máme však ambici dosáhnout úrovně 3 (dobře definovaný program). Metody a nástroje vybíráme, například zvažujeme TOGAF, ale obáváme se jeho komplexnosti.


39

Martin Hladík

2. Používáte konkrétní metodiky EA (např. TOGAF)? Jaké máte zkušenosti s využívanou metodikou? Rozumí vrcholový management smyslu a koncepci EA? a) b)

Nepoužíváme, management se EA nezabývá. Používáme vlastní modely a standardy vycházející z UML. Konkrétní EA metodiku nepoužíváme. Management (mimo IT) se neřeší problematiku EA. c) Zatím ne, vybíráme vhodnou metodiku. V současnosti vysvětlujeme managementu na straně byznysu, jaké má EA přínosy pro podnik. 3. Jakými aktuálními problémy (ve smyslu požadavky) se nyní v kontextu EA zabýváte? Vnímáte dostatečné propojení byznys potřeb a IT v právě realizovaných projektech? Co jsou hlavní důvody případného nepropojení těchto světů? a)

Ve střednědobém období budeme realizovat výměnu hlavních IS. Bez EA nebudeme schopni snadno analyzovat dopady a připravovat plán realizace. V běžných IT projektech funguje komunikace byznysu a IT dobře, tato diskuse však není dostatečná nebo chybí s ohledem na nové technologie (např. BPM) nebo velké změny (viz výše). Klíčové pro úspěch EA je, aby podnik řešil z hlediska EA relevantní problémy (tj. rozsáhlé změny IS), EA poskytovala modely architektury (pro potřeby analýzy a návrhu) a především zajišťovala podporu projektů (nesmí fungovat jen jako „zákonodárce“, ale také jako „kauč“). b) Začali jsme připravovat upgrade hlavního IS a realizujeme několik dalších velkých projektů. Byznys oddělení jsou obvykle zapojována na počátku projektu (specifikace zadání, business case, schválení projektu) a poté v rámci akceptace a zavádění nového IS do podniku. Tento způsob spolupráce považujeme za dostatečný. c) V poslední době několik projektů skončilo neúspěchem z důvodu neexistence nebo nedostatečné vyspělosti některých tzv. sdílených komponent podnikového IS (např. integrační vrstva, kvalita a řízení podnikových dat atp.). Proto jsme nedávno začali analyzovat možnosti implementace EA s cílem řešit právě tyto problémy. V rámci jednotlivých projektu byznys s IT spolupracuje. Bohužel však nevnímá potřebu vytvoření sdílených komponent, které jsou nutné pro budoucí rozvoj IS (např. implementaci nového obchodního IS). 4. Na základě čeho identifikujete prioritní problémy k řešení? Jaké máte zkušenosti s kalkulací business case v kontextu EA? a) b)

c)

40

EA by měla prioritně řešit projekty vyžadující největší investice s cílem zajistit nejsnazší řešení. Priority IT jsou stanoveny při ročním plánování na základě potřeb byznysu, okrajově dle potřeb IT (nyní například upgrade hlavního IS z důvodu končící podpory stávajícího HW). EA (ve smyslu výše uvedeném) pomáhá identifikovat dopady změny IS, podporuje tedy přesnější kalkulaci na straně nákladů. Priority IT se určují na základě prioritizace potřeb byznysu, zohledňuje se především business case jednotlivých požadavků a neformálně také důležitost byznys oddělení v podniku. Z hlediska EA budeme vybírat ty



problémy, které umožní nebo usnadní implementaci nových strategických IS (např. obchodní IS). Na první pohled lze situaci v českých podnicích (s diskuse s kolegy vím, že podobný stav je i v jiných organizacích v ČR) považovat za překvapující. Nicméně řada organizací je stále velmi decentralizovaná (rozdělená na tzv. sila, která realizují vlastní byznys, používají vlastní aplikace atd.), sdílené funkce jsou pouze okrajové (např. lidské zdroje, nákup, finance). Případné změnové projekty se tak týkají vždy jen téměř izolované části, proto není třeba řešit složité úlohy týkající se architektury. Nicméně tento stav se mění s příchodem nových systémů řízení (např. procesní řízení) a IT systémů (např. master data management). Pravděpodobně díky tomu výše uvedená diskuse s představiteli praxe nepřinesla žádné ohromující poznatky týkající se EA.

8. Závěr Zkoumané metodiky EA poskytují podobné přístupy k řešení EA. Hlavní rozdíly spatřuji v terminologii, rozsahu a detailu jednotlivých částí. V podmínkách českých podniků považuji za vhodné volit takovou metodiku, která zajistí kompatibilitu s prostředím mateřské skupiny (pokud je organizace její součástí) a existuje dostatek lidských zdrojů a zkušeností na trhu. Je zřejmé, že uvažování o EA začíná na území IT a to navzdory zdůraznění, že cílem EA je zajistit správnou organizaci podniku a tomu odpovídající organizaci IT. Je to patrně tím, že řada velkých podniků uvažuje v dlouhodobých vizích pouze o finančních či obchodních výsledcích a naopak změnu provozního modelu (který často umožňuje/omezuje dosažení cílů) v této perspektivě neřeší. Zdůvodnění smyslu implementace EA – „podpora realizace strategických změn v organizaci“ [The Open Group, 2009] – je jasné, v kontextu výše uvedeného však nepoužitelné. Jsem názoru, že ekonomické prostředí, ve kterém dotazované firmy podnikají, stejně jako jejich závislost na mateřských organizacích způsobují, že tyto organizace v současnosti nepotřebují nebo nejsou kompetentní provádět strategické změny a tudíž komplexní řešení EA postrádá smysl. Nástroje pro zhodnocení situace podniku a návrh priorit pro EA existují. Veřejně dostupné posuzují obecné vlastnosti organizace a na tomto základě stanoví vyspělost – např. [NASCIO, 2003]. Z mého pohledu je vypovídací schopnost těchto metod značně omezená – lze ji využít pro plánování vnitřního rozvoje EA oddělení, nikoliv pro stanovení konkrétních priorit rozvoje podniku. Přední konzultační firmy mají podrobnější nástroje, ty jsou však dostupné pouze komerčně a i jejich možnosti jsou často limitovány specifickým prostředí konkrétní organizace. Přístup podniků k prioritizaci projektů (včetně s dopadem na EA) je obvykle prováděn na roční bázi v souvislosti s přípravou podnikového rozpočtu. Domnívám se, že EA by měla do tohoto plánovacího procesu vstupovat v závěsu s cílem identifikovat dopady projektů (změn) do organizace a doporučit konkrétní přístup k řešení (v souvislosti s EA). V tomto pohledu se EA stává součástí strategických procesů v oblasti plánování. Tento názor potvrzuje také např. [IFEAD, 2006/1]. Zkušenosti s EA v českých podmínkách jsou spíše teoretické nebo pouze v kontextu IT. Z různých analytických prognóz plyne, že podniky i v našem prostředí se nevyhnou dalšímu snižování nákladů a zvyšování flexibility (např. pro rychlejší zavádění nových produktů na trh, větší přizpůsobení služeb individuálnímu klientovi atp.), kterého již SYSTÉMOVÁ INTEGRACE 2/2011

41

Martin Hladík

nebude možné dosáhnout bez zásadních změn. Ty však půjde jen těžko realizovat bez zavedení EA. Odhaduji, že tento jev bude doprovázen silnou poptávkou po kvalifikovaných lidských zdrojích a vhodných nástrojích. Především komplexita vnitřního uspořádání podniků a heterogennost jejich IT bude realizaci změn komplikovat. Proto by bylo vhodné začít s přípravou EA v dostatečném předstihu. Nynější management podniků však patrně tento problém nevnímá. Klíčem bude převedení problému do finančního vyjádření, což však bude možné pouze na základě poznání detailní situace podniku a jejího budoucího vývoje. Poděkování Tento článek vznikl za podpory grantu GAČR P 403-10-0303 (Enterprise Architecture jako princip v řízení malých a středních organizací).

9. Seznam zdrojů [Bhagwat, 2007] BHAGWAT, A.: Enterprise Architecture Maturity Assessment, NDIA 7th Annual CMMI Technology Conference 2007. [Brown, 2004] BROWN, T.: The Value of Enterprise Architecture, 2004. [de Vries, 2008] de VRIES, M., van RENSBURG, A. C.: Enterprise Architecture – New Business Value Perspectives, South African Journal of Industrial Engineering, Vol 19, University of Pretoria 2008, South Africa. [Hrabě, 2010] HRABĚ, P.: Úloha služeb v rámci podnikové architektury (Enterprise Architecture), příspěvěk k Systémové integraci 2010. [IBM, 2009] IBM: TOGAF & IBM EA Method, interní materiál společnosti IBM, 2009. [IFEAD, 2006/1] Institute For Enterprise Architecture Developments: Extended Enterprise Architecture Framework – Essentials Guide, 2006. [IFEAD, 2006/2] Institute For Enterprise Architecture Developments: Enterprise Architecture Assessment Guide, 2006. [Kotter, 2003] KOTTER, J. P., COHEN, D. S.: Srdce změny, Praha: Management Press, 2003 [Kotter, 2004] KOTTER, J. P.: Vedení procesu změny, Praha: Management Press, 2004 [Lankhorst, 2009] LANKHORST, M.: Enterprise Architecture at Work: Modelling, Communication and Analysis, Springer, 2009. ISBN: 3642013090. [NASCIO, 2003] National Association of State Chief Information Officers: NASCIO Enterprise Architecture Maturity Model, Version 1.3, 2003. [PMI, 2000] Project Managment Institute: A Guide to the Project Managment Body of Knowledge, Pennsylvania 2000. [Pragmatic EA, 2010] Pragmatic EA Ltd: Pragmatic Enterprise Architecture Framework: Framework Comparison, a part of PEAF documentation, 2010. [Schekkerman, 2003] SCHEKKERMAN, J.: How to survive in the jungle of enterprise architecture frameworks, Trafford Publishing, 2003. ISBN: 141201607X.

42



[Schelp, 2007] SCHELP, J., STUTZ, M.: A Balanced Scorecard Approach to Measure The Value of Enterprise Architecture, Tear 2007. [The Open Group, 2009] The Open Group: TOGAF Version 9. The Open Group Architecture Framework (TOGAF), The Open Group, 2009. ISBN:978-90-8753-230-7. [Urbaczewski, 2006] URBACZEWSKI, L., MRDALJ, S.: A comparison of enterprise architecture frameworks, Eastern Michigan University, 2006. [US FGO, 2007] US Federal Government Office: FEA Practice Guide, 2007. [US FGO, 2009] US Federal Government Office: Enterprise Architecture Assessment Framework, 2009. [van den Berg, 2006] van den BERG, M., van STEENBERGEN, M.: Building an enterprise architecture practice, Springer, 2006. ISBN: 1402056052. [Voříšek, 2008] VOŘÍŠEK, J. a kol.: Principy a modely řízení podnikové informatiky, Oeconomica, 2008. ISBN: 8024514400.


43

Předpoklady úspěšné implementace podnikové architektury

Recommend Documents