Kome je potrebna Enterprise Architecture i zašto?

Copyright © 2009 Zabegalin E.V.

1 Trenutno stanje arhitektonskih metodologija i praksi

AT stranim zemljama ah, metodološki i praktično je odavno razrađen određeni raspon tema čija je tema arhitektura kompleksa organizacione i tehničke objekte kao što su preduzeća, "elektronske vlade", korporativni informacioni sistemi.

AT Rusija, uprkos činjenici da se pojmovi "arhitektura informacionog sistema"„Arhitektura informatičke tehnologije preduzeća“, „arhitektura elektronske vlade“ odavno su postale moderne i široko se koriste među IT profesionalcima, ozbiljan metodološki interes za „arhitektonske“ teme prisutan je samo u uskom krugu stručnjaka entuzijasta (uključujući autore publikacija), aktivnosti koje su u ovoj oblasti uglavnom edukativnog i popularnog karaktera.

Stoga, ako govorimo o standardizaciji "arhitektonskih" metodologija u Rusiji i njihovoj kasnijoj širokoj praktičnoj upotrebi u domaćim kompanijama, onda se čini da je to pitanje neizvjesne budućnosti. Međutim, „arhitektonski“ pokret u ruskim preduzećima bi praktično trebao početi sada.

"Arhitektura preduzeća", na ruskom "Arhitektura preduzeća" (AP), razvila se u opštu disciplinu kao korak istorijski razvoj skup metodologija vezanih za arhitekturu automatizovanih informacionih sistema - to su metodologije J. Zachmana, čl. Spivak, CIMOSA, GERAM, TOGAF itd. Analiza ovog istorijskog procesa je dovoljno detaljna u.

Do danas, najistaknutiji i najznačajniji izvori savremenih metodoloških ideja i praksi EA uključuju:

Zachmanov okvir za arhitekturu preduzeća;

ISO 19439:2006 "Integracija preduzeća - Okvir za modeliranje preduzeća";

ISO 15704:2000 standard. Sistemi industrijske automatizacije - Zahtjevi za referentne arhitekture i metodologije poduzeća;

"Federal Enterprise Architecture" (FEA), koju praktikuje i razvija američka vlada;

"Okvir proširene arhitekture preduzeća" (E2AF), razvijen od strane nezavisna organizacija"Institut za razvoj arhitekture preduzeća" ;

Okvir otvorene grupne arhitekture (TOGAF).

Uz to, u Rusiji je 2000. godine razvijena i objavljena konceptualna arhitektonska šema „3D-Enterprise“, u kojoj su matrične ideje J. Zachmana dopunjene trećom – privremenom – dimenzijom koja odražava transformaciju strukture preduzeća.

Napominje se da se značajno interesovanje za temu AP objašnjava hitnom potrebom savremenih menadžera i analitičara za višedimenzionalnim sistemskim opisom i planiranjem procesa razvoja organizacija (uključujući preduzeća). Interes za ovakav opis diktira, u najmanju ruku, praktična potreba da se uvek ima dovoljno smislenih znanja o trenutnoj strukturi organizacije, koja se mogu koristiti i za racionalno planiranje transformacije organizacije u promenljivim uslovima. Ako je takvo znanje dostupno, održavano i korišćeno u organizaciji u otuđenom obliku, onda se ono pretvara u efikasan alat upravljanja. Ovo posebno važi za nove lidere i menadžere organizacija (preduzeća).

Slika 1 – Menadžeri i analitičari imaju praktičnu potrebu da uvijek imaju dovoljno smislenog znanja o strukturi organizacije (preduzeća)

Istovremeno, nivo apstrakcije i složenosti većine navedenih metodologija ostaje veoma visok i može ometati njihovu efektivnu upotrebu u njihovim organizacijama. praktični menadžeri i specijaliste. različite vrste„Matrice“ i „kocke“ predložene u navedenim metodologijama mogu se činiti nepotrebno umjetnim i stoga nezgodnim za praktičnu upotrebu. Tako se, na primjer, čini da je priroda iste "Zachmanove matrice" više filozofska nego praktična inženjering, ona je prije shematski vizualizirana specifikacija sistematskog pristupa analizi velikih i složeno strukturiranih organizacionih i tehničkih objekata. Međutim, to ni najmanje ne negira ogromnu metodološku vrijednost i praktični značaj razvojne discipline AP.

U interesu praktične primene discipline EA, prevazilaženje ove izveštačenosti može se započeti traženjem odgovora na pitanje: kome i zašto u preduzeću može biti potrebna „Arhitektura preduzeća“?

2 Svrha "Arhitekture preduzeća"

Slika 2 šematski prikazuje strukturu i sadržaj generalizovanog preduzeća. Iz ovog dijagrama se vidi da AP, posmatran i korišten kao model, može biti praktično tražen u preduzeću samo kao alat za upravljanje, jer ni tehničkom ni proizvodnom osoblju AP nije potreban za obavljanje svojih proizvodnih funkcija.

Ovaj zaključak proizilazi iz činjenice da su svi objekti upravljanja prikazani na dijagramu istovremeno objekti koji se odražavaju u modelu EA, koji će u budućnosti postati i objekt upravljanja (arhitektonski model preduzeća je prikazan na dijagramu kao njegov komponenta).

Slika 2 – Generalizovana struktura preduzeća

Kao alat za upravljanje, EA se može koristiti za podršku svim njegovim glavnim funkcijama - analiza, planiranje, organizacija, motivacija, kontrola, koordinacija.

Slika 3 - "Arhitektura preduzeća" može se koristiti za podršku osnovnih funkcija upravljanja

Iz uloge EA kao alata za upravljanje, mogu se izvesti najmanje dvije glavne funkcije Enterprise Architecture:

u konturi operativnog upravljanja preduzeća - to je formalizacija i pružanje otuđenog znanja o postojećoj strukturi i funkcionisanju preduzeća;

u konturi strateško upravljanje preduzeće - je formalizacija i odredba

otuđeno znanje o planiranim strukturnim i funkcionalnim transformacijama preduzeća.

Slika 4 - Glavne funkcije "Arhitekture preduzeća"

AP se može koristiti sa ovim funkcijama na svim nivoima upravljanja: od nivoa upravljanja preduzećem do pogona. Ovo (eksplicitno ili implicitno) osiguravaju dobro poznate metodologije -

"Zachman okvir za arhitekturu preduzeća", "Okvir proširene arhitekture preduzeća", "TOGAF",

"GERAM", standard ISO 19439-2006 ("Generički", "Parcijalni", "Partikularni" nivoi).

Nakon J. Zachmana, najkonkretniji i najkonzistentniji nivoi upravljanja za korištenje AP-a su predloženi u shemi „3D-Enterprise“ – „Glavne potrebe, ciljevi, planovi, ograničenja“, „Poslovni model“, „Logički model“, „ Tehnička arhitektura”, “Detaljna implementacija”, “Praksa korištenja”.

3 Sastav "Arhitekture preduzeća"

Sve arhitektonske metodologije se slažu da je za dovoljno smislen opis uređaja preduzeća (organizacije) potrebno koristiti mnogo različitih gledišta (pogleda) na ovom uređaju. Ova gledišta se takođe mogu nazvati arhitektonskim domenima, aspektima sadržaja i slično. Opisivanje (i modeliranje) strukture preduzeća iz mnogo različitih perspektiva rezultira "arhitekturom preduzeća".

Različite metodologije koriste različite skupove arhitektonskih gledišta. Na primjer:

u Zachman okviru za arhitekturu preduzeća, to su "Podaci", "Funkcija", "Mreža", "Ljudi", "Vreme", "Motivacija";

u proširenom okviru arhitekture preduzeća (E2AF) je "Posao", "Informacije", "Informacije

Sistemi", "Tehnološka infrastruktura";

u GERAM-u i ISO 19439-2006 to su "Funkcija", "Informacije", "Resursi", "Organizacija";

u TOGAF-u to su "Posao", "Informacije", "Primjena", "Tehnologija".

Autor ovog članka smatra da je praktično svrsishodno prevazići tako raznovrsnost metodoloških pristupa izboru suštinskih aspekata EA korištenjem bilo kojeg jednostavnog i razumljivog principa za logičko izvođenje ovih aspekata.

Takav princip može proizaći iz opšteg fundamentalnog shvatanja „sistema“ kao skupa elemenata koji namerno deluju. Na osnovu toga, sljedeći osnovni i lako razumljivi suštinski aspekti "Arhitekture preduzeća" mogu se fundamentalno razlikovati:

1) Građevinski aspekt- preduzeće se gradi od mnogo različitih fizičkih i informacionih komponenti, uključujući: osnovna sredstva i drugu imovinu, utrošenu i proizvedenu energiju, osoblje, papirnu dokumentaciju, elektronske informacije, automatizaciju i alate za automatsku kontrolu, odnosno to su „građevinske cigle“ od kojih je preduzeće fizički sastavljeno. Na ovaj aspekt možete primijeniti i sinonimni pojam - strukturni aspekt.

2) Funkcionalni aspekt- preduzeće posluje, proizvodi proizvode, pruža usluge, kupuje i prodaje sirovine, materijale, proizvode, na njemu se odvijaju tehnološki i poslovni procesi, odnosno ovaj aspekt ističe eksternu i unutrašnju manifestaciju aktivnosti preduzeća;

3) Logički aspekt- djelatnost preduzeća je svrsishodna, u skladu sa ciljevima preduzeća, utvrđuju se njegova konstrukcija i funkcionalne strukture. Ovaj aspekt naglašava poslovni smisao stvaranja i rada preduzeća.

Glavne komponente logičke strukture preduzeća su takve spekulativne komponente kao što su svrha, misija, vizija, ciljevi preduzeća, njegovo mesto na tržištu, principi izbora glavnih tipova njegovih građevinskih komponenti, principi funkcionisanja i razvoj preduzeća.

AT U Zachmanovoj matrici, ovaj aspekt je naznačen imenom prvog reda „Obim“ („Svrha reda 1 je da definiše granice preduzeća, šta je uključeno…“).

AT Federalna arhitektura preduzeća (FEA) je "referentni model performansi".

AT E2AF i u GERAM-u logički aspekt se ne razlikuje eksplicitno i uključen je u „poslovni“ aspekt. Međutim, osnovni principi E2AF kažu: „Nema strategije, nema arhitekture preduzeća... Nema opsega – nema arhitekture preduzeća

Opseg i ciljevi i ciljevi postavljaju nivo apstrakcije arhitekture preduzeća... Poslovni pokretači, ciljevi i ciljevi su vodeći..." .

AT TOGAF logički aspekt odgovara "Viziji arhitekture" ("... ključni elementi "Vizije arhitekture"- ...

misiju, viziju, strategiju i ciljeve preduzeća..., uključuju principe arhitekture, definišu širinu obuhvata preduzeća, specifične domene arhitekture..." ).

Sumirajući pregled logičkog aspekta i koristeći filozofski jezik, može se tvrditi da je logički aspekt strukture preduzeća neophodan za predstavljanje "Integralne ideje preduzeća", "Integralne ideje preduzeća" , "Integralni koncept preduzeća", na engleskom možemo ponuditi - "Pojam preduzeća".

4) Hronološki aspekt- kompanija se stvara, posluje i mijenja se tokom vremena. Trebalo bi evidentirati prošlo, sadašnje i planirano strukturno stanje preduzeća, odnosno - ovo je "Istorija života".

U GERAM-u, u ISO 15704-2000, ISO 19439-2006, predložene su mnoge faze životnog ciklusa za strukturiranje vremenskog aspekta: "Identifikacija", "Koncept", "Zahtjevi", "Dizajn", "Implementacija", "Operacija", "Dekomisija".

AT metodologija TOGAF - Architecture Development Method (ADM) - vremenski aspekt se ogleda u redosledu faza razvoja, implementacije i promene same "Arhitekture preduzeća".

Šema "3D-Enterprise" omogućava planiranje perspektivnih stanja preduzeća u vremenskoj dimenziji EA, uključujući pojedinačne projekte i razvojne programe. Konkretno, redosled implementacije tehnoloških komponenti (sistema) preduzeća može uključivati: stratešku analizu ciljeva i potreba, projektovanje tehničkih rešenja, detaljnu implementaciju sistema rešenja, implementaciju rešenja, korišćenje (funkcionisanje) sistema. , poboljšanje sistema.

Slika 5 – Glavne tačke gledišta o strukturi preduzeća

Dakle, "Arhitektura preduzeća" se može definisati kao struktura preduzeća, koju njegovo rukovodstvo razmatra, najmanje sa četiri glavne tačke gledišta (u četiri glavna aspekta) i predstavljeno (uključujući i modelovanu) odgovarajućim skupom od četiri glavne vrste arhitektura Preduzeća: logička, građevinska (strukturna), funkcionalna i hronološka.

Komponente arhitekture zgrade preduzeća mogu se smatrati:

organizaciona arhitektura je organizaciona struktura preduzeća;

arhitektura imovine je vlasnička struktura preduzeća;

informaciona arhitektura je struktura skupa dokumenata (organizacionih, regulatornih, tehničkih, itd.) i informacionih baza podataka preduzeća;

proizvodno-tehnološka arhitektura je struktura proizvodnih i energetskih kapaciteta preduzeća, kao i struktura kompleksa instrumentacije i automatizacije i kompleksa opreme za automatizaciju.

To Komponente funkcionalne arhitekture preduzeća mogu se pripisati:

struktura funkcionalnih sistema i podsistema preduzeća;

struktura poslovnih funkcija i poslovnih procesa preduzeća;

strukture tokova materijala i informacija u preduzeću.

Slika 6 - Integrisani prikaz "Arhitekture preduzeća"

Pored četiri glavna tipa arhitekture preduzeća, mogući su i drugi, koji odgovaraju drugim gledištima, na primjer:

IT arhitektura je struktura skupa automatizovanih informacionih sistema (informacione tehnologije) preduzeća;

Poslovna arhitektura je arhitektura preduzeća bez njegove IT arhitekture.

4 Kako nabaviti i koristiti Enterprise Architecture

Menadžment preduzeća može dobiti AP na dva načina: prvi je da razvije AP od strane osoblja preduzeća, drugi je da se obrati vanjskim konsultantima.

Prvi put će zahtijevati upravljanje preduzećem:

formiranje radne grupe, koja će se potom transformisati u stalnu arhitektonsku službu preduzeća;

izbor i nabavka gotovih specijal kompjuterski program za elektronsko modeliranje AP-a i obuku stručnjaka preduzeća za njegovu upotrebu;

samostalna izrada i dokumentacija metodološke podrške AP;

samostalan razvoj AP.

Izrada AP od strane eksternih konsultanata zahtevaće od menadžmenta preduzeća da zaključi ugovor o obavljanju poslova:

za direktan razvoj AP;

o izradi i dokumentovanju metodološke podrške AP;

o stvaranju arhitektonske službe preduzeća.

Kompjuterski programi za elektronsko modeliranje poslovnih procesa i sistemskih struktura koji postoje na tržištu omogućavaju konvertovanje baza podataka elektronskih modela iz njihovih specijalizovanih formata u www-format i njihovo objavljivanje na internom (intranet) sajtu preduzeća. Ovo omogućava realizaciju

pogodan pristup bez licence za menadžere i stručnjake preduzeća elektronski model AP.

Nakon toga, formirana i pripremljena arhitektonska služba preduzeća može samostalno rješavati probleme modeliranja opcija za buduće stanje AP-a u interesu prihvatanja od strane menadžmenta. strateške odluke za razvoj preduzeća.

Spisak korištenih izvora

1. Zinder E. "3D-preduzeće" - model strategije transformacionog sistema. "Direktor informativne službe", br. 4, 2000. http://www.sept2000.ru/articles/2008/03/03/1/.

2. Zinder E. Arhitektura preduzeća u kontekstu poslovni reinženjering. „Inteligentna preduzeća/korporativni sistemi“, br. 4, br. 7, 2008.

3. Galaktionov V. Arhitektura sistema i njeno mesto u arhitekturi preduzeća. "Direktor informativne službe", br. 5, 2002.

4. Danilin A., Slyusarenko A. Arhitektura i strategija. "Jin" i "Jang" preduzeća informacionih tehnologija. M. Internet univerzitet informacionih tehnologija, 2005.

5. Drozhzhinov V., Shtrik A. Standardizacija arhitekture ministarstava američke vlade. PC Week/RE. br. 28, br. 31, 2005.

6. Zachman John A. Zachmanov okvir.http://www.zachmaninternational.com/

7. Kancelarija za upravljanje i budžet. Federalna arhitektura preduzeća (FEA).http://www.whitehouse.gov/omb/e-gov/fea/

8. Schekkerman J. Extended Enterprise Architecture Framework Essentials Guide. Institut za razvoj arhitekture preduzeća, 2006.http://www.enterprise-architecture.info/

9. Okvir otvorene grupne arhitekture (TOGAF).http://www.opengroup.org/architecture/togaf8doc/arch/toc.html

10. Generalizovana referentna arhitektura i metodologija preduzeća (GERAM). IFIP–IFAC, 1999.

11. Ivanova I.A. Menadžment: Tutorial. - M.: Izdavačka kuća RIOR, 2004.

Već smo primijetili da ne postoji jedinstvena tačna definicijašta je arhitektura preduzeća. Razne konsultantske kompanije, industrijske asocijacije, profesionalna udruženja koriste malo drugačije koncepte i metode da opisuju ovaj koncept. Štaviše, ovi koncepti i metodologije su u stalnom toku, tako da pokušaj da se precizno opiše šta je arhitektura preduzeća na način koji odražava današnje razmišljanje jeste „gađanje u pokretnu metu“.

Uopšteno govoreći, prilikom razvoja i korišćenja arhitekture preduzeća, naravno, preporučljivo je pridržavati se bilo koje jedne metodologije koja bi obezbedila jedinstvo u pristupima i odgovarajućim skupovima alata za opisivanje arhitekture. Ukratko se osvrćemo na najpoznatije tehnike u "Tehnike opisa arhitekture. Zachman i Gartner modeli, META Group i TOGAF tehnike" i "NASCIO. 4+1 modeli i SAM. Microsoft tehnike i dr. Odabir "optimalne" tehnike" . Ovdje ćemo detaljno opisati naše opšta ideja o konceptu arhitekture preduzeća.

Arhitektura preduzeća je dinamičan i moćan alat koji pomaže organizacijama da razumeju sopstvenu strukturu i način na koji obavljaju svoj posao i funkcije. On pruža "mapu" preduzeća i "plan rute" za promene u poslovnom i tehnološkom području.

Tipično, arhitektura preduzeća ima oblik prilično širokog skupa modela koji opisuju strukturu i funkcije preduzeća. Važna oblast primene ovih modela je sistematizacija procesa planiranja informacionih tehnologija i obezbeđivanje bolji uslovi za proces odlučivanje.

Individualni modeli arhitekture preduzeća su logično organizovani tako da zajedno obezbeđuju sve veći nivo detalja informacije o preduzeću – njegovi ciljevi i ciljevi implementirani korporativni programi i organizacionu strukturu, sisteme i podatke, korišćene tehnologije i sve druge oblasti od interesa.

Ovo je prilično dosadna i suvoparna definicija alata koji, zapravo, može imati ogroman utjecaj na rješavanje složenih problema i pružiti svježi pogled na složene i kontroverzne situacije s kojima se stalno susreće u aktivnostima bilo koje organizacije. Arhitekturu preduzeća nije lako stvoriti. S druge strane, teškoće povezane s tim ne treba preuveličavati. Suština je da jednom razvijena arhitektura preduzeća može donijeti značajne prednosti.

Arhitektura preduzeća je više proces nego statična stvar. Nećemo reći da je njegovo stvaranje laka zabavna šetnja. Ali ipak, to može biti privlačna i, na neki način, očaravajuća aktivnost. Arhitektura preduzeća nije jednostavna tema, ali pokušaćemo da je učinimo manje "zastrašujućom i obeshrabrujućom" u nastavku. Metode opisivanja arhitekture preduzeća koje već postoje danas omogućavaju organizovanje odgovarajućeg procesa uz prisustvo čak i minimalne količine početnih informacija na intuitivan i prirodan način. Istovremeno, kompletnost opisa arhitekture može se postepeno povećavati, kako raste razumevanje objekta opisa arhitekture - strukture i funkcija preduzeća, kao i pratećih informacionih tehnologija.

Kada dizajnirate arhitekturu preduzeća, morate se pozabaviti velikim brojem dimenzija i odnosa između njih koji se moraju uzeti u obzir. Stoga nije slučajno da mnoge tehnike za opisivanje arhitekture, koje ćemo dalje razmotriti, imaju svoje korijene u takvoj disciplini kao što je sistemska analiza. Uopšteno govoreći, razvoj arhitekture preduzeća nije tehnički proces koji je isključivo vezan za informacione tehnologije. Naravno, za njegov razvoj, po pravilu, prikladno tehnološki alati, ali uglavnom su to alati koji vam omogućavaju da kreirate dijagrame i tekstove, tj. softverski paketi poznati većini ljudi. Upotreba ovih je dovoljna jednostavni alati Na osnovu odgovarajućih metodologija, međutim, omogućava prikupljanje osnovnih informacija o aktivnostima organizacije, povezivanje različitih činjenica i izvođenje zaključaka koji pojednostavljuju i pojašnjavaju složen proces donošenja odluka koji se svakodnevno ponavlja u poslovanju. Važnija je kreativna komponenta ovog procesa, o čemu će biti reči na predavanjima 10-12.

Dobra arhitektura preduzeća obezbeđuje uravnoteženu analizu činjenica o organizaciji i daje menadžmentu načine da ispita svoje organizacije i način na koji one rade, pomaže im da formulišu nove strategije i daje pravac u procesu planiranja razvoja kako bi organizacije bile u skladu sa stalnim promenama. uslove i prioritete. Riječ je, naravno, o srednjoročnim i dugoročnim horizontima planiranja, kako poslovno, tako i tehnološko. Dobra arhitektura preduzeća obezbeđuje odzivnost i fleksibilnost, što se ogleda u odgovarajućim organizacionim oblicima, procesima, sistemima, portfoliju informacionih i aplikativnih sistema.

Korisnici arhitekture preduzeća su prilično velika publika stručnjaka i menadžera:

• profesionalci u oblasti kreiranja informacionih sistema koji su uključeni u relevantne korporativne projekte za kreiranje aplikacija koje su važne za preduzeće;
• sistemski arhitekti, koji su odgovorni za kreiranje arhitekture pojedinačnih informacionih sistema;
• poslovni analitičari koji vode proces dizajniranja organizacijskih struktura i poslovnih procesa;
• rukovodioci koji su zainteresovani za sistematsku, strukturiranu analizu problema i mogućnosti koje se otvaraju za poslovanje.

Ako pogledate ciljeve kojima se teži različitim pristupima opisivanju arhitekture poduzeća, tada u uspješnim, ispravnim metodama možete pronaći mnogo zajedničkog:

• koristiti za analizu višestrukih tačaka gledišta na predmet proučavanja (preduzeće i njegovi informacioni sistemi) u cilju „zavadi pa vladaj“ u procesu suzbijanja objektivne složenosti realnog sveta. Važno je shvatiti da nijedna pojedinačna tačka gledišta nije dovoljna za razumijevanje cjeline;
• da bi se obezbedio proces sinteze, svi modeli koji su uključeni u arhitekturu su povezani sa drugim modelima. To su ili detaljnije dekompozicije ili povezani pogledi. Ovo bogatstvo odnosa između modela direktno određuje kvalitet arhitekture.

Dakle, prije nego što nastavimo, evo još jedne definicije arhitekture preduzeća, koja je data na web stranici www.geao.org "Globalne organizacije za arhitekturu preduzeća" (GEAO - Global Enterprise Architecture Organization):

„Arhitektura preduzeća opisuje načine na koje se ukupna vizija organizacije odražava u strukturi i dinamici preduzeća. Na različitim nivoima apstrakcije, ona pruža jedinstven skup modela, principa, smernica i politika koje se koriste za kreiranje , razvijati i sprovoditi sisteme na nivou iu kontekstu čitavog preduzeća u celini.

Imajte na umu da se izraz "sistem" ovdje ne odnosi nužno kompjuterski sistem– može se odnositi i na organizacione strukture, sisteme upravljanja itd. Ali sama ova definicija je prilično apstraktna, tako da ćemo pokušati da joj damo sve veći stepen detalja kako je predstavljamo.

U daljem tekstu koristimo informacije iz više izvora i pokušavamo da ih kompajliramo u okviru nekog integrisanog koncepta arhitekture preduzeća, koji uključuje glavne elemente većine metodologija. Posebno ćemo se pridržavati preporuka.

Već smo napomenuli da je pokretačka snaga arhitekture preduzeća holistička vizija koja prelazi granice organizacije. Prikazano na sl. 4.1, dijagram koji je predložio GEAO ilustruje različite nivoe apstrakcije povezane sa opisom preduzeća. Imajte na umu da unutar jedne organizacije postoji samo jedna arhitektura preduzeća, ali u isto vrijeme, na nivou pojedinačnih sistema, može postojati veliki broj arhitekture rješenja. Arhitektura preduzeća pokriva i poslovne i IT aspekte, kao i procese razvoja, evoluciju arhitekture i strukture upravljanja i kontrole onih procesa koji se kreću iz trenutnog stanja arhitekture u željeno buduće stanje.

Viktor Galaktionov, 20.05.2002
Časopis "Director IS", #05, 2002 // Izdavačka kuća "Otvoreni sistemi" (http://www.osp.ru/)

AT savremenim uslovima Posebno je važno stalno i pravilno usklađivati ​​IT aspekte dizajna modernog automatizovanog preduzeća sa aktuelnim poslovnim aspektima. Ovo treba uraditi počevši od definicije poslovne arhitekture preduzeća i razvoja sistemske arhitekture (IT arhitekture) u skladu sa njom. U ovom članku autor dijeli svoje praktično iskustvo u razvoju sistemskih arhitektura za velike banke i daje konkretne savjete o tome kako se to može učiniti, uključujući i preduzeća u drugim industrijama.

Ja sam geograf, a ne putnik. Nedostaju mi ​​putnici. Nisu geografi ti koji broje gradove, rijeke, planine, mora, okeane i pustinje. Geograf je previše važna osoba, nema vremena za lutanje. Ne napušta svoju kancelariju. Ali on ugošćuje putnike i zapisuje njihove priče.

Antoine de Saint-Exupery. "Mali princ". Poglavlje 15. Geograf

Poznato je da svaki posao moderna kompanija sve više zavisi od informacione tehnologije. Razvoj pojedinih oblasti poslovanja, na primjer, razvoj "kartičarskog poslovanja" u bankama, postao je moguć samo zahvaljujući pojavi modernih IT-a. Naravno, ovo važi i za preduzeća u drugim industrijama. Stoga se možemo nadati da se predstavljeno iskustvo može koristiti u poslovanju bilo koje druge, nebankarske kompanije bez značajnih napora prilagodbe.
Karakteristike sadašnjeg nivoa razvoja bankarskih informacionih tehnologija leže u činjenici da se u mnogim bankama koje su mogle da održe svoje poslovanje nakon krize 1998. godine, a danas nastavljaju da ga aktivno razvijaju i povećavaju, uvode visokotehnološka bankarska rešenja protiv pozadini tekuće operacije. softverski sistemi i kompleksi prethodnih generacija, često zastarjeli. S druge strane, gašenje bankarskog poslovanja čak i na nekoliko sati, a još manje gašenje na jedan ili više dana radi povlačenja zastarjelog softver a puštanje u rad novog, u većini slučajeva će biti jednako gubitku poslovanja. U ovoj situaciji, u svakom trenutku, potrebno je imati jasnu predstavu o trenutnom stanju svih implementiranih i funkcionisanih informacionih sistema, kao i jednako jasno razumevanje njihovog daljeg razvoja, uzimajući u obzir izglede za razvoj banke, njena arhitektura kao arhitektura preduzeća. (U literaturi na engleskom jeziku - metode, članci, standardi - ovo odgovara terminu arhitektura preduzeća.)
Treba napomenuti da arhitektura preduzeća postoji nezavisno kako na našu svijest, tako i na veličinu ovog preduzeća - bilo da je u pitanju globalna korporacija, mala fabrika, mala trgovačko preduzeće itd. Malo preduzeće ima istu arhitekturu kao i veliko, ali se ne razlikuju previše u pogledu sastava komponenti. Međutim, neki menadžeri to razumiju i mogu sebi priuštiti da obrate pažnju na sve aspekte organizacije vlastitog preduzeća (u pravilu su to čelnici velikih kompanija), dok drugi ne. Druga je stvar što malo preduzeće može da ima samo dva ili tri proizvoda, misija i strategija nisu eksplicitno fiksirani (ova nevolja je, inače, uobičajena u velikim kompanijama), broj zaposlenih je 30 ljudi, a dva računara sa U proizvodnji se koriste MS Word 97. Ali čak iu ovom slučaju, ovo je sve što čini arhitekturu ovog preduzeća.
Članak predstavlja prilično detaljan i istovremeno pragmatičan pristup organizaciji rada na analizi arhitekture preduzeća u cjelini i planiranju arhitekture sistema, uključujući i njegovu dokumentaciju. Osnovni ciljevi dokumentovanja poslovnog znanja (razvoj arhitekture preduzeća) su osiguranje sigurnosti ulaganja u poslovanje i transparentnost poslovanja na svim nivoima.
Poslovna transparentnost počinje transparentnim razumijevanjem arhitekture preduzeća, sa jasnom podjelom na tri međuzavisna nivoa: strateški nivo, nivo poslovne arhitekture i nivo arhitekture sistema. Arhitektura sistema je određena poslovnom arhitekturom, a njen dizajn se može zasnivati ​​samo na poslovnoj arhitekturi, koja opet zavisi od strategije preduzeća. Ovakav pristup omogućava, po našem mišljenju, ne samo da se pravilno organizuje sam rad i napravi ispravna podela funkcija i odgovornosti poslovnog arhitekte („biznis developera“) odgovornog za razvoj poslovanja, odnosno poslovnu arhitekturu preduzeća, i arhitektu sistema, ali i, što je najvažnije, izgraditi uravnoteženu arhitekturu preduzeća koja adekvatno odgovara njegovoj misiji i strategiji.
Glavne definicije su date na početku članka. Zatim se razmatra sastav i sadržaj arhitekture sistema, analizira se odnos između entiteta poslovne arhitekture i arhitekture sistema. Faze i učesnici životnog ciklusa arhitekture sistema, posebno funkcije učesnika, razmotreni su dovoljno detaljno. Konačno, u skraćenom obliku predstavljena je struktura znanja koja leži u osnovi arhitekture sistema i izvučeni su konačni zaključci.

Osnovni koncepti

Arhitektura preduzeća- ovo je najopštiji i najsveobuhvatniji prikaz preduzeća, u ovom slučaju banke, kao privrednog subjekta koji ima kratkoročne i dugoročne ciljeve za obavljanje svoje osnovne djelatnosti, definisane misijom u regionalnom i globalnom, u našem slučaju finansijsko-kreditno tržište, te strategija razvoja, eksterni i interni resursi neophodni za ispunjenje misije i postizanje postavljenih ciljeva, kao i utvrđena pravila za obavljanje osnovne djelatnosti (poslovanja).
Za potrebe analize sistema, arhitektura preduzeća se može posmatrati u dva aspekta:

• statički - prema stanju banke u određenom trenutku;
• dinamički - kao proces tranzicije (migracije) banke iz trenutnog stanja u neko željeno stanje u budućnosti.

Arhitektura preduzeća koja se razmatra u statici sastoji se od sledećih elemenata:

• misija i strategija, strateški ciljevi i zadaci;
• poslovna arhitektura;
• arhitektura sistema.

Arhitektura preduzeća razmatrana u dinamici je koherentan, koherentan plan akcije i koordinirani projekti potrebni za transformaciju trenutne arhitekture organizacije u stanje definisano kao dugoročni cilj, na osnovu trenutnih i planiranih poslovnih ciljeva i poslovnih procesa organizacije.

Rice. 2.

Dakle, arhitektura preduzeća u opštem slučaju je opisana sledećim sekvencijalno zavisnim sekcijama (vidi slike 1 i 2):

• formulisana misija i strategija banke, strateški ciljevi i zadaci;
• poslovna arhitektura u trenutnom (kakvom jeste) i planiranom (koji će biti) stanju,
• arhitektura sistema u trenutnom (kao što jeste) i planiranom (koji će biti) stanju;
• akcioni planovi i projekti za prelazak iz postojećeg stanja u planirano.

Na sl. Slika 1 pokazuje da implementacija plana migracije ne znači zamrzavanje razvoja poslovne i sistemske arhitekture. Dakle, planirana arhitektura sistema je arhitektura "biti" samo u određenoj fazi razvoja preduzeća. Istovremeno se vratite na strateškom nivou misija i strateški ciljevi i zadaci ne znači potrebu za revizijom misije i strategije. Ali na kraju svakog ciklusa nužno se vrši analiza efikasnosti razvijenih i implementiranih mjera, ako je potrebno, u drugoj iteraciji se prilagođava poslovna arhitektura, arhitektura sistema i provode novi planovi migracije. U svakom trenutku može postojati nekoliko ciklusa, svaki takav ciklus ne mora da utiče na celo preduzeće u celini, ciklus može da utiče na određene oblasti, određena poslovna pitanja i može se evidentirati kao poseban projekat.
Sa faznim planom migracije, da bi se popravili postignuti rezultati, moguće je izgraditi srednju (migracionu) jednu ili više arhitektura.
Misija, strategija i poslovni ciljevi odrediti pravac razvoja banke i postaviti dugoročne ciljeve i zadatke.
Poslovna arhitektura na osnovu misije, strategije razvoja i dugoročnih poslovnih ciljeva, utvrđuje potrebnu organizacionu strukturu, strukturu kanala prodaje i funkcionalni model banke, dokumentaciju koja se koristi u procesu razvoja i implementacije proizvoda. Funkcionalni model opisuje poslovne procese usmjerene na realizaciju tekućih zadataka i dugoročnih ciljeva.
Poslovna arhitektura uključuje:

• proizvode i usluge koje banka nudi i planira za prodaju (uključujući pojedinačne šeme za njihovu proizvodnju), formalizovane u obliku jedinstvenog registra proizvoda i usluga, koji takođe sadrži segmentaciju klijenata, tarife i vlasnike proizvoda;
• kanali za prodaju proizvoda i usluga, izgrađeni kako na osnovu strukturnih i teritorijalnih podjela banke, tako i na bazi savremenih informacionih tehnologija;
• funkcije i procesi za implementaciju eksternih i internih proizvoda i usluga, formiranje stabala funkcija i procesa (u daljem tekstu: poslovne funkcije i poslovni procesi);
• finansijski i administrativni dokumenti (i na papiru i na u elektronskom formatu), formalizovan u obliku jedinstvenog registra (albuma obrazaca) bankovnih dokumenata;
• definisani tokovi dokumenata pravila o internom i eksternom protoku dokumenata;
• organizacionu strukturu, uključujući osoblje banka i njene teritorijalne jedinice koje su samostalne ekonomske jedinice ( pravna lica), komisije, radne grupe i uloge pojedinih službenika, opise poslova, pravilnike o odjelima i radnim tijelima i druga akta kojima se uređuju odnosi i raspodjela odgovornosti između zaposlenih u banci, kao i između strukturne podjele jar.

Arhitektura sistema(IT arhitektura, arhitektura IS preduzeća) - definira skup tehnoloških i tehničkih rješenja za osiguranje informatička podrška poslovanje banke u skladu sa pravilima i konceptima definisanim poslovnom arhitekturom.
Nadalje, pod "rješenjima" podrazumijevamo, u zavisnosti od konteksta, ne samo specifičnu opremu i softver i informacione sisteme, već i principe, standarde i metodologije koje se koriste u razvoju ili odabiru informacijskih i softverskih sistema, u izboru i konfiguraciji oprema.
Planovi migracije odrediti scenario prelaska banke iz postojećeg u perspektivno stanje, određen strateškim ciljevima i zadacima. Planovi migracije definišu transformacije i poslovne i sistemske arhitekture. Sa faznom migracijom, u svrhu formalizacije međurezultata, razvija se posredna (migracija) jedna ili više poslovnih i sistemskih arhitektura. Planovi migracije u skladu sa metodologijom upravljanja projektima koju je usvojila banka formalizovani su kao zasebni projekti, uključujući, posebno:

• definisanje projekta kao skupa zadataka i aktivnosti;
• faze i rokovi za realizaciju projekta u cjelini i zadaci i aktivnosti koje čine projekat;
• analiza konkurentskog okruženja i rizika povezanih sa realizacijom projekta;
• sastav rashodnih stavki budžeta projekta;
• kriterijume za uspeh projekta i očekivani ekonomski efekat.

Arhitektura sistema

Arhitektura sistema se sastoji od tri međusobno povezane komponente - arhitekture aplikacije, arhitekture podataka i tehničke arhitekture (vidi sliku 3). Arhitektura sistema u sistemu standarda datog preduzeća određuje pravila za formiranje njegovih komponenti i obezbeđivanje interakcije između njih.

Rice. 3.

Komponente arhitekture sistema

Arhitektura aplikacije uključuje:

• aplikativni sistemi (aplikacije) koji osiguravaju izvršavanje poslovnih funkcija i poslovnih procesa;
• interfejsi za međusobnu interakciju aplikacijskih sistema i sa eksternim sistemima i izvorima podataka ili potrošačima;
• alati i metode za razvoj i održavanje aplikacija.

Arhitektura podataka uključuje:

• automatizovane baze podataka koje obezbeđuju akumulaciju, skladištenje i obradu podataka određenih poslovnom arhitekturom;
• Sistemi za upravljanje bazama podataka ili pohranjivanjem podataka koji se koriste u tu svrhu;
• pravila i sredstva za odobravanje pristupa podacima.

Tehnička arhitektura sastoji se od mrežne arhitekture i arhitekture platforme.
Mrežna arhitektura uključuje:

• lokalne i teritorijalne računarske mreže, uključujući fizičke sopstvene i iznajmljene komunikacione kanale i opremu za formiranje kanala;
• Komunikacijski protokoli, usluge i sistemi adresiranja koji se koriste u mrežama;
• planove za vanredne situacije kako bi se osigurao nesmetani rad mreža u vanrednim situacijama.

Arhitektura platforme uključuje:

• Računalni hardver - serveri, radne stanice, diskovi i druga računalna oprema;
• Operativni i kontrolni sistemi, komunalni i uredski softverski sustavi;
• planove za vanredne situacije kako bi se osigurao nesmetani rad opreme (uglavnom servera) i baza podataka u vanrednim uslovima.

Za rješavanje problema arhitekture sistema u stanju je kompanija, po pravilu, posvećena Služba arhitekte sistema. Ova služba je odgovorna za sljedeće poslove:

• koordinacija rada IT odjela na dokumentovanju postojeće arhitekture sistema u početnoj fazi i naknadnom održavanju ažurne baze znanja o arhitekturi sistema;
• utvrđivanje perspektivnih pravaca razvoja arhitekture sistema u skladu sa strateškim ciljevima i zadacima banke, detaljnije u formi perspektivne poslovne arhitekture;
• projektovanje (zajedno sa drugim specijalizovanim odeljenjima za informacione tehnologije) perspektivne arhitekture sistema i planova za migraciju iz sadašnjeg stanja u budućnost;
• formulisanje zahteva i ograničenja za kreirane ili implementirane alate za automatizaciju koji obezbeđuju kvalitet i integritet arhitekture sistema;
• kontrola konzistentnosti arhitektura sistema razvijenih u okviru različitih projekata;
• praćenje usklađenosti sa zahtjevima za osiguranje kvaliteta i integriteta arhitekture sistema od strane odjela banke uključenih u razvoj, održavanje i rad informacionih sistema.

Odvojeno, treba se zadržati na jednom fundamentalnom pitanju: ko razvija arhitekturu sistema - arhitekta sistema ili programer softvera, tehnolog. Ispravna je odluka kada se odgovornost za razvoj arhitekture sistema dodijeli IT odjelima koji projektuju, razvijaju, testiraju, održavaju (uključujući i dekomisioniranje) softverske i hardverske sisteme i komplekse. Dokumentacija o arhitekturi sistema dio je obavezne projektne i operativne dokumentacije. Ovaj pristup vam omogućava da kreirate malu uslugu arhitekte sistema. U suprotnom, razvoj arhitekture sistema od strane namenskog servisa zahteva značajno povećanje broja arhitekata sistema, a razvojni procesi se ili jako usporavaju, ili razvijena arhitektura sistema postaje neadekvatna već u procesu razvoja.

Odnosi između arhitekture sistema i poslovne arhitekture

Arhitekturu preduzeća u potpunosti opisuju sljedeći entiteti (vidi sliku 4):

1. Misija i strategija banke, strateški ciljevi i zadaci.
2. Proizvodi i poslovni procesi.
3. Dokumenti.
4. Organizacijske strukture.
5. Prijave.
6. Podaci.
7. Oprema.
8. Akcioni planovi i projekti za prelazak iz postojećeg stanja u planirano.

Rice. 4. Međusobni odnos entiteta najvišeg nivoa arhitekture preduzeća

Na sl. 4 prikazuje samo entitete najvišeg nivoa. Svaki od entiteta se rastavlja na skup detaljnijih entiteta. Dakle, samo entitet „Proizvodi“ se na kraju rastavlja na više od deset tabela, uključujući grupe hrane, tarifni planovi, ciljne segmente klijenti itd.
Očigledno, postoje jake veze između svih ovih entiteta. Na primjer, implementaciju proizvoda prate određeni dokumenti, podržani informacijskom podrškom određenih aplikacija i modula koji koriste određene baze podataka. U implementaciju ovog proizvoda uključeni su različiti zaposlenici i odjeli. Proizvod ima vlasnika.

Rice. 5. Arhitektura preduzeća i mesto arhitekture sistema u njoj

Na sl. Slika 5 pruža uvećani grafički prikaz arhitekture preduzeća i njenih komponenti za definisanje.
Primjer ključnih odnosa između glavnih elemenata poslovne arhitekture i arhitekture sistema prikazan je na Sl. 6 u obliku ER dijagrama.

Rice. 6.

Suštine i odnosi dvije arhitekture

Životni ciklus arhitekture sistema

Za regulisanje životnog ciklusa (LC) sistema uopšte (uključujući preduzeća), kao i njihovih informacionih sistema i softvera (PS), posebno, postoji niz standarda. Oni pružaju mogućnost prilagođavanja modela životnog ciklusa, uključujući faze (faze) specifičnostima određenog preduzeća i projekta. Dakle, faze životnog ciklusa opisane u ovom i sljedećim odjeljcima nisu u suprotnosti s normativnim i nisu dogma. Njihova prednost u smislu upotrebe u ovom članku je jednostavnost i iskustvo praktične primjene.

Rice. 7.

Životni ciklus arhitekture sistema sastoji se od sljedećih faza: (vidi sliku 7):

• početna dokumentacija;
• upotreba;
• dizajn;
• migracija.

BILJEŠKA. Nakon što je faza migracije završena, proces se ponavlja, sljedeća iteracija počinje s fazom korištenja. Početna faza dokumentacije u razvoju novog IS-a može izostati. Razvoj arhitekture sistema počinje sa fazom projektovanja.
Tokom faze upotrebe, evolucioni razvoj arhitekturu sistema u skladu sa prethodno formulisanim principima i bez promene osnovnih tehničko-tehnoloških rešenja.
PRIMJER. Neka se arhitektura sistema programa održavanja razvije u fazi projektovanja računovodstvo u centrali i filijalama i implementiran (faza migracije). Znanja o sistemskoj arhitekturi ovog rješenja prelaze u fazu korištenja dok se ne jave novi poslovni zahtjevi za kompletiranje/modernizaciju izgrađenog sistema. Poznavanje sistemske arhitekture kreiranog rješenja kompanija koristi za izgradnju skladišta podataka u cilju konsolidacije informacija i naknadnog dobijanja upravljačkih izvještaja. Ali na osnovu ovih saznanja, dizajnira se sistemska arhitektura skladišta podataka, a zatim sistemi za izveštavanje o menadžmentu, koji naknadno, prošavši svoje faze migracije, ulaze u faze korišćenja. Dakle, možemo govoriti o modelu višeslojne arhitekture sistema, u kojem arhitektura sistema u različitim slojevima može biti u različitim fazama životnog ciklusa (vidi sliku 8).

Rice. osam.

U fazi projektovanja razvija se perspektivna (da bude) arhitektura sistema, formulišu se novi principi za izgradnju arhitekture sistema i razvijaju nova osnovna tehničko-tehnološka rešenja u skladu sa ovim principima. Obično je razlog za izvođenje ove faze značajne promjene u poslovnoj arhitekturi, pojava novih poslovnih zahtjeva koji značajno utiču na arhitekturu sistema.
U fazi migracije sprovodi se skup organizacionih, tehničkih i tehnoloških mera kako bi se obezbedio prelazak arhitekture sistema iz trenutnog stanja u obećavajuće ili u sledeće srednje stanje tokom fazne migracije u skladu sa planovima migracije pripremljenim u prethodnu fazu.
Životni ciklus arhitekture sistema povezan je sa životnim ciklusom softvera. Životni ciklus softverskih alata (PS) sastoji se od sljedećih glavnih faza:

• studija izvodljivosti;
• razvoj tehničkih specifikacija;
• razvoj tehnički projekat;
• izrada i dokumentacija PS;
• PS testiranje;
• uvođenje PS;
• rad trafostanice;
• razgradnju PS.

Arhitekta sistema kontroliše odluke o dizajnu tokom životnog ciklusa softvera. Kontrola se vrši u vidu koordinacije projektne dokumentacije koju pripremaju i šalju arhitekti sistema od strane odjela odgovornih za implementaciju jedne ili druge faze životnog ciklusa PS.
Prikazani su opisi faza životnog ciklusa arhitekture sistema, obim radova na arhitekturi sistema koji se izvode u svakoj fazi, izvođači ovih radova, kao i korespondencija sa fazama životnog ciklusa PS. ispod.

Inicijalna dokumentacija

Faza životnog ciklusa arhitekture sistema "Inicijalna dokumentacija" nema direktnu korespondenciju sa fazama životnog ciklusa softverskih alata. Sadržajno, ova faza je predstavljena funkcijama njenih aktivnih učesnika (vidi tabelu 1).

Tabela 1.

Upotreba

Sljedeće faze životnog ciklusa softverskih alata odgovaraju fazi životnog ciklusa arhitekture sistema "Upotreba":

• Izrada tehničkih specifikacija za PS.
• Izrada tehničkog projekta PS.
• PS testiranje.

(Vidi napomenu, sliku 8 i gornji primjer. Iz primjera vidimo da razvoj TOR-a, TP-a, testiranje i implementacija skladišta podataka i sistema upravljanja izvještavanjem koristi znanje o sistemskoj arhitekturi računovodstvenog sistema u komercijalnom poslovanju , a arhitektura sistema je trenutno u fazi upotrebe, dok je arhitektura sistema skladišta podataka trenutno u fazi projektovanja.)
Funkcije njegovih aktivnih učesnika u fazi "Upotreba" prikazane su u tabeli. 2.

Tabela 2.

Dizajn

Ovdje se može postaviti pitanje: kuda je krenuo razvoj iskaza problema? I da li je to uopšte potrebno? Faza životnog ciklusa arhitekture sistema "Dizajn" odgovara sledećim fazama životnog ciklusa softverskih alata:

• Izrada tehničkih specifikacija za PS.
• Izrada tehničkog projekta PS.

Naravno, potrebna nam je, službenim jezikom rečeno, faza „Analiza objekta automatizacije“, koja uključuje izradu iskaza problema, formulaciju poslovnih zahtjeva i, naravno, postoji takva faza. Međutim, detaljna rasprava o ovim pitanjima je izvan okvira ovog članka, koji je ograničen na razmatranje arhitekture sistema.
Dozvolite mi ipak da objasnim. Potreba za promjenom poslovanja i, kao rezultat toga, potreba za restrukturiranjem poslovne arhitekture može biti uzrokovana:

1. promjene misije ili strategije;
2. promjene tržišne situacije;
3. regulatorna tijela.

Nakon realizacije ove potrebe, dolazi do formulacije poslovnih zahtjeva, ali sve se to dešava dok smo još u sloju poslovne arhitekture (vidi sliku 4). Strelice od entiteta "Proizvodi" i "Dokumenti" usmjerene na entitete "Oprema", "Programi" i "Podaci" odgovaraju iskazu problema (poslovni zahtjevi). Vratimo se našem primjeru iz kojeg vidimo da se za razvoj TOR, TP, testiranje i implementaciju skladišta podataka koriste znanja o sistemskoj arhitekturi računovodstvenog sistema koji je već u komercijalnom radu, a njegova sistemska arhitektura je trenutno u faza upotrebe. Arhitektura sistema skladišta podataka je trenutno u fazi projektovanja (vidi sliku 8).
Funkcije aktivnih učesnika u fazi "Dizajn" prikazane su u tabeli. 3 .

Tabela 3

Migracija

Faza životnog ciklusa arhitekture sistema "Migracija" odgovara sledećim fazama životnog ciklusa softverskih alata:

• Testiranje softvera.
• Implementacija softvera.

Funkcije aktivnih učesnika u fazi „Migracije“ prikazane su u tabeli. četiri .

Tabela 4

Dakle, arhitektura sistema je stvarno pogođena u sljedećim fazama životnog ciklusa softvera:

• U fazi "Razvoj tehničkih specifikacija za PS" vrši se analiza postojeće arhitekture sistema u cilju utvrđivanja mogućnosti i svrsishodnosti korištenja postojećih resursa za rješavanje novopostavljenih poslovnih problema. Osim toga, prilikom izrade projektnog zadatka, zahtjevi i ograničenja koja nameće postojeća arhitektura sistema uzimaju se u obzir kad god je to moguće.
• U fazi "Izrada tehničkog projekta PS" vrši se stvarno formiranje ili promjena arhitekture sistema, što je neophodno za realizaciju novopostavljenih poslovnih zadataka. Zahtjevi i ograničenja koja nameće postojeća arhitektura sistema uzimaju se u obzir kako bi se osigurao kontinuitet i minimizirali troškovi nadogradnje.
• O fazama "Testiranje" i "Implementacija" od razvijenog softvera, zahtjevi arhitekture sistema se koriste za formiranje potrebnog tehnološkog okruženja za testiranje i rad ovih PS.

Sastav baze znanja o arhitekturi sistema

Budući da su samo liste onoga što trebate znati o arhitekturi sistema vrlo velike za prezentaciju u članku u časopisu (oni iznose desetine pozicija), u nastavku su opisani samo dijelovi relevantne baze znanja i pokušava se barem ocrtati sadržaj ovih sekcija.
Baza znanja o arhitekturi sistema treba da se sastoji od najmanje tri sekcije:

1. Trenutna arhitektura sistema.
2. Perspektivna (planirana) arhitektura sistema.
3. Planovi migracije.

Odjeljci "Trenutna arhitektura sistema" i "Prospektivna arhitektura sistema" imaju istu strukturu i sastoje se od sljedećih pododjeljaka:

1. Principi arhitekture sistema zgrada.
2. Osnovna tehničko-tehnološka rješenja.
3. Zahtjevi i standardi.
4. Primijenjena arhitektura.
5. Tehnička arhitektura.
6. Arhitektura podataka.

Principi konstrukcije

Dati su zahtjevi i ograničenja koja se nameću arhitekturi sistema sa strane poslovne arhitekture. Naznačeni su svi zahtevi i ograničenja – kako formulisani direktno u poslovnoj arhitekturi, tako i ona dodatna koja formuliše arhitekta sistema.
Dat je opis principa izgradnje arhitekture sistema koji proizilaze iz gore navedenih zahtjeva i ograničenja.

Glavne odluke

Opisana su glavna tehničko-tehnološka rješenja koja čine osnovu arhitekture sistema. Na primjer, to može biti odluka da se AS/400 računalo koristi kao glavna hardverska platforma informacionog sistema banke, ili odluka da se koristi DB2 DBMS kao glavni alat za upravljanje informacionim resursima banke.
Svaka odluka je popraćena komentarom koji objašnjava kako ovu odluku odgovara gore formulisanim principima izgradnje arhitekture sistema.
Glavne odluke koje se donose tokom projektovanja arhitekture sistema su sastavljene u posebnim dokumentima, sa kratkim pregledom pozadine, suštine problema i usvojenog fundamentalnog rešenja problema, koje je obavezno u budućnosti prilikom projektovanja, razvoja. i implementaciju informacionog sistema.

Zahtjevi i standardi

Specificirani su svi zahtjevi, standardi i ograničenja sa kojima je arhitektura sistema usklađena. Ako je potrebno, pojedinačni standardi (zahtjevi, ograničenja) ili reference na njih mogu se duplirati u narednim poglavljima.
Date su reference (šifra, naziv, izdanje, itd.) na eksterne standarde. Po potrebi se daju puni ili djelomični tekstovi eksternih standarda.
Opisani su interni standardi (standardi preduzeća), navodeći šifru (ako je dodijeljena), naziv, izdanje i tijelo koje odobrava.
Opisani su dodatni zahtjevi i ograničenja koja moraju zadovoljiti arhitektura sistema i elementi informacijske infrastrukture koji nisu dobili status standarda.
Objašnjeno je koji su to konkretni principi izgradnje arhitekture sistema ili usvojena osnovna tehničko-tehnološka rješenja iziskivali korištenje/razmatranje ovog standarda/zahtjeva ili ograničenja.

Arhitektura aplikacije

Opisani su primijenjeni sistemi (aplikacije) koji osiguravaju izvršavanje poslovnih funkcija i poslovnih procesa i njihovu interakciju. Nivo detalja opisa treba da odgovara programskom modulu, shvaćenom kao programska jedinica, nezavisno pohranjena kao datoteka ili dio biblioteke.

Tehnička arhitektura

Mrežna arhitektura

Sadrži opise teritorijalne komunikacione infrastrukture i lokalnih mreža (LAN).

Arhitektura platforme

Sadrži opis operativnih sistema i opreme odvojeno za servere i radne stanice.

Arhitektura podataka

Baze podataka i skladišta podataka

Sadrži opis baza podataka i drugačije organiziranih nizova informacija.

Sistemi upravljanja bazama podataka

Sadrži opis korištenih sistema upravljanja bazom podataka.

Plan migracije

Sadrži plan migracije sa trenutne arhitekture sistema u budućnost.
Ako se očekuje fazna migracija, onda su ovdje uključeni i posredni planovi migracije.
Kao što je ranije pomenuto, plan migracije je formalizovan kao nacrt. Dakle, za svaki plan, odjeljak uključuje sve dokumente predviđene metodologijom upravljanja projektima Banke, kako odobrene, tako i one u izradi ili odobrenju.

Zaključak

Gore smo pokazali da je sastav i sadržaj znanja o arhitekturi sistema duboko strukturiran skup visoko međusobno povezanih informacija. Štaviše, odnosi nisu ograničeni na odnose između entiteta arhitekture sistema (vidi sliku 3), već su takođe blisko povezani sa entitetima poslovne arhitekture. Dakle, u praksi često postaje neophodno pronaći odgovor na sljedeća pitanja:

• Ko u banci obavlja ovu ili onu poslovnu funkciju, koliko redovno, koji događaj pokreće izvršenje ove poslovne funkcije, da li je automatizovana ili ne, ili je izvršenje ove poslovne funkcije?
• Koje informacije se unose za određenu poslovnu funkciju, ko je dobavljač ovih informacija, u kom obliku dolaze?
• Koji softverski alati se koriste za obavljanje određene poslovne funkcije, koje druge IT funkcije obavljaju ovi programi, koje baze podataka i direktorije se koriste, koje ekrane i koje izvještaje generiše program?
• Koje su informacije dolazne i odlazne za određeni program, u kom obliku dolaze dolazne informacije i formiraju se odlazne informacije?
• Kako je organizovana informaciona interakcija dva programa: kroz formiranje/čitanje fajla, direktno preko API-ja, preko e-pošte, preko sistema na nivou srednjeg softvera, kakva je struktura razmene informacija, koja je frekvencija?
• Koja odjeljenja koriste određeni program, koga treba obavijestiti kada se program ili bilo koji propis promijeni?
• Da li se trenutno koristi ova ili ona IT funkcija programa, ko, koliko često?

Naravno, postoje i mnoga druga pitanja koja su na neki način povezana sa sistemskom i poslovnom arhitekturom.
Zbog ograničene veličine članka u časopisu, analiza ovih problema je izvan njegovog okvira. Napominjemo samo da su za strukturiranje i dokumentovanje ovog znanja neophodne mogućnosti MS Word-a ili MS Excel-a. Potrebno je koristiti naprednije softverski sistemi, ali još važnije je korištenje odgovarajućih tehnika ili čak metodologija. Jedna od ovih smjernica, koja, prema iskustvu autora, ispunjava potrebne zahtjeve, jeste „ARIS metodologija“ (ARhitektura integrisanog informacionog sistema). Međutim, ovo je sasvim druga tema, možda za neki drugi članak.

Na mnogo načina, opravdanje potrebe za razvojem modela poslovne arhitekture povezano je sa razumijevanjem faktora koji podstiču preduzeće na traženje rješenja za optimizaciju u oblasti organizacionih aktivnosti. Ovi faktori mogu uključivati ​​makroekonomske trendove, konkurentsko okruženje, promjene u poslovnim strategijama, itd. Poznavanje ovih faktora i njihovo povezivanje sa mogućnostima rješavanja problema modeliranja poslovne arhitekture je kritično za podršku projekta sa najvišim menadžmentom organizacije.

Problem potvrđivanja potrebe i budžeta projekta za kreiranje modela poslovne arhitekture povezan je ne samo sa identifikacijom „pokretačkih“ faktora, već i sa složenošću potvrđivanja očekivanih efekata. U mnogim slučajevima, u početnoj fazi, moguće je samo deklarisati procjene u vezi sa indirektnim unapređenjem poslovanja organizacije, koje je teško uporediti sa jasno definisanim finansijskim koristima. Čak i u slučaju nastanka događaja sa mjerljivim efektima, dokaz direktne povezanosti ovih događaja sa izgradnjom i implementacijom modela poslovne arhitekture u procesu upravljanja organizacijom nije uvijek moguć.

Teško je dati bilo kakve generalne pristupe koji bi potkrijepili očekivano ekonomski efekti zbog pojave aktuelnog modela poslovne arhitekture u organizaciji. Na mnogo načina, konačni dobitak je određen jedinstvenošću situacije svake pojedine organizacije. To može biti uspješan reinženjering poslovnih procesa, optimizacija informacijske i tehnološke infrastrukture, smanjenje vremena i troškova za dobijanje početnih podataka pri pokretanju projekata i sl., implementirano na bazi korištenja modela.

U najopštijem pristupu, efekte kreiranja modela poslovne arhitekture treba pozicionirati sa povećanjem ukupne upravljivosti preduzeća. Što se tiče IT komponente arhitekture preduzeća, svetska praksa ukazuje na mogućnost smanjenja troškova po zaposlenom i do 30%, dok nepostojanje dokumentovane IT arhitekture povlači dodatne troškove do 12-18% u nizu operativnih sistema. oblasti.

Ukoliko je potrebno dobiti procjene o „integralnim“ efektima od implementacije modela poslovne arhitekture, uzimanje u obzir samo finansijskih koristi neće biti dovoljno da opravda ulaganje. Stoga će biti neophodno koristiti složenije mehanizme poravnanja, uključujući i „nefinansijske“ efekte koji su značajni za aktivnosti organizacije. Ova vrsta efekata treba da uključuje minimiziranje rizika tokom različitih promena u aktivnostima organizacije kroz korišćenje mogućnosti modela poslovne arhitekture za simulaciju različitih opcija scenarija, uključujući dobijanje različitih kvalitativnih i kvantitativne procjene. S obzirom na visoku dinamiku promjena i složenost moderna organizacija, pitanja minimiziranja rizika povezanih sa pitanjima restrukturiranja su od posebnog značaja.

Karakteristika investicionih projekata za kreiranje modela poslovne arhitekture je prilično dugo vreme čekanja na jasno uočene efekte. U određenoj mjeri, ovdje možemo povući analogiju sa očekivanjima povrata troškova za obuku osoblja kako bi se poboljšala ukupna informaciona ili projektna kultura. Kao dio obrazloženja efektivnosti arhitekture IT komponenti, trenutno se razmatraju mogućnosti korištenja indikatora kao što su povrat na sredstva (ROA) i povrat na priliku.

Jedno od početnih standardnih pitanja čelnika organizacije, koji ranije nisu bili upoznati sa mogućnostima i zadacima modeliranja poslovnih procesa, jeste da se razjasne očekivana korist od rezultata konsultantskog rada modeliranja.

Često su standardni odgovori na ova pitanja povezani s naglaskom na optimizaciji poslovnih procesa organizacije i, u skladu s tim, navođenjem "osnovnog skupa" parametara optimizacije:

♦ dupliciranje funkcija;

♦ uska grla;

♦ mjesta troškova;

♦ kvalitet pojedinačnih operacija;

♦ redundantne transakcije;

♦ mogućnosti automatizacije;

♦ mogućnost uvođenja sistema upravljanja kvalitetom;

♦ mogućnost sertifikacije prema ISO 900x.

Uz svu tačnost ovih odgovora, mora se priznati da sa stanovišta redoslijeda rada i postizanja rezultata oni nisu prioritet.

Sasvim nezavisan, važan i prvi koji se postiže je rezultat u pogledu naručivanja i dokumentovanja znanja o organizaciji. U sklopu izgradnje modela neizbježno se dešavaju sljedeći procesi:

♦ inventarizacija i izvlačenje iz različitih izvora (uključujući i pojedinačne kvalifikovane zaposlene) informacija (znanja) specifičnih sa stanovišta aktivnosti organizacije;

♦ strukturiranje i sistematizacija izdvojenih informacija, uzimajući u obzir glavne ciljeve i zadatke organizacije;

♦ formalizacija i dokumentovanje informacija (znanja) o organizaciji.

Očigledno, bez obzira na ciljeve optimizacije, kvalitativna akumulacija, strukturiranje i formalizacija informacija (znanja) su veoma važni sa stanovišta:

♦ tehnološka podrška procesima očuvanja znanja organizacije;

♦ smanjenje zavisnosti od ključnih stručnih resursa za prenošenje znanja i kompetencija na nove zaposlene;

♦ povećanje nivoa upravljivosti organizacije kroz formalizaciju zahtjevi posla i uputstva osoblju.

Po pravilu, nakon sistematizacije i formalizacije znanja o trenutnom stanju aktivnosti organizacije, čak i prije opisivanja procesa i odabira metode za njihovu optimizaciju (reinženjering), na osnovu specijalizovanih alata za modeliranje, identifikuju se organizacione i tehnološke rezerve. koji se mogu koristiti za poboljšanje efikasnosti organizacije.

U fazi sistematizacije i formalizacije vrši se stvarna provjera dostupnosti i jasnoće definicije i, ako je potrebno, pojašnjenje tako važnih podataka za organizaciju kao što su:

♦ zadaci;

♦ indikatori učinka;

♦ propisi (uputstva, nalozi, itd.) poslovnih procesa.

U velikom broju slučajeva može se reći da su normativne smjernice jednako izvršne i provjerljive u smislu kvaliteta izvršenja koliko i formalizirane. U tom smislu, u fazi sistematizacije i formalizacije, provjerava se „izvodljivost“ ciljeva i propisa (standarda).

Stoga je ispravan odgovor potencijalnom kupcu na pitanje „zašto nam je potreban model“ poslovne arhitekture organizacije da ukaže na najmanje dva fundamentalno važna rezultata (cilja):

♦ sistematizacija i dokumentovanje (formalizacija) informacija (znanja) značajnih za delatnost, čime se obezbeđuje:

a) tehnološku osnovu za unutarkorporativno očuvanje i dostupnost specijalizovanog znanja (know-how) organizacije;

b) povećanje nivoa upravljivosti resursa organizacije zbog kvalitativne formalizacije propisa za njihovo korišćenje (Sl. 1);

Rice. 1. Problemi upravljanja znanjem u organizaciji u smislu poslovnih procesa

♦ stvaranje metodološke i tehnološke osnove za faznu optimizaciju (reinženjering) organizacije, koja omogućava tehničku i ekonomsku procjenu mjera modernizacije, identifikaciju organizacionih, funkcionalnih i tehnoloških rezervi za poboljšanje efikasnosti organizacije (Sl. 2).

Rice. 2. Obećavajuće odluke o korištenju znanja o poslovnim procesima prilikom donošenja upravljačke odluke

Jedan od dodatnih argumenata u prilog potrebi modeliranja poslovne arhitekture organizacije su globalni trendovi u standardizaciji zahtjeva za obavezno prisustvo modela poslovnih procesa organizacije. Dokaz ovih trendova je pojava specijalizovanih standarda i metodologija za projektovanje arhitekture preduzeća.

Kao glavne metodologije i standarde treba pomenuti „okvirne“ standarde za razvoj arhitekture preduzeća;

a) ISO 15704 - standard za formalni opis arhitekture preduzeća, koji je predložila radna grupa IFAC/IFIP (International Federation of Automatic Control/International Federation for Information Processing);

b) ISO 15288 je standard koji definiše životni ciklus sistemi;

c) ISO 12207 je standard koji definiše životni ciklus softvera.

Postoji preko 30 dodatnih "podržavajućih" sistema i standarda softverskog inženjeringa (npr. ISO 14258 koji definiše koncepte i pravila za modeliranje preduzeća).

Razvoj modela poslovne arhitekture je jedan od logičnih narednih koraka za one organizacije koje su počele da implementiraju koncept uslužno orijentisane arhitekture (SOA). U svojoj srži, SOA odražava karakteristike trenutne moderne situacije u međusobnom prodiranju IT-a i poslovanja, kada je izuzetno teško povući granicu između poslovnih funkcija organizacije i informacionih tehnologija koje ih pružaju.

Sa stanovišta SOA podrške, model poslovne arhitekture je glavni alat za sinhronizaciju poslovnih potreba i mogućnosti informacionih tehnologija. Upravo model poslovne arhitekture snosi glavni teret obezbeđivanja uslova za procesni pristup projektovanju i optimizaciji same poslovne arhitekture organizacije, nakon čega sledi IT dizajn. Prema SOA konceptu, poslovna arhitektura treba da se zasniva na modelu preduzeća orijentisanom na proces. Kombinacija ovog pristupa sa konceptom uslužno orijentisane arhitekture informacionih tehnologija omogućava vam da bolje povežete proces razvoja komponenti informacionih sistema sa misijom, glavnim zadacima i funkcijama organizacija. Sa SOA-om, organizacije imaju potencijal da razviju skup implementacija različitih poslovnih procesa koje preduzeće može ponovo koristiti kao gotove usluge.

Izjave o zadacima za modeliranje poslovne arhitekture u kontekstu SOA podrške imaju za cilj da obezbede sledeće zahteve za projektovanje IS:

♦ eksplicitno odvajanje poslovne logike primijenjenog sistema od logike prezentacije informacija;

♦ implementacija poslovne logike primijenjenog sistema u vidu većeg broja programskih modula (servisa) koji su dostupni izvana (korisnicima i drugim modulima), najčešće u režimu „zahtjev-odgovor“, kroz dobro- definisani formalni pristupni interfejsi.

Istovremeno, „korisnik usluge“, koji može biti aplikacijski sistem ili neki drugi servis, ima mogućnost pozivanja usluge preko interfejsa koristeći odgovarajuće komunikacione mehanizme, a takođe jasno pozicionira svoje mesto u poslovnom procesu.

Pored uloge „pružanja“, odnosno podrške implementaciji SOA koncepta, model poslovne arhitekture ima samostalan značaj i odgovarajuće definicije zadataka. Visoka dinamika promjena u okruženju savremeno poslovanje, ne može a da ne utiče na brzinu i obim razvoja poslovnog modeliranja. Izrada dugoročnih prognoza na osnovu stabilnosti situacije nije moguća u gotovo svim oblastima poslovanja. Naprotiv, kompanije se moraju prilagoditi okruženju koje se stalno mijenja i razviti vještine za brzo prilagođavanje tekućim poslovnim promjenama. S tim u vezi, trenutno se razvijaju koncepti organizacija koji sadrže posebne interne mehanizme koji im omogućavaju da se mijenjaju u skladu sa zahtjevima vanjskog okruženja.

Sve veća uloga poslovnog modeliranja determinisana je ne samo visokom dinamikom okruženja „životne aktivnosti“ organizacije, već i okolnostima da resurs mogućnosti da se na „izazove“ tržišta efikasno odgovori samo putem IT-a ima značajno smanjena. Sve češće se pojavljuju izjave da se haos ne može automatizirati, da je automatizacija haosa još veći haos, da se moderni IT ne može smatrati lijekom za sve poslovne probleme.

Glavne rezerve za povećanje efikasnosti i konkurentnosti preduzeća trenutno su povezane sa optimizacijom njihove poslovne arhitekture, doslednom implementacijom modela upravljanja procesima i obezbeđivanjem fleksibilnosti. organizacijske strukture i poslovni procesi koji se odnose na upravljanje dodanom vrednošću i dr. Ove mogućnosti u velikoj meri pruža detaljna poslovna arhitektura preduzeća, koja treba da sadrži opis procesa promene u organizaciji delatnosti preduzeća, kao i da obezbedi efektivno upravljanje ove procese.

Razvoj modela poslovne arhitekture omogućava preduzeću da se obezbedi univerzalni alat koji doprinosi, pre svega, svesti o sopstvenoj strukturi i metodama organizacije. proizvodni procesi. Ovaj model vam omogućava da formirate plan za promociju organizacije u oblasti poslovanja i novih tehnologija.

Dobro osmišljena arhitektura može i treba da se koristi od strane menadžmenta preduzeća u cilju proučavanja principa njegovog funkcionisanja, a takođe omogućava razvoj novih, naprednijih strategija, organizovanje novih načina planiranja razvoja, uzimajući u obzir potreba za ispunjavanjem stalno promenljivih eksternih uslova (naravno, govorimo o srednjoročnom i dugoročnom planiranju). Takva arhitektura omogućava brzo reagovanje i fleksibilnost, što je posledica izbora odgovarajućih oblika organizacije, posebnog razvoja procesa i upotrebe određenih klasa informacionih sistema.

U prilog ovim tezama o ulozi i mjestu poslovnog modeliranja možemo navesti izjavu Gartnerovog analitičara Džima Sinura (Jim Sinur): modeliranje u posljednje vrijeme“. Općenito, treba napomenuti da za razne stručno mišljenje većina preduzeća će voditi projekte koji će na ovaj ili onaj način uticati na različite aspekte problema poboljšanja poslovnih procesa, uprkos mješovitim procjenama prakse reinženjeringa poslovnih procesa sredinom 1990-ih.

Pored metodoloških inovacija i trendova u razvoju poslovne organizacije i IT-a, na razvoj tržišta potreba poslovnog modeliranja značajno utiču i savremeni pristupi procjenom stepena razvijenosti (zrelosti) organizacije. U okviru ovih pristupa, model poslovne arhitekture je obavezna komponenta za procjenu organizacije.

Kao primer metodologije koja se koristi u razvijenim zemljama za procenu zrelosti javnih organizacija, možemo navesti model Uprave za finansijsku kontrolu SAD, koji definiše pet nivoa zrelosti.

Upotreba poslovnog modela u aktivnostima organizacije otvara široke mogućnosti za kvalitativnu i kvantitativnu procjenu njene učinkovitosti, uključujući korištenje općeprihvaćenih (standardiziranih) metodologija i alata. Zapravo, poslovni model vam omogućava da osigurate mjerljivost ključnih karakteristika organizacije korištenjem odgovarajućih metrika: metrika za procjenu „kvaliteta“ samog procesa, metrika za procjenu direktnih rezultata (outputa), metrika za procjenu konačnih rezultata .

Metrike na nivou procesa mjere efikasnost samog procesa. Tipične metrike su vrijeme ciklusa, cijena po transakciji ili rezultat procesa. metrika ishoda procjenjuje sposobnost procesa da proizvede proizvod ili uslugu kao rezultat prema specifikacijama. Tipične metrike za procjenu direktnih rezultata su postotak grešaka i broj serviranih zahtjeva po jedinici vremena. metrika evaluacije ishoda procjenjuje proces sa stanovišta krajnjeg korisnika (kupca) i performanse funkcija organizacije.

Očigledno je da se postavljanje zadataka za modeliranje za proizvodnu (komercijalnu) organizaciju može značajno razlikovati od zadataka državnog kontrolnog (nadzornog) tijela. Iz tog razloga, naravno, potrebno je specifično prilagođavanje svake od metoda visokog nivoa području modeliranja. Tržište konsultantskih usluga sasvim adekvatno odgovara na ovu potrebu. Dakle, trenutno postoje praktično značajni modeli za različite sektore privrede i državne agencije, koji se implementiraju na osnovu različitih metodologija i alata za modeliranje, kao što su ARIS metodologija i IDS Sheer AG porodica softverskih proizvoda zasnovanih na njoj, jezik UML modeliranje i Rational Rose alat za razvoj informacionih sistema orijentisanih na objekte od IBM-a, IDEF metodologiju, DFD i AllFusion Modeling Suite (ranije BPwin i ERwin) od Computer Associates, itd.

Bez sumnje, kada preduzeće postavlja zadatke na svoj način, međunarodna certifikacija i izlaskom na tržišta razvijenih stranih zemalja, posebno je relevantan razvoj modela poslovnih procesa. Iz tog razloga, pokretanje ovih radova u preduzeću nije "počast" novoj "modi". Bez sumnje, stvaranje i naknadna podrška modela neće samo pozitivan uticaj na cjelokupni imidž organizacije, ali će također pomoći da se poboljša cjelokupno upravljanje i proizvodna kultura poduzeća. U određenoj mjeri, buđenje interesa organa državna vlast(OGV) i poslovne zajednice modeliranje poslovnih procesa može se uporediti sa ranijim i široko korištenim procesom uvođenja metoda i tehnologija upravljanja projektima.

Treba napomenuti da su OGV Ruske Federacije, koji su odgovorni za formiranje naučne i tehničke politike u različitim oblastima, provedbu administrativnih reformi, prilično "osjetljivo" reagirali na gore navedene globalne trendove i odredili ciljne zadatke za njihovo razmatranje. u Ruskoj Federaciji.

Stanje formalizacije i, na osnovu toga, optimizacija administrativnih i upravljačkih procesa OGV definisano je u dokumentu „Strategija razvoja i korišćenja informaciono-komunikacionih tehnologija u Ruskoj Federaciji“ kao glavni indikatori planiranih aktivnosti. Tabela u nastavku odražava trenutno stanje, izglede i državnu politiku o uvođenju poslovnog modeliranja u aktivnosti OGV Ruske Federacije (Tabela 1).

Ovako povećana pažnja državnih organa Ruske Federacije na problem uvođenja formaliziranih mehanizama za opisivanje aktivnosti državnih organizacija sasvim je opravdana. Uprkos činjenici da zbog svoje specifičnosti državne organizacije imaju veću (u poređenju sa komercijalnim strukturama) inerciju i selektivnost u reagovanju na promene tržišta, sadašnja „nagomilana masa“ potreba dostigla je kritičnu tačku.

Trenutno se menadžerski i izvršni nivo javnih organizacija često suočava sa mnogo značajnijim problemima od komercijalnog sektora. Prije svega, to je potreba da se u svom djelovanju obavezno koristi regulatorni i pravni okvir, koji je prilično opširan, složen i često dozvoljava dvosmisleno tumačenje. Broj zakonskih i podzakonskih akata federalne i resorne prirode se kreće stotinama i hiljadama, broj vrsta operativnih dokumenata i podataka koji se obrađuju u pojedinim ministarstvima i resorima dostiže nekoliko stotina. Često je izvođenje procesa organizovano na način da jedan zaposleni ima obim posla koji prevazilazi razumne standarde, a da istovremeno snosi ozbiljnu administrativnu i krivičnu odgovornost. U ovim okolnostima, stvaranje uslova za efikasan i zakonit rad državnih službenika je izuzetno hitan zadatak i država preduzima odgovarajuće korake da ga riješi:

♦ uvodi se elektronska administrativna regulativa;

♦ formiraju se mehanizmi informacione i konsultantske podrške;

♦ optimizuje se organizaciona struktura.

To potvrđuju i administrativna reforma, inicijative za masovnije uvođenje elektronske administrativne regulative, formiranje e-uprave itd. U svim ovim projektima formiranje i optimizacija poslovnih modela je preliminarni proces koji određuje osnovne početne podaci.

U vezi sa pitanjem „zašto nam treba model“ je i pitanje „kome treba“ model. Pitanje definicije potencijalni potrošači(korisnici) modela je ključ za specificiranje i detaljiziranje ciljeva. Modeliranje poslovnih procesa može pokriti različite aspekte preduzeća: glavnu i formutivnu infrastrukturu preduzeća. Shodno tome, krug zainteresovanih lica u vidu menadžera i izvođača biće određen pravcem aktivnosti organizacije odabranim (izabranim) za modeliranje.

Na nivou odjeljenja preduzeća, kao zainteresirani potrošači modela mogu djelovati: administrativni aparat, odjeli informacionih tehnologija, kadrovski odjeli, pravni odjeli itd.

Istovremeno, prilično velika publika stručnjaka i menadžera može djelovati kao korisnici modela poslovne arhitekture poduzeća unutar odjela:

♦ poslovnu analitiku u različitim oblastima predmetne (ciljne) djelatnosti organizacije;

♦ programeri informacija i tehnološkim sistemima;

♦ sistemski arhitekti, koji su odgovorni za kreiranje arhitekture pojedinačnih informacionih sistema;

♦ poslovni analitičari koji vode proces dizajniranja organizacione strukture;

♦ menadžeri koji su zainteresovani za sistematsku, strukturiranu analizu problema i mogućnosti koje se otvaraju za poslovanje, itd.

U principu, inicijativa za modeliranje poslovnih procesa može doći od bilo kojeg odjela poduzeća. Zavisi od nivoa svijesti šefova odjela o mogućnostima i korisnosti modela, prioriteta tekućih zadataka optimizacije aktivnosti, potpunosti modeliranja pojedinačnih poslovnih procesa preduzeća.

U stvarnosti, u većini slučajeva, inicijativa za razvoj modela poslovnih procesa dolazi od odjela informacionih tehnologija u organizaciji. To je zbog potrebe automatizacije pojedinih oblasti aktivnosti preduzeća na pozadini opšte visoke aktivnosti u implementaciji IT-a u svim oblastima poslovanja i sve većeg udela u budžetima preduzeća za IT komponentu.

Uz svu pozitivnost same činjenice aktivnosti IT odjela (kao i svakog drugog funkcionalnog odjela) u implementaciji poslovnog modeliranja, ispravno je zadržati inicijativu i kontrolu ovog procesa za najviši menadžment organizacije. Ovo će izbjeći "usko odjeljenje" čisto IT (ili neki drugi) pristup modeliranju, usmjeren na rješavanje određenog zadatka nakon činjenice - automatizaciju zasebnog procesa i pružanje rješenja za korporativni zadatak - stvaranje alata za procjenu i optimizaciju poslovanja procesa u okviru postizanja performansi cilja čitavu organizaciju.

Podrška i generalni menadžment Uvođenjem modela poslovne arhitekture u preduzeće ne isključuju niti umanjuju ulogu funkcionalnih jedinica u ovom radu. Što model postaje „širi“ i „dublji“, što je „bliži“ korisniku, to se veći broj zainteresovanih strana pojavljuje u njegovom razvoju i podršci.

Kao rezultat modeliranja aktivnosti preduzeća u okviru procesnog pristupa, „neminovno“ dolazi do postepenog (kako je model detaljan) prikazivanja uloge, mesta, efekta koje uvode sve organizacione i kadrovske strukture preduzeća. . Iz tog razloga, osiguravajući da se značaj jedinice adekvatno odražava u opšti model preduzeća, kao i naknadna potraga za povećanjem „doprinosa“ ciljnim rezultatima preduzeća, odnosno „smanjenjem“ troškova jedinice, isprovocirati će rukovodioce ovih jedinica da aktivno učestvuju u izgradnji model poslovne arhitekture.

U određenoj mjeri, pitanje „kome treba poslovni model“ može se uporediti sa pitanjem „kome treba elektronsko upravljanje dokumentima". Od nekog trenutka, radni tok koriste svi, a svako odeljenje učestvuje u postavljanju zadataka za kreiranje specijalizovanih elektronskih propisa za podršku „svog“ dela toka rada i njihovu „revnosnu“ zaštitu, a u vezi sa poslovnim modeliranjem, svako odeljenje počinje da gradi "svoj sopstveni deo" modela poslovne arhitekture velike zgrade.

Postavljanje ciljeva, implementacija, implementacija i skaliranje rezultata projekata modeliranja poslovnih procesa značajne su prekretnice u promjeni ukupne korporativne kulture preduzeća. Zaposleni postepeno stiču znanja, vještine i iskustva procesnog pristupa u obavljanju svojih aktivnosti, jasno se pozicioniraju u složenoj strukturi organizacije, ovladavaju savremenim metodama vrednovanja rezultata svog rada i pronalaženja načina da ga optimiziraju.

Kreiranje modela poslovne arhitekture je svojevrsno zbirno informaciono, tehnološko i organizaciono okruženje za prikazivanje i implementaciju procesnog pristupa preduzeća. Ovo okruženje, koje, s jedne strane, omogućava svakoj zainteresovanoj osobi da „iznese“ kvalitativne i kvantitativne predloge za unapređenje delatnosti preduzeća, a sa druge strane, svim učesnicima da objektivno procene „pozitivne“ i „negativne“ aspekte. prijedloga.

Pored povećanja „svesti“ učesnika u poslovnim procesima o njihovoj misiji u aktivnostima preduzeća, „nova“ korporativna kultura obezbeđuje obaveznu dokumentaciju i čuvanje istorije svih promena u vezi sa ciljnom delatnošću preduzeća. preduzeće. Takav pedantan i kvalitativno formalizovan odnos prema godinama akumuliranog znanja u organizaciji je osnova za njihovo efikasno korišćenje.

Širenje zainteresovanih učesnika u izgradnji modela i formiranje nove kulture korporativnog upravljanja u većoj meri uslov je i/ili posledica projekta modeliranja. Praktični koraci za implementaciju projekta formiraju se na osnovu razumijevanja sadržaja ciljnih zadataka za modeliranje.

Zadaci modeliranja proizlaze iz ciljeva koje je formulisala organizacija da unapredi svoje aktivnosti. Kao što je gore navedeno, ciljni zadaci za modeliranje poslovnih procesa raspoređeni su u dva glavna područja:

1) sistematizacija i formalizacija - izgradnja deskriptivnih modela;

2) konstrukcija analitičkih i optimizacijskih modela.

Unutar odabranih oblasti može se izvršiti dodatna podjela oblasti, uzimajući u obzir prisustvo dva glavna tipa istraživanja, odnosno samih poslovnih procesa i resursa uključenih u poslovne procese. Na osnovu toga, podzadaci kao što su:

1) kvalitativna i kvantitativna procjena (optimizacija) realizovanih poslovnih procesa;

2) kvalitativna i kvantitativna procena (optimizacija) korišćenja resursa organizacije u okviru tekućih poslovnih procesa.

U odnosu na poslovne procese, zadaci modeliranja se mogu podijeliti na tipove procesa: jezgro, omogućavanje, eksterna interakcija i razvoj (vidi Poglavlje 2). Što se tiče "neprocesnih" istraživačkih objekata, zadaci modeliranja se mogu specificirati za procese formalizacije ciljeva preduzeća, organizacione strukture, tehnološke strukture, informaciona struktura, arhitektura poslovnih funkcija, regulatorni okvir, ključni indikatori aktivnosti itd.

Dodatna sistematizacija zadataka modeliranja može se povezati sa implementiranim metodama za konstruisanje i korišćenje modela poslovne arhitekture preduzeća. Primjeri takvih zadataka mogu biti: funkcionalna analiza troškova, simulacijsko modeliranje, sistematizacija i formalizacija.

U praksi se prema odabranim oblastima postavljanja zadataka modeliranja poslovnih procesa grupišu sljedeća aktuelna pitanja na koja menadžment organizacije želi da dobije argumentirane odgovore:

♦ Koji su integralni troškovi i vremenski troškovi potrebni za implementaciju određenog poslovnog procesa (podprocesa)?

♦ Koji je sastav organizacionih, tehnoloških i informacionih resursa, kao i propisa, neophodan za obavljanje određenog poslovnog procesa?

♦ Koja je dinamika korišćenja organizacionih, tehnoloških i informacionih resursa neophodnih za završetak određenog poslovnog procesa?

♦ Koji resursi (organizacioni, tehnološki i informacioni) ili propisi su glavni ograničavajući faktori za proširenje sposobnosti organizacije da poveća kvalitativne i kvantitativne karakteristike poslovnih zadataka koji se rešavaju?

♦ Koje su operacije (poslovne funkcije) dodijeljene određenoj službenoj jedinici u okviru ciljne aktivnosti organizacije?

♦ Koja lista operacija ( rutiranje) treba da izvrši službena jedinica u slučaju pojave specifične standardne ili nestandardne situacije u vezi sa sprovođenjem ciljne aktivnosti organizacije?

♦ Koja kvalitativna i kvantitativna poboljšanja treba očekivati ​​nakon modernizacije (uvođenja novih) informacionih sistema, pravnih akata, organizacionih jedinica, proizvodnih tehnologija itd.

Navedeni pravci postavljanja zadataka čine grupu uslovno nazvanih zadataka za tehnološko projektovanje modela („arhitektonski“ zadaci). Istovremeno, objektivno, postoji nezavisna grupa zadataka povezanih s logikom organizacije izvođenja projekta modeliranja:

♦ definisanje faza;

♦ definisanje uloga u projektu;

♦ formiranje i upravljanje u projektnom timu, itd.

O ovoj listi zadataka, kao io realizaciji "arhitektonskih" zadataka, biće detaljnije reči u drugim odeljcima knjige.

Treba napomenuti da je kvalitativna formulacija iskaza problema za modeliranje poslovnih procesa u odnosu na profil, trenutno stanje i prioritet problema organizacije ključni uslov za uspjeh projekta. Treba jasno shvatiti da u postavljanju ciljeva treba da učestvuju ne samo svi zainteresovani, već i kompetentne osobe. Prilikom rješavanja ovakvih pitanja potrebno je isključiti moguće situacije zamjene poslovne kompetencije (na nivou pravne, tehnološke, menadžerske) informatičkom kompetencijom i obrnuto.

Sasvim prirodno i opravdano pitanje nakon saznanja kome je i zašto potreban model poslovne arhitekture je razjašnjenje parametara i fundamentalne mogućnosti otplate ovakvog konsultantskog projekta.

Ovakvo postavljanje pitanja, kao i formiranje odgovora na njega, ne razlikuje se mnogo od situacije kada se pokaže zašto je koncept informacionog sistema potreban pri pokretanju velikih projekata informatizacije organizacije.

Napori da se izgradi poslovna arhitektura, koja je predstavljena u obliku poslovnih modela, brzo se isplate i imaju veliki broj dodatne pogodnosti. Prednosti izgradnje modela poslovne arhitekture leže u dvije ravni: dodatne funkcije poslovanje i smanjenje troškova. Procjenjuje se da kreiranje poslovnih modela i prateća optimizacija troškova, čak i bez radikalnih poslovnih promjena, mogu omogućiti uštede do 10%. A prilikom modeliranja alternativnih opcija poslovnog procesa, organizacije mogu uštedjeti do 20%.

Počeo sam da radim sa jednom kompanijom na temu arhitekture preduzeća (Enterprise Architecture) i odlučio da ispravim svoje shvatanje EA, kako bih bio jasniji i jednostavniji. Publikacija Johna A. Zachmana iz 1987. godine "Okvir za arhitekturu informacionih sistema" generalno se smatra datumom rođenja EA, iako se sam termin pojavio u ranijim spisima. Uprkos činjenici da je arhitektura preduzeća prilično mlada stvar, već je uspela da pokvari svoju reputaciju. Kao i svaka druga arhitektura, arhitektura preduzeća nije dobro definisana (pogledajte, na primer, 10 definicija arhitekture preduzeća), ali ima veliki broj neuspešnih projekata (pogledajte Gartner identifikuje deset zamki arhitekture preduzeća ili 8 razloga zašto programi arhitekture preduzeća ne uspevaju) . Obično, nakon završetka projekta arhitekture preduzeća, možete čuti sljedeću frazu: Nacrtali smo sve potrebne slike, ali nemamo pojma kako izvući barem neku korist od toga.". Zato, hajde da pričamo o svemu od samog početka.

I počećemo izdaleka. Postoje dvije tačke gledišta o korisnosti informacijske tehnologije. Prema prvoj tački gledišta informacione tehnologije omogućavaju povećanje produktivnosti rada, tj. ljudi će raditi efikasnije ako se njihove aktivnosti automatizuju. Postoji i suprotna tačka gledišta, izražena, na primjer, u knjigama kao što su „Sjaj i siromaštvo informacijske tehnologije. Zašto IT nije konkurentska prednost" Nicholasa J. Carra ili "Šta biznis želi od IT" Terryja Whitea. Iznenađujuće, oba ova gledišta su tačna. Ali hajde da suzimo krug našeg razmišljanja i da ne govorimo o informacionim tehnologijama uopšte, već samo o poslovnim aplikacijama, tj. sistemi koji automatizuju poslovne procese organizacije. U početku, razvoj i implementacija ovakvih sistema donosi opipljiv efekat. Kada različiti zaposlenici počnu odražavati slične operacije u jednoj bazi podataka dostupnoj putem mreže s različitih radnih mjesta, međusobno komunicirati kroz takva rješenja i specijalizirati se za određene funkcije, njihova produktivnost se povećava. Ovo je mnogo bolje nego da se međusobno zovete telefonom ili razmjenjujete emocionalno nabijene poruke e-mail. Stoga se počinju automatizirati razni drugi procesi, možda ne tako česti i ne toliko potrebni. Efikasnost takve automatizacije nije tako visoka. Nisko viseće jabuke su već počupane i moramo izmisliti sofisticiranije načine da postignemo rezultat. U nekom trenutku, troškovi korištenja poslovnih aplikacija postaju veći od koristi koje proizlaze iz njihovog korištenja, ali više nije moguće zaustaviti overklokovanu lokomotivu. Razlog za ovaj prag je organska složenost informacionih sistema (IT Complexity). Zapravo, u nekom trenutku se jednostavno zbunimo oko toga šta radimo, a informacioni sistemi nam pomažu da se još više zbunimo. Arhitektura (preduzeće) je samo način da se kontroliše složenost svojstvena sistemima, da se ima na umu manje ili više adekvatna slika, dok se i dalje dozvoljava upravljanje ovom složenošću.

Sljedeći problem je što se takva slika ne može pripremiti za budućnost. (U ovom trenutku, arhitekte će vam reći mnogo fraza o različitim gledištima, pogledima, interesnim stranama i zabrinutostima). Stoga, da odgovorimo na pitanje „Zašto radimo arhitekturu preduzeća?“ potrebno od samog početka. Dozvolite mi da istaknem tri najčešća odgovora:

1. Imamo strategiju koja odgovara na pitanje šta želimo, ali ne znamo kako to učiniti.
2. Nemamo strategiju, ali imamo poplavu zahtjeva za promjenom koje ne možemo podnijeti.
3. Informacije o našim aktivnostima su kontradiktorne i nemamo vremena da u svakom slučaju otkrivamo zašto se to dešava.

(Ako mislite da postoje druge, češće opcije, navedite to u komentarima).

U prvom slučaju, moramo napraviti Strategije –> Plan. Uglavnom se radi o poslovnoj strategiji. Obično izgleda kao skup nekih delta između onoga što imate i onoga što želite, izraženo prilično jednostavnim terminima: tržišni udio u smislu prihoda, baze kupaca, itd. Generalno, znate, strategija je dokument o sutrašnjim ježevima , koji će postati današnji miševi. O tome šta bi u ovom slučaju trebalo učiniti pisaću u posebnoj poruci, ali za sada nekoliko riječi o tome kako organizirati takav proces. Po mom mišljenju, organizacioni oblik razvoja arhitekture preduzeća je projekat koji traje 8-16 nedelja. Metodologija - TOGAF ADM itd. Treba privući resurse, uglavnom interne. Rezultati projekta su: mapa puta, lista organizacionih i procesnih promjena, rizici, prijedlozi za praćenje i upravljanje kretanjem u datom pravcu. Općenito, sve što se u tradicionalnim projektima radi u fazi planiranja naziva se lijepom riječju glavni plan. O timu ovakvog projekta, skupu aktivnosti i artefaktima - isto u jednoj od sljedećih poruka.

Opcija broj 2: Upravljanje promjenama. Umjesto strategije, postoji niz različitih ciljeva za različite poslovne korisnike. Neki treba da smanje troškove, drugi treba da iznesu nove proizvode i usluge na tržište, a treći moraju da poboljšaju zadovoljstvo kupaca (ukratko pogledajte o arhitekturi preduzeća). Svi kupci su poštovani ljudi i svima je potrebna pomoć. Ali složenost je već porasla i ne razumijemo kako pomoći svima u isto vrijeme. jednostavno i Pogrešan način staviti sve u red lijepo ime, na primjer, "Jedinstvena lista prioriteta", a način raspodjele zadataka među informacionim sistemima - "Besplatna blagajna!" - ko može brže i jeftinije, poverićemo mu. Prava odluka- multifaktorska klasifikacija upita, drugim riječima - taksonomija. Metodologija - u stilu Zachmana. Organizacija – stvaranje funkcionalne jedinice. U prethodnoj napomeni Da li su poslovni analitičari prijatelji, komšije ili daleki rođaci? Napisao sam da će dolaskom i usvajanjem treće verzije BABOK-a poslovni analitičari moći da rade ovaj posao. Ali za sada ne mogu. Trenutno poslovni analitičari mogu odgovoriti na pitanje „Šta treba učiniti?”, a arhitekti rješenja mogu odgovoriti na pitanje „Kako to učiniti?”. Zahtijeva i odgovor na pitanje „Zašto?“, kako se ova promjena odnosi na postojeće proizvode i procese, druge promjene, aplikacije.

I konačno, situacija kada je složenost već pobijedila i čelnici organizacije imaju svijest o tome. o istima Slike, kojih nema kada su potrebni da bi se brzo riješio sporan problem i koji ostatak vremena leže potpuno beskorisni teret. Ova situacija govori o arhitektonskom spremištu. Možda negdje postoje slike koje opisuju arhitekturu, ali ako se ne mogu dobiti u roku od minut-dva, onda menadžer, i bilo koji menadžer, to neće učiniti sam, već će tražiti od nekog drugog da dobije sliku („Pozovite arhitektu ovdje !"). Ako osoba ne radi s aplikacijom barem jednom u 1-2 sedmice, onda to uopće neće raditi. Ako programer informacionog sistema nema jednostavne, razumljive i spremne za korišćenje API-je za dobijanje tipova klijenata, listu filijala, funkcionalnu organizacionu strukturu itd., onda će sigurno dodati još jednu ploču u svoj informacioni sistem , u kojem će natjerati korisnike da ponovo unose podatke iz ovih direktorija. Ne znam ni za jedan EA alat koji je podjednako pogodan za demonstriranje prekrasnih slika vrhunskim menadžerima i koji istovremeno posjeduje urođenu interoperabilnost za integraciju u stvarne poslovne aplikacije. Nadam se da će se takvi, prije ili kasnije, pojaviti. A onda će se opcija broj tri pretvoriti u jednostavan projekat za implementaciju informacionog sistema i njegovu kasniju upotrebu i razvoj.

Nastavlja se (priča o arhitekturi preduzeća)!