Kome treba Enterprise Architecture i zašto?

Copyright © 2009 Zabegalin E.V.

1 Trenutno stanje arhitektonskih metodologija i praksi

NA stranih zemalja, već je odavno metodološki i praktično razrađen određeni niz tema čiji je predmet arhitektura složenih organizacijski i tehnički objekti kao što su poduzeća, "elektroničke vlade", korporativni informacijski sustavi.

NA Rusija, unatoč činjenici da pojmovi "arhitektura informacijskog sustava"“Enterprise IT architecture”, “electronic governance architecture”, odavno su postale moderne i naširoko se koriste među IT stručnjacima, 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 ovom području uglavnom edukativne i popularizacijske prirode.

Stoga, ako govorimo o standardizaciji "arhitektonskih" metodologija u Rusiji i njihovoj kasnijoj širokoj praktičnoj primjeni u domaćim tvrtkama, čini se da je to pitanje neizvjesne budućnosti. Međutim, u praksi, za početak "arhitektonski" pokret na Ruska poduzeća potrebno sada.

"Enterprise Architecture", na ruskom "Enterprise Architecture" (AP), razvila se u opću disciplinu kao korak u povijesnom razvoju mnogih metodologija vezanih uz arhitekturu automatiziranih informacijskih sustava - to su metodologije J. Zachmana, St. . Spivak, CIMOSA, GERAM, TOGAF itd. Analiza ovog povijesnog procesa prikazana je dovoljno detaljno u.

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

Zachmanov okvir za arhitekturu poduzeća;

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

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

"Federal Enterprise Architecture" (FEA), koju provodi i razvija vlada SAD-a;

"Extended Enterprise Architecture Framework" (E2AF), razvijen od strane nezavisne organizacije "Institute For Enterprise Architecture Developments";

Open Group Architecture Framework (TOGAF).

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

Napominje se da se značajan interes za temu AP objašnjava hitnom potrebom suvremenih menadžera i analitičara za višedimenzionalnim sustavnim opisom i planiranjem procesa razvoja organizacija (uključujući poduzeća). Zanimanje za takav opis diktirano je, u najmanju ruku, praktičnom potrebom da se o postojećoj strukturi organizacije uvijek ima dovoljno smislenih znanja, koja se mogu koristiti i za racionalno planiranje transformacije organizacije u promjenjivim uvjetima. Ako je takvo znanje dostupno, održavano i korišteno u organizaciji u otuđenom obliku, ono se pretvara u učinkovit upravljački alat. To posebno vrijedi za nove voditelje i menadžere organizacija (poduzeća).

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

U isto vrijeme, razina apstraktnosti i složenosti većine navedenih metodologija ostaje vrlo visoka i može spriječiti njihovu učinkovitu upotrebu u organizacijama od strane njihovih praktičnih menadžera i stručnjaka. drugačija vrsta Predložene "matrice" i "kocke" u navedenim metodologijama mogu se činiti nepotrebno umjetnima i stoga neprikladnima za praktičnu upotrebu. Tako se, na primjer, čini da je priroda iste "Zachmanove matrice" više filozofska nego praktična inženjeringa, radije je shematski vizualizirana specifikacija sustavnog pristupa analizi velikih i složeno strukturiranih organizacijskih i tehničkih objekata. Međutim, to ni najmanje ne negira ogromnu metodološku vrijednost i praktični značaj razvoja discipline AP.

U interesu praktične primjene EA discipline, prevladavanje te artificijelnosti može se započeti traženjem odgovora na pitanje: kome i zašto u poduzeću može trebati “Enterprise Architecture”?

2 Svrha "Enterprise Architecture"

Slika 2 shematski prikazuje strukturu i sadržaj generaliziranog poduzeća. Iz ove sheme se može vidjeti da AP, razmatran i korišten kao model, može biti praktički tražen u poduzeću samo kao alat za upravljanje, jer ni tehničko ni proizvodno osoblje ne treba AP za obavljanje svojih proizvodnih funkcija.

Ovaj zaključak proizlazi iz činjenice da su svi objekti upravljanja naznačeni na dijagramu istovremeno objekti koji će se odražavati u EA modelu, koji će u budućnosti također postati objekt upravljanja (arhitektonski model poduzeća prikazan je na dijagramu kao njegova komponenta ).

Slika 2 - Generalizirana struktura poduzeća

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

Slika 3 - "Enterprise Architecture" može se koristiti za podršku osnovnim funkcijama upravljanja

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

u konturi operativni menadžment poduzeće - to je formalizacija i pružanje otuđenog znanja o postojećem ustroju i funkcioniranju poduzeća;

u konturi strateškog upravljanja poduzećem - je formalizacija i odredba

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

Slika 4 - Glavne funkcije "Enterprise Architecture"

AP se može koristiti s ovim funkcijama na svim razinama upravljanja: od razine upravljanja poduzećem do pogona. Ovo (eksplicitno ili implicitno) osiguravaju dobro poznate metodologije -

"Zachmanov okvir za arhitekturu poduzeća", "Okvir proširene arhitekture poduzeća", "TOGAF",

"GERAM", standard ISO 19439-2006 (razine "Generic", "Partial", "Particular").

Nakon J. Zachmana, najspecifičnije i dosljednije menadžerske razine uporaba AP-a predložena je 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 "Enterprise Architecture"

Sve arhitektonske metodologije se slažu da je za dovoljno smislen opis uređaja poduzeća (organizacije) potrebno koristiti mnogo različitih gledišta (pogleda) na ovaj uređaj. Ova se gledišta također mogu nazvati arhitektonskim domenama, sadržajnim aspektima i slično. Opisivanje (i modeliranje) strukture poduzeća iz mnogo različitih perspektiva rezultira "Arhitekturom poduzeća".

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

u Zachman Framework for Enterprise Architecture to su "Podaci", "Funkcija", "Mreža", "Ljudi", "Vrijeme", "Motivacija";

u Extended Enterprise Architecture Framework (E2AF) je "Posao", "Informacije", "Informacije

Sustavi“, „Tehnološka infrastruktura“;

u GERAM-u i ISO 19439-2006 to su "Funkcija", "Informacija", "Resurs", "Organizacija";

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

Autor ovog članka smatra praktično svrsishodnim prevladati takvu raznolikost metodoloških pristupa izboru sadržajnih aspekata PK korištenjem bilo kojeg jednostavnog i razumljivog načela za logično izvođenje tih aspekata.

Takvo načelo može proizaći iz općeg temeljnog razumijevanja "sustava" kao skupa svrhovito međusobno povezanih elemenata. Na temelju toga mogu se temeljno razlikovati sljedeći osnovni i lako razumljivi sadržajni aspekti "Enterprise Architecture":

1) Građevinski aspekt- poduzeće je izgrađeno od mnogo različitih fizičkih i informacijskih komponenti, uključujući: dugotrajnu imovinu i drugu imovinu, utrošenu i proizvedenu energiju, osoblje, papirnate dokumente, elektroničke informacije, alate za automatizaciju i automatska kontrola, odnosno to su „cigle za gradnju“ od kojih je poduzeće fizički sastavljeno. Na ovaj aspekt možete primijeniti i sinonimni pojam - strukturni aspekt.

2) Funkcionalni aspekt- poduzeće posluje, proizvodi proizvode, pruža usluge, kupuje i prodaje sirovine, materijale, proizvode, u njemu se odvijaju tehnološki i poslovni procesi, odnosno u ovom aspektu razlikuje se vanjska i unutarnja manifestacija djelatnosti poduzeća;

3) Logički aspekt- djelatnost poduzeća je svrsishodna, u skladu s ciljevima poduzeća utvrđena je njegova konstrukcija i funkcionalna struktura. Ovaj aspekt naglašava poslovni smisao nastanka i poslovanja poduzeća.

Glavne komponente logičke strukture poduzeća su takve spekulativne komponente kao što su svrha, misija, vizija, ciljevi poduzeća, njegovo mjesto na tržištu, načela za odabir glavnih vrsta njegovih građevinskih komponenti, načela funkcioniranja i razvoj poduzeća.

NA U Zachmanovoj matrici ovaj je aspekt naznačen nazivom prvog retka "Opseg" ("Svrha retka 1 je definiranje granica poduzeća, što je uključeno...").

NA Federal Enterprise Architecture (FEA) je "referentni model performansi".

NA E2AF i u GERAM-u logički aspekt nije eksplicitno istaknut i uključen je u "Poslovni" aspekt. Međutim, temeljna načela E2AF-a kažu: "Nema strategije, nema poslovne arhitekture ... Nema opsega - Nema poslovne arhitekture

Opseg te ciljevi i ciljevi postavljaju razinu apstrakcije poslovne arhitekture ... Poslovni pokretači, ciljevi i ciljevi su vodeći ..." .

NA TOGAF logički aspekt odgovara "Arhitekturskoj viziji" ("... ključni elementi "Arhitekturske vizije"- ...

misija poduzeća, vizija, strategija i ciljevi ..., uključuju načela arhitekture, definiraju širinu pokrivenosti poduzeća, specifične domene arhitekture ..." ).

Sumirajući pregled logičkog aspekta i koristeći se filozofskim jezikom, može se tvrditi da je logički aspekt strukture poduzeća neophodan za predstavljanje "Integralne ideje poduzeća", "Integralnog koncepta poduzeća", " Integralni koncept poduzeća", na engleskom jeziku možemo ponuditi - "The Notion of the Enterprise" .

4) Kronološki aspekt- tvrtka nastaje, posluje i mijenja se kroz vrijeme. Treba evidentirati prošla, sadašnja i planirana strukturna stanja poduzeća, odnosno - to je "Povijest života".

U GERAM-u, u ISO 15704-2000, ISO 19439-2006, predlažu se mnoge faze za strukturiranje vremenskog aspekta životni ciklus: "Identifikacija", "Koncept", "Zahtjevi", "Dizajn", "Implementacija", "Rad", "Dekomisija".

NA metodologija TOGAF - Architecture Development Method (ADM) - vremenski aspekt se odražava slijedom faza razvoja, implementacije i promjene same "Enterprise Architecture".

Shema "3D-Enterprise" omogućuje planiranje budućih stanja poduzeća u vremenskoj dimenziji EA, uključujući pojedinačne projekte i razvojne programe. Konkretno, redoslijed implementacije tehnoloških komponenti (sustava) poduzeća može uključivati: stratešku analizu ciljeva i potreba, dizajn tehničkih rješenja, detaljnu implementaciju sustava rješenja, implementaciju rješenja, korištenje (rad) sustava , poboljšanje sustava.

Slika 5 - Glavna stajališta o strukturi poduzeća

Dakle, "Arhitektura poduzeća" može se definirati kao struktura poduzeća, razmatrana od strane njegove uprave, s najmanje četiri glavne točke gledišta (u četiri glavna aspekta) i predstavljena (uključujući modelirana) odgovarajućim skupom od četiri glavne vrste arhitekture poduzeća: logična, konstrukcijska (strukturalna), funkcionalna i kronološka.

Komponente arhitekture zgrade poduzeća mogu se smatrati:

organizacijska arhitektura je organizacijska struktura poduzeća;

vlasnička arhitektura je vlasnička struktura poduzeća;

informacijska arhitektura je struktura skupa dokumenata (organizacijskih, regulatornih, tehničkih itd.) i podatkovnih baza podataka poduzeća;

proizvodno-tehnološka arhitektura je struktura proizvodnih i energetskih kapaciteta poduzeća, kao i struktura instrumentacijskih i automatiziranih kompleksa i automatizacijskih kompleksa.

Do Komponente funkcionalne arhitekture poduzeća mogu se pripisati:

struktura funkcionalnih sustava i podsustava poduzeća;

struktura poslovnih funkcija i poslovnih procesa poduzeća;

strukture tokova materijala i informacija u poduzeću.

Slika 6 - Integrirani prikaz "Enterprise Architecture"

Uz četiri glavna tipa arhitekture poduzeća, moguće su i druge, koje odgovaraju drugim gledištima, na primjer:

IT arhitektura je struktura skupa automatiziranih informacijskih sustava (informacijske tehnologije) poduzeća;

Poslovna arhitektura je arhitektura poduzeća koja se razmatra bez njegove IT arhitekture.

4 Kako nabaviti i koristiti Enterprise Architecture

Uprava poduzeća može dobiti AP na dva načina: prvi je da razvije AP članovi poduzeća, drugi je obratiti se vanjskim konzultantima.

Prvi put će zahtijevati upravljanje poduzećem:

formiranje radne skupine, koja će se zatim trebati transformirati u stalnu arhitektonsku službu poduzeća;

odabir i nabava gotovog specijaliziranog računalnog programa za elektroničko modeliranje nesreća i osposobljavanje stručnjaka poduzeća za njegovo korištenje;

samostalni razvoj i dokumentacija metodološka podrška AP;

samostalni razvoj AP.

Razvoj AP-a od strane vanjskih konzultanata zahtijevat će od uprave poduzeća sklapanje ugovora o obavljanju poslova:

za izravan razvoj AP-a;

na izradi i dokumentiranju metodološke potpore PU;

o stvaranju arhitektonske službe poduzeća.

Računalni programi za elektroničko modeliranje poslovnih procesa i struktura sustava koji postoje na tržištu omogućuju konverziju baza podataka elektroničkih modela iz njihovih specijaliziranih formata u www-format i njihovo objavljivanje na internoj (intranet) stranici poduzeća. To omogućuje realizaciju

prikladan pristup bez licenci za menadžere i stručnjake poduzeća elektroničkom modelu EA.

Nakon toga, formirana i pripremljena arhitektonska služba poduzeća može samostalno riješiti probleme opcija modeliranja za buduće stanje EA u interesu prihvaćanja od strane uprave strateške odluke za razvoj poduzeća.

Popis korištenih izvora

1. Zinder E. "3D-poduzeće" - model strategije transformirajućeg sustava. "Direktor službe za informiranje", broj 4, 2000. http://www.sept2000.ru/articles/2008/03/03/1/.

2. Zinder E. Arhitektura poduzeća u kontekstu poslovni reinženjering. "Inteligentno poduzeće / Korporacijski sustavi", br. 4, br. 7, 2008.

3. Galaktionov V. Arhitektura sustava i njeno mjesto u arhitekturi poduzeća. "Direktor službe za informiranje", broj 5, 2002.

4. Danilin A., Slyusarenko A. Arhitektura i strategija. "Yin" i "Yang" poduzeća informacijske tehnologije. M. Internetsko sveučilište informacijskih tehnologija, 2005.

5. Drozhzhinov V., Shtrik A. Standardizacija arhitekture američkih državnih odjela. PC tjedan/RE. broj 28, broj 31, 2005.

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

7. Ured za upravljanje i proračun. Federal Enterprise Architecture (FEA).http://www.whitehouse.gov/omb/e-gov/fea/

8. Schekkerman J. Osnovni vodič za prošireni okvir Enterprise Architecture. Institut za razvoj arhitekture poduzeća, 2006.http://www.enterprise-architecture.info/

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

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

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

1. Arhitektonski opis poduzeća: kako organizaciju rada učiniti vidljivom

Arhitektura poduzeća je način na koji je ono organizirano. Koliko je organizirano (arhitektura) tko na čemu radi i kome taj posao treba. Poduzeće je uvijek nekako organizirano, dobro ili loše. Organizacija (arhitektura) poduzeća je nevidljiva, ali je moguće napraviti potpuno vidljiv arhitektonski opis. Ako postoji arhitektonski opis, onda se on može koristiti za raspravu o organizaciji poduzeća od strane svih strana koje su zainteresirane za ovu organizaciju (uključujući ljude kompetentne u pitanjima organizacije) - i tada postoji šansa da se organizacija može poboljšati. Ako nema opisa arhitekture dokumentiranog na nekom nosaču informacija otuđenom iz glave, onda svatko ima neki (ne pitajte koji) opis u nekom (ne pitajte kojem) obliku u vlastitoj glavi, a čak i tijekom jednog razgovora taj se opis može promijeniti tri ili četiri puta u jednoj osobi. Kad se raspravlja o organizaciji rada poduzeća, zajamčeno je da svatko ima različite ideje o sporazumima, a rezultat rada na takvim ugovorima opisan je u Krilovljevoj basni o labudu, raku i štuci.

Arhitektonski opis sastoji se od niza dijagrama koje ljudi koriste kako bi razumjeli kako organizacija funkcionira i zatim se složili oko toga što treba promijeniti u organizaciji. Arhitektonski opis prvenstveno je alat za sklapanje dogovora s važnim osobama (stakeholderima) o važni aspekti organizacija rada. Nemojte brkati organizacijske propise (koji sadrže i važne i manje važne, i općenito puno riječi) s arhitektonskim opisom koji sadrži samo najvažnije, ali izražen što je moguće formalnije kako bi se izbjegle pogreške.

Za opis arhitekture poduzeća koristi se poseban jezik, Archimate. Ovaj jezik vam omogućuje da zapišete najvažnije u organizaciji poduzeća - i zanemarite male detalje.

Odmah rezervirajmo da je u Archimeiteu moguće opisati samo organizaciju rada za uredski plankton. Nikakvi predmeti stvarne materijalne proizvodnje ne mogu se opisati u Archimeiteu, opisuju se samo informacije o tim objektima. Nema kuhanja krumpira, nema prijenosa ingota sa stroja na stroj - samo i isključivo informacije o svemu tome. Archimate je idealan za banke i osiguravajuća društva, sjedišta (iz kojih se ne vide prave radionice), projektantske biroe (gdje su teške grede samo u računalnim modelima i papirnatim ispisima) pa čak i građevinska sjedišta (gdje distribuiraju narudžbe i bilježe učinjeno , ali sami ništa ne rade ručno). Ali one dijelove poduzeća koji ne uzimaju u obzir zatezanje matica, već stvarno zatežu zahrđale matice, nakon što su ih primili iz skladišta, ne može opisati Archimate. Ali za prikaz skladišnog računovodstva ili dizajna i računovodstva rada - molim.

Arhitekt je netko tko osmišljava arhitekturu koja će zadovoljiti sve zainteresirane. On izmišlja tu arhitekturu, opisuje je u obliku arhimskih dijagrama i koordinira je s raznim važnim ljudima. Sam trenutak opisa arhitekture na Archimeiteu je nevažan. Oni koji jednostavno pišu na Archimeite (španjolski, svahili) iz diktata ne mogu se nazvati arhitektima, oni su samo činovnici (pisari). Dobro, nadbiskupi (nadbiskupi).

Za mnoge ljude imenovane arhitektima, pokazalo se da je potpuno iznenađenje neizbježan prijelaz s prikazivanja rezultata raznih intervjua na Archimeteu kao "arhitektonskog opisa kakav jest" na pisanje "arhitektonskog opisa koji će biti" i odmah nakon bliske komunikacije s nadređenima o transformaciji svježe nacrtanih Archimate dijagrama u organizacijsku stvarnost poduzeća. Arhimat će vam pomoći u vašem poslu ništa više od spellcheckera Vorda u dobivanju Nobelove nagrade za književnost.

Upozoren si.

2. Ljudi, programi, oprema

Archimate smatra da je najvažnija stvar u poduzeću prisutnost troje razine rada, od kojih se svaki ljudski princip smanjuje: od ljudi, programa i oprema. Ljudi bez softvera su bespomoćni, softver bez hardvera je mrtav. Oprema bez pokretanja programa beskoristan je komad željeza, programi bez rada ljudi također nisu potrebni. Dakle, u arhitekturi poduzeća moraju biti prikazane sve tri razine radnog učinka u njihovoj međusobnoj povezanosti.

Svaka razina ima svoju izvršitelji posla, i njihovi radni predmeti raditi. Rad se zapravo sastoji u tome da izvođači na neki način mijenjaju objekte rada. Izvršitelji rada i predmeti rada obično se predstavljaju imenicama, radovi glagolima i glagolskim imenicama. Bitno je da sami predmeti rada ne znaju ništa raditi, pasivni su. Ali izvršitelji su aktivni, rade na objektima i korištenju predmeta.

Razina ljudi je značajna. Ljudi iza informacija vide one objekte okolnog svijeta koje te informacije prikazuju. Gledaju vremensku prognozu i vide sutrašnje vrijeme (a ne opis vremena), pogledaju izvješće o izgradnji i vide stvarni broj katova (a ne stvarno izvješće), pogledaju račun dobiti i gubitka i vide istu dobit . Ljudi imaju ciljeve, ovlasti (mogu dati naredbe nekim drugim ljudima da rade) i odgovornost (moraju obećati da će izvršavati naredbe nekih drugih ljudi). Svrhovito djelovanje postoji samo na ovoj razini.

Programska razina je obrada informacija sadržanih u podacima. Od nekih podataka programi stvaraju druge podatke koji se razlikuju i po formatu i po sadržaju. Nitko nikome ništa ne obećava (programi ne mogu obećati, samo ljudi mogu) i ne daje upute (samo ljudi mogu davati), ne teži nikakvim ciljevima (samo ljudi imaju ciljeve). Na ovoj razini znamo što podaci znače u stvarnom svijetu: opasno je dodavati kilometre kilogramima. glavni zadatak programska razina – kako bi podaci obrađeni na pravi način bili u pravo vrijeme s pravim ljudima.

Hardverska razina je bezdušni svijet u kojem više nema obrade podataka, već samo pohranjivanje i prijenos podataka. Naravno, postoje i programi na hardverskoj razini, ali oni su druge vrste - nitko ovdje ne zna što ti podaci znače u stvarnom svijetu. Zadaća hardvera je pohraniti na neki način adresirane bajtove, ne ulazeći u njihovo značenje, poslati te bajtove na zahtjev programa, kao i pohraniti same programe i omogućiti njihovo izvršavanje.

3. Elementi i odnosi
Poduzeće u Archimeitu opisano je u obliku elemenata (predstavljenih različitim figurama) koji su u nekoj vrsti međusobnog odnosa (odnosi su prikazani kao spojne linije između figura elemenata). Archimate je vrijedan po tome što nudi sve što može opisati rad poduzeća.
-- 16 vrsta predmeta za razinu ljudi,
-- 7 vrsta predmeta za razinu programa,
-- 9 vrsta predmeta za razinu opreme,
-- 11 tipova odnosa u kojima elementi mogu biti jedni s drugima i prikaz račvanja za te odnose.

Ako namjeravate nekako promijeniti arhitekturu poduzeća u stvarnom životu (inače, zašto ste uopće počeli crtati Archimate dijagrame?), onda za to također možete koristiti:
-- 7 vrsta elemenata za postavljanje ciljeva i opravdavanje organizacijskih promjena
-- 4 vrste elemenata za projektiranje prijelaza na novu arhitekturu

Tu je i komentar i odnos komentara s nekim drugim elementima, kao i okvir za grupiranje elemenata.

To je cijeli Archimete. Ali neka vas njegova jednostavnost ne zavara. Veliki i moćni također ima samo 33 slova.

4. Ne trebamo vas, trebamo vašu uslugu.

Važno je da se nijedan posao u poduzeću ne radi tek tako, svi su nekome iz nekog razloga potrebni. Usluge su djela koja su korisna za neke druge izvođače (točnije, korisna za rad tih izvođača). Za potrošače usluga apsolutno je nevažno kako je organizirano izvođenje tih radova: tko s čime radi kako bi uslugu izložio vanjskoj potrošnji. Za njih je samo važno preko kojih će se kanala (e-mail, prozor s djevojkom, telefonski poziv i sl.) i sučelja (ako se radi o programima) te usluge pružati.

Postoje hardverske usluge koje se pružaju programima i softverske usluge koje se pružaju ljudima. Tri sloja poduzeća spojena su ovim uslugama -- iz svakog sloja uglavnom su vidljive samo usluge ostalih slojeva.

Odnosno, možete zamijeniti svu opremu, a programi to neće primijetiti ako usluge opreme ostanu iste. Isto je i s programima: sve ih zamijenite, ali ako usluge ostanu iste, ljudi će to preživjeti. U načelu, to vrijedi i za samo poduzeće: ako su usluge ljudi koje poduzeće pruža vanjskom svijetu (a kombinacija takvih usluga i ugovora koji ih povezuje tzv. proizvod) izvodit će se na vrlo drugačiji način od strane organiziranih ljudi koji koriste vrlo različite programe koji rade na vrlo različitom hardveru, a kupci to neće primijetiti. To je ono što arhitekti poduzeća koriste: oni opisuju poduzeće, a zatim polako mijenjaju softver i hardver kako bi podržali pružanje usluga kritičnih za misiju. To je ono što se naziva pristupom usmjerenim na uslugu: podijeli (različite razine rada usluge) i vladaj. Dakle, još uvijek je kako izgledati: poduzeće je spojeno uslugama, ali za arhitekta je podijeljeno tim uslugama.

Želja za podjelom i vladanjem među arhitektima je tolika da dijele usluge i radove čak i iste razine. Na primjer, lako je zamisliti programe koji pružaju usluge drugim programima umjesto ljudima. Ili oprema čiji je raison d'être služiti (pružati uslugu, tj. "raditi za") drugu opremu.

Za pružanje izvana vidljivi rad-uslugu treba puno činiti izvana nevidljivoga unutarnje rad -- izmjene predmeta rada od strane izvođača radova. Prisutnost ove granice unutarnjeg i vanjskog razmatranja ("crna kutija" s nevidljivim unutarnjim izvođačima, poslovima i objektima nasuprot "prozirnoj kutiji" kada su savršeno vidljivi) je prisutnost granice sustava. Arhimski modeli sustava, odvajajući dijelove/razine poduzeća po uslugama (iako se o "sustavima" u specifikaciji Archimatea ne spominje ni riječ).

5. Ljudi

Podsjetimo na točku tri: za opis razine organizacije rada ljudi, Archimate ima isti broj tipova elemenata (17) kao i za razine programa i opreme zajedno (7 + 9) - i to nije nimalo slučajno.

Sami ljudi u Archimeiteu nisu predstavljeni svojim osobnostima. Kod Archimeitea nije osoba ta koja slika mjesto, nego mjesto koje slika osobu. U Archimeiteu je izvođač živa osoba, ali samo na organizacijskoj poziciji. Stoga Archimete upravo ta mjesta naziva "ljudi", bez obzira tko ih trenutno popunjava - jedna osoba, cijela grupa ljudi s organizacijske razine (od sektora i odjela do podružnice u drugoj državi ili čak cijele tvrtke) , privremeni radnici, slučajni građani-kupci, partnerske firme. Arhimat razumije da sva ta ustrojbena mjesta zauzimaju živi ljudi, ali on te ljude naziva upravo po imenima ustrojbenih mjesta. Majstor, zamjenik voditelja odjela dostave, odjel dostave, podružnica u Mytishchiju, klijent, revizor - to su "ljudi", bez obzira tko su zaposlenici koji slučajno zauzimaju te organizacijske pozicije. Arhitekt, kao i obično, brine o vječnom: ako se majstor ili predsjednik razboli, a jedna osoba zamijeni drugu za vrijeme trajanja bolesti, dijagram će ostati istinit: organizacija posla se neće promijeniti.

Arhimetovci su raznolikiji od onih ljudi koji se nalaze u "organizacijskoj strukturi" (organigram): nipošto se svi odnosi među Arhimetovcima ne svode na šefovanje-podređenost. Dakle, partneri i klijenti se obično ne spominju u organizacijskoj strukturi, ali u Archimeiteu je njihov prikaz uobičajena stvar.

6. Uloge

Arhitekti su toliko podmukli da rade s dijelovima ljudi nazivajući ih "ulogama". uloga poziva se onaj vremenski raspoređeni dio ljudi koji obavlja određeni broj poslova za koje je potrebna neka posebna kvalifikacija. Dakle, ako je radnik u kazalištu prisiljen ili pjevati ili plesati, on ima dvije uloge: kada pjeva, onda je uloga pjevača, a kada pleše, uloga je plesača.

narod imenovani na uloge, i uloge imenovani raditi. Posebno treba istaknuti činjenicu da se arhitekti organizacije bave organizacijom rada, a ne vođenjem (leadershipom). Dodjeljivanje uloga ljudima, a uloga poslovima, briga je arhitekta organizacije. A voditeljeva briga je a) postavljanje živih "ljudi" s prezimenima, imenima i batinama, lošim i korisnim navikama, određenim vještinama na mjesta "ljudi" i b) pričanje ljudi na mjesta "ljudi" s mrkvom i štap za obavljanje posla koji im je dodijeljen. Dakle, na dijagramima Archimatea nećete vidjeti imena: samo položaje, uloge, odjele, tvrtke, "odgovorne osobe", "predstavnike", kolegijalna tijela, privremene grupe i udruženja itd.

U životu ugovoreni sastanak o ulogama i radu obično se odražava u naredbama, naredbama, pravilnicima i drugim "administrativnim dokumentima". Takav sustav podjele ljudi potreban je ne samo da bi se pokazala svestranost zanimanja ljudi (da vas podsjetim: i pojedinaca i cijelih odjela - kada velika tvrtka od 1000 zaposlenih djeluje i kao dobavljač u odnosu na jednu tvrtku, i kao kupca u odnosu na druge tvrtke), ali i zato da arhitekti manje mijenjaju svoje dijagrame, te da se rjeđe izdaju nalozi kojima se utvrđuje organizacija rada.

Tipičan primjer: neka organizacija počinje saditi peršin, ali još nije jasno tko će saditi taj peršin - nadležni kažu "vi pokažite što tu treba napraviti, a onda ću ja imenovati odgovarajućeg kandidata". Oni pišu „Propis o peršinu“, gdje uvode ulogu „poglavara u peršinu“ i „seniora u peršinu“ i propisuju sav njihov rad. Imajte na umu da Uredba još nije naredba, a ne naredba. Ovo je konstatacija činjenice da neka organizacijska mjesta (glavni i viši u peršinu) trebaju biti popunjena da bi posao (za sadnju peršina) mogao krenuti. Načelnik proučava ovaj nacrt uredbe, te zaključuje da se sadnjom peršina trebaju baviti inženjeri i pravnici. Zatim napiše naredbu u kojoj a) odobrava položaj i b) propisuje da će dužnost predstojnika peršina obnašati inženjer, a stariji od peršina biti pravnik. Evo kako to izgleda:

Točkasti konektori su "odnos odredišta" između elemenata. Tu su, naravno, i izravni odnosi između ljudi i djela (ako izostavite spominjanje uloge). Takav odnos nazvat ćemo izvedenim, no on ipak postoji - možemo reći da je u ovom slučaju inženjer zadužen za osiguranje sadnica, a pravnik za sadnju.

Imajte na umu da će ovaj dizajn funkcionirati čak i kada inženjer Ivanov ode u mirovinu, a Sidorov bude angažiran da ga zamijeni. U ovom dizajnu je lako promijeniti inženjera za agronoma ili za Upravu peršina (kada aktivnost raste) - ovaj mehanizam odredište uloge na posao (na primjer, prema Pravilniku), a ljudi na uloge (na primjer, po Naredbi) također funkcionira u slučaju kada je "ljudi" cijela gomila ljudi itd. Riječ je o organizaciji. Svi ti propisi i naredbe obično nisu označeni na dijagramu: njima se na dijagramima dogovara kako će se organizirati rad, a ne s kojim dokumentima će se ti sporazumi sastavljati.

Savjet: Poznajem nekoliko organizacija u kojima je albume arhitektonskih opisa poduzeća odobrio direktor umjesto debelog hrpa propisa. Jer su se arhitektonski dijagrami pokazali točnijim i izražajnijim od brojnih tekstualnih opisa koje su potom pokušali sastaviti iz njih.

Jasno je da najživlji Ivanov i Sidorov (odnosno djelatnici koji su navedeni u Upravi za peršin) u konačnici rade na sadnji peršina. Ali oni će potrošiti samo dio svog vremena i talenta na poduzeće (a samo se taj dio vremena odražava na element "ljudi" u arhitekturi poduzeća), a ostatak vremena će spavati, jesti, šetati, učiti i zabavljati se. Oni će potrošiti samo djelić vremena koje potroše na posao na svoju ulogu u poslu sadnje peršina - jer vjerojatno imaju mnogo različitih uloga, obavljaju mnoge razna djela. Da, i određeni broj ljudi može biti dodijeljen istoj ulozi - pojedinačni ljudi ili čak nekoliko odjela.

I ljudi i uloge mogu se podijeliti na bilo koji broj dijelova ako želite prikazati neke pojedinosti o zapošljavanju ljudi koji rade.

Raditi neki posao razliciti ljudi mogu se udružiti na neko vrijeme (to se obično ne odražava na organizacijsku strukturu), a takva privremena udruga zove se kolegijalnu ulogu.

7. Djela ljudi

Poslovi ljudi su:

• već se dogodilo - razvoja događaja. Događaji se obično nazivaju glagolom svršenog oblika prošlog vremena: "sadi se peršin". Te radove mogu izvesti nenamjerno ("došlo je do pogreške"), osobe izvan poduzeća (kupci, konkurenti, partneri), a općenito taj posao nisu mogli izvesti ljudi (već npr. programi, oprema, ili čak sile prirode - - "Sunset").
• usmjereni na postizanje rezultata, a izvršavaju se u vremenskom razmaku (često - jedan za drugim) - procesima. Nazivaju se glagolom u neodređenom obliku - "kopati", "saditi", "razvijati". Procesi su obično trčanje događaj, i lansirati događaja, a također pokreću jedni druge, tvoreći lanac od početnog događaja do događaja rezultata.
• dobiven kao rezultat rada privremenog tima ujedinjenog kolegijalnom ulogom -- kolegijalnih procesa. Nazivaju se i glagolom u neodređenom obliku.
• odabrani za nešto drugo osim vremenske baze za postizanje rezultata (na primjer, zahtijevanje dodjele uloga s određenim kvalifikacijama za njih ili konzumiranje neke vrste specifičan pogled resursi) -- praksi. Prakse se ne izvode toliko same po sebi, već se u različitim trenucima izvode određeni procesi koje oni kombiniraju (ili fragmenti procesa do kojih materija nije stigla na dijagramu, pa su prikazani bez zamaha u vremenu, čok, "u torba" - to je naznačeno "ono što se vježba" umjesto da se radi u određeno vrijeme). Stoga se prakse ne označavaju glagolima, nego glagolskim imenicama: "saditi peršin" upravo je praksa.


• radovi dani nekome izvana, kako su značajni i viđeni izvana -- Usluge. Usluge implementiran interni rad koji obavljaju interne uloge, i koristi se tijekom vanjski radovi obavljaju vanjske uloge. U načelu, svaki rad ljudi obavlja se samo da bi se implementirati neku vrstu usluge – odnosno da netko drugi (npr. naručitelj, ili podizvođači) može koristiti te radove.

U principu, cijelo poduzeće je podijeljeno na neke dijelove, a ti dijelovi izlažu van (drugim dijelovima poduzeća, ili izvan granica poduzeća, ili drugoj razini) usluge kako bi opravdali svoje postojanje. Ako postoje poteškoće u razumijevanju tko je u čemu radikoristiodređene usluge, odnosno koje uslugeimplementiratiodređeni radovi - to znači da nešto ne znate ili niste dobro razmislili.

Kako bi pojasnio za što je točno usluga vrijedna, Archimete ima čak i poseban element:vanjska korist, koji vezan s uslugom.

* * *

U principu, već je jasno da je priča u takvom smislu prilično uspješna - ne izgleda previše apstraktno i apsurdna je upravo u onoj mjeri u kojoj je apsurdan i sam Archimate. Tada više ne možete pisati nove tekstove iz serije "Arhim na ruskom", već jednostavno ispraviti prethodno napisane. Pa, nastavite s lokalizacijom programa.

Drugi članak o mitološkoj svijesti također će biti kratak. Danas ću vam reći do kojih problema dovodi mitološka svijest pri modeliranju poslovne arhitekture.

Poznati Zachmanov model pokušava odgovoriti na pitanje što je arhitektura poduzeća i kako je treba modelirati. Temelj ovog modela su pitanja na koja se predlaže odgovor: tko, kada, gdje, zašto i kako nešto radi na nečemu. Čini se da je to logičan okvir za opisivanje poslovne arhitekture, a mnogi ljudi misle da jest.

No, već i letimičan pogled na ovaj okvir ostavlja osjećaj nezadovoljstva, jer nije jasno kako odgovoriti na pitanje tko je i zašto strojno obradio detalj? Tko: Ivan Ivanovich, ili tokar, čiju je ulogu igrao Ivan Ivanovich? Zašto: zato što je tokar dobio posao ili zato što je Ivan Ivanovič sklopio ugovor prema kojemu se obvezuje raditi kao tokar u zamjenu za hranu? Zašto: zato što Ivan Ivanovič želi jesti ili zato što je dio potreban u montažnoj radionici?

Dublje proučavanje ovog okvira navodi na razmišljanje o njegovoj primjenjivosti na opis tehnološki procesi. Na primjer, neka raste kukuruz na polju. Primjenjujući Zachmanov model, moram odgovoriti na pitanja. WHO? Kukuruz. Što on radi? Raste. Zašto? Jer svijet tako funkcionira. Za što? Ali tko zna zašto raste kukuruz?!

Čitatelj obučen za opisivanje poslovnih arhitektura brzo će me ispraviti. Reći će da postavljam pogrešna pitanja. Treba se zapitati: tko uzgaja, zašto uzgaja, što uzgaja. Ali onda se ispostavi da mogu opisati aktivnost subjekta koji uzgaja kukuruz, ali ne mogu opisati sam rast. Pomiren s činjenicom da ne mogu opisati proces rasta, još uvijek imam neriješena pitanja: tko i zašto uzgaja kukuruz (vidi gore)?

Ispada da postavljanjem naizgled logičnih pitanja u najboljem slučaju dobijem nekoliko odgovora, a u najgorem slučaju ne dobijem ih uopće. Ako uzmemo ekstremni slučaj kada imamo potpuno robotizirano poduzeće u kojem uopće nema ljudi, onda odgovor na pitanje "tko?" bit će - "nitko". Kao rezultat toga, ne možemo reći ništa o ovom poduzeću! Istina, postoji jedan izlaz iz ove situacije, pomalo lukav - samo trebate upotrijebiti mitsku svijest i animirati robote. Tada ćemo, oživjevši neživo, moći odgovoriti na pitanje: tko? Robot. Zašto? Zato što je ovaj robot tako dizajniran ili zato što ga je programer tako programirao. Za drugo pitanje opet dobivamo čudne odgovore. Zašto se to dogodilo i koja pitanja zaista vrijedi postaviti? Pokušat ću ukratko iznijeti svoje mišljenje o ovoj temi govoreći o logičkim pogreškama koje sam pronašao u Zachmanovom modelu.

Ako pogledate pitanja koja se postavljaju u Zachmanovom modelu, možete vidjeti da ona točno odgovaraju teoriji aktivnosti. Djelatnost je mentalna funkcija subjekta (skupine subjekata). Stoga, odgovarajući na Zachmanova pitanja, gradimo model mentalne funkcije subjekta (subjekata). Znanost koja proučava psihičke funkcije subjekata naziva se psihologija. Ispada da Zachman odgovara na pitanja koja postavljaju psiholozi: zašto subjekt čini ovu ili onu radnju? Ili kako motivirati subjekta da izvrši određene radnje? Ova su pitanja svakako zanimljiva i važna, ali jesu li odgovori na njih opis arhitekture poduzeća? Da biste odgovorili na ovo pitanje, morate razumjeti što je poduzeće?

Kako se zapravo odvija dizajn poduzeća i koji artefakti nastaju u tom procesu? Prije projektiranja poduzeća izrađuje se model zahtjeva za njim. Model zahtjeva formira se na temelju zahtjeva koje ovom poduzeću postavljaju svi njegovi sudionici, izvođači i dionici. Analog u IT-u su zahtjevi za softverski proizvod. Nadalje, na temelju ovih zahtjeva, model poslovnih procesa se gradi sa potrebnim stupnjem detalja. Analog u IT-u bit će popis funkcija softverskog proizvoda. Zatim se gradi model funkcionalnih objekata ili, govoreći specijalizirani jezik, tehnička mjesta koja bi trebala sudjelovati u gore navedenim procesima. Analog u IT-u bit će opis procedura i objašnjenje koje procedure su uključene u koje funkcije. Zatim se odabiru oni dijelovi opreme koji mogu ispuniti uloge navedenih tehničkih mjesta. Pandan u IT-u je programski kod.

Poduzeće je funkcionalni objekt koji je stvoren da zadovolji određene zahtjeve. U tom smislu, poduzeće se ne razlikuje od predmeta kao što je sat ili proizvodna linija. Često se umjesto pojma funkcionalni objekt može čuti izraz tehničko mjesto. Funkcionalno mjesto razlikuje se od dijela opreme po tome što dio opreme djeluje kao funkcionalno mjesto. Na primjer, transformator djeluje kao pretvarač napona, dok u drugačije vrijeme različiti transformatori mogu obavljati ulogu istog pretvarača. Drugi primjer tehničkog mjesta je pozicija, odjel, odjel, država. Na primjer, tokar je uključen u funkciju proizvodnje dijelova. Ovo je tehničko mjesto čiju ulogu mogu obavljati različiti dijelovi opreme u različito vrijeme ( pojedinaca). O poteškoćama modeliranja tehničkih mjesta i dijelova opreme ukratko sam pisao u članku.

Kod modeliranja tehničkih mjesta opisujemo procese i sudionike u tim procesima. Napominjem da sudionici, a ne izvođači, ti koji transformator ne mogu pretvoriti napon, jer on nije animirano biće. O tome sam pisao u prošlom članku. Ako se ipak kaže da transformator "transformira" napon, onda je to metonimija, koja se otkriva na sljedeći način: transformator igra ulogu pretvarača napona, koji (pretvarač) sudjeluje u procesu pretvorbe napona. O metonimiji možete čitati u knjizi "Metaphors We Live By", autori: George Lakoff, Mark Johnson. Druga uobičajena metonimija bila bi "računalo rješava probleme". Oni koji doista vjeruju da transformator, ili računalo stvarno nešto rade, oživljavaju neživo, koristeći mitsku svijest.

Imajte na umu da do ove točke nismo rekli ni riječ o ciljevima, izvođačima i uzročno-posljedičnim vezama. Govorili smo samo o zahtjevima, o funkcijama i sudionicima tih funkcija - tehničkim mjestima. Ciljevi su ostali u fazi formiranja zahtjeva za poduzeće i nisu išli dalje. Te ciljeve možemo, ali i ne moramo znati - to nema razlike u modelu poduzeća. Model poduzeća odgovara na pitanje: kako ispunjavamo zahtjeve, a ne odakle ti zahtjevi dolaze. Nema ni izvođača, jer ne trebamo koristiti teoriju aktivnosti da bismo opisali sudionike u aktivnosti. Ne gradimo uzročne veze. Ako je potrebno izgraditi model uzročno-posljedičnih veza, onda je to još jedan dodatni model. To je znanje koje tehnolozi koriste kada projektiraju poduzeće, a ja nisam vidio da netko gradi takve modele. To je gransko znanje, a na institutima se uči godinama. Modeliranje zašto avion leti je nerealno teško i nitko to ne radi. Samo simulirajte let aviona.

Dakle, Zachmanov model ne uključuje zahtjeve za poduzeće, on uključuje model procesa, ali na dosta specifičan način - s naznakom izvršitelja procesa, koji se, kao što rekoh, mogu pronaći samo u teoriji. djelatnosti, te ne razdvaja model tehničkih mjesta i model dijelova opreme.

Kao što sam ranije rekao, Zachmanov model je više o aktivnosti. U isto vrijeme, bilo bi lijepo da se Zachmanov model koristi za njegovu namjenu - kao način opisivanja aktivnosti. To bi omogućilo analizu motiva i interesa ljudi za njihov rad, no problem je u tome što se taj model pogrešno koristi. Na primjer, na pitanje "zašto tokar oštri dio?" možete dobiti odgovor: "potreban je u montažnoj radionici." Ali potreba za njim u montažnoj radionici ne odgovara na pitanje zašto tokar izoštrava dio. Odgovor nije bio na postavljeno pitanje, nego na neko drugo. Na primjer, za takav odgovor, pitanje bi bilo ispravno: u kojem procesu, ili u kojoj operaciji treba biti uključen strojni dio? Ili na kojem radnom mjestu je to potrebno? Vidite, ovo uopće nije pitanje "zašto". Osim toga, jako mi je neugodno zbog Zachmanove sposobnosti da računalu ili informacijskom sustavu podari mogućnost da nešto učini. Najvjerojatnije ih ne animira, već koristi metonimiju u modeliranju, što je, po meni, nedopustivo.

Prava pitanja su: Koji su zahtjevi za poduzeće? Koji se procesi odvijaju u poduzeću? Koja su tehnička mjesta uključena u koje procese? Koji dijelovi opreme igraju ulogu kojih funkcionalnih mjesta i kada?

Zapravo sve. Sretna Nova godina i vidimo se uskoro!

Počeo sam raditi s jednom tvrtkom na temu Enterprise Architecture (Enterprise Architecture) i odlučio sam korigirati svoje razumijevanje EA, učiniti ga jasnijim i jednostavnijim. Publikacija Johna A. Zachmana "A Framework for Information Systems Architecture" iz 1987. općenito se smatra datumom rođenja EA, iako se sam termin pojavio u više ranijih radova. Unatoč činjenici da je arhitektura poduzeća prilično mlada stvar, već je uspjela pokvariti svoj ugled. Kao i svaka druga arhitektura, arhitektura poduzeća nije dobro definirana (pogledajte, na primjer, 10 definicija arhitekture poduzeća), ali ima veliki broj neuspjelih projekata (pogledajte Gartner identificira deset zamki arhitekture poduzeća ili 8 razloga neuspjeha programa arhitekture poduzeća) . Obično, nakon završetka projekta poslovne arhitekture, možete čuti sljedeću frazu: Nacrtali smo sve potrebne slike, ali nemamo pojma kako od toga izvući barem neku korist.". Stoga, razgovarajmo o svemu od samog početka.

A krenut ćemo izdaleka. Postoje dva gledišta o korisnosti informacijske tehnologije. Prema prvom stajalištu, informacijske tehnologije omogućuju povećanje produktivnosti rada, tj. ljudi će raditi učinkovitije ako su njihove aktivnosti automatizirane. Postoji i suprotno gledište, izraženo, na primjer, u knjigama poput „Sjaj i siromaštvo informacijske tehnologije. Zašto IT nije konkurentska prednost" Nicholasa J. Carra ili "Što posao želi od IT-a" Terryja Whitea. Začudo, oba ova gledišta su točna. Ali suzimo krug razmišljanja i ne govorimo o informacijskoj tehnologiji općenito, već samo o poslovnim aplikacijama, tj. sustavi koji automatiziraju poslovne procese organizacije. U početku, razvoj i implementacija takvih sustava donosi opipljiv učinak. 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 putem takvih rješenja i specijalizirati se za određene funkcije, njihova se produktivnost povećava. To je puno bolje nego da se međusobno zovete telefonom ili razmjenjujete poruke nabijene emocijama e-pošta. Stoga se počinju automatizirati razni drugi procesi, možda ne tako česti i ne toliko potrebni. Učinkovitost takve automatizacije nije tako visoka. Nisko viseće jabuke već su obrane i moramo izmisliti sofisticiranije načine za postizanje rezultata. Troškovi korištenja poslovnih aplikacija u jednom trenutku postanu veći od koristi proizašle iz njihove upotrebe, ali overclockanu lokomotivu više nije moguće zaustaviti. Razlog za ovaj prag je organska složenost informacijskih sustava (IT Complexity). Zapravo, u nekom trenutku jednostavno postanemo zbunjeni onim što radimo, a informacijski sustavi nam pomažu da budemo još zbunjeniji. Arhitektura (enterprise) je samo način da se kontrolira složenost koja je svojstvena sustavima, da se ima u vidu koliko-toliko adekvatna slika, a da se još uvijek može upravljati ovom složenošću.

Sljedeći problem je što se takva slika ne može pripremiti za budućnost. (U ovom trenutku, arhitekti će vam reći puno poštarskih riječi o različitim stajalištima, pogledima, dionicima i zabrinutostima). Stoga, da odgovorimo na pitanje "Zašto radimo arhitekturu poduzeća?" potrebno od samog početka. Dopustite mi da istaknem tri najčešća odgovora:

1. Imamo strategiju koja odgovara na pitanje što želimo, ali ne znamo kako to učiniti.
2. Nemamo strategiju, ali imamo bujicu zahtjeva za promjenama s kojima se ne možemo nositi.
3. Informacije o našim aktivnostima su kontradiktorne i nemamo vremena razumjeti svaku konkretan slučaj, zašto se ovo događa.

(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, baza kupaca itd. Općenito, znate, strategija je dokument o ježevima sutrašnjice , koji će postati današnji miševi. O tome što treba učiniti u ovom slučaju napisat ću u zasebnoj poruci, ali za sada nekoliko riječi o tome kako organizirati takav proces. Po mom mišljenju, organizacijski oblik Razvoj Enterprise Architecture je projekt koji traje 8-16 tjedana. Metodologija - TOGAF ADM itd. Treba privući resurse, uglavnom unutarnje. Rezultati projekta su: mapa puta, popis organizacijskih i procesnih promjena, rizici, prijedlozi za praćenje i upravljanje kretanjem u zadanom smjeru. Općenito, sve što se radi u tradicionalnim projektima u fazi planiranja naziva se lijepom riječju glavni plan. O timu takvog 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 trebaju smanjiti troškove, drugi trebaju donijeti nove proizvode i usluge na tržište, a treći trebaju poboljšati zadovoljstvo kupaca (pogledajte Ukratko o arhitekturi poduzeća). Svi kupci su cijenjeni ljudi i svima je potrebna pomoć. Ali složenost je već narasla i ne razumijemo kako pomoći svima u isto vrijeme. Jednostavan i pogrešan način da se svi postroje predivno ime, primjerice, "Jedinstvena lista prioriteta", a način raspodjele poslova po informacijskim sustavima - "Besplatna blagajna!" - tko može brže i jeftinije, njemu ćemo se povjeriti. Ispravno rješenje je multifaktorijalna klasifikacija upita, drugim riječima taksonomija. Metodologija – u stilu Zachmana. Organizacija – stvaranje funkcionalna jedinica. U prethodnoj bilješci Jesu li poslovni analitičari prijatelji, susjedi ili dalji rođaci? Napisao sam da će s pojavom i usvajanjem treće verzije BABOK-a poslovni analitičari moći obavljati ovaj posao. Ali zasad ne mogu. Trenutno poslovni analitičari mogu odgovoriti na pitanje “Što treba učiniti?”, a arhitekti rješenja mogu odgovoriti na pitanje “Kako to učiniti?”. Također zahtijeva odgovor na pitanje “Zašto?”, kako je ova promjena povezana s postojećim proizvodima i procesima, drugim promjenama, aplikacijama.

I konačno, situacija kada je kompleksnost već pobijedila i čelnici organizacije toga imaju svijest. o istima Slike, kojih nema kada su potrebni za brzo rješavanje kontroverznog problema, a ostatak vremena leže potpuno beskoristan teret. Ova situacija govori o arhitektonskom spremištu. Možda negdje postoje slike koje opisuju arhitekturu, ali ako se one ne mogu dobiti u roku od minute-dvije, onda pročelnik, a ni bilo koji menadžer, neće to učiniti sam, nego će zamoliti nekog drugog da uslika (“Ovdje pozovite arhitekta” !"). Ako osoba ne radi s aplikacijom barem jednom svaka 1-2 tjedna, onda to uopće neće učiniti. Ako programer informacijskog sustava nema jednostavne, razumljive i spremne API-je za dobivanje tipova klijenata, popisa poslovnica, funkcionalne organizacijske strukture i sl., onda će svakako dodati još jednu ploču u svoj informacijski sustav , u kojem će korisnike ponovno prisiljavati na unos podataka iz tih imenika. Nije mi poznat niti jedan EA alat koji je jednako prikladan za demonstraciju lijepe slike vrhunskih menadžera, a istodobno posjeduju 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 projekt implementacije informacijskog sustava i njegovog kasnijeg korištenja i razvoja.

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

Teorijski aspekti arhitektura poduzeća. Ključni elementi arhitekture poduzeća. Arhitektura poduzeća je najopćenitiji i najopsežniji prikaz poduzeća kao gospodarskog subjekta koji ima kratkoročne i dugoročne ciljeve obavljanja svoje osnovne djelatnosti, određene misijom na regionalnom i globalnom tržištu i strategijom razvoja, vanjskim te unutarnjih resursa potrebnih za ispunjenje misije i postizanje postavljenih ciljeva, kao i utvrđenih pravila za obavljanje temeljnog poslovanja. Teoretski...

Podijelite rad na društvenim mrežama

Ako vam ovaj rad ne odgovara, na dnu stranice nalazi se popis sličnih radova. Također možete koristiti gumb za pretraživanje

Uvod

1.3. Slojevi u arhitekturi

Bibliografija

Uvod

Nedavno vanjsko okruženje mijenja se vrlo brzo, pa se zahtjevi za prilagodljivošću poduzeća povećavaju iz godine u godinu. Razna analitička istraživanja pokazala su da većina međunarodne tvrtke nemaju vremena prilagoditi se tekućim promjenama, dok je trend na ovom području negativan. Glavni problem u osiguravanju prilagodljivosti poduzeća je koordinacija i kontrola promjena koje se unutar njega trebaju provoditi. Promjenom ciljeva mijenja se i strategija, što za posljedicu ima promjenu poslovnih procesa i prioriteta projekta te organizacijsku strukturu. Sve to neizravno utječe na razinu znanja i ovlasti u poduzeću, a time i na protok informacija, što će zahtijevati promjene u postojećim informacijskim sustavima.

Arhitektura poduzeća je najopćenitiji i najopsežniji prikaz poduzeća kao gospodarskog subjekta koji ima kratkoročne i dugoročne ciljeve obavljanja svoje osnovne djelatnosti definirane misijom na regionalnom i globalnom tržištu te strategijom razvoja , vanjski i unutarnji resursi potrebni za ispunjenje misije i postizanje postavljenih ciljeva, kao i utvrđena pravila za obavljanje glavne djelatnosti - poslovanja.

1. Teorijski aspekti arhitekture poduzeća

1.1. Ključni elementi arhitekture poduzeća

Enterprise Architecture Management pruža okvir za sinkronizaciju objekata unutar poduzeća, dok istovremeno osigurava da se kontinuirano mijenjaju u svrhu optimizacije poslovanja.

Kontrola promjena i konzistentnost svih elemenata arhitekture pridonose povećanju prilagodljivosti poduzeća, što je trenutno važan čimbenik u konkurenciji. Istodobno, informacijski sustavi često mogu postati faktor odvraćanja od promjena, što znači da posebnu pozornost treba posvetiti sinkronizaciji elemenata poslovne arhitekture i IT arhitekture. Za upravljanje arhitekturom poduzeća koristi se standardni ciklus koji se sastoji od sljedećih koraka: opisivanje postojeće arhitekture, projektiranje njezinog ciljnog stanja, formiranje plana prijelaza s postojeće na ciljnu arhitekturu. U prvom koraku potrebno je odrediti koje elemente arhitekture iu kojoj mjeri treba opisati.

S jedne strane, detaljiziranost izrađenog opisa znači dublje proučavanje, as druge strane su nepotrebni troškovi rada, kako za izradu samog opisa, tako i za njegovo održavanje ažurnim. Kako kažu, "najbolji je neprijatelj dobrog", pa samim tim i Detaljan opis arhitektonski elementi nisu korisni. U ovoj fazi važno je utvrditi ključne elemente arhitekture poduzeća od svih mogućih i usredotočiti se na njihov opis i analizu.

Praksa pokazuje da se prva neusklađenost u arhitekturi poduzeća, u pravilu, javlja između ciljeva, poslovnih procesa i organizacijske strukture. U mnogim slučajevima više ciljeva nije podržano potrebna sredstva i poslovnih procesa. Stoga je već u procesu analize arhitekture moguće odrediti plan rada za optimizaciju aktivnosti poduzeća u ovom području. Ako analiziramo informacijske tehnologije poduzeća, onda su i one često neusklađene s njegovim postojećim, a još više s ciljanim poslovnim procesima. I ovdje postoji veliko polje za optimizaciju aktivnosti.

Osim nedosljednosti između ključnih elemenata arhitekture poduzeća, često postoje problemi unutar nje pojedinačni element, prije svega, to je dupliciranje, kao i organizacijske i informacijske praznine itd. Međutim, nisu samo broj promjena i zahtjevi za agilnošću poduzeća uzrokovali tako ozbiljan fokus na pitanja upravljanja arhitekturom. Složenost tehnoloških sustava je sve veća, što znači smanjenje njihove pouzdanosti. U ovom slučaju, formalizacija arhitekture postaje osnova za pružanje procedura upravljanja operativnim rizikom u poduzeću, jer ako su njeni glavni elementi formalizirani, tada više nije teško identificirati rizike i analizirati učinkovitost kontrolnih postupaka. Stoga je najkritičnije upravljanje arhitekturom u velike tvrtke koji koriste složene tehnologije koje su povezane s mnogim operativnim i tehnološkim rizicima.

Unatoč raznolikosti metodologija u području upravljanja arhitekturom, u praksi je većina poduzeća ograničena na sljedeće elemente: poslovne ciljeve; organizacijska struktura; Ključni pokazatelji uspješnosti; Poslovni procesi; portfelj projekata; dokumenti; Informacijski sustavi; znanje osoblja. Ovo je potreban minimum koji vam omogućuje međusobno usklađivanje glavnih elemenata arhitekture. Međutim, ako su ciljevi, pokazatelji, organizacijska struktura i poslovni procesi često već nekako međusobno povezani, onda između procesa i informacijski sustavičesto nema tog odnosa. U tom smislu, jedan od prioriteta za mnoga poduzeća je prijelaz s modela poslovne arhitekture i regulative na definiranje zahtjeva informacijske tehnologije i izgradnju odgovarajuće IT arhitekture.

Informacijski jaz uzrokovan je prijenosom informacija od poslovnih analitičara do IT stručnjaka, au ovoj točki formalizacija takvih elemenata arhitekture kao što su zahtjevi, IT funkcije, transakcije, struktura podataka zajedno s poslovnim procesima omogućuje da se ovaj jaz zatvori. Na ovoj fazi važno je ispravno koristiti preporuke sadržane u metodologijama opisa arhitekture poduzeća, kao što je TOGAF.

Dakle, kako bi se uklonio „informacijski jaz“, potrebno je proširiti opis postojeće arhitekture poduzeća i, posebno, poslovne arhitekture u smjeru IT arhitekture, uzimajući u obzir jedinstvo metodologije opisa koja se koristi za i poslovni analitičari i IT stručnjaci. U ovom prijelazu s opisa arhitekture poslovnih procesa na opis IT arhitekture važno je formalizirati nekoliko dodatnih elemenata arhitekture. Prije svega potrebno je opisati podatkovnu arhitekturu koja se gradi na temelju informacija i dokumenata koji se koriste u poslovnim procesima, nakon čega treba formirati aplikacijsku arhitekturu i IT infrastrukturu.

Da bi se izgradila podatkovna arhitektura, potrebno je identificirati glavne entitete i na njima agregirati sve “kvante” informacija prikupljenih iz opisa poslovnih procesa. Praksa pokazuje da se za rješavanje ovog problema treba koristiti standardnom metodologijom opisa podataka Entity-Relationship Model ERM, unutar koje se sve informacije mogu jasno strukturirati. Sljedeća razina formalizacija IT arhitekture prijelaz s arhitekture poslovnih procesa i podatkovne arhitekture na stvaranje aplikativne arhitekture. U ovoj fazi važno je definirati klase informacijskih sustava potrebne za automatizaciju, kao i module za svaki informacijski sustav. Osnova za projektiranje arhitekture aplikacije i njezinu sinkronizaciju s poslovnom arhitekturom je mapa procesa (općeniti prikaz svih poslovnih procesa u poduzeću). Na modelu arhitekture aplikacije nalaze se glavni tipovi informacijskih sustava, koji se dalje detaljiziraju na modelu modula informacijskog sustava i dalje do razine pojedinačnih ekranskih transakcija.

Drugi ključni element arhitekture u smislu odnosa između poslovne arhitekture i IT arhitekture su zahtjevi informacijskog sustava. Zapravo, modeli zahtjeva su ciljna funkcionalnost IT rješenja, koja je strukturirana po poslovnim procesima ili po odjelima. Na temelju ovih zahtjeva i postojećih modela poslovnih procesa, kao i uzimajući u obzir izgrađene podatkovne modele, projektirana je nova (ciljana) arhitektura aplikacije. U isto vrijeme, uz metodologije upravljanja arhitekturom poduzeća, za rješavanje zadataka moraju se koristiti i industrijski standardi. Na primjer, u slučaju telekomunikacijskih tvrtki kao osnova se mogu koristiti materijali iz metodologije New Generation Operation System and Software (NGOSS), koju je 2001. izradio TeleManagement Forum i sadrži sljedeće modele:

1. model poslovanja telekomunikacijske tvrtke eTOM (Enhanced Telecom Operations Map eTOM);
2. informacijski model telekomunikacija poduzeća (SID za dijeljene informacije i podatkovni model informacijskog okvira za cijelo poduzeće);
3. aplikacijski okvir telekomunikacijske tvrtke ( Applications Framework Telecom Applications Map TAM ).

1.2. Modeli i alati arhitekture aplikacija

Arhitektura aplikacije pokriva prilično široko područje, koje počinje identificiranjem aplikacijskih sustava koje poduzeće treba za obavljanje poslovnih procesa, a uključuje aspekte kao što su dizajn, razvoj (ili nabava) i integracija aplikacijskog sustava. U pravilu se u arhitekturi aplikacija razlikuju dva glavna područja: formiranje i upravljanje portfeljem aplikacijskih sustava poduzeća i razvoj aplikacijskih sustava.

Portfelj aplikacija poduzeća opći je plan o tome kako skup aplikacijskih sustava zadovoljava potrebe poslovnih procesa poduzeća. Definira opseg i prioritet svake aplikacije, kao i način na koji će se postići potrebna funkcionalnost: razvojem sustava, kupnjom gotovih aplikacija, iznajmljivanjem aplikacije ili integracijom i korištenjem mogućnosti postojeće aplikacije. aplikacije. Portfelj aplikacijskih sustava opisuje aplikacije dizajnirane za obavljanje funkcija organizacije i razmjenu informacija između kupaca, dobavljača i partnera poduzeća. Ujedno se opisuju i kanali moguće interakcije korisnika s aplikacijama: web preglednici, grafičko sučelje „debelog“ klijenta, Mobilni uredaji itd.

Područje razvoja primijenjenih sustava opisuje one tehnologije koje se koriste za izgradnju sustava, njihovu podjelu na funkcionalne komponente, stvaranje sučelja, postavki, kao i predloške, priručnike i sl. koji se za to koriste. Ovo područje također definira organizaciju razvojnog procesa, alate koji se za to koriste, razvojni ciklus sustava koji je prihvatilo poduzeće, kontrolu verzija, upravljanje konfiguracijom, korišteni međuprogram, alate za dizajn. Glavna zadaća područja je smanjenje troškova izrade primijenjenih sustava i poboljšanje njihove kvalitete pružanjem jedinstvenih pristupa razvoju. To pak dovodi do smanjenja ukupno različiti tehnički scenariji vezani uz projektiranje arhitekture, operativnu podršku, arhitekturu integracije sustava, obuku osoblja. Ovdje je potrebno uključivanje arhitekata aplikativnog sustava. Naravno, ovo područje ima smisla dodijeliti samo onim organizacijama u kojima se provodi samostalan razvoj ili usavršavanje aplikacija, za razliku od modela outsourcinga. Na temelju ovih komentara i odvajanja dvaju područja u arhitekturi aplikacija, portfelju aplikacija i razvoju, može se reći da je uvođenje nekog novog sustava u poduzeće, na primjer, naplate, dio upravljanja portfeljem aplikacija poduzeća. Istovremeno, tehnologije i principi koji se koriste u projektiranju sustava, kao i njegovoj implementaciji i održavanju, pripadaju području razvoja. U budućnosti ćemo govoriti o arhitekturi aplikacija, imajući u vidu prije svega portfelj aplikativnih sustava. U idealnom slučaju, portfelj poslovnih aplikacija trebao bi uključivati ​​trenutni skup aplikacija i neki model da bi se razumjelo koje će aplikacije biti potrebne u budućnosti kako bi se zadovoljile nove poslovne i organizacijske potrebe. Portfelj aplikacija također treba specificirati odnose između funkcionalnih i tehnoloških (operativnih) komponenti okruženja informacijske tehnologije poduzeća, tj. objasniti zašto su određene tehnologije uključene u infrastrukturu za izgradnju portfelja poslovnih aplikacijskih sustava. Ovaj je aspekt važan jer su ulaganja u infrastrukturu značajan dio kapitalnih izdataka i moraju biti dobro opravdana. Konačno, portfelj aplikacija trebao bi dati ideju o tome koliko će to koštati u smislu financijskih troškova i koliko će dugo biti potrebno organizaciji da migrira u željeno buduće stanje pomoću ovih aplikacijskih sustava. Dakle, portfelj primijenjenih sustava je integrirani skup IS-a poduzeća koji zadovoljava potrebe poslovanja i uključuje sljedeće aspekte:

1. Postojeći portfelj primijenjenih sustava. To je katalog postojećih aplikacija i komponente koja odražava njihove odnose s poslovnim procesima koje podržavaju, sučelja s drugim sustavima, korištene i potrebne informacije te korištene obrasce infrastrukture. Da bi bio doista koristan alat, također mora pomoći u identificiranju onih elemenata portfelja koji se mogu ponovno koristiti i ponovno koristiti u cijelom poduzeću te poticati takvu ponovnu upotrebu.
2. Planirani portfelj primijenjenih sustava. Predstavlja funkcionalnost koja je potrebna za pružanje željenog stanja poslovne i poslovne informacijske arhitekture.
3. Plan migracije. Proces prelaska sa sadašnjeg na budući portfelj aplikativnih sustava unutar IT projekata. Projekti se također mogu kombinirati u projektne portfelje. Prvi korak u planiranju portfelja aplikacijskih sustava je procijeniti trenutno stanje portfelja i kako odgovara potrebama organizacije sa strateškog i tehnološkog gledišta, tj. sa stajališta zadataka, poslovne strategije i sa stajališta tehničkog stanja i strategije korištenja tehnologija u poduzeću. Usklađenost s poslovnim strategijama ocjenjuje se na temelju doprinosa aplikativnih sustava ostvarenju poslovnih rezultata, što je određeno poslovnom arhitekturom poduzeća. Tehnološka usklađenost ocjenjuje se na temelju analize usklađenosti aplikacijskih sustava s načelima i tehnološkim standardima usvojenim u tehnološkoj arhitekturi poduzeća. Postoje različiti načini vrednovanja portfelja i razne klasifikacije aplikacijski sustavi poduzeća. Jedan od mogućih modela vrednovanja portfelja primijenjenih sustava je njihovo vrednovanje prema dva kriterija poslovnoj vrijednosti i tehničkom stanju. Vrednovanje portfelja služi Polazna točka u identificiranju problematičnih područja i prilika za bolje zadovoljavanje poslovnih potreba i odlučivanju o ulaganju u nove sustave ili nadogradnji postojećih. Kao rezultat ove procjene, aplikacijski sustavi spadaju u jednu od četiri moguće kategorije:
   1. sustavima prijeti prestanak rada (zamjena) ili konsolidacija;
   2. sustavi koji zahtijevaju ponovnu procjenu ili repozicioniranje;
   3. sustave koje je potrebno ažurirati;
   4. sustave koji zahtijevaju održavanje i razvoj.

Tehničko stanje ocjenjuje se na temelju brojnih karakteristika, uključujući točnost i ispravnost podataka, arhitekturu, strukturu koda, odzivnost, vrijeme zastoja, razinu održavanja, sposobnost izvješćivanja itd. Vrijednost sustava s poslovne točke gledišta odnosi se na sposobnost sustava da obavlja bitne funkcije poduzeća, odjela ili procesa. Sljedeći broj će dati karakteristike svake kategorije sustava u skladu s ovom klasifikacijom.

1.3. Slojevi u arhitekturi

Koncept slojeva jedan je od uobičajenih modela koje koriste programeri softver rastaviti složene sustave na jednostavnije dijelove. Arhitekture računalnih sustava, na primjer, razlikuju slojeve koda programskog jezika, funkcije operacijskog sustava, upravljačke programe uređaja, skupove instrukcija CPU-a i internu logiku čipa. U okruženju umrežavanje FTP protokol radi na temelju TCP protokola, koji pak radi "na vrhu" IP protokola, koji se nalazi "iznad" Ethernet protokola. Dakle, razmotrimo glavne razloge zanimanja za slojeve arhitekture softverskih sustava:

Slojevi se lako formaliziraju. Intuitivno je jasno da ako je sustav podijeljen na nekoliko slojeva, tada je sloj n komponenta ili skup komponenti sustava koje koriste samo komponente sloja n-1 i mogu ga koristiti samo komponente sloja n+1.

Slojevi imaju jednostavnu i deskriptivnu semantiku. Općenito, u arhitekturi softverskog sustava, slojevi predstavljaju razine apstrakcije. Sloj n+1 koristi sloj n, stoga apstrakcija koncepata sloja n+1 barem nije niža od one sloja n, a u idealnom slučaju ako je arhitektura sustava učinkovita, njegova bi razina apstrakcije trebala biti viša. Sukladno tome, sloj n skriva (inkapsulira) logiku rada s konceptima definiranim na ovom sloju, omogućujući sloju n + 1 da implementira rad sa složenijim konceptima, organizira složeniju logiku koristeći izražajna sredstva donjeg sloja.

Slojevi su široko rasprostranjeni. Doista, prilično velik broj softverskih sustava, posebno kada je riječ o programski sustavi mjerila poduzeća (sustavi poduzeća), imaju slojevitu strukturu. Naravno, vrlo često postoji situacija kada se u pravilu krši stroga slojevita struktura sustava, to je posljedica arhitektonske erozije (arhitektonski nedostatak) i njegovo uklanjanje u većini slučajeva može donijeti opipljive koristi (ovi aspekti se raspravljaju u nastavku ).

Alternativna implementacija. Možete odabrati alternativnu implementaciju osnovnih slojeva komponente gornjeg sloja mogu raditi bez ikakvih promjena u nižim slojevima, pod uvjetom da su sučelja sačuvana.

Ovisnost između slojeva, to jest, zapravo, sučelja koja pružaju niži slojevi prema gornjem, može se minimizirati. Ovo minimiziranje sučelja povećava fleksibilnost sustava.

Shema arhitektonskih slojeva također ima određene nedostatke:

kaskadne promjene. Slojevi su dobri u enkapsulaciji puno toga, ali ne svega: modificiranje jednog sloja ponekad zahtijeva kaskadne promjene na drugim slojevima. Klasičan primjer iz područja aplikacija poslovnog softvera: polje dodano tablici baze podataka treba se reproducirati u grafičkom sučelju i mora pronaći odgovarajući prikaz u svakom međusloju.

Pad performansi. Prisutnost redundantnih slojeva često smanjuje performanse sustava. Kako se krećete od sloja do sloja, podaci obično prolaze kroz transformacije iz jednog prikaza u drugi. Unatoč tome, enkapsulacija temeljnih funkcija često može postići vrlo značajnu prednost. Na primjer, optimiziranje transakcijskog sloja obično rezultira boljom izvedbom za sve slojeve iznad njega.

Za potrebe analize sustava, arhitektura poduzeća može se razmatrati u dva aspekta:

1. statički - prema stanju banke u nekoj fiksnoj vremenskoj točki;
2. dinamički - kao proces prijelaza (migracije) banke iz sadašnjeg stanja u neko željeno stanje u budućnosti.

Arhitektura poduzeća koja se razmatra u statici sastoji se od sljedećih elemenata:

1. misija i strategija, strateški ciljevi i ciljevi;
2. poslovne arhitekture;
3. Arhitektura sustava.

Gledano kao dinamična arhitektura poduzeća, to je koherentan, koherentan plan akcija i koordiniranih projekata potrebnih za transformaciju trenutne arhitekture organizacije u stanje definirano kao dugoročni cilj temeljen na trenutnom i planiranom poslovne svrhe i Poslovni procesi organizacije.

Stoga je arhitektura poduzeća općenito opisana sljedećim sekvencijalno ovisnim odjeljcima:

1. formulirana misija i strategija banke, strateški ciljevi i ciljevi;
2. poslovnu arhitekturu u trenutnom (kakvom jest) i planiranom (budućem) stanju,
3. arhitektura sustava u trenutnom (kakva jest) i planiranom (biti) stanju;
4. akcijski planovi i projekti prijelaza iz sadašnjeg stanja u planirano.

Dakle, planirana arhitektura sustava je "biti" arhitektura samo u određenoj fazi razvoja poduzeća.

Istodobno, povratak na stratešku razinu misije i strateških ciljeva i zadataka ne znači potrebu revizije misije i strategije. No, na kraju svakog ciklusa nužno se provodi analiza učinkovitosti razvijenih i implementiranih mjera, po potrebi se u drugoj iteraciji prilagođava poslovna arhitektura, arhitektura sustava i implementiraju novi planovi migracije. U svakom trenutku može postojati nekoliko ciklusa, svaki takav ciklus ne mora nužno utjecati na cijelo poduzeće u cjelini, ciklus može utjecati na određena područja, određena poslovna pitanja i može se evidentirati kao zaseban projekt.

Kod faznog plana migracije, u svrhu popravljanja postignutih rezultata, moguće je izgraditi među (migraciju) jednu ili više arhitektura. Misija, strategija i poslovni ciljevi određuju smjer razvoja poduzeća i postavljaju dugoročne ciljeve.

U arhitekturi poduzeća treba razlikovati sljedeće slojeve:

1. Prednji ured (Front-Office)

Front-Office (Prednji ured)kao vanjski računovodstveni sustav (inposlovna arhitektura poduzeća- je zbirkaPoslovni procesi, procedure, normativni dokumenti (propisi), referentne knjige, tiskani obrasci, organizacijske i kadrovske jedinice koje osiguravaju izravnu interakciju s klijentom sa strane poduzeća:

1. Prijem i unos za daljnju obradu primarni dokumenti,
2. Ispis i pružanje informacija i dokumenata klijentu,
3. Pozivanje klijenata i slanje informativnih poruka klijentima,
4. Primanje dolaznih telefonskih poziva, upita i davanje informacija.

Front-Office (Front office) kao vanjski računovodstveni sustav (inarhitektura sustava poduzećaje skup informacijskih sustava, uključujući baze podataka i imenike, s ciljem automatizacijePoslovni procesiinterakcija s klijentom.

1. Srednji ured (srednji ured)

Srednji ured u poslovne arhitekture - ovo je skup poslovnih procesa, procedura, regulatornih dokumenata (propisa), priručnika, tiskanih obrazaca, organizacijskih i kadrovskih jedinica koje osiguravaju pripremu i donošenje odluka.

Primjeri srednjih odjela ureda:

Jedinica za provjeru dužnika u službi sigurnosti,

Sektor upravljanja rizicima.

Srednji ured u Arhitektura sustava -ovo je skup informacijskih sustava, uključujući baze podataka i imenike, s ciljem automatizacije poslovnih procesa vezanih uz pripremu i donošenje odluka.

Primjeri informacijskih sustava srednjeg ureda:

sustav obračuna položaja,

Sustav provjere zajmoprimca u uredu za kreditne povijesti,

Sustav za izračun bodovanja za zahtjev za kredit.

1. Stražnji ured

Back office (pozadinski ured) kako unutarnji sustav računovodstvo (uposlovne arhitekture) poduzeća su skup poslovnih procesa, procedura,normativni dokumenti (propisi), referentne knjige, tiskani obrasci, organizacijske i kadrovske jedinice koje provode dnevničko (registarsko) knjigovodstvo poslovanja. Obično, registar računovodstvo je dnevnik transakcija s drugim ugovornim stranama, nije povezano s računovodstveni računi, nije dvostrana.

Pozadinski ured u Arhitektura sustavapoduzeća su skup informacijskih sustava, uključujući baze podataka i imenike, koji provode dnevnik (registar) računovodstva poslovanja.

1. Računovodstvo

poslovno računovodstvo ( poslovne arhitekture) je skup poslovnih procesa, postupaka, regulatornih dokumenata (propisa), referentnih knjiga, tiskanih obrazaca, organizacijskih i kadrovskih jedinica koje provode računovodstvo i izvješćivanje u skladu s RAS (Računovodstveni propisi - Računovodstveni standardi Rusije) i MSFI ( Međunarodni standardi financijsko izvješćivanje), održavanje bilance poduzeća.

1. Skladište informacija (DWH)
2. Izvještavanje

Izvjestavati arhitektura sustava - skup informacijskih sustava, uključujući baze podataka i imenike, koji automatiziraju izradu izvješća na temelju podataka iz skladišta informacija.

Primjeri sustava izvješćivanja:

sustav izvješćivanja uprave,

Sustav analitičkog izvještavanja,

Sustav ključni pokazatelji učinkovitost poslovnih jedinica,

Sustav za generiranje indikatora za izračun bodovanja kreditnog zahtjeva.

Bibliografija

1. Vasiliev R. B., Kalyanov G. N., Levochkin G. A., Lukinova O. V. Strateški menadžment informacijski sustavi; Internet Sveučilište informacijskih tehnologija, Binom. Laboratorija znanja - Moskva, 2013. godine. - 512 c.
2. Gritsenko Yu. B. Arhitektura poduzeća: udžbenik / Gritsenko Yu. B. 2011. 256 str.
3. Danilin A.V., Slyusarenko A.I., Tečaj obuke Enterprise architecture [Elektronički izvor] - Način pristupa:http://www.intuit.ru/department/itmngt/entarc/
4. Kalyanov G.N. Modeliranje, analiza, reorganizacija i automatizacija poslovnih procesa. Udžbenik: M.: Financije i statistika, 2006.

Stranica 17

Ostali srodni radovi koji bi vas mogli zanimati.vshm>
803.		Arhitektura ugostiteljstva	36,04 KB
	Arhitektonski aspekti izgradnje i smještaja hotela. Uloga interijera i dizajna hotela u hotelskoj ponudi. Uvod Specifičnost hotela je u raznolikosti funkcija ovih objekata. povoljni uvjeti ljudske životne aktivnosti u hotelima osigurane su stvaranjem udobnosti kako u samoj zgradi hotela, tako i na teritoriju uz nju.
17390.		Arhitektura Velikog Novgoroda	324.25KB
	Prevladavajuće gledište je da je stari grad takozvano Naselje koje se nalazi na desnoj obali Volhova, dva kilometra od modernog grada. Kako bi se dublje upoznali s arhitekturom ovog grada, tema rada je odabrana kao Arhitektura Novgoroda XI-XV stoljeća. Tehnika takvih radova sastojala se u tome da se na pocrnjele bakrene limove rezačem nanosi šara iu njene utore utapa zlatna žica. Može se pripisati najstarijem: ploča na kojoj je ispisan vrlo je stara po nizu svojstava i karaktera...
19556.		Staljinistički vertikalizam i arhitektura	24,72 KB
	Da bismo razumjeli specifičnosti samog sovjetskog puta te oblikovanja i sadržaja sovjetske arhitekture, potrebno je proučiti ograničenja i propise koje je nametnula općenacionalna organizacija. profesionalna djelatnost na način razmišljanja konkretnih majstora. i s druge strane, planovi za stanove u stilu staljinističkog carstva koji sadrže terase, dnevne sobe za domaćice itd.: Neoklasicizam Neoklasicizam je termin usvojen u sovjetskoj povijesti umjetnosti za označavanje različitih društvenih orijentacija i ideoloških ...
17255.		Hramska arhitektura Moskve	595.99KB
	Svijetli kolorit zidova od opeke crkve Trojstva, raščlanjen elegantnim ukrasnim obrubom od bijelog klesanog kamena i obojenih glaziranih pločica, premaz od bijelog njemačkog željeza, zlatni križevi na zelenim popločanim kupolama, sve zajedno stvaralo je neodoljiv dojam. ..
13405.		Arhitektura starobabilonskog kraljevstva	528.04KB
	Njegovo središte bio je grad Babilon Babili znači Vrata boga čiji su kraljevi u II tisućljeću. Vrhunac starobabilonskog kraljevstva pao je na vladavinu šestog kralja I. babilonske dinastije, Hamurabija. Pod njim se Babilon iz malog grada pretvorio u najveći ekonomski politički i Centar za kulturu Prednja Azija.
7046.		Arhitektura i struktura osobnog računala. Von Neumannovo načelo	9,14 KB
	PC je relativno jeftino univerzalno mikroračunalo dizajnirano za jednog korisnika. Moderna računala dizajnirana su prema načelu otvorene arhitekture.
6695.		Arhitektura baze podataka. Fizička i logička neovisnost	106.36KB
	Daje sljedeće definicije baze podataka baze podataka i DBMS-a: BnD banka podataka je sustav posebno organiziranih baza podataka programskih tehničkih jezičnih organizacijskih i metodoloških alata dizajniranih da osiguraju centralizirano prikupljanje i kolektivnu višenamjensku upotrebu podataka. DB baze podataka je imenovana zbirka podataka koja odražava stanje objekata i njihove odnose u predmetnom području koje se razmatra. Sustav upravljanja bazom podataka DBMS je skup jezika i ...
18392.		Razvoj obrazovnog i metodološkog kompleksa za disciplinu "Arhitektura računala"	606.23KB
	Zatim se krug korisnika proširio prvenstveno zahvaljujući znanstvenicima koji su pomoću računala provodili strojne pokuse. Elektronički udžbenik je obrazovni proizvod koji se može reproducirati samo pomoću alata za informatiku, uključujući računalo, koji odgovara odobrenom programu obuke ili programu koji je razvio autor za predloženi tečaj i ima bitno nove značajke u usporedbi s konvencionalnim udžbenikom. elektronički udžbenik može biti dizajniran za...
9225.		ARHITEKTURA I KOMPONENTNA BAZA LOKALNIH RAČUNALNIH MREŽA LA	150,96 KB
	21. stoljeće i treće tisućljeće koje je stiglo sve više nameću pitanje: što zrakoplovi(LA) borbena avijacija će osigurati prevlast u zraku? Na postavljeno pitanje slijedi nedvosmislen odgovor - bit će to lovci sljedeće, 5. generacije, mlaznog doba zrakoplovstva. Teško je i nije uvijek moguće povući jasnu granicu između generacija zrakoplova. Da, i promjena generacija je prilično spor proces.
21769.		Intel procesori, arhitektura procesora, čipseti i njihove karakteristike	95,27 KB
	Središnja procesorska jedinica (mikroprocesor, CPU) - dio računalnog hardvera odgovoran za izvođenje aritmetičkih operacija određenih programima i koordinaciju rada svih računalnih uređaja. Procesor je posebno uzgojen poluvodički kristal na kojem su smješteni tranzistori.