Kdo potřebuje Enterprise Architecture a proč?

Copyright © 2009 Zabegalin E.V.

1 Současný stav architektonických metodologií a postupů

V cizí země aha, už dávno je metodologicky i prakticky rozpracován určitý okruh témat, jejichž předmětem je architektura komplexních organizační a technické objekty, jako jsou podniky, „elektronické vlády“, podnikové informační systémy.

V Rusko, navzdory skutečnosti, že termíny „architektura informačního systému“„Enterprise IT architecture“, „electronic Government architecture“, se již dávno staly módou a jsou široce používány mezi IT profesionály, vážný metodologický zájem o „architektonická“ témata je přítomen pouze v úzkém okruhu nadšených odborníků (včetně autorů publikací), aktivity, které mají v této oblasti především vzdělávací a popularizační charakter.

Pokud se tedy budeme bavit o standardizaci „architektonických“ metodik v Rusku a jejich následném širokém praktickém využití v tuzemských firmách, pak se zdá, že jde o nejistou budoucnost. „Architektonické“ hnutí v ruských podnicích by však mělo prakticky začít již nyní.

„Enterprise Architecture“, v ruštině „Enterprise Architecture“ (AP), se vyvinula v obecnou disciplínu jako krok historický vývoj soubor metodik souvisejících s architekturou automatizovaných informačních systémů - jedná se o metodiky J. Zachmana, Art. Spivak, CIMOSA, GERAM, TOGAF aj. Rozbor tohoto historického procesu je dostatečně podrobně uveden v.

K dnešnímu dni patří mezi nejvýznamnější a nejvýznamnější zdroje moderních metodologických myšlenek a postupů EA:

Zachman Framework pro podnikovou architekturu;

ISO 19439:2006 "Enterprise integration - Framework for enterprise modeling";

Norma ISO 15704:2000. Průmyslové automatizační systémy - Požadavky na podnikové referenční architektury a metodiky;

"Federal Enterprise Architecture" (FEA), praktikovaná a vyvinutá vládou USA;

"Extended Enterprise Architecture Framework" (E2AF), vyvinutý společností nezávislá organizace"Institut pro rozvoj podnikové architektury";

Open Group Architecture Framework (TOGAF).

Spolu s tím bylo v Rusku v roce 2000 vyvinuto a publikováno konceptuální architektonické schéma "3D-Enterprise", ve kterém byly maticové myšlenky J. Zachmana doplněny o třetí - dočasnou - dimenzi, která odráží transformaci podnikové struktury.

Je třeba poznamenat, že významný zájem o téma AP je vysvětlen naléhavou potřebou moderních manažerů a analytiků po vícerozměrném systémovém popisu a plánování procesu rozvoje organizací (včetně podniků). Zájem o takový popis je dán přinejmenším praktickou potřebou mít vždy dostatek smysluplných znalostí o aktuální struktuře organizace, které lze využít i pro racionální plánování transformace organizace v měnících se podmínkách. Pokud jsou takové znalosti dostupné, udržované a používané v organizaci v odcizené podobě, pak se mění v účinný nástroj řízení. To platí zejména pro nové vedoucí a manažery organizací (podniků).

Obrázek 1 - Manažeři a analytici mají praktickou potřebu mít vždy dostatečné smysluplné znalosti o struktuře organizace (podniku)

Úroveň abstrakce a složitosti většiny uvedených metodik přitom zůstává velmi vysoká a může bránit jejich efektivnímu využití v jejich organizacích. praktické manažery a specialisty. jiný druh"Matice" a "kostky" navrhované v uvedených metodikách se mohou zdát zbytečně umělé, a proto pro praktické použití nepohodlné. Takže například povaha téže „Zachmanovy matice“ se zdá být spíše filozofická než praktické inženýrství, jde spíše o schematicky vizualizovanou specifikaci systematického přístupu k analýze velkých a komplexně strukturovaných organizačních a technických objektů. To však ani v nejmenším nepopírá obrovskou metodologickou hodnotu a praktický význam rozvíjející se disciplíny AP.

V zájmu praktické aplikace disciplíny EA může být překonání této umělosti zahájeno hledáním odpovědi na otázku: kdo a proč v podniku může potřebovat „podnikovou architekturu“?

2 Účel "Enterprise Architecture"

Obrázek 2 schematicky znázorňuje strukturu a obsah zobecněného podniku. Z tohoto schématu je vidět, že AP, uvažovaný a používaný jako model, může být v podniku prakticky žádaný pouze jako nástroj řízení, protože technický ani výrobní personál AP k výkonu svých výrobních funkcí nepotřebuje.

Tento závěr vyplývá ze skutečnosti, že všechny objekty řízení uvedené v diagramu jsou současně objekty, které se mají promítnout do modelu EA, který se v budoucnu stane také objektem řízení (architektonický model podniku je v diagramu znázorněn jako jeho součást ).

Obrázek 2 - Zobecněná struktura podniku

Jako nástroj řízení lze EA využít k podpoře všech jeho hlavních funkcí – analýzy, plánování, organizace, motivace, kontroly, koordinace.

Obrázek 3 - "Enterprise Architecture" lze použít k podpoře základních funkcí správy

Z role EA jako nástroje pro správu lze odvodit alespoň dvě hlavní funkce Enterprise Architecture:

v obrysu provozního řízení podniku - je to formalizace a poskytování odcizených znalostí o stávající struktuře a fungování podniku;

v obrysu strategické řízení podnik - je formalizace a poskytování

odcizené znalosti o plánovaných strukturálních a funkčních transformacích podniku.

Obrázek 4 - Hlavní funkce "Enterprise Architecture"

AP lze s těmito funkcemi používat na všech úrovních řízení: od úrovně podnikového řízení až po dílnu. To je (explicitně nebo implicitně) zajištěno známými metodikami -

"Zachman Framework for Enterprise Architecture", "Extended Enterprise Architecture Framework", "TOGAF",

"GERAM", norma ISO 19439-2006 (úrovně "obecné", "částečné", "zvláštní").

Po J. Zachmanovi jsou ve schématu „3D-Enterprise“ navrženy nejkonkrétnější a nejkonzistentnější úrovně řízení pro využití AP – „Hlavní potřeby, cíle, plány, omezení“, „Obchodní model“, „Logický model“, „ Technická architektura“, „Detailní provedení“, „Praxe použití“.

3 Složení "Enterprise Architecture"

Všechny architektonické metodiky se shodují v tom, že pro dostatečně smysluplný popis zařízení podniku (organizace) je nutné na toto zařízení použít mnoho různých úhlů pohledu (pohledů). Tato hlediska mohou být také označována jako architektonické domény, aspekty obsahu a podobně. Popisování (a modelování) struktury podniku z mnoha různých pohledů vede k „podnikové architektuře“.

Různé metodologie používají různé sady architektonických hledisek. Například:

v Zachman Framework for Enterprise Architecture jsou to „Data“, „Funkce“, „Síť“, „Lidé“, „Čas“, „Motivace“;

v Extended Enterprise Architecture Framework (E2AF) je "Obchod", "Informace", "Informace"

systémy", "Technologická infrastruktura";

v GERAM a v ISO 19439-2006 jsou to "Funkce", "Informace", "Zdroj", "Organizace";

v TOGAF jsou to "Obchod", "Informace", "Aplikace", "Technologie".

Autor tohoto článku považuje za prakticky účelné překonat takovou rozmanitost metodických přístupů k volbě věcných aspektů EA využitím libovolného jednoduchého a srozumitelného principu pro logické odvození těchto aspektů.

Takový princip může vyplývat z obecného fundamentálního chápání „systému“ jako souboru účelově interagujících prvků. Na základě toho lze zásadně rozlišit následující základní a snadno pochopitelné věcné aspekty „Enterprise Architecture“:

1) Stavební aspekt- podnik je postaven z mnoha různých fyzických a informačních složek, včetně: dlouhodobého majetku a jiného majetku, spotřebované a vyrobené energie, personálu, papírových dokumentů, elektronických informací, automatizace a nástrojů automatického řízení, to jsou „stavební kostky“ ze kterých se podnik fyzicky skládá. K tomuto aspektu lze také použít synonymický termín - strukturální aspekt.

2) Funkční aspekt- podnik působí, vyrábí výrobky, poskytuje služby, nakupuje a prodává suroviny, materiály, výrobky, provádí se v něm technologické a obchodní procesy, to znamená, že tento aspekt rozlišuje vnější a vnitřní projevy činnosti podniku;

3) Logický aspekt- činnost podniku je účelná, v souladu s cíli podniku jsou stanoveny jeho stavební a funkční struktury. Tento aspekt zdůrazňuje obchodní smysl vzniku a fungování podniku.

Hlavními složkami logické struktury podniku jsou takové spekulativní složky jako účel, poslání, vize, cíle podniku, jeho místo na trhu, zásady pro výběr hlavních typů jeho stavebních prvků, zásady fungování a rozvoj podniku.

V V Zachmanově matici je tento aspekt označen názvem prvního řádku „Scope“ („Účelem 1. řady je definovat hranice Enterprise, co je zahrnuto…“ ).

V Federal Enterprise Architecture (FEA) je „referenční model výkonu“.

V E2AF a v GERAM není logický aspekt explicitně rozlišován a je zahrnut v "obchodním" aspektu. Základní principy E2AF však říkají: „Žádná strategie, žádná podniková architektura... Žádný rozsah – žádná podniková architektura

Rozsah a cíle a cíle nastavují úroveň abstrakce podnikové architektury ... Ovladače podnikání, cíle a cíle vedou ...“ .

V Logický aspekt TOGAF odpovídá „vizi architektury“ („... klíčové prvky „vize architektury“- ...

poslání podniku, vize, strategie a cíle ..., zahrnují principy architektury, definují šíři pokrytí podniku, konkrétní domény architektury ...“ ).

Shrneme-li přehled logického aspektu a pomocí filozofického jazyka, lze tvrdit, že logický aspekt podnikové struktury je nezbytný k tomu, aby reprezentoval „Integrální myšlenku podniku“, „Integrální koncept podniku“, „ Integrální koncept podniku", v angličtině můžeme nabídnout - "The Notion of the Enterprise" .

4) Chronologický aspekt- společnost vzniká, funguje a v čase se mění. Minulé, současné a plánované strukturální stavy podniku by měly být zaznamenány, tj. - to je "Historie života".

V GERAM, v ISO 15704-2000, ISO 19439-2006, je navrženo mnoho fází životního cyklu pro strukturování časového aspektu: "Identifikace", "Koncepce", "Požadavky", "Návrh", "Implementace", "Provoz", "Vyřazení z provozu".

V metodika TOGAF - Architecture Development Method (ADM) - časové hledisko se odráží v sledu fází vývoje, implementace a změny samotné "Enterprise Architecture".

Schéma "3D-Enterprise" umožňuje plánovat perspektivní stavy podniku v časové dimenzi EA, včetně jednotlivých projektů a rozvojových programů. Posloupnost implementace technologických součástí (systémů) podniku může zahrnovat zejména: strategickou analýzu cílů a potřeb, návrh technických řešení, podrobnou implementaci systému řešení, implementaci řešení, využití (provoz) systému , vylepšení systému.

Obrázek 5 - Hlavní úhly pohledu na strukturu podniku

„Architekturu podniku“ lze tedy definovat jako strukturu podniku, posuzovanou jeho vedením alespoň ze čtyř hlavních hledisek (ve čtyřech hlavních aspektech) a reprezentovanou (včetně modelované) vhodnou sadou čtyř hlavní typy architektur Podniky: logické, konstrukční (strukturální), funkční a chronologické.

Za komponenty stavební architektury podniku lze považovat:

organizační architektura je organizační struktura podniku;

majetková architektura je vlastnická struktura podniku;

informační architektura je struktura souboru dokumentů (organizační, regulační, technické atd.) a podnikových informačních databází;

výrobní a technologická architektura je struktura výrobních a energetických kapacit podniku, stejně jako struktura přístrojových a automatizačních komplexů a automatizačních komplexů.

Na Komponenty funkční architektury podniku lze připsat:

struktura funkčních systémů a subsystémů podniku;

struktura obchodních funkcí a obchodních procesů podniku;

struktury toků materiálů a informací v podniku.

Obrázek 6 - Integrovaný pohled na "Enterprise Architecture"

Kromě čtyř hlavních typů podnikové architektury jsou možné další, odpovídající jiným hlediskům, například:

IT architektura je struktura souboru automatizovaných informačních systémů (informačních technologií) podniku;

Obchodní architektura je architektura podniku bez její IT architektury.

4 Jak získat a používat Enterprise Architecture

Management podniku může získat AP dvěma způsoby: prvním je vyvinout AP zaměstnanci podniku, druhým je obrátit se na externí konzultanty.

První cesta bude vyžadovat řízení podniku:

vytvoření pracovní skupiny, která se následně bude muset přeměnit na stálou architektonickou službu podniku;

výběr a pořízení hotových specializovaných počítačový program pro elektronické modelování AP a školení podnikových specialistů v jeho používání;

samostatný rozvoj a dokumentace metodické podpory AP;

samostatný vývoj AP.

Vývoj AP externími konzultanty bude vyžadovat, aby vedení podniku uzavřelo smlouvu o provedení práce:

pro přímý rozvoj AP;

o vývoji a dokumentaci metodické podpory EA;

o vytvoření architektonické služby podniku.

Počítačové programy pro elektronické modelování podnikových procesů a systémových struktur, které existují na trhu, umožňují převádět databáze elektronických modelů z jejich specializovaných formátů do formátu www a následně je publikovat na vnitřních (intranetových) stránkách podniku. To umožňuje realizovat

pohodlný a bezlicenční přístup pro manažery a specialisty podniku elektronický model AP.

Následně může vytvořená a připravená architektonická služba podniku samostatně řešit problémy modelování možností pro budoucí stav EA v zájmu přijetí vedením strategická rozhodnutí pro rozvoj podniku.

Seznam použitých zdrojů

1. Zinder E. "3D-podnik" - model strategie transformujícího se systému. "Ředitel informační služby", č. 4, 2000. http://www.sept2000.ru/articles/2008/03/03/1/.

2. Zinder E. Enterprise Architecture in Context obchodní reengineering. "Inteligentní podnikové / podnikové systémy", č. 4, č. 7, 2008.

3. Galaktionov V. Architektura systému a její místo v podnikové architektuře. "Ředitel informační služby", č. 5, 2002.

4. Danilin A., Slyusarenko A. Architektura a strategie. "Jin" a "Jang" podniků informačních technologií. M. Internetová univerzita informačních technologií, 2005.

5. Drozhzhinov V., Shtrik A. Standardizace architektury ministerstev vlády USA. PC týden/RE. č. 28, č. 31, 2005.

6. Zachman John A. Zachmanův rámec.http://www.zachmaninternational.com/

7. Úřad pro řízení a rozpočet. Federal Enterprise Architecture (FEA).http://www.whitehouse.gov/omb/e-gov/fea/

8. Schekkerman J. Extended Enterprise Architecture Framework Essentials Guide. Institute for Enterprise Architecture Developments, 2006.http://www.enterprise-architecture.info/

9. Open Group Architecture Framework (TOGAF).http://www.opengroup.org/architecture/togaf8doc/arch/toc.html

10. Generalized Enterprise Reference Architecture and Methodology (GERAM). IFIP-IFAC, 1999.

11. Ivanova I.A. Řízení: Tutorial. - M.: Nakladatelství RIOR, 2004.

Již jsme poznamenali, že neexistuje žádný singl správná definice co je podniková architektura. Různé poradenské společnosti, průmyslové asociace, profesní asociace používají k popisu tohoto konceptu mírně odlišné pojmy a metody. Navíc jsou tyto koncepty a metodiky v neustálém pohybu, takže snaha přesně popsat, co je podniková architektura způsobem, který odráží dnešní myšlení, je „střelba na pohyblivý cíl“.

Obecně řečeno, při vývoji a používání podnikové architektury je samozřejmě vhodné držet se jakékoli metodiky, která by zajistila jednotu v přístupech a vhodných sadách nástrojů pro popis architektury. Stručně uvádíme nejznámější techniky v "Techniky popisu architektury. Modely Zachmana a Gartnera, techniky META Group a TOGAF" a "NASCIO. Modely 4 + 1 a SAM. Techniky Microsoftu a další. Výběr "optimální" techniky" . Zde podrobně popisujeme naše hlavní myšlenka o konceptu podnikové architektury.

Podniková architektura je dynamický a výkonný nástroj, který pomáhá organizacím porozumět jejich vlastní struktuře a tomu, jak vykonávají svou práci a funkce. Poskytuje „mapu“ podniku a „plán cesty“ pro změny v obchodních i technologických oblastech.

Podniková architektura má obvykle podobu poměrně široké sady modelů, které popisují strukturu a funkce podniku. Důležitou oblastí použití těchto modelů je systematizace procesu plánování a poskytování informačních technologií lepší podmínky pro proces rozhodování.

Jednotlivé modely podnikové architektury jsou logicky uspořádány tak, aby společně poskytovaly stále se zvyšující úroveň detailu informace o podniku - jeho cíle a cíle realizované firemní programy a organizační struktura, systémy a data, používané technologie a všechny další oblasti zájmu.

Jedná se o poněkud nudnou a suchou definici nástroje, který může mít ve skutečnosti obrovský dopad na řešení složitých problémů a poskytnout neotřelý pohled na složité a kontroverzní situace, se kterými se v činnosti jakékoli organizace neustále setkáváme. Podnikovou architekturu není snadné vytvořit. Na druhou stranu by se potíže s tím spojené neměly přehánět. Pointa je, že jakmile bude podniková architektura vyvinuta, může přinést významné výhody.

Podniková architektura je spíše proces než statická věc. Nebudeme tvrdit, že jeho tvorba je snadná zábavná procházka. Ale přesto to může být atraktivní a v jistém smyslu uhrančivá činnost. Podniková architektura není jednoduché téma, ale v následujícím se pokusíme, aby byla méně „zastrašující a skličující“. Existující metody popisu architektury podniku, které již dnes existují, umožňují organizovat odpovídající proces za přítomnosti i minimálního množství výchozích informací intuitivním a přirozeným způsobem. Úplnost popisu architektury lze přitom postupně zvyšovat s tím, jak roste chápání předmětu popisu architektury - struktura a funkce podniku, jakož i podpůrné informační technologie.

Při návrhu podnikové architektury se musíte vypořádat s velkým množstvím dimenzí a vztahů mezi nimi, které je třeba vzít v úvahu. Není proto náhoda, že mnoho technik pro popis architektury, o kterých budeme uvažovat dále, má kořeny v takové disciplíně, jako je systémová analýza. Obecně řečeno, vývoj podnikové architektury není technický proces, který by se týkal výhradně informačních technologií. Samozřejmě, pro jeho rozvoj, zpravidla vhodné technologické nástroje, ale z velké části se jedná o nástroje, které umožňují vytvářet diagramy a texty, tzn. softwarové balíčky, které většina lidí zná. Jejich použití je dostatečné jednoduché nástroje na základě vhodných metodik však umožňuje shromažďovat základní informace o činnosti organizace, spojovat různá fakta a vyvozovat závěry, které zjednodušují a objasňují složitý rozhodovací proces, který se v podnikání opakuje každý den. Důležitější je kreativní složka tohoto procesu, o které bude řeč v přednáškách 10-12.

Dobrá podniková architektura poskytuje vyváženou analýzu faktů o organizaci a poskytuje managementu způsoby, jak studovat jejich organizace a jak fungují, pomáhá jim formulovat nové strategie a poskytuje směr v procesu plánování rozvoje, aby organizace byly v souladu s neustále se měnícími podmínkami. podmínky a priority. Bavíme se samozřejmě o střednědobých a dlouhodobých plánovacích horizontech, a to jak z hlediska obchodního, tak technologického. Dobrá podniková architektura poskytuje odezvu a flexibilitu, což se odráží ve vhodných organizačních formách, procesech, systémech, portfoliu informačních a aplikačních systémů.

Uživatelé podnikové architektury jsou poměrně velké publikum specialistů a manažerů:

• profesionály v oblasti tvorby informačních systémů, kteří se podílejí na relevantních firemních projektech pro tvorbu aplikací důležitých pro podnik;
• systémové architekty, kteří zodpovídají za tvorbu architektury jednotlivých informačních systémů;
• obchodní analytici, kteří vedou proces navrhování organizačních struktur a obchodních procesů;
• vedoucí pracovníci, kteří mají zájem o systematickou, strukturovanou analýzu problémů a příležitostí, které se otevírají pro podnikání.

Pokud se podíváte na cíle, které jsou sledovány různými přístupy k popisu architektury podniku, pak v úspěšných a správných metodách můžete najít mnoho společného:

• využít k analýze více úhlů pohledu na předmět studia (podnik a jeho informační systémy) za účelem „rozdělování a panování“ v procesu boje s objektivní složitostí reálného světa. Je důležité pochopit, že žádný jediný úhel pohledu nestačí k pochopení celku;
• za účelem zajištění procesu syntézy jsou všechny modely, které jsou součástí architektury, spojeny s jinými modely. Jsou to buď podrobnější rozklady nebo související pohledy. Toto bohatství vztahů mezi modely přímo určuje kvalitu architektury.

Než tedy budeme pokračovat, zde je další definice podnikové architektury, která je uvedena na webu www.geao.org organizace „Global Enterprise Architecture Organization“ (GEAO – Global Enterprise Architecture Organization):

"Podniková architektura popisuje způsoby, jakými se celková vize organizace odráží ve struktuře a dynamice podniku. Na různých úrovních abstrakce poskytuje jednotný soubor modelů, principů, směrnic a politik, které se používají k vytváření , vyvíjet a prosazovat systémy ve velkém měřítku a v kontextu celého podniku jako celku.

Všimněte si, že termín "systém" zde nemusí nutně odkazovat počítačový systém– může také odkazovat na organizační struktury, systémy řízení atd. Tato definice je však sama o sobě spíše abstraktní, takže se ji pokusíme přiblížit čím dál tím podrobněji.

V dalším textu využíváme informace z více zdrojů a snažíme se je sestavit v rámci nějakého integrovaného konceptu podnikové architektury, který obsahuje hlavní prvky většiny metodik. Zejména se budeme řídit doporučeními.

Již jsme poznamenali, že hnací silou podnikové architektury je holistická vize, která překračuje hranice organizace. Na Obr. 4.1, diagram navržený GEAO ilustruje různé úrovně abstrakce spojené s popisem podniku. Všimněte si, že v rámci jedné organizace existuje pouze jedna podniková architektura, ale zároveň na úrovni jednotlivých systémů mohou existovat velký počet architektury řešení. Podniková architektura pokrývá jak obchodní a IT aspekty, tak vývojové procesy, evoluci architektury a struktury správy a řízení těch procesů, které přecházejí ze současného stavu architektury do budoucího požadovaného stavu.

Viktor Galaktionov, 20.05.2002
Magazine "Director IS", #05, 2002 // Vydavatelství "Open Systems" (http://www.osp.ru/)

V moderní podmínky Zvláště důležité je neustále a správně sladit IT aspekty návrhu moderního automatizovaného podniku se současnými obchodními aspekty. To by mělo být provedeno počínaje definicí obchodní architektury podniku a vývojem systémové architektury (architektura IT), která je s ní v souladu. V tomto článku autor sdílí své praktické zkušenosti s vývojem systémových architektur pro velké banky a poskytuje konkrétní rady, jak toho lze dosáhnout, a to i pro podniky v jiných odvětvích.

Jsem geograf, ne cestovatel. Chybí mi cestovatelé. Nejsou to geografové, kdo počítá města, řeky, hory, moře, oceány a pouště. Zeměpisec je příliš důležitý člověk, nemá čas se toulat. Neopouští svou kancelář. Cestovatele ale hostí a zapisuje jejich příběhy.

Antoine de Saint-Exupery. "Malý princ". Kapitola 15. Zeměpisec

Je známo, že jakékoliv podnikání moderní společnost stále více závislý na informačních technologiích. Rozvoj určitých oblastí podnikání, například rozvoj „kartového byznysu“ v bankách, byl možný pouze díky vzniku moderních IT. To samozřejmě platí i pro podniky v jiných odvětvích. Lze tedy doufat, že prezentované zkušenosti lze bez výraznějších adaptačních snah využít v podnikání jakékoli jiné, nebankovní společnosti.
Rysy současného stupně rozvoje bankovních informačních technologií spočívají v tom, že v mnoha bankách, které si po krizi v roce 1998 dokázaly udržet své podnikání a dnes jej aktivně rozvíjejí a rozšiřují, jsou zaváděna high-tech bankovní řešení proti pozadí probíhající operace. softwarové systémy a komplexy předchozích generací, často zastaralé. Na druhou stranu, odstavení bankovního podnikání i na několik hodin, natož odstavení na jeden nebo více dní za účelem vyřazení zastaralého software a uvedení nového do provozu se ve většině případů bude rovnat ztrátě podnikání. V této situaci je v každém okamžiku nutné mít jasnou představu o aktuálním stavu všech implementovaných a provozovaných informačních systémů a stejně tak jasně chápat jejich další vývoj s ohledem na perspektivu. pro rozvoj banky, její architektury as podniková architektura. (V anglicky psané literatuře - metody, články, normy - to odpovídá termínu podniková architektura.)
Je třeba poznamenat, že podniková architektura existuje nezávisle jak na našem vědomí, tak na velikosti tohoto podniku – ať už je to globální korporace, malá továrna, malá obchodní podnik atd. Malý podnik má stejnou architekturu jako velký, přičemž se složením komponent příliš neliší. Někteří manažeři to však chápou a mohou si dovolit věnovat pozornost všem aspektům organizace vlastního podniku (zpravidla se jedná o šéfy velkých společností), zatímco jiní ne. Jiná věc je, že malý podnik může mít jen dva nebo tři produkty, poslání a strategie nejsou výslovně pevně dané (tento problém je mimochodem běžný ve velkých společnostech), počet zaměstnanců je 30 lidí a dva počítače s MS se používají ve výrobě Word 97. Ale i v tomto případě je to vše, co tvoří architekturu tohoto podniku.
Článek představuje poměrně podrobný a zároveň pragmatický přístup k organizaci práce na analýze podnikové architektury jako celku a plánování architektury systému včetně její dokumentace. Hlavními cíli dokumentování obchodních znalostí (vývoj podnikové architektury) je zajištění bezpečnosti investic do podnikání a transparentnost podnikání na všech úrovních.
Transparentnost podnikání začíná transparentním pochopením podnikové architektury, s jejím jasným rozdělením do tří vzájemně závislých úrovní: strategická úroveň, úroveň obchodní architektury, úroveň architektury systému. Architektura systému je určena obchodní architekturou a její návrh může vycházet pouze z obchodní architektury, která zase závisí na strategii podniku. Tento přístup podle našeho názoru umožňuje nejen správně zorganizovat samotnou práci a správně rozdělit funkce a odpovědnosti business architekta („business developer“) odpovědného za rozvoj podnikání, tedy obchodní architekturu podniku, a systémového architekta, ale také, co je nejdůležitější, vybudovat vyváženou podnikovou architekturu, která adekvátně odpovídá jejímu poslání a strategii.
Hlavní definice jsou uvedeny na začátku článku. Poté je zvažována skladba a obsah architektury systému, je analyzován vztah mezi entitami business architektury a systémové architektury. Fáze a účastníci životního cyklu architektury systému, zejména funkce účastníků, jsou zvažovány dostatečně podrobně. Nakonec je ve zkrácené formě prezentována struktura znalostí, na nichž je architektura systému založena, a jsou vyvozeny konečné závěry.

Základní pojmy

Podniková architektura- jedná se o nejobecnější a nejkomplexnější reprezentaci podniku, v tomto případě - banky, jako ekonomického subjektu, který má krátkodobé a dlouhodobé cíle pro výkon své hlavní činnosti, definované posláním v regionálním a globálním měřítku, v našem případě finanční a úvěrový trh a strategii rozvoje, vnější a vnitřní zdroje nezbytné k naplnění poslání a dosažení stanovených cílů, jakož i stanovená pravidla pro provozování hlavní činnosti (podnikání).
Pro účely systémové analýzy lze architekturu podniku posuzovat ve dvou aspektech:

• statické - podle stavu banky v určitém pevném okamžiku;
• dynamický - jako proces přechodu (migrace) banky ze současného stavu do nějakého žádoucího stavu v budoucnu.

Podniková architektura uvažovaná ve statice se skládá z následujících prvků:

• mise a strategie, strategické cíle a záměry;
• obchodní architektura;
• architektura systému.

Podniková architektura zvažovaná v dynamice je koherentní, soudržný akční plán a koordinované projekty potřebné k transformaci současné architektury organizace do stavu definovaného jako dlouhodobý cíl, založený na současných a plánovaných obchodních cílech a obchodních procesech organizace.

Rýže. 2.

Podniková architektura je tedy v obecném případě popsána následujícími sekvenčně závislými sekcemi (viz obr. 1 a obr. 2):

• formulované poslání a strategie banky, strategické cíle a záměry;
• obchodní architektura v současném (jak je) a plánovaném (budoucím) stavu,
• architektura systému v současném (jak je) a plánovaném (budoucím) stavu;
• akční plány a projekty přechodu ze současného stavu do plánovaného.

Na Obr. Obrázek 1 ukazuje, že implementace plánu migrace neznamená zamrznutí ve vývoji obchodní a systémové architektury. Plánovaná architektura systému je tedy architekturou „být“ pouze v určité fázi vývoje podniku. Zároveň se vraťte do strategická úroveň mise a strategické cíle a záměry neznamená nutnost revidovat misi a strategii. Ale na konci každého cyklu je nutně provedena analýza účinnosti vyvinutých a implementovaných opatření, v případě potřeby se ve druhé iteraci upraví obchodní architektura, architektura systému a implementují se nové plány migrace. V každém časovém okamžiku může existovat několik cyklů, každý takový cyklus nemusí nutně ovlivnit celý podnik jako celek, cyklus může ovlivnit určité oblasti, určité obchodní záležitosti a může být zaznamenán jako samostatný projekt.
S plánem postupné migrace je možné za účelem opravy dosažených výsledků vybudovat přechodnou (migraci) jednu nebo více architektur.
Poslání, strategie a obchodní cíle určovat směr rozvoje banky a stanovovat dlouhodobé cíle a záměry.
Obchodní architektura na základě poslání, strategie rozvoje a dlouhodobých obchodních cílů určuje potřebnou organizační strukturu, strukturu prodejních kanálů a funkční model banky, dokumenty používané při procesu vývoje a implementace produktů. Funkční model popisuje podnikové procesy zaměřené na realizaci aktuálních úkolů a dlouhodobých cílů.
Obchodní architektura zahrnuje:

• produkty a služby nabízené a plánované k prodeji bankou (včetně individuálních schémat jejich výroby), formalizované v podobě jednotného registru produktů a služeb, který obsahuje i segmentaci klientů, tarify a vlastníky produktů;
• kanály pro prodej produktů a služeb, vybudované jak na základě strukturálního a teritoriálního členění banky, tak na bázi moderních informačních technologií;
• funkce a procesy pro implementaci externích a interních produktů a služeb, tvořící stromy funkcí a procesů (dále jen obchodní funkce a obchodní procesy);
• finanční a administrativní dokumenty (v papírové i tištěné podobě). v elektronické podobě), formalizované ve formě jednotného registru (alba formulářů) bankovních dokumentů;
• definovány toky dokumentů předpisy o interním a externím toku dokumentů;
• organizační struktura vč personální obsazení banka a její územní jednotky, které jsou samostatnými ekonomickými jednotkami ( právnické osoby), výbory, pracovní skupiny a role funkcí jednotlivých zaměstnanců, pracovní náplň, předpisy o útvarech a pracovních orgánech a další dokumenty upravující vztah a rozdělení odpovědnosti mezi zaměstnance banky, jakož i mezi strukturální dělení sklenice.

Architektura systému(IT architektura, podniková architektura IS) - definuje soubor technologických a technických řešení k zajištění informační podpora bankovní operace v souladu s pravidly a koncepty definovanými obchodní architekturou.
Dále pod „řešením“ budeme v závislosti na kontextu rozumět nejen konkrétní zařízení a software a informační systémy, ale také principy, standardy a metodiky používané při vývoji nebo výběru informačních a softwarových systémů, při výběru a konfiguraci. vybavení.
Migrační plány určit scénář přechodu banky ze současného stavu do perspektivního, určený strategickými záměry a záměry. Migrační plány definují transformace obchodní i systémové architektury. Při postupné migraci se pro účely formalizace průběžných výsledků vyvine střední (migrace) jedna nebo více obchodních a systémových architektur. Migrační plány v souladu s metodikou projektového řízení přijatou bankou jsou formalizovány jako samostatné projekty, mezi které patří zejména:

• definice projektu jako souboru úkolů a činností;
• fáze a termíny realizace projektu jako celku a úkoly a činnosti tvořící projekt;
• analýza konkurenčního prostředí a rizik spojených s realizací projektu;
• složení výdajových položek rozpočtu projektu;
• kritéria úspěšnosti projektu a očekávaný ekonomický efekt.

Architektura systému

Architektura systému se skládá ze tří vzájemně propojených komponent – ​​aplikační architektury, datové architektury a technické architektury (viz obrázek 3). Architektura systému v systému standardů daného podniku určuje pravidla pro tvorbu jeho součástí a zajištění vzájemného působení mezi nimi.

Rýže. 3.

Komponenty systémové architektury

Architektura aplikace zahrnuje:

• aplikační systémy (aplikace), které zajišťují provádění obchodních funkcí a obchodních procesů;
• rozhraní pro interakci aplikačních systémů mezi sebou navzájem as externími systémy a datovými zdroji nebo spotřebiteli;
• nástroje a metody pro vývoj a údržbu aplikací.

Datová architektura zahrnuje:

• automatizované databáze, které poskytují shromažďování, ukládání a zpracování dat určených obchodní architekturou;
• systémy pro správu databází nebo ukládání dat používané pro tento účel;
• pravidla a prostředky pro autorizaci přístupu k datům.

Technická architektura sestává ze síťové architektury a architektury platformy.
Architektura sítě zahrnuje:

• místní a teritoriální počítačové sítě, včetně fyzických vlastních a pronajatých komunikačních kanálů a zařízení pro tvorbu kanálů;
• komunikační protokoly, služby a adresovací systémy používané v sítích;
• havarijní plány pro zajištění nepřetržitého provozu sítí v mimořádných situacích.

Architektura platformy zahrnuje:

• počítačový hardware - servery, pracovní stanice, mechaniky a další počítačové vybavení;
• Operační a řídicí systémy, utility a kancelářské softwarové systémy;
• havarijní plány pro zajištění nepřetržitého provozu zařízení (zejména serverů) a databází v havarijních podmínkách.

K řešení problémů systémové architektury ve stavu společnosti zpravidla specializovaný Služba systémového architekta. Tato služba je zodpovědná za následující úkoly:

• koordinace práce IT oddělení na dokumentaci aktuální systémové architektury v počáteční fázi a následné udržování znalostní báze o architektuře systému na aktuální úrovni;
• stanovení perspektivních směrů rozvoje systémové architektury v souladu se strategickými cíli a záměry banky, detailně rozepsaných do podoby perspektivní business architektury;
• navrhnout (spolu s dalšími specializovanými útvary informačních technologií) perspektivní architekturu systému a plány na migraci ze současného stavu do budoucnosti;
• formulace požadavků a omezení na vytvářené nebo implementované automatizační nástroje, které zajišťují kvalitu a integritu architektury systému;
• kontrola konzistence systémových architektur vyvinutých v rámci různých projektů;
• sledování plnění požadavků na zajištění kvality a integrity systémové architektury ze strany útvarů banky podílejících se na vývoji, údržbě a provozu informačních systémů.

Samostatně bychom se měli zabývat jednou základní otázkou: kdo vyvíjí architekturu systému - systémový architekt nebo vývojář softwaru, technolog. Správné rozhodnutí je, když je odpovědnost za vývoj systémové architektury přidělena IT oddělením, která navrhují, vyvíjejí, testují, udržují (včetně vyřazování z provozu) softwarové a hardwarové systémy a komplexy. Dokumentace architektury systému je součástí povinné projektové a provozní dokumentace. Tento přístup vám umožňuje vytvořit službu malého architekta systému. V opačném případě vývoj systémové architektury dedikovanou službou vyžaduje výrazné zvýšení počtu systémových architektů a vývojové procesy se buď velmi zpomalí, nebo se vyvíjená systémová architektura stane neadekvátní již v procesu svého vývoje.

Vztahy mezi architekturou systému a architekturou podnikání

Podniková architektura je plně popsána následujícími subjekty (viz obrázek 4):

1. Poslání a strategie banky, strategické cíle a záměry.
2. Produkty a obchodní procesy.
3. Dokumenty.
4. Organizační struktura.
5. Aplikace.
6. Data.
7. Zařízení.
8. Akční plány a projekty přechodu ze současného stavu do plánovaného.

Rýže. 4. Vzájemný vztah entit nejvyšší úrovně podnikové architektury

Na Obr. 4 zobrazuje pouze entity nejvyšší úrovně. Každá z entit se rozpadá na sadu podrobnějších entit. Pouze entita „Produkty“ se tedy nakonec rozloží do více než deseti tabulek, včetně skupiny potravin, tarifní plány, cílové segmenty klienty atd.
Je zřejmé, že mezi všemi těmito entitami existují silné vztahy. Například implementace produktu je doprovázena určitými dokumenty, podpořenými informační podporou určitými aplikacemi a moduly, které využívají určité databáze. Na implementaci tohoto produktu se podílejí různí zaměstnanci a oddělení. Produkt má vlastníka.

Rýže. 5. Podniková architektura a místo systémové architektury v ní

Na Obr. Obrázek 5 poskytuje zvětšené grafické znázornění podnikové architektury a jejích definujících komponent.
Příklad klíčových vztahů mezi hlavními prvky podnikové architektury a architektury systémů je na Obr. 6 ve formě ER diagramu.

Rýže. 6.

Esence a vztahy dvou architektur

Životní cyklus architektury systému

Pro regulaci životních cyklů (LC) systémů obecně (včetně podniků) a zejména jejich informačních systémů a softwaru (PS) existuje řada norem. Poskytují možnost přizpůsobení modelů životního cyklu včetně fází (fází) specifikům konkrétního podniku a projektu. Fáze životního cyklu popsané v této a dalších částech tedy nejsou v rozporu s normativními a nejsou dogmatem. Jejich výhodou z hlediska použití v tomto článku je jednoduchost a zkušenost s praktickou aplikací.

Rýže. 7.

Životní cyklus architektury systému se skládá z následujících fází: (viz obrázek 7):

• výchozí dokumentace;
• používání;
• design;
• migrace.

POZNÁMKA. Po dokončení fáze migrace se proces opakuje, další iterace začíná fází používání. Může chybět počáteční dokumentační fáze při vývoji nového IS. Vývoj architektury systému začíná fází návrhu.
Během fáze používání, evoluční vývoj architektura systému v souladu s dříve formulovanými principy a beze změny hlavních technických a technologických řešení.
PŘÍKLAD. Nechte systémovou architekturu programu údržby vyvinout ve fázi návrhu účetnictví v centrále a pobočkách a implementována (fáze migrace). Znalosti o systémové architektuře tohoto řešení přecházejí do fáze používání, dokud nevzniknou nové obchodní požadavky na dostavbu / modernizaci vybudovaného systému. Znalost systémové architektury vytvořeného řešení využívá společnost k vybudování datového skladu za účelem konsolidace informací a následného příjmu manažerského reportingu. Ale na základě těchto znalostí je navržena systémová architektura datového skladu a následně systémy management reportingu, které následně po prodělaných fázích migrace vstupují do fází používání. Lze tedy hovořit o modelu vícevrstvé systémové architektury, ve kterém se architektura systému v různých vrstvách může nacházet v různých fázích životního cyklu (viz obr. 8).

Rýže. osm.

Ve fázi návrhu se uskutečňuje vývoj perspektivní (budoucí) systémové architektury, formulují se nové principy pro konstrukci systémové architektury a vyvíjejí se nová základní technická a technologická řešení v souladu s těmito principy. Obvykle je důvodem provedení této fáze významné změny v business architektuře vznik nových obchodních požadavků, které významně ovlivňují architekturu systému.
Ve fázi migrace je proveden soubor organizačních, technických a technologických opatření k zajištění přechodu architektury systému ze současného stavu do perspektivního nebo do dalšího mezistavu při fázované migraci v souladu s migračními plány zpracovanými v r. předchozí fáze.
Životní cyklus architektury systému souvisí s životním cyklem softwaru. Životní cyklus softwarových nástrojů (PS) se skládá z následujících hlavních fází:

• studie proveditelnosti;
• vývoj technických specifikací;
• rozvoj technický projekt;
• vývoj a dokumentace PS;
• PS testování;
• zavedení PS;
• provoz rozvodny;
• vyřazení PS.

Architekt systému řídí rozhodnutí o návrhu během životního cyklu softwaru. Kontrola je prováděna formou koordinace projektových dokumentů zpracovaných a zaslaných systémovému architektovi útvary odpovědnými za realizaci té či oné fáze životního cyklu PS.
Jsou uvedeny popisy fází životního cyklu architektury systému, rozsah prací na architektuře systému provedených v každé fázi, vykonavatelé těchto prací a také korespondence s fázemi životního cyklu PS. níže.

Počáteční dokumentace

Fáze životního cyklu systémové architektury "Počáteční dokumentace" nemá přímou shodu ve fázích životního cyklu softwarových nástrojů. Obsahově je tato fáze reprezentována funkcemi jejích aktivních účastníků (viz tabulka 1).

Stůl 1.

Používání

Fázi životního cyklu systémové architektury „Užití“ odpovídají následující fáze životního cyklu softwarových nástrojů:

• Vývoj technických specifikací pro PS.
• Vývoj technického návrhu PS.
• PS testování.

(Viz pozn., obr. 8 a příklad výše. Z příkladu můžeme vidět, že vývoj TOR, TP, testování a implementace datového skladu a manažerského reportingového systému využívají znalosti systémové architektury účetního systému v komerčním provozu a jehož systémová architektura je v současné době ve fázi používání, zatímco architektura systému datového skladu je v současné době ve fázi návrhu.)
Funkce jeho aktivních účastníků ve fázi „Užití“ jsou uvedeny v tabulce. 2.

Tabulka 2

Design

Zde může vyvstat otázka: kam se poděl vývoj problémového prohlášení? A je to vůbec potřeba? Fáze životního cyklu systémové architektury „Design“ odpovídá následujícím fázím životního cyklu softwarových nástrojů:

• Příprava technických specifikací pro PS.
• Příprava technického návrhu PS.

Samozřejmě potřebujeme, řečeno oficiální řečí, fázi „Analýza objektu automatizace“, včetně vypracování prohlášení o problému, formulace obchodních požadavků, a taková fáze samozřejmě existuje. Podrobná diskuse o těchto problémech však přesahuje rámec článku, který se omezuje na zvážení architektury systému.
Dovolte mi to však vysvětlit. Potřeba změnit podnikání a v důsledku toho potřeba restrukturalizace obchodní architektury může být způsobena:

1. změny mise nebo strategie;
2. změny situace na trhu;
3. regulační orgány.

Po uvědomění si této potřeby dochází k formulaci obchodních požadavků, ale to vše se děje, když jsme stále ve vrstvě obchodní architektury (viz obrázek 4). Šipky z entit "Produkty" a "Dokumenty" směřující k entitám "Zařízení", "Programy" a "Data" odpovídají prohlášení o problému (obchodním požadavkům). Vraťme se k našemu příkladu, ze kterého vidíme, že vývoj TOR, TP, testování a implementace datového skladu využívají znalosti o systémové architektuře účetního systému, který je již v komerčním provozu a jeho systémová architektura je v současnosti v fáze použití. Systémová architektura datového skladu je aktuálně ve fázi návrhu (viz obrázek 8).
Funkce aktivních účastníků ve fázi „Design“ jsou uvedeny v tabulce. 3.

Tabulka 3

Migrace

Fáze životního cyklu systémové architektury „Migrace“ odpovídá následujícím fázím životního cyklu softwarových nástrojů:

• Testování softwaru.
• Implementace softwaru.

Funkce aktivních účastníků ve fázi „Migrace“ jsou uvedeny v tabulce. čtyři .

Tabulka 4

Architektura systému je tedy skutečně ovlivněna v následujících fázích životního cyklu softwaru:

• Ve fázi „Vývoj technických specifikací pro PS“ je provedena analýza stávající systémové architektury s cílem možnosti a účelnosti využití stávajících zdrojů k řešení nově nastavených obchodních problémů. Kromě toho se při přípravě zadání berou v úvahu požadavky a omezení vyplývající ze stávající systémové architektury, kdykoli je to možné.
• Ve fázi "Vývoj technického návrhu PS" probíhá vlastní tvorba nebo změna architektury systému, která je nezbytná pro realizaci nově nastavených obchodních úkolů. Požadavky a omezení vyplývající ze stávající systémové architektury jsou brány v úvahu, aby byla zajištěna kontinuita a minimalizovány náklady na upgrade.
• Na fázích "Testování" a "Implementace" vyvíjeného softwaru jsou požadavky systémové architektury využity k vytvoření potřebného technologického prostředí pro testování a provoz těchto PS.

Složení znalostní báze o architektuře systému

Protože pouze seznamy toho, co potřebujete vědět o architektuře systému, jsou velmi rozsáhlé pro prezentaci v článku v časopise (jedná se o desítky pozic), níže jsou popsány pouze části příslušné znalostní báze a je učiněn pokus alespoň nastínit obsah těchto oddílů.
Znalostní báze architektury systému by se měla skládat alespoň ze tří částí:

1. Současná architektura systému.
2. Perspektivní (plánovaná) architektura systému.
3. Migrační plány.

Sekce "Současná architektura systému" a "Prospektivní architektura systému" mají stejnou strukturu a sestávají z následujících podsekcí:

1. Principy architektury stavebního systému.
2. Základní technická a technologická řešení.
3. Požadavky a normy.
4. Aplikovaná architektura.
5. Technická architektura.
6. Datová architektura.

Stavební principy

Jsou uvedeny požadavky a omezení kladené na architekturu systému ze strany obchodní architektury. Jsou uvedeny všechny požadavky a omezení - jak formulované přímo v business architektuře, tak i dodatečné formulované systémovým architektem.
Je uveden popis principů budování systémové architektury vyplývající z výše uvedených požadavků a omezení.

Zásadní rozhodnutí

Jsou popsána hlavní technická a technologická řešení, která tvoří základ architektury systému. Může se například jednat o rozhodnutí použít počítač AS/400 jako hlavní hardwarovou platformu pro informační systém banky nebo rozhodnutí použít DB2 DBMS jako hlavní nástroj pro správu informačních zdrojů banky.
Každé rozhodnutí je doplněno komentářem vysvětlujícím jak toto rozhodnutí odpovídá výše formulovaným principům budování systémové architektury.
Hlavní rozhodnutí učiněná při návrhu architektury systému jsou zpracována v samostatných dokumentech se stručným shrnutím pozadí, podstaty problému a přijatého zásadního řešení problému, které je v budoucnu povinné při navrhování, vývoji a implementaci informačního systému.

Požadavky a normy

Jsou specifikovány všechny požadavky, normy a omezení, kterým architektura systému vyhovuje. V případě potřeby lze jednotlivé normy (požadavky, omezení) nebo odkazy na ně duplikovat v následujících kapitolách.
Jsou uvedeny odkazy (kód, název, vydání atd.) na externí normy. V případě potřeby jsou uvedeny úplné nebo částečné texty vnějších norem.
Jsou popsány interní standardy (podnikové standardy) s uvedením kódu (pokud byl přidělen), názvu, vydání a schvalovacího orgánu.
Jsou popsány další požadavky a omezení, které musí splňovat architektura systému a prvky informační infrastruktury, které nezískaly status standardu.
Je vysvětleno, které konkrétní principy budování systémové architektury nebo přijatá základní technická a technologická řešení si vyžádaly použití / zohlednění této normy / požadavku nebo omezení.

Architektura aplikace

Jsou popsány aplikované systémy (aplikace), které zajišťují výkon podnikových funkcí a podnikových procesů a jejich interakce. Úroveň podrobnosti popisu by měla odpovídat programovému modulu, chápanému jako programová jednotka, samostatně uložená jako soubor nebo sekce knihovny.

Technická architektura

Architektura sítě

Obsahuje popisy územní komunikační infrastruktury a místních sítí (LAN).

Architektura platformy

Obsahuje popis operačních systémů a zařízení zvlášť pro servery a pracovní stanice.

Datová architektura

Databáze a datová úložiště

Obsahuje popis databází a jinak organizovaných informačních polí.

Systémy pro správu databází

Obsahuje popis používaných systémů správy databází.

Plán migrace

Obsahuje plán migrace ze současné architektury systému do budoucnosti.
Pokud se očekává postupná migrace, jsou zde zahrnuty i přechodné plány migrace.
Jak již bylo zmíněno dříve, migrační plán je formalizován jako návrh. U každého plánu tak tato část obsahuje všechny dokumenty stanovené metodikou projektového řízení banky, schválené i připravované či schvalované.

Závěr

Výše jsme ukázali, že složení a obsah znalostí o architektuře systému je hluboce strukturovaný soubor vysoce propojených informací. Vztahy se navíc neomezují na vztahy mezi entitami systémové architektury (viz obr. 3), ale úzce souvisí i s entitami podnikové architektury. V praxi je tedy často nutné najít odpověď na následující otázky:

• Kdo v bance vykonává tu či onu obchodní funkci, jak pravidelně, jaká událost způsobuje výkon této obchodní funkce, je automatizovaná či nikoli, nebo je výkon této obchodní funkce vykonáván?
• Jaké informace jsou vstupem pro konkrétní obchodní funkci, kdo je dodavatelem těchto informací, v jaké formě přicházejí?
• Jaké softwarové nástroje se používají k provádění konkrétní obchodní funkce, jaké další funkce IT tyto programy provádějí, jaké databáze a adresáře se používají, jaké obrazovky a jaké zprávy program generuje?
• Jaké informace jsou pro konkrétní program příchozí a odchozí, v jaké formě přicházejí příchozí a odchozí informace?
• Jak je organizována informační interakce dvou programů: prostřednictvím vytvoření / čtení souboru, přímo prostřednictvím API, prostřednictvím e-mailu, prostřednictvím systémů na úrovni middlewaru, jaká je struktura výměny informací, jaká je frekvence?
• Která oddělení používají konkrétní program, kdo musí být upozorněn, když se program nebo jakékoli nařízení změní?
• Je ta či ona IT funkce programu aktuálně využívána, kým, jak často?

Samozřejmě existuje také mnoho dalších problémů, které nějak souvisí se systémovou a obchodní architekturou.
Vzhledem k omezené velikosti článku v časopise je analýza těchto problémů nad jeho rámec. Podotýkáme pouze, že pro strukturování a dokumentaci těchto znalostí jsou nepostradatelné možnosti MS Word nebo MS Excel. Nutno použít pokročilejší softwarové systémy, ale ještě důležitější je použití vhodných technik nebo dokonce metodik. Jedním z těchto návodů, který dle zkušeností autora splňuje potřebné požadavky, je „metodika ARIS“ (ARchitecture of Integrated Information System). To je však úplně jiné téma, snad na jiný článek.

V mnoha ohledech je ospravedlnění potřeby vyvinout model obchodní architektury spojeno s pochopením faktorů, které tlačí podnik k hledání optimalizačních řešení v oblasti organizování činností. Tyto faktory mohou zahrnovat makroekonomické trendy, konkurenční prostředí, změny v obchodních strategiích atd. Znalost těchto faktorů a jejich propojení se schopnostmi modelování obchodní architektury pro řešení problémů je zásadní pro podporu projektu u nejvyššího vedení organizace.

Problém zdůvodnění potřeby a rozpočtů projektu na vytvoření modelu obchodní architektury je spojen nejen s identifikací „hnacích“ faktorů, ale také se složitostí doložení očekávaných efektů. V mnoha případech je v počáteční fázi možné deklarovat pouze odhady týkající se nepřímého zlepšení podnikání organizace, které je obtížné srovnávat s jasně definovanými finančními přínosy. I v případě výskytu událostí s kvantifikovatelnými dopady není vždy možné prokázat přímou souvislost těchto událostí s konstrukcí a implementací modelu obchodní architektury v procesu řízení organizace.

Je obtížné poskytnout nějaké obecné přístupy k doložení očekávaného ekonomické efekty v důsledku vzniku skutečného modelu obchodní architektury v organizaci. V mnoha ohledech je konečný zisk určen jedinečností situace každé konkrétní organizace. Může to být úspěšný reengineering podnikových procesů, optimalizace informační a technologické infrastruktury, snížení času a nákladů na získávání počátečních dat při spouštění projektů apod. realizované na základě využití modelu.

V nejobecnějším přístupu by účinky vytvoření modelu obchodní architektury měly být umístěny se zvýšením celkové ovladatelnosti podniku. Pokud jde o IT složku podnikové architektury, světová praxe ukazuje možnost snížení nákladů na zaměstnance až o 30 %, přičemž absence dokumentované IT architektury s sebou nese dodatečné náklady až 12–18 % v řadě provozních oblasti.

Je-li nutné získat odhady o „integrálních“ účincích implementace modelu obchodní architektury, zohlednění pouze finančních přínosů nebude pro ospravedlnění investice dostatečné. Proto bude nutné využívat složitější mechanismy vypořádání, včetně „nefinančních“ efektů, které jsou pro činnost organizace významné. Tento typ efektů by měl zahrnovat minimalizaci rizik během různých změn v činnostech organizace využitím schopností modelu obchodní architektury k simulaci různých variant scénářů, včetně získání různých kvalitativních a kvantitativní hodnocení. Vzhledem k vysoké dynamice změn a složitosti moderní organizace Zvláště důležité jsou otázky minimalizace rizik spojených s otázkami restrukturalizace.

Charakteristickým rysem investičních projektů pro vytvoření modelu obchodní architektury je poměrně dlouhá čekací doba na jasně pozorované efekty. Do jisté míry zde můžeme nakreslit analogii s očekáváním návratnosti nákladů na školení zaměstnanců pro zlepšení celkové informační či projektové kultury. V rámci zdůvodnění efektivity architektury IT komponent jsou v současné době zvažovány možnosti využití ukazatelů jako je návratnost aktiv (ROA) a návratnost příležitosti.

Jednou z úvodních standardních otázek od vedoucích organizací, kteří dříve nebyli obeznámeni s možnostmi a úkoly modelování podnikových procesů, je objasnění očekávaných přínosů z výsledků modelovací poradenské práce.

Často jsou standardní odpovědi na tyto otázky spojeny s důrazem na optimalizaci podnikových procesů organizace a v souladu s tím uvedením „základní sady“ optimalizačních parametrů:

♦ duplikace funkcí;

♦ úzká místa;

♦ nákladová střediska;

♦ kvalita jednotlivých operací;

♦ nadbytečné transakce;

♦ možnosti automatizace;

♦ možnost zavedení systémů managementu kvality;

♦ možnost certifikace dle ISO 900x.

Při vší správnosti těchto odpovědí je třeba uznat, že z hlediska návaznosti práce a dosahování výsledků nejde o nejvyšší priority.

Zcela samostatný, důležitý a první, kterého se dosáhne, je výsledek týkající se uspořádání a dokumentace znalostí o organizaci. V rámci vytváření modelu nevyhnutelně dochází k následujícím procesům:

♦ inventarizace a získávání z různých zdrojů (včetně jednotlivých kvalifikovaných zaměstnanců) informací (znalostí) specifických z hlediska činnosti organizace;

♦ strukturování a systematizace extrahovaných informací s přihlédnutím k hlavním cílům a záměrům organizace;

♦ formalizace a dokumentace informací (znalostí) o organizaci.

Je zřejmé, že bez ohledu na cíle optimalizace jsou kvalitativní akumulace, strukturování a formalizace informací (znalostí) velmi důležité z hlediska:

♦ technologická podpora procesů uchování know-how organizace;

♦ snížení závislosti na klíčových odborných zdrojích při přenosu znalostí a kompetencí na nové zaměstnance;

♦ zvýšení úrovně ovladatelnosti organizace prostřednictvím formalizace pracovní požadavky a pokyny pro zaměstnance.

Zpravidla po systematizaci a formalizaci poznatků o aktuálním stavu činnosti organizace, ještě před popisem procesů a volbou metody jejich optimalizace (reengineering), jsou na základě specializovaných modelovacích nástrojů identifikovány organizační a technologické rezervy, které lze použít ke zlepšení efektivity organizace.

Ve fázi systematizace a formalizace se provádí vlastní ověření dostupnosti a jasnosti definice a v případě potřeby objasnění tak důležitých údajů pro organizaci, jako jsou:

♦ úkoly;

♦ ukazatele výkonnosti;

♦ předpisy (pokyny, příkazy atd.) obchodních procesů.

V řadě případů lze říci, že normativní směrnice jsou z hlediska kvality provedení stejně tak proveditelné a ověřitelné, jako jsou formalizovatelné. V tomto smyslu je ve fázi systemizace a formalizace kontrolována „funkčnost“ cílů a předpisů (norem).

Správnou odpovědí potenciálního zákazníka na otázku „proč potřebujeme model“ obchodní architektury organizace je proto uvést alespoň dva zásadně důležité výsledky (cíle):

♦ systematizace a dokumentace (formalizace) informací (znalostí) významných pro činnost, která zajišťuje:

a) technologický základ pro vnitropodnikové uchovávání a dostupnost specializovaných znalostí (know-how) organizace;

b) zvýšení úrovně řiditelnosti zdrojů organizace díky kvalitativní formalizaci předpisů pro jejich použití (obr. 1);

Rýže. 1. Problémy managementu znalostí v organizaci z hlediska podnikových procesů

♦ vytvoření metodického a technologického základu pro etapovou optimalizaci (reengineering) organizace, která umožňuje provádět technicko-ekonomické posouzení modernizačních opatření, identifikovat organizační, funkční a technologické rezervy pro zvýšení efektivity organizace (obr. 2).

Rýže. 2. Slibná rozhodnutí o využití znalostí o podnikových procesech při tvorbě manažerská rozhodnutí

Jedním z dalších argumentů ve prospěch potřeby modelovat obchodní architekturu organizace jsou globální trendy ve standardizaci požadavků na povinnou přítomnost modelů podnikových procesů organizace. Důkazem těchto trendů je vznik specializovaných standardů a metodik pro návrh podnikové architektury.

Jako hlavní metodiky a standardy bychom měli zmínit „rámcové“ standardy pro vývoj podnikové architektury;

a) ISO 15704 - norma pro formální popis podnikové architektury, která byla navržena pracovní skupinou IFAC / IFIP (Mezinárodní federace automatického řízení / Mezinárodní federace pro zpracování informací);

b) ISO 15288 je standard, který definuje životní cyklus systémy;

c) ISO 12207 je norma, která definuje životní cyklus softwaru.

Existuje více než 30 dalších „podpůrných“ systémů a standardů softwarového inženýrství (např. ISO 14258 definující koncepty a pravidla pro podnikové modelování).

Vývoj modelu obchodní architektury je jedním z logických dalších kroků pro ty organizace, které začaly implementovat koncept architektury orientované na služby (SOA). SOA ve svém jádru reflektuje rysy současné moderní situace ve vzájemném pronikání IT a byznysu, kdy je extrémně obtížné stanovit hranici mezi obchodními funkcemi organizace a informačními technologiemi, které je zajišťují.

Z pohledu podpory SOA je model obchodní architektury hlavním nástrojem pro synchronizaci obchodních potřeb a schopností informačních technologií. Právě model podnikové architektury nese hlavní břemeno zajištění podmínek pro procesní přístup k návrhu a optimalizaci samotné podnikové architektury organizace a následně návrhu IT. Podle konceptu SOA by obchodní architektura měla být založena na procesně orientovaném podnikovém modelu. Kombinace tohoto přístupu s konceptem servisně orientované architektury informačních technologií umožňuje lépe propojit proces vývoje komponent informačních systémů s posláním, hlavními úkoly a funkcemi organizací. Díky SOA mají organizace potenciál vyvinout sadu implementací různých obchodních procesů, které může podnik znovu použít jako hotové služby.

Zadání úkolů pro modelování business architektury v kontextu podpory SOA je zaměřeno na zajištění následujících požadavků na návrh IS:

♦ explicitní oddělení obchodní logiky aplikovaného systému od logiky prezentace informací;

♦ implementace obchodní logiky aplikovaného systému ve formě řady programových modulů (služeb), které jsou dostupné zvenčí (uživatelům a dalším modulům), nejčastěji v režimu „žádost-odpověď“, prostřednictvím dobře- definovaná formální přístupová rozhraní.

„Spotřebitel služby“, kterým může být aplikační systém nebo jiná služba, má zároveň možnost volat službu prostřednictvím rozhraní pomocí vhodných komunikačních mechanismů a také jasně umisťuje své místo v obchodním procesu.

Kromě role „poskytování“, konkrétně podpory implementace konceptu SOA, má model obchodní architektury samostatný význam a odpovídající definice úkolů. Vysoká dynamika změn prostředí moderní podnikání, nemůže nemít silný vliv na rychlost a rozsah rozvoje obchodního modelování. Vytváření dlouhodobých předpovědí na základě stability situace není možné téměř v žádné oblasti podnikání. Naopak, společnosti se musí přizpůsobovat neustále se měnícímu prostředí a rozvíjet dovednosti, aby se rychle přizpůsobily probíhajícím obchodním změnám. V tomto ohledu jsou v současné době vyvíjeny koncepce organizací, které obsahují speciální vnitřní mechanismy, které je umožňují měnit v souladu s požadavky vnějšího prostředí.

Rostoucí role business modelingu je dána nejen vysokou dynamikou prostředí „životní aktivity“ organizace, ale také okolnostmi, které má zdroj příležitostí efektivně reagovat na „výzvy“ trhu pouze pomocí IT. byla výrazně snížena. Stále častěji se objevují prohlášení, že chaos nelze automatizovat, že automatizace chaosu je ještě větším chaosem, že moderní IT nelze považovat za všelék na všechny obchodní problémy.

Hlavní rezervy pro zvýšení efektivity a konkurenceschopnosti podniků jsou v současnosti spojeny s optimalizací jejich podnikové architektury, důslednou implementací modelu procesního řízení a zajištěním flexibility. Organizační struktura a podnikových procesů souvisejících s řízením přidané hodnoty atd. Tyto příležitosti do značné míry poskytuje podrobná podniková architektura podniku, která by měla obsahovat jak popis procesů změny organizace činnosti podniku, tak poskytovat efektivní řízení tyto procesy.

Vývoj modelu obchodní architektury umožňuje podniku poskytnout univerzální nástroj, který přispívá především k povědomí o jeho vlastní struktuře a metodách organizace. výrobní procesy. Tento model vám umožňuje vytvořit plán na podporu organizace v oblasti podnikání a nově vznikajících technologií.

Dobře navržená architektura může a měla by být použita managementem podniku ke studiu principů jeho fungování a také umožňuje vyvíjet nové, pokročilejší strategie, organizovat nové způsoby plánování rozvoje s ohledem na potřeba plnit neustále se měnící vnější podmínky (hovoříme samozřejmě o plánování ve střednědobém a dlouhodobém horizontu). Taková architektura umožňuje rychlou odezvu a flexibilitu, která je dána volbou vhodných forem organizace, speciálním propracováním procesů a využitím určitých tříd informačních systémů.

Na podporu těchto tezí o úloze a místě obchodního modelování můžeme citovat prohlášení analytika Gartner Jima Sinura (Jim Sinur): modelování v poslední době“. Obecně je třeba poznamenat, že pro různé názor odborníka většina podniků povede projekty, které se tak či onak budou zabývat různými aspekty problému zlepšování podnikových procesů, a to navzdory smíšeným hodnocením postupů reengineeringu podnikových procesů v polovině 90. let.

Kromě metodických inovací a trendů ve vývoji obchodní organizace a IT je vývoj trhu pro potřeby business modelingu významně ovlivněn moderní přístupy posouzením úrovně rozvoje (vyspělosti) organizace. V rámci těchto přístupů je model obchodní architektury povinným prvkem pro hodnocení organizace.

Jako příklad metodiky používané ve vyspělých zemích pro hodnocení vyspělosti veřejných organizací lze uvést model US Financial Control Administration, který definuje pět úrovní vyspělosti.

Využití obchodního modelu v činnostech organizace otevírá široké možnosti pro kvalitativní i kvantitativní hodnocení její efektivity, včetně využití obecně uznávaných (standardizovaných) metodik a nástrojů. Ve skutečnosti vám obchodní model umožňuje zajistit měřitelnost klíčových charakteristik organizace pomocí vhodných metrik: metriky pro hodnocení „kvality“ samotného procesu, metriky pro hodnocení přímých výsledků (output), metriky pro hodnocení konečných výsledků .

Metriky na úrovni procesu měří efektivitu samotného procesu. Typickými metrikami jsou doba cyklu, náklady na transakci nebo výstup procesu. Metriky výsledků hodnotí schopnost procesů produkovat produkt nebo službu jako výstup podle specifikací. Typickými metrikami pro vyhodnocování přímých výsledků jsou procento chyb a počet požadavků obsluhovaných za jednotku času. Metriky hodnocení výsledků hodnotí proces z pohledu koncového uživatele (zákazníka) a plnění funkcí organizace.

Je zřejmé, že úkoly modelování pro výrobní (obchodní) organizaci se mohou výrazně lišit od úkolů státního kontrolního (dozorového) orgánu. Z tohoto důvodu je samozřejmě nutné specifické přizpůsobení každé z vysokoúrovňových metod oblasti modelování. Trh poradenských služeb na tuto potřebu zcela adekvátně reaguje. V současné době tedy existují prakticky významné modely pro různá odvětví hospodářství a státní úřady, které jsou implementovány na základě různých metodik a modelovacích nástrojů, jako je metodika ARIS a na ní založená rodina softwarových produktů IDS Sheer AG, jazyk UML modelování a Rational Rose nástroj pro vývoj objektově orientovaných informačních systémů od IBM, metodika IDEF, DFD a AllFusion Modeling Suite (dříve BPwin a ERwin) od Computer Associates atd.

Nepochybně, když si podnik stanoví úkoly svým vlastním způsobem, mezinárodní certifikace a vstupu na trhy vyspělých zahraničních zemí je důležitý zejména rozvoj modelů podnikových procesů. Z tohoto důvodu není zahájení těchto prací v podniku „poctou“ nové „módě“. Bezpochyby bude tvorba a následná podpora modelů nejen pozitivní vliv na celkové image organizace, ale také pomůže zlepšit celkovou kulturu řízení a výroby podniku. Do jisté míry probouzející se zájem orgánů státní moc(OGV) a modelování podnikových procesů lze srovnat s dřívějším a široce používaným procesem zavádění metod a technologií projektového řízení.

Je třeba poznamenat, že OGV Ruské federace, které jsou odpovědné za formování vědeckotechnické politiky v různých oblastech, provádění správních reforem, reagovaly na výše uvedené globální trendy spíše „citlivě“ a stanovily si cílové úkoly k jejich zvážení. v Ruské federaci.

Stav formalizace a na jejím základě optimalizace administrativních a řídících procesů OGV je definován v dokumentu „Strategie rozvoje a využití informačních a komunikačních technologií v Ruské federaci“ jako hlavní indikátory plánovaných aktivit. Níže uvedená tabulka odráží současný stav, vyhlídky a státní politiku při zavádění obchodního modelování do činnosti OGV Ruské federace (tabulka 1).

Taková zvýšená pozornost státních orgánů Ruské federace problému zavádění formalizovaných mechanismů pro popis činnosti státních organizací je zcela oprávněná. Navzdory tomu, že státní organizace mají vzhledem ke své specifičnosti větší (ve srovnání s komerčními strukturami) setrvačnost a selektivitu v reakci na změny trhu, současná „nahromaděná masa“ potřeb dosáhla kritického bodu.

V současné době se manažerská a výkonná úroveň veřejných organizací často potýká s mnohem významnějšími problémy než komerční sektor. V prvé řadě je to nutnost využívat při své činnosti závazně regulační a právní rámec, který je značně rozsáhlý, složitý a často umožňuje nejednoznačný výklad. Počet právních a podzákonných předpisů federálního a resortního charakteru se pohybuje ve stovkách a tisících, počet druhů operativních dokumentů a údajů, které jsou předmětem zpracování na některých ministerstvech a resortech, dosahuje několika stovek. Často je provádění procesů organizováno tak, že jeden zaměstnanec má zátěž překračující přiměřené normy a zároveň nese závažnou administrativní a trestněprávní odpovědnost. Za těchto okolností je vytváření podmínek pro efektivní a legální práci úředníků mimořádně naléhavým úkolem a stát podniká příslušné kroky k jeho řešení:

♦ zavádí se elektronický správní řád;

♦ formují se mechanismy informační a konzultační podpory;

♦ optimalizuje se organizační struktura.

Potvrzuje to administrativní reforma, iniciativy pro rozsáhlé zavádění elektronických správních předpisů, vznik e-governmentu atd. Ve všech těchto projektech je formování a optimalizace obchodních modelů předběžným procesem, který určuje základní počáteční data.

S otázkou „proč potřebujeme modelku“ souvisí otázka „kdo model potřebuje“. Otázka definice potenciální spotřebitelé(uživatelů) modelu je klíčem ke specifikaci a upřesnění cílů. Modelování obchodních procesů může pokrývat různé aspekty podniku: hlavní a formativní infrastrukturu podniku. Podle toho bude okruh zájemců v podobě manažerů a performerů určen směrem činnosti organizace zvolené (zvolené) pro modelování.

Na úrovni podnikových divizí mohou vystupovat jako zainteresovaní spotřebitelé modelu: administrativní aparát, divize informačních technologií, personální divize, právní divize atd.

Současně může poměrně velké publikum specialistů a manažerů vystupovat jako uživatelé modelu obchodní architektury podniku v rámci oddělení:

♦ obchodní analytika v různých oblastech předmětu (cílové) činnosti organizace;

♦ vývojáři informací a technologické systémy;

♦ systémové architekty, kteří zodpovídají za tvorbu architektury jednotlivých informačních systémů;

♦ obchodní analytici, kteří vedou proces navrhování organizační struktury;

♦ manažeři, kteří mají zájem o systematickou, strukturovanou analýzu problémů a příležitostí, které se podnikání otevírají atd.

Iniciativa k modelování obchodních procesů může v zásadě pocházet z jakéhokoli oddělení podniku. Záleží na míře informovanosti vedoucích oddělení o možnostech a užitečnosti modelů, prioritě aktuálních úkolů optimalizace činností, úplnosti modelování jednotlivých podnikových procesů podniku.

Ve skutečnosti ve většině případů iniciativa vyvíjet modely obchodních procesů pochází od oddělení informačních technologií organizace. Důvodem je potřeba automatizovat určité oblasti činnosti podniků na pozadí obecně vysoké aktivity při zavádění IT ve všech oblastech podnikání a stále se zvyšujícího podílu podnikových rozpočtů na složku IT.

Při vší pozitivitě samotného faktu činnosti IT oddělení (ale i jakéhokoli jiného funkčního oddělení) při zavádění business modelingu je správné ponechat iniciativu a kontrolu tohoto procesu pro vrcholové vedení organizace. Vyhnete se tak „úzkému útvarovému“ čistě IT (či jinému) přístupu k modelování, zaměřenému na řešení konkrétního úkolu dodatečně – automatizace samostatného procesu, a poskytnutí řešení firemního úkolu – vytvoření nástroje pro hodnocení a optimalizaci podnikání procesů v rámci dosahování výkonnostních cílů celé organizace.

Podpora a obecné vedení Zavedením modelu obchodní architektury v podniku nevylučují ani nesnižují roli funkčních jednotek v této práci. Čím „širší“ a „hlubší“ se model stává, čím „blíže“ je uživateli, tím větší počet zainteresovaných stran se objevuje v jeho vývoji a podpoře.

V důsledku modelování činnosti podniku v rámci procesního přístupu „nevyhnutelně“ dochází k postupnému (jak je model podrobný) zobrazení role, místa, efektu zaváděného všemi organizačními a personálními strukturami podniku. . Z tohoto důvodu je třeba zajistit, aby byl význam jednotky náležitě zohledněn obecný model podniku, jakož i následné hledání zvýšení „příspěvku“ k cílovým výsledkům podniku, případně „snížení“ nákladů útvaru, vyprovokuje vedoucí těchto útvarů k aktivní účasti na konstrukce modelu obchodní architektury.

Do jisté míry lze otázku „kdo potřebuje obchodní model“ srovnat s otázkou „kdo potřebuje elektronická správa dokumentů". Workflow od jistého okamžiku využívají všichni a každé oddělení se podílí na stanovení úkolů pro tvorbu specializovaných elektronických předpisů pro podporu „své“ části workflow a jejich „horlivou“ ochranu a ve vztahu k business modeling každé oddělení začíná budovat "svou vlastní část" model velké budovy obchodní architektury.

Stanovení cílů, implementace, implementace a škálování výsledků projektů modelování podnikových procesů jsou významnými milníky ve změně celkové podnikové kultury podniku. Zaměstnanci postupně získávají znalosti, dovednosti a zkušenosti procesního přístupu při výkonu svých činností, jasně se zařazují do komplexní struktury organizace, ovládají moderní metody hodnocení výsledků své práce a hledání cest k její optimalizaci.

Vytvoření modelu obchodní architektury je druh kolektivního informačního, technologického a organizačního prostředí pro zobrazení a implementaci procesního přístupu podniku. Toto prostředí, které na jedné straně umožňuje každému zájemci „vyjadřovat“ kvalitativní i kvantitativní návrhy na zlepšení činnosti podniku, a na straně druhé všem zúčastněným objektivně hodnotit „pozitivní“ a „negativní“ aspekty. návrhu.

„Nová“ firemní kultura kromě zvýšení „uvědomění“ účastníků obchodních procesů o jejich poslání v činnosti podniku zajišťuje povinnou dokumentaci a uchování historie všech změn souvisejících s cílovou činností podniku. podnik. Takový pedantský a kvalitativně formalizovaný postoj k letům nashromážděným znalostem v organizaci je základem pro jejich efektivní využití.

Podmínkou a/nebo důsledkem modelovacího projektu je rozšíření zainteresovaných účastníků do konstrukce modelu a utváření nové kultury řízení podniku ve větší míře. Praktické kroky pro realizaci projektu jsou tvořeny na základě pochopení obsahu cílových úloh pro modelování.

Modelové úkoly vyplývají z cílů formulovaných organizací ke zlepšení její činnosti. Jak je uvedeno výše, cílové úlohy pro modelování obchodních procesů jsou rozděleny do dvou hlavních oblastí:

1) systemizace a formalizace - konstrukce deskriptivních modelů;

2) konstrukce analytických a optimalizačních modelů.

V rámci vybraných oblastí lze provést další rozdělení oblastí s přihlédnutím k přítomnosti dvou hlavních typů výzkumu, a to samotných obchodních procesů a zdrojů zapojených do obchodních procesů. Na základě toho takové dílčí úkoly jako:

1) kvalitativní a kvantitativní hodnocení (optimalizace) implementovaných podnikových procesů;

2) kvalitativní a kvantitativní hodnocení (optimalizace) využití zdrojů organizace v rámci probíhajících obchodních procesů.

Ve vztahu k podnikovým procesům lze úlohy modelování rozdělit na typy procesů: jádro, umožňování, vnější interakce a vývoj (viz kapitola 2). S ohledem na "neprocesní" výzkumné objekty lze specifikovat modelovací úlohy pro procesy formalizace cílů podniku, organizační struktury, technologické struktury, informační struktura, architektura obchodních funkcí, regulační rámec, klíčové ukazatelečinnosti, atd.

Další systematizaci úloh modelování lze propojit s implementovanými metodami pro konstrukci a používání modelu podnikové obchodní architektury. Příklady takových úloh mohou být: funkční analýza nákladů, simulační modelování, systematizace a formalizace.

V praxi jsou podle vybraných oblastí stanovení úkolů modelování podnikových procesů seskupeny následující aktuální otázky, na které by vedení organizace rádo dostalo odůvodněné odpovědi:

♦ Jaké jsou integrální náklady a časové náklady potřebné k implementaci určitého obchodního procesu (subprocesu)?

♦ Jaké složení organizačních, technologických a informačních zdrojů, jakož i předpisů, je nutné k provedení konkrétního obchodního procesu?

♦ Jaká je dynamika využití organizačních, technologických a informačních zdrojů nezbytných k dokončení konkrétního obchodního procesu?

♦ Jaké zdroje (organizační, technologické a informační) nebo předpisy jsou hlavními limitujícími faktory pro rozšíření schopnosti organizace zvyšovat kvalitativní a kvantitativní charakteristiky řešených obchodních úkolů?

♦ Jaké operace (pracovní funkce) jsou přiděleny konkrétnímu úřednímu útvaru v rámci cílové činnosti organizace?

♦ Jaký seznam operací ( směrování) by měla být prováděna služebním útvarem při vzniku konkrétní standardní či nestandardní situace související s realizací cílové činnosti organizace?

♦ Jaká kvalitativní a kvantitativní zlepšení lze očekávat po modernizaci (zavedení nových) informačních systémů, právních aktů, organizačních jednotek, výrobních technologií apod.

Výše uvedené směry zadávání úloh tvoří skupinu podmíněně nazývaných úloh pro technologický návrh modelu („architektonické“ úlohy). Zároveň objektivně existuje nezávislá skupina úkolů spojená s logikou organizace provádění modelového projektu:

♦ definice etap;

♦ definice rolí v projektu;

♦ formování a řízení v projektovém týmu atd.

O tomto výčtu úkolů, stejně jako o realizaci „architektonických“ úkolů, se budeme podrobněji věnovat v dalších částech knihy.

Je třeba poznamenat, že kvalitativní formulace problémových prohlášení pro modelování podnikových procesů ve vztahu k profilu, aktuálnímu stavu a prioritě problémů organizace je klíčovou podmínkou úspěchu projektu. Mělo by být jasné, že na stanovení cílů by se měli podílet nejen všichni zainteresovaní, ale také kompetentní osoby. Při řešení takových otázek je nutné vyloučit možné situace záměny obchodní kompetence (na úrovni právní, technologické, manažerské) kompetencí IT a naopak.

Zcela přirozená a oprávněná otázka po zjištění, kdo a proč model business architektury potřebuje, je vyjasnění parametrů a zásadní možnosti splácení tohoto druhu poradenského projektu.

Takové konstatování otázky, stejně jako formování odpovědi na ni, se příliš neliší od situace, kdy se ukazuje, proč je při zahájení rozsáhlých projektů informatizace organizace potřeba koncepce informačního systému.

Snahy o vybudování obchodní architektury, která je prezentována ve formě obchodních modelů, se rychle vyplácejí a mají velké množství další výhody. Výhody budování modelu obchodní architektury modelů spočívají ve dvou rovinách: další funkce podnikání a snížit náklady. Odhaduje se, že tvorba obchodních modelů a s tím spojená optimalizace nákladů i bez radikálních obchodních změn může přinést až 10% úsporu. A při modelování alternativních možností obchodních procesů mohou organizace ušetřit až 20 %.

Začal jsem pracovat s jednou společností na téma podnikové architektury (Enterprise Architecture) a rozhodl jsem se opravit své chápání EA, aby bylo jasnější a jednodušší. Publikace Johna A. Zachmana „A Framework for Information Systems Architecture“ z roku 1987 je obecně považována za datum narození EA, ačkoli samotný termín se objevil v dřívějších spisech. Navzdory skutečnosti, že architektura podniku je poměrně mladá věc, již si dokázala pokazit pověst. Jako každá jiná architektura není podniková architektura dobře definována (viz například 10 definic podnikové architektury), ale má velké množství neúspěšných projektů (viz Gartner identifikuje deset úskalí podnikové architektury nebo 8 důvodů selhání programů podnikové architektury) . Obvykle po dokončení projektu podnikové architektury můžete slyšet následující frázi: Nakreslili jsme všechny potřebné obrázky, ale netušíme, jak z toho získat alespoň nějaký užitek.". Proto si řekněme vše od úplného začátku.

A začneme z dálky. Existují dva pohledy na užitečnost informačních technologií. Podle prvního pohledu Informační technologie umožňují zvýšit produktivitu práce, tzn. lidé budou pracovat efektivněji, pokud budou jejich činnosti automatizovány. Existuje také opačný názor, vyjádřený například v knihách jako „Lesk a chudoba informačních technologií. Proč IT není konkurenční výhoda“ od Nicholase J. Carra nebo „Co podnik chce od IT“ od Terryho Whitea. Oba tyto pohledy jsou překvapivě správné. Zúžme ale okruh našeho uvažování a mluvme nikoli o informačních technologiích obecně, ale pouze o podnikových aplikacích, tzn. systémy, které automatizují obchodní procesy organizace. Vývoj a implementace takových systémů přináší nejprve hmatatelný efekt. Když různí zaměstnanci začnou reflektovat podobné operace v jediné databázi přístupné přes síť z různých pracovišť, interagují spolu prostřednictvím takových řešení a specializují se na určité funkce, jejich produktivita se zvyšuje. Je to mnohem lepší než si telefonovat nebo si vyměňovat emocionálně nabité zprávy e-mailem. Začínají se proto automatizovat různé další procesy, možná ne tak časté a ne tak nutné. Účinnost takové automatizace není tak vysoká. Nízko visící jablka jsou již otrhaná a my musíme vymýšlet sofistikovanější způsoby, jak dosáhnout výsledku. V určitém okamžiku se náklady na používání podnikových aplikací stanou většími než přínosy plynoucí z jejich používání, ale zastavit přetaktovanou lokomotivu již není možné. Důvodem tohoto prahu je organická složitost informačních systémů (IT Complexity). Ve skutečnosti jsme v určité chvíli zmateni tím, co děláme, a informační systémy nám pomáhají být zmatenější. Architektura (podnik) je jen způsob, jak kontrolovat inherentní složitost systémů, jak mít na paměti více či méně adekvátní obraz, a přitom stále umožňuje tuto složitost řídit.

Dalším problémem je, že takový obrázek nelze připravit pro budoucnost. (V tomto bodě vám architekti řeknou spoustu módních slov o různých úhlech pohledu, názorech, zainteresovaných stranách a obavách). Proto odpovědět na otázku „Proč děláme podnikovou architekturu?“ potřeba od samého začátku. Dovolte mi zdůraznit tři nejčastější odpovědi:

1. Máme strategii, která odpovídá na otázku, co chceme, ale nevíme, jak to udělat.
2. Nemáme strategii, ale máme záplavu žádostí o změnu, které nezvládáme.
3. Informace o naší činnosti jsou rozporuplné a nemáme čas v každém případě zjišťovat, proč se tak děje.

(Pokud si myslíte, že existují jiné, častější možnosti, uveďte to prosím do komentářů).

V prvním případě musíme udělat Strategie –> Plán. Jde především o obchodní strategii. Obvykle to vypadá jako soubor nějakých delt mezi tím, co máte, a tím, co chcete, vyjádřeno poměrně jednoduše: podíl na trhu z hlediska příjmů, zákaznické základny atd. Obecně, víte, strategie je dokument o ježcích zítřka , ze kterých se stanou dnešní myši. O tom, co by se v tomto případě mělo udělat, napíšu v samostatné zprávě, ale zatím pár slov o tom, jak takový proces zorganizovat. Organizační forma vývoje enterprise architektury je dle mého názoru projekt trvající 8-16 týdnů. Metodika - TOGAF ADM atd. Zdroje by měly být přitahovány, především vnitřní. Výsledkem projektu jsou: cestovní mapa, seznam organizačních a procesních změn, rizik, návrhy na sledování a řízení pohybu daným směrem. Všeobecně se vše, co se dělá v tradičních projektech ve fázi plánování, nazývá krásné slovo mistrovský plán. O týmu takového projektu, souboru aktivit a artefaktů - totéž v jedné z následujících zpráv.

Možnost číslo 2: Řízení změn. Místo strategie existuje sada různých cílů pro různé firemní zákazníky. Někteří potřebují snížit náklady, jiní potřebují uvést na trh nové produkty a služby a další potřebují zlepšit spokojenost zákazníků (viz Enterprise Architecture pro pár vět). Všichni zákazníci jsou respektovaní lidé a každý potřebuje pomoc. Ale složitost už narostla a my nerozumíme tomu, jak pomoci všem zároveň. jednoduché a Špatným směrem dát všechny do souladu krásné jméno, např. "Jednotný seznam priorit" a způsob rozdělování úkolů mezi informační systémy je "Pokladna zdarma!" - kdo to zvládne rychleji a levněji, toho pověříme. Správné rozhodnutí- multifaktoriální klasifikace dotazů, jinými slovy - taxonomie. Metodika - ve stylu Zachmana. Organizace - vytvoření funkčního celku. V předchozí poznámce Jsou obchodní analytici přáteli, sousedy nebo vzdálenými příbuznými? Napsal jsem, že s příchodem a přijetím třetí verze BABOK budou obchodní analytici schopni tuto práci dělat. Ale zatím se jim to nedaří. V současné době jsou obchodní analytici schopni odpovědět na otázku „Co je třeba udělat?“ a architekti řešení mohou odpovědět na otázku „Jak na to?“. Vyžaduje také odpověď na otázku „Proč?“, jak tato změna souvisí se stávajícími produkty a procesy, dalšími změnami, aplikacemi.

A konečně situace, kdy komplexnost již zvítězila a vedoucí organizace si to uvědomují. o těch stejných obrázky, které tu nejsou, když jsou potřeba k rychlému vyřešení kontroverzního problému, a které po zbytek času leží zcela zbytečným nákladem. Tato situace hovoří o architektonickém úložišti. Někde mohou být obrázky popisující architekturu, ale pokud je nelze získat během minuty nebo dvou, pak to vedoucí a jakýkoli manažer neudělá sám, ale požádá někoho jiného, ​​aby udělal obrázek („Zavolejte sem architektovi !"). Pokud člověk s aplikací nepracuje alespoň jednou za 1-2 týdny, tak to nebude dělat vůbec. Pokud vývojář informačního systému nedisponuje jednoduchými, srozumitelnými a připravenými API pro získávání typů klientů, seznam poboček, funkční organizační strukturu atd., pak určitě přidá další desku do svého informačního systému , ve kterém donutí uživatele znovu zadávat údaje z těchto adresářů. Nevím o žádném nástroji EA, který by byl stejně vhodný k předvádění krásných obrázků vrcholovým manažerům a zároveň měl vrozenou interoperabilitu pro integraci do skutečných podnikových aplikací. Doufám, že se takové dříve nebo později objeví. A pak se varianta číslo tři promění v jednoduchý projekt na implementaci informačního systému a jeho následné využití a rozvoj.

Pokračování (příběh podnikové architektury)!