Este necesar un interpret. Problema se complică și mai mult de faptul că fiecare dintre cele patru tipuri (PAEI) oferă un sens diferit cuvintelor „a fi”, „vrei” și „necesar”, pe baza particularității propriei imagini a Un antreprenor, de regulă, ia decizii, percepând

Necesar: Cunoștințe de economie Pentru a te pregăti pentru o carieră în relații publice, trebuie să obții o educație solidă în economie. Fiind angajat ca profesionist, va trebui să se ocupe de aspecte financiare

Pasul 6: Aplicarea arhitecturii Orice organizație care dorește să utilizeze o arhitectură de proces trebuie să dezvolte disciplina necesară. Aceasta înseamnă că toate proiectele relevante trebuie să ia în considerare arhitectura și să identifice unde se abate de la convenit

Exemplu de obiective generale de arhitectură: Realizarea unei creșteri de 200% a veniturilor din vânzări în următorii trei ani; asigura o crestere a profitului de 150% in urmatorii trei ani Principii generale: valorile noastre corporative: cel mai bun raport calitate-pret

De ce avem nevoie de conceptul de „aprobare”? De ce folosim termenul „afirmare”? Dacă scrie „lipsește o afirmație”, atunci un element important (cauză, efect, scop sau sarcină intermediară etc.) nu este menționat în arborele logic. Folosind

Ce este necesar pentru asta? Dacă există o dorință, nu este deloc dificil să creezi beneficiile enumerate. Luați, de exemplu, împărtășirea abilităților și experienței în cadrul unei unități. Acest lucru necesită o unitate care să funcționeze bine, cu capacitatea de a

Capitolul 1 De ce aveți nevoie de un model de arhitectură de afaceri: Declarații de probleme de modelare standard a proceselor de afaceri O mare parte din rațiunea dezvoltării unui model de arhitectură de afaceri se bazează pe înțelegerea factorilor care împing o întreprindere să caute optimizare.

O anumită experiență necesară Aceste planuri antreprenoriale ne-au adus amintiri din prima noastră experiență cu VC.

Este nevoie de un geniu. Abilitatea medie nu mai este suficientă. Ne dezvoltăm. Ceea ce este mediu astăzi va fi sub medie mâine. Nu suntem pe un carusel de târg, unde este suficient doar să ne ținem de un inel de cupru pentru a nu cădea. Înaintăm constant. merge mai departe

În multe privințe, justificarea necesității dezvoltării unui model de arhitectură de afaceri este asociată cu înțelegerea factorilor care împing o întreprindere să caute soluții de optimizare în domeniul organizării activităților. Acești factori pot include tendințele macroeconomice, mediul competitiv, schimbările în strategiile de afaceri etc. Cunoașterea acestor factori și legarea lor de capabilitățile de rezolvare a problemelor ale modelării arhitecturii de afaceri este esențială pentru a susține proiectul cu conducerea de vârf a organizației.

Problema fundamentarii nevoii si bugetelor unui proiect de a crea un model de arhitectura de business este asociata nu numai cu identificarea factorilor „motoare”, ci si cu complexitatea fundamentarii efectelor asteptate. În multe cazuri pe stadiul inițial se pot declara doar estimări legate de îmbunătățirea indirectă a activității organizației, care sunt greu de comparat cu beneficii financiare clar definite. Chiar și în cazul apariției unor evenimente cu efecte cuantificabile, dovada legăturii directe a acestor evenimente cu construirea și implementarea unui model de arhitectură de afaceri în procesul de management al unei organizații nu este întotdeauna posibilă.

Este dificil să oferim abordări generale pentru a fundamenta efectele economice așteptate din cauza apariției unui model real de arhitectură de afaceri într-o organizație. În multe privințe, câștigul final este determinat de unicitatea situației fiecărei organizații particulare. Aceasta poate fi reinginerirea de succes a proceselor de afaceri, optimizarea infrastructurii informaționale și tehnologice, reducerea timpului și a costurilor pentru obținerea datelor inițiale la lansarea proiectelor etc., implementate pe baza utilizării modelului.

În abordarea cea mai generală, efectele creării unui model de arhitectură de afaceri ar trebui să fie poziționate cu o creștere a capacității de gestionare a întreprinderii. În ceea ce privește componenta IT a arhitecturii întreprinderii, practica mondială arată posibilitatea reducerii costurilor per angajat cu până la 30%, în timp ce absența unei arhitecturi IT documentate implică costuri suplimentare de până la 12-18% într-un număr de operațiuni. zone.

Dacă este necesar să se obțină estimări privind efectele „integrale” din implementarea modelului de arhitectură de afaceri, luarea în considerare doar a beneficiilor financiare va fi insuficientă pentru a justifica investiția. Prin urmare, va fi necesar să se utilizeze mecanisme de decontare mai complexe, inclusiv efecte „nefinanciare” care sunt semnificative pentru activitățile organizației. Acest tip de efecte ar trebui să includă reducerea la minimum a riscurilor în timpul diferitelor schimbări în activitățile organizației, prin utilizarea capabilităților modelului de arhitectură de afaceri pentru a simula diferite opțiuni de scenariu, inclusiv obținerea diferitelor calitative și evaluări cantitative. Având în vedere dinamica ridicată a schimbării și complexitatea organizare modernă, aspectele de minimizare a riscurilor asociate cu problemele de restructurare sunt de o importanță deosebită.

O caracteristică a proiectelor de investiții pentru a crea un model de arhitectură de afaceri este un timp destul de lung de așteptare pentru efectele observate în mod clar. Într-o oarecare măsură, aici putem face o analogie cu așteptările privind returnarea costurilor pentru formarea personalului pentru a îmbunătăți informația generală sau cultura proiectului. Ca parte a raționalizării eficienței arhitecturii componentelor IT, sunt în prezent luate în considerare posibilitățile de utilizare a unor indicatori precum Return on Assets (ROA) și Return on Opportunity.

Una dintre întrebările standard inițiale de la șefii organizației, care nu erau familiarizați anterior cu posibilitățile și sarcinile modelării proceselor de afaceri, este de a clarifica beneficiile așteptate din rezultatele muncii de consultanță în modelare.

Adesea, răspunsurile standard la aceste întrebări sunt asociate cu un accent pe optimizarea proceselor de afaceri ale organizației și, în consecință, listarea unui „set de bază” de parametri de optimizare:

♦ duplicarea funcţiilor;

♦ blocaje;

♦ centre de cost;

♦ calitatea operațiunilor individuale;

♦ tranzacții redundante;

♦ posibilități de automatizare;

♦ posibilitatea introducerii sistemelor de management al calitatii;

♦ posibilitatea de certificare conform ISO 900x.

Cu toată corectitudinea acestor răspunsuri, trebuie recunoscut că din punctul de vedere al succesiunii lucrărilor și al obținerii rezultatelor, acestea nu sunt priorități de top.

Destul de independent, important și primul care trebuie atins este rezultatul privind ordonarea și documentarea cunoștințelor despre organizație. Ca parte a construirii unui model, apar inevitabil următoarele procese:

♦ inventarierea si extragerea din diverse surse (inclusiv angajati individuali calificati) de informatii (cunostinte) specifice din punct de vedere al activitatilor organizatiei;

♦ structurarea și sistematizarea informațiilor extrase, ținând cont de principalele scopuri și obiective ale organizației;

♦ formalizarea și documentarea informațiilor (cunoștințelor) despre organizație.

Evident, indiferent de obiectivele de optimizare, acumularea calitativă, structurarea și formalizarea informațiilor (cunoștințelor) sunt foarte importante din punct de vedere:

♦ suport tehnologic pentru procesele de conservare a know-how-ului organizaţiei;

♦ reducerea dependenței de resursele experților cheie pentru a transfera cunoștințe și competențe către noii angajați;

♦ creșterea nivelului de gestionare a organizației prin formalizarea cerințelor postului și a instrucțiunilor pentru personal.

De regulă, după sistematizarea și formalizarea cunoștințelor privind starea actuală a activităților organizației, chiar înainte de descrierea proceselor și de alegerea unei metode de optimizare a acestora (reinginerie), se identifică rezervele organizaționale și tehnologice pe baza instrumentelor de modelare specializate care poate fi folosit pentru a îmbunătăți eficiența organizației.

În etapa de sistematizare și formalizare, se efectuează verificarea efectivă a disponibilității și clarității definiției și, dacă este necesar, clarificarea unor date atât de importante pentru organizație, cum ar fi:

♦ sarcini;

♦ indicatori de performanță;

♦ reglementări (instrucțiuni, comenzi etc.) ale proceselor de afaceri.

Într-o serie de cazuri, se poate spune că liniile directoare normative sunt la fel de executabile și verificabile din punct de vedere al calității execuției, pe atât de formalizabile. În acest sens, la etapa de sistematizare și formalizare se verifică „funcționalitatea” țintelor și reglementărilor (standardelor).

Prin urmare, răspunsul corect pentru un potențial client la întrebarea „de ce avem nevoie de un model” a arhitecturii de afaceri a organizației este să indice cel puțin două rezultate (obiective) importante:

♦ sistematizarea și documentarea (formalizarea) informațiilor (cunoștințelor) semnificative pentru activitate, care asigură:

a) baza tehnologică pentru conservarea și disponibilitatea intra-corporativă cunoștințe de specialitate(know-how) organizații;

b) creşterea nivelului de gestionare a resurselor organizaţiei datorită formalizării calitative a reglementărilor de utilizare a acestora (Fig. 1);

Orez. 1. Probleme de management al cunoștințelor în organizație în ceea ce privește procesele de afaceri

♦ crearea unei baze metodologice și tehnologice pentru optimizarea (reinginerirea) pas cu pas a organizației, care să permită realizarea unei evaluări tehnico-economice a măsurilor de modernizare, identificarea rezervelor organizatorice, funcționale și tehnologice pentru îmbunătățirea eficienței; a organizaţiei (Fig. 2).

Orez. 2. Decizii promițătoare cu privire la utilizarea cunoștințelor despre procesele de afaceri la luare decizii de management

Unul dintre argumentele suplimentare în favoarea necesității modelării arhitecturii de afaceri a organizației este tendințele globale în standardizarea cerințelor pentru prezența obligatorie a modelelor de procese de afaceri ale organizației. Dovada acestor tendințe este apariția standardelor și metodologiilor specializate pentru proiectarea arhitecturii întreprinderii.

Ca principale metodologii și standarde, trebuie menționate standardele „cadru” pentru dezvoltarea arhitecturii întreprinderii;

a) ISO 15704 este un standard pentru descrierea formală a unei arhitecturi de întreprindere care a fost propusă grup de lucru IFAC/IFIP (International Federation of Automatic Control/International Federation for Information Processing);

b) ISO 15288 este un standard care defineşte ciclu de viață sisteme;

c) ISO 12207 este un standard care definește ciclul de viață al software-ului.

Există peste 30 de sisteme „suport” suplimentare și standarde de inginerie software (de exemplu, ISO 14258 care definește conceptele și regulile pentru modelarea întreprinderii).

Dezvoltarea unui model de arhitectură de afaceri este unul dintre următorii pași logici pentru acele organizații care au început să implementeze conceptul de arhitectură orientată pe servicii (SOA). În centrul său, SOA reflectă trăsăturile situației moderne actuale în pătrunderea reciprocă a IT și a afacerii, când este extrem de dificil să se tragă o linie între funcțiile de business ale organizației și tehnologiile informaționale care le asigură.

Din punctul de vedere al suportului SOA, modelul de arhitectură de afaceri este principalul instrument de sincronizare a nevoilor afacerii și a capabilităților tehnologiei informației. Este modelul de arhitectură de afaceri care poartă principala sarcină de a oferi condiții pentru o abordare prin proces pentru proiectarea și optimizarea arhitecturii de afaceri a organizației în sine, urmată de proiectarea IT. Conform conceptului SOA, arhitectura afacerii ar trebui să se bazeze pe un model de întreprindere orientat spre proces. Combinația acestei abordări cu conceptul de arhitectură a tehnologiei informației orientate către servicii vă permite să legați mai bine procesul de dezvoltare a componentelor sistemelor informaționale cu misiunea, sarcinile principale și funcțiile organizațiilor. Cu SOA, organizațiile au potențialul de a dezvolta un set de implementări ale diferitelor procese de afaceri care pot fi reutilizate de întreprindere ca servicii gata făcute.

Declarațiile de sarcini pentru modelarea arhitecturii de afaceri în contextul suportului SOA au ca scop asigurarea următoarelor cerințe pentru proiectarea IS:

♦ separarea explicită a logicii de business a sistemului aplicat de logica prezentării informaţiei;

♦ implementarea logicii de business a sistemului aplicativ sub forma unui număr de module software(servicii) care sunt disponibile din exterior (pentru utilizatori și alte module), cel mai adesea în modul „cerere-răspuns”, prin interfețe de acces formale bine definite.

În același timp, „consumatorul de servicii”, care poate fi un sistem de aplicație sau un alt serviciu, are capacitatea de a apela serviciul prin interfețe folosind mecanismele de comunicare adecvate și, de asemenea, își poziționează clar locul în procesul de afaceri.

Pe lângă rolul de „furnizare”, și anume suport pentru implementarea conceptului SOA, modelul de arhitectură de afaceri are o semnificație independentă și definițiile sarcinilor corespunzătoare. Dinamica ridicată a schimbărilor în mediu afaceri moderne, nu poate decât să aibă o influență puternică asupra vitezei și sferei de dezvoltare a modelării de afaceri. Efectuarea de previziuni pe termen lung bazate pe stabilitatea situației nu este posibilă în aproape orice domeniu de afaceri. Dimpotrivă, companiile trebuie să se adapteze la un mediu în continuă schimbare și să dezvolte abilitățile de a se adapta rapid la schimbările de afaceri în curs. În acest sens, în prezent se dezvoltă concepte de organizații care conțin mecanisme interne speciale care le permit să se schimbe în conformitate cu cerințele mediului extern.

Rolul din ce în ce mai mare al modelării afacerilor este determinat nu numai de dinamica ridicată a mediului de „activitate de viață” al organizației, ci și de circumstanțele pe care le are resursa de oportunități de a răspunde eficient „provocărilor” pieței doar prin intermediul IT. a fost redus semnificativ. Din ce în ce mai mult, există afirmații că haosul nu poate fi automatizat, că automatizarea haosului este și mai mult haos, că IT-ul modern nu poate fi considerat un panaceu pentru toate problemele de afaceri.

Principalele rezerve pentru creșterea eficienței și competitivității întreprinderilor sunt asociate în prezent cu optimizarea arhitecturii lor de afaceri, implementarea consecventă a modelului de management al proceselor, asigurarea flexibilității structurii organizaționale și a proceselor de afaceri asociate managementului valorii adăugate etc. oportunități sunt oferite în mare măsură în detaliu o arhitectură de afaceri bine dezvoltată a companiei, care să conțină o descriere a proceselor de schimbare în organizarea activităților companiei, precum și să asigure managementul eficient al acestor procese.

Dezvoltarea unui model de arhitectură de afaceri permite întreprinderii să i se asigure un instrument universal care contribuie, în primul rând, la conștientizarea propriei structuri și metode de organizare. Procese de producție. Acest model vă permite să vă formați un plan de promovare a organizației în domeniul afacerilor și tehnologiilor emergente.

O arhitectură bine concepută poate și ar trebui utilizată de conducerea unei întreprinderi pentru a studia principiile funcționării acesteia și, de asemenea, face posibilă dezvoltarea unor strategii noi, mai avansate, organizarea unor noi modalități de planificare a dezvoltării, ținând cont de necesitatea de a îndeplini condiții externe în continuă schimbare (desigur, vorbim de planificare pe termen mediu și lung). O astfel de arhitectură permite un răspuns rapid și flexibilitate, ceea ce se datorează alegerii formelor adecvate de organizare, elaborării speciale a proceselor și utilizării anumitor clase de sisteme informaționale.

În sprijinul acestor teze privind rolul și locul modelării în afaceri, putem cita afirmația analistului Gartner Jim Sinur (Jim Sinur): modeling în ultima vreme”. În general, trebuie remarcat faptul că, conform diverselor evaluări ale experților, majoritatea întreprinderilor vor realiza proiecte care într-un fel sau altul vor afecta diverse aspecte ale problemei îmbunătățirii proceselor de afaceri, în ciuda evaluărilor ambigue ale practicii de reinginiere a proceselor de afaceri ale mijlocul anilor 1990.

Pe lângă inovațiile metodologice și tendințele în dezvoltarea organizării afacerilor și IT, dezvoltarea pieței pentru nevoile de modelare a afacerilor este influențată semnificativ de abordări moderne prin evaluarea nivelului de dezvoltare (maturitate) al organizaţiei. În cadrul acestor abordări, modelul de arhitectură de afaceri este o componentă obligatorie pentru evaluarea organizației.

Ca exemplu de metodologia de evaluare a maturității utilizată în țările dezvoltate organizatii guvernamentale putem cita modelul Administraţiei pentru Controlul Financiar din SUA, care defineşte cinci niveluri de maturitate.

Utilizarea unui model de afaceri în activitățile unei organizații deschide oportunități largi de evaluare calitativă și cantitativă a eficacității acestuia, inclusiv utilizarea metodologiilor și instrumentelor general acceptate (standardizate). De fapt, modelul de afaceri vă permite să asigurați măsurabilitatea caracteristicilor cheie ale organizației prin utilizarea unor metrici adecvate: metrici pentru evaluarea „calității” procesului în sine, metrici pentru evaluarea rezultatelor directe (output), metrici pentru evaluarea rezultatelor finale .

Măsurile la nivel de proces măsoară eficacitatea procesului în sine. Măsurile tipice sunt durata ciclului, costul pe tranzacție sau rezultatul procesului. Măsurile de rezultat evaluează capacitatea proceselor de a produce un produs sau serviciu ca rezultat conform specificațiilor. Valorile tipice pentru evaluarea rezultatelor directe sunt procentul de erori și numărul de solicitări servite pe unitatea de timp. Măsurile de evaluare a rezultatelor evaluează procesul din punctul de vedere al utilizatorului final (client) și performanța funcțiilor organizației.

Este evident că stabilirea sarcinilor pentru modelare pentru o organizație de producție (comercială) poate diferi semnificativ de sarcinile organului de control (de supraveghere) de stat. Din acest motiv, desigur, este necesară o ajustare specifică a fiecăreia dintre metodele de nivel înalt la zona de modelare. Piața răspunde destul de adecvat acestei nevoi. servicii de consultanță. Deci, în prezent există modele practic semnificative pentru diverse sectoare ale economiei și agenții guvernamentale, care sunt implementate pe baza diverselor metodologii și instrumente de modelare, cum ar fi metodologia ARIS și familia de produse software IDS Sheer AG bazate pe aceasta, limbajul de modelare UML și instrumentul de dezvoltare a obiectelor.Sisteme informaționale Rational Rose de la IBM, metodologia IDEF, DFD și AllFusion Modeling Suite (fostă BPwin și ERwin) de la Computer Associates etc.

Fără îndoială, atunci când stabilește sarcini de către o întreprindere în felul ei, certificare internaționalăși intrarea pe piețele dezvoltate țări străine dezvoltarea modelelor de procese de afaceri este deosebit de relevantă. Din acest motiv, inițierea acestor lucrări la întreprindere nu este un „omagiu” noii „mode”. Nu există nicio îndoială că crearea și susținerea ulterioară a modelelor nu numai că va avea un impact pozitiv asupra imaginii generale a organizației, ci va ajuta și la îmbunătățirea managementului general și a culturii de producție a întreprinderii. Într-o oarecare măsură, interesul trezit al organelor puterea statului(OGV) și comunitatea de afaceri la modelarea proceselor de afaceri pot fi comparate cu procesul anterior și utilizat pe scară largă de introducere a metodelor și tehnologiilor de management de proiect.

Trebuie remarcat faptul că OGV-urile Federației Ruse, care sunt responsabile pentru formarea politicii științifice și tehnice în diverse domenii, punerea în aplicare a reformelor administrative, au reacționat destul de „sensibil” la tendințele globale de mai sus și au determinat sarcini țintă pentru a fi luate în considerare. în Federația Rusă.

Starea formalizării și, pe baza acesteia, optimizarea administrativ- procesele de management OGV este definit în documentul „Strategia pentru dezvoltarea și utilizarea tehnologiilor informației și comunicațiilor în Federația Rusă” ca fiind principalii indicatori ai activităților planificate. Tabelul de mai jos reflectă starea actuală, perspectivele și politica de stat privind introducerea modelului de afaceri în activitățile OGV al Federației Ruse (Tabelul 1).

O astfel de atenție sporită a autorităților de stat ale Federației Ruse la problema introducerii unor mecanisme oficializate de descriere a activităților organizațiilor de stat este destul de justificată. În ciuda faptului că, datorită naturii lor specifice, organizațiile de stat au o inerție și selectivitate mai mari (comparativ cu structurile comerciale) în a răspunde la schimbările pieței, actuala „masă acumulată” de nevoi a atins un punct critic.

În prezent, nivelul managerial și executiv al organizațiilor publice se confruntă adesea cu probleme mult mai semnificative decât sectorul comercial. În primul rând, este necesitatea de a folosi fara esecîn activităţile sale normative şi Cadrul legal, care este destul de extins, complex și permite adesea o interpretare ambiguă. Numărul de acte normative și de reglementări de natură federală și departamentală este de sute și mii, numărul de tipuri de documente și date operaționale care sunt supuse prelucrării în unele ministere și departamente ajunge la câteva sute. Adesea, executarea proceselor este organizată în așa fel încât un angajat are un volum de muncă care depășește standardele rezonabile și, în același timp, poartă răspundere administrativă și penală gravă. În aceste condiții, formarea condițiilor pentru munca efectivă și legală a funcționarilor publici este o sarcină extrem de urgentă, iar statul ia măsurile adecvate pentru a o rezolva:

♦ se introduc reglementări administrative electronice;

♦ se formează mecanisme de sprijin de informare și consultanță;

♦ optimizat structura organizationala.

Acest lucru este confirmat de reforma administrativă, inițiativele pentru introducerea pe scară largă a electronicului reglementări administrative, formarea e-guvernării etc. În toate aceste proiecte, formarea și optimizarea modelelor de afaceri este un proces preliminar care determină datele inițiale de bază.

Legat de întrebarea „de ce avem nevoie de un model” este întrebarea „cine are nevoie” de un model. Problema identificării potențialilor consumatori (utilizatori) ai modelului este cheia pentru specificarea și detalierea țintelor. Modelarea proceselor de afaceri poate acoperi diferite aspecte ale întreprinderii: infrastructura principală și formativă a întreprinderii. În consecință, cercul de persoane interesate sub formă de manageri și interpreți va fi determinat de direcția de activitate a organizației aleasă (aleasă) pentru modelare.

La nivelul diviziilor de întreprindere pot acționa ca consumatori interesați ai modelului: aparatul administrativ, diviziile de tehnologie a informației, diviziile de personal, diviziile juridice etc.

În același timp, un public destul de mare de specialiști și manageri poate acționa ca utilizatori ai modelului de arhitectură de afaceri a unei întreprinderi în cadrul departamentelor:

♦ business analytics în diverse domenii ale subiectului (țintă) de activitate a organizației;

♦ dezvoltatori de sisteme informatice si tehnologice;

♦ arhitecți de sistem, care sunt responsabili cu realizarea arhitecturii sistemelor informaționale individuale;

♦ analiști de afaceri care conduc procesul de proiectare a structurii organizaționale;

♦ manageri care sunt interesați de o analiză sistematică, structurată a problemelor și oportunităților care se deschid afacerii etc.

În principiu, inițiativa de a realiza modelarea proceselor de afaceri poate veni de la orice departament al întreprinderii. Depinde de nivelul de conștientizare al șefilor de departament cu privire la posibilitățile și utilitatea modelelor, prioritatea sarcinilor curente de optimizare a activităților, caracterul complet al modelării proceselor individuale de afaceri ale întreprinderii.

În realitate, în majoritatea cazurilor, inițiativa de a dezvolta modele de procese de afaceri vine de la departamentele de tehnologia informației ale organizației. Acest lucru se datorează nevoii de automatizare a anumitor domenii de activitate ale întreprinderilor pe fondul unei activități generale ridicate în implementarea IT în toate domeniile de afaceri și a unei ponderi tot mai mari din bugetele întreprinderii pentru componenta IT.

Cu toată pozitivitatea faptului însuși a activității departamentelor IT (precum și a oricărui alt departament funcțional) în implementarea modelării afacerii, este corect să se păstreze inițiativa și controlul acestui proces pentru conducerea de vârf a organizației. Acest lucru va evita o abordare „departamentală îngustă” pur IT (sau de altă natură) a modelării, care vizează rezolvarea unei anumite sarcini după fapt - automatizarea unui proces separat și oferirea unei soluții pentru o sarcină corporativă - crearea unui instrument pentru evaluarea și optimizarea afacerii procesele în cadrul atingerii țintelor de performanță vizează întreaga organizație.

Sprijin și management general Prin introducerea unui model de arhitectură de afaceri într-o întreprindere, acestea nu exclud sau diminuează rolul unităților funcționale în această lucrare. Cu cât modelul devine „mai larg” și „mai profund”, cu atât este „mai aproape” de utilizator, Mai mult părțile interesate apare în dezvoltarea și sprijinul acestuia.

Ca urmare a modelării activității unei întreprinderi în cadrul abordării procesului, „inevitabil” are loc o afișare treptată (pe măsură ce modelul este detaliat) a rolului, locului, efectului introdus de toate structurile organizatorice și de personal ale întreprinderii. . Din acest motiv, asigurarea unei reflectări adecvate a semnificației unității în modelul general de întreprindere, precum și căutarea ulterioară a unei creșteri a „contribuției” la rezultatele țintă ale întreprinderii, sau a unei „reduceri” a costurilor. al unității, va provoca șefii acestor unități să participe activ la construirea modelului de arhitectură de afaceri.

Într-o anumită măsură, întrebarea „cine are nevoie de un model de afaceri” poate fi comparată cu întrebarea „cine are nevoie de managementul documentelor electronice”. De la un moment dat, fluxul de lucru este folosit de toată lumea, iar fiecare departament ia parte la stabilirea sarcinilor pentru crearea unor reglementări electronice specializate pentru sprijinirea părții „sa” a fluxului de lucru și a protecției „zeloase” a acestora, precum și în ceea ce privește modelarea de afaceri, fiecare departament începe să construiască „partea sa” model de arhitectură de afaceri mari de clădire.

Stabilirea obiectivelor, implementarea, implementarea și scalarea rezultatelor proiectelor de modelare a proceselor de afaceri sunt repere semnificative în schimbarea generală. cultură corporatistăîntreprinderilor. Angajații dobândesc treptat cunoștințe, abilități și experiență în abordarea procesului în desfășurarea activităților lor, se poziționează în mod clar în structura complexă a organizației, stăpânesc în moduri moderne evaluarea rezultatelor muncii lor și găsirea modalităților de optimizare a acesteia.

Crearea unui model de arhitectură de afaceri este un fel de mediu informațional colectiv, tehnologic și organizațional pentru afișarea și implementarea abordării procesuale a unei întreprinderi. Acest mediu, care, pe de o parte, permite fiecărei persoane interesate să „exprime” propuneri calitative și cantitative pentru îmbunătățirea activităților întreprinderii, iar pe de altă parte, tuturor participanților să evalueze în mod obiectiv aspectele „pozitive” și „negative”. a propunerii.

Pe lângă creșterea „conștientizării” participanților la procesele de afaceri a misiunii lor în activitățile întreprinderii, „noua” cultură corporativă asigură documentarea obligatorie și păstrarea istoricului tuturor modificărilor legate de activitatea țintă a întreprinderii. afacere. O astfel de atitudine pedantă și formalizată calitativ față de anii de cunoștințe acumulate în organizație stă la baza utilizării lor eficiente.

Extinderea participanților interesați în construirea modelului și formarea unei noi culturi de management corporativ într-o măsură mai mare este o condiție și/sau o consecință a proiectului de modelare. Etapele practice pentru implementarea proiectului se formează pe baza înțelegerii conținutului sarcinilor țintă pentru modelare.

Sarcinile de modelare decurg din obiectivele formulate de organizație pentru a-și îmbunătăți activitățile. După cum sa menționat mai sus, sarcinile țintă pentru modelarea proceselor de afaceri sunt distribuite în două domenii principale:

1) sistematizare și formalizare - construirea de modele descriptive;

2) construirea de modele analitice și de optimizare.

În cadrul ariilor selectate se poate realiza o diviziune suplimentară de domenii, ținând cont de prezența a două tipuri principale de cercetare, și anume procesele de afaceri în sine și resursele implicate în procesele de afaceri. Pe baza acestui fapt, subsarcini precum:

1) evaluarea (optimizarea) calitativă și cantitativă a proceselor de afaceri implementate;

2) evaluarea (optimizarea) calitativă și cantitativă a utilizării resurselor organizației în cadrul proceselor de afaceri în desfășurare.

În legătură cu procesele de afaceri, sarcinile de modelare pot fi împărțite în tipuri de procese: de bază, de activare, interacțiune externă și dezvoltare (vezi Capitolul 2). În ceea ce privește obiectele de cercetare „non-proces”, pot fi specificate sarcini de modelare pentru procesele de formalizare a scopurilor întreprinderii, structura organizatorică, structura tehnologica, structura informațiilor, arhitectura funcției de afaceri, cadrul de reglementare, indicatori cheie activități etc.

Sistematizarea suplimentară a sarcinilor de modelare poate fi legată de metodele implementate pentru construirea și utilizarea unui model de arhitectură de afaceri de întreprindere. Exemple de astfel de sarcini pot fi: analiza costurilor funcționale, modelarea prin simulare, sistematizarea și formalizarea.

În practică, în funcție de domeniile selectate de stabilire a sarcinilor de modelare a proceselor de afaceri, sunt grupate următoarele: probleme de actualitate la care conducerea organizației ar dori să primească răspunsuri motivate:

♦ Care sunt costurile integrale și costurile de timp necesare pentru implementarea unui anumit proces de afaceri (subproces)?

♦ Ce compoziție a resurselor organizaționale, tehnologice și informaționale, precum și a reglementărilor, este necesară pentru realizarea unui anumit proces de afaceri?

♦ Care este dinamica utilizării resurselor organizaționale, tehnologice și informaționale necesare pentru a finaliza un anumit proces de afaceri?

♦ Ce resurse (organizaționale, tehnologice și informaționale) sau reglementări sunt principalii factori limitativi pentru extinderea capacității organizației de a crește caracteristicile calitative și cantitative ale sarcinilor de afaceri care se rezolvă?

♦ Ce operațiuni ( funcții oficiale) sunt repartizați unei anumite unități oficiale în cadrul implementării activităților țintă ale organizației?

♦ Ce listă de operațiuni ( rutare) ar trebui efectuată de unitatea oficială la apariția unei situații specifice standard sau nestandard legate de implementarea activității țintă a organizației?

♦ Ce îmbunătățiri calitative și cantitative ar trebui așteptate după modernizarea (introducerea de noi) sisteme informaționale, acte juridice, unități organizatorice, tehnologii de producție etc.

Direcțiile de mai sus de stabilire a sarcinilor formează un grup de sarcini numite condiționat pentru proiectarea tehnologică a modelului (sarcini „arhitecturale”). În același timp, în mod obiectiv, există un grup independent de sarcini asociate logicii organizării execuției unui proiect de modelare:

♦ definirea etapelor;

♦ definirea rolurilor în proiect;

♦ formarea si managementul in echipa de proiect etc.

Această listă sarcinile, precum și implementarea sarcinilor „arhitecturale”, vor fi discutate mai detaliat în alte secțiuni ale cărții.

Trebuie remarcat faptul că formularea calitativă a enunțurilor de probleme pentru modelarea proceselor de afaceri în raport cu profilul, starea actuală și prioritatea problemelor organizației este o condiție cheie pentru succesul proiectului. Ar trebui să se înțeleagă clar că nu numai toți cei interesați, ci și persoanele competente ar trebui să participe la stabilirea obiectivelor. La rezolvarea unor astfel de probleme este necesar să se excludă eventualele situații de înlocuire a competenței de afaceri (la nivel juridic, tehnologic, managerial) cu competența IT și invers.

O întrebare destul de firească și justificată după ce am aflat cine are nevoie de un model de arhitectură de afaceri și de ce este să clarificăm parametrii și posibilitatea fundamentală de a rambursa acest gen de proiect de consultanță.

O astfel de afirmație a întrebării, precum și formarea unui răspuns la aceasta, nu este mult diferită de situația în care se dovedește de ce este necesar conceptul de sistem informațional atunci când se inițiază proiecte de informatizare la scară largă ale unei organizații.

Efortul de a construi o arhitectură de afaceri care este prezentată sub formă de modele de afaceri se achită rapid de la sine și are un număr mare de beneficii suplimentare. Beneficiile construirii unui model de arhitectură de afaceri de modele se află în două planuri: caracteristici suplimentare afaceri și reduce costurile. Se estimează că crearea de modele de afaceri și optimizarea costurilor asociate, chiar și fără schimbări radicale în afaceri, pot oferi economii de până la 10%. Și atunci când modelează opțiuni alternative de proces de afaceri, organizațiile pot economisi până la 20%.

1. Descrierea arhitecturală a întreprinderii: cum se face vizibilă organizarea muncii

Arhitectura unei întreprinderi este modul în care este organizată. Cât de organizat (arhitectura) este cine lucrează la ce și cine are nevoie de această muncă. O întreprindere este întotdeauna organizată cumva, bună sau rea. Organizarea (arhitectura) întreprinderii este invizibilă, dar este posibil să se facă o descriere arhitecturală complet vizibilă. Dacă există o descriere arhitecturală, atunci poate fi folosită pentru a discuta despre organizarea întreprinderii de către toate părțile interesate de această organizație (inclusiv persoanele competente în probleme de organizare) - și atunci există șansa ca organizația să poată fi îmbunătățită. Dacă nu există o descriere arhitecturală documentată pe un suport de informații înstrăinat de cap, atunci toată lumea are o descriere (nu întrebați care) într-o formă (nu întrebați care) în propriul cap și chiar și în timpul unei conversații această descriere se poate schimba de trei sau de patru ori într-o singură persoană. Când se discută despre organizarea activității unei întreprinderi, toată lumea are garanția de a avea idei diferite despre acorduri, iar rezultatul muncii la astfel de acorduri este descris în fabula lui Krylov despre o lebădă, cancer și știucă.

O descriere arhitecturală constă dintr-o serie de diagrame pe care oamenii le folosesc pentru a se învârti pentru a înțelege cum funcționează o organizație și apoi să convină asupra a ceea ce trebuie schimbat în organizație. Descrierea arhitecturală este în primul rând un instrument de negociere a persoanelor importante (părți interesate) asupra aspectelor importante ale organizării muncii. Nu confunda regulamentele organizatorice (care contin atat importante cat si putin importante, si in general foarte multe cuvinte) cu o descriere arhitecturala, care contine doar cele mai importante, dar exprimate cat mai formal pentru a evita greselile.

Pentru a descrie arhitectura unei întreprinderi, se folosește un limbaj special, Archimate. Acest limbaj vă permite să notați cel mai important lucru în organizarea întreprinderii - și să ignorați micile detalii.

Să facem imediat o rezervare că în Archimeite este posibil să descriem doar organizarea muncii pentru planctonul de birou. Nu pot fi descrise obiecte de producție materială reală în Archimeite, sunt descrise doar informații despre aceste obiecte. Fără gătit cartofi, fără transferuri de lingouri de la mașină la mașină - numai și exclusiv informații despre toate acestea. Archimate este ideal pentru bănci și companii de asigurări, sedii (din care atelierele reale nu sunt vizibile), birouri de proiectare (unde grinzile grele sunt doar în modele computerizate și tipărite pe hârtie) și chiar sedii de construcții (unde distribuie comenzile și înregistrează ceea ce s-a făcut). , dar ei înșiși nu fac nimic manual). Dar acele părți ale întreprinderii care nu iau în considerare strângerea piulițelor, dar strâng efectiv piulițele ruginite, după ce le-au primit din depozit, nu pot fi descrise de Archimate. Dar pentru a descrie contabilitatea depozitului sau proiectarea și contabilitatea muncii - vă rugăm.

Un arhitect este cineva care vine cu o arhitectură care va satisface toate părțile interesate. El inventează această arhitectură, o descrie sub formă de diagrame Archimate și o coordonează cu diverși oameni importanți. Însuși momentul descrierii arhitecturii pe arhimeit este lipsit de importanță. Cei care pur și simplu scriu în arhimeit (spaniola, swahili) din dictare nu pot fi numiți arhitecți, sunt doar funcționari (scrii). Bine, arhiepiscopi (arhiepiscopi).

Pentru multe persoane numiți arhitecți, se dovedește a fi o surpriză completă faptul că inevitabila trecere de la prezentarea rezultatelor diverselor interviuri despre Arhimete ca o „descriere arhitecturală așa cum este” la scrierea unei „descriere arhitecturală a fi” și imediat următoarea comunicare strânsă cu superiori despre transformarea diagramelor Archimate proaspăt desenate în realitatea organizatorică a întreprinderii. Un arhimat vă va ajuta în afacerea dvs. nu mai mult decât un verificator ortografic Vord în obținerea unui Premiu Nobel pentru literatură.

Ai fost avertizat.

2. Oameni, programe, echipamente

Archimate consideră că cel mai important lucru într-o întreprindere este prezența a trei niveluri de lucru, pe fiecare dintre care principiul uman scade: al oamenilor, programeși echipamente. Oamenii fără software sunt neputincioși, software-ul fără hardware este mort. Echipamentele fără programe care rulează sunt o piesă de fier inutilă, nici programele fără oameni care lucrează nu sunt necesare. Deci, în arhitectura întreprinderii, trebuie prezentate toate cele trei niveluri de performanță a muncii în interconectarea lor.

Fiecare nivel are al lui executanţi de lucrări, si al lor obiecte de lucru muncă. De fapt, munca este că interpreții schimbă cumva obiectele lucrării. Performanții de lucru și obiectele de lucru sunt de obicei reprezentate prin substantive, lucrările prin verbe și substantive verbale. Este important ca obiectele muncii în sine să nu știe să facă nimic, sunt pasive. Dar executorii sunt activi, lucrează pe obiecte și folosesc obiecte.

Nivelul oamenilor este semnificativ. Oamenii din spatele informațiilor văd acele obiecte ale lumii înconjurătoare pe care le înfățișează această informație. Ei se uită la prognoza meteo și văd vremea de mâine (și nu o descriere a vremii), se uită la raportul de construcție și văd numărul de etaje reale (și nu raportul real), se uită la contul de venit și văd același profit . Oamenii au scopuri, puteri (pot da ordine altor oameni să lucreze) și responsabilitate (trebuie să promită că vor îndeplini ordinele altor oameni). Activitatea intenționată există doar la acest nivel.

Nivelul programului este prelucrarea informațiilor conținute în date. Din unele date, programele produc alte date care diferă atât ca format, cât și ca conținut. Nimeni nu promite nimic nimănui (programele nu pot promite, doar oamenii pot) și nu dă instrucțiuni (doar oamenii pot instrui), nu urmărește niciun scop (doar oamenii au obiective). La acest nivel, știm ce înseamnă datele în lumea reală: este periculos să adăugați kilometri la kilograme. Sarcina principală a nivelului de program este de a face ca datele să fie prelucrate în mod corect, la momentul potrivit, către persoanele potrivite.

Nivelul hardware este o lume fără suflet în care nu mai există nicio prelucrare a datelor, ci doar stocarea și transmiterea datelor. Desigur, există și programe la nivel hardware, dar sunt de alt fel - nimeni de aici nu știe ce înseamnă aceste date în lumea reală. Sarcina hardware-ului este de a stoca octeți adresați cumva, fără a intra în sensul lor, de a trimite acești octeți la cererea programelor și, de asemenea, de a stoca programele în sine și de a le permite să fie executate.

3. Elemente și relații
Întreprinderea din Archimeit este descrisă sub forma unor elemente (reprezentate prin figuri diferite) care sunt într-un fel de relație între ele (relațiile sunt descrise ca linii de legătură între figurile elementelor). Archimate este valoros prin faptul că oferă totul pentru a descrie munca unei întreprinderi.
-- 16 tipuri de articole pentru nivel de oameni,
-- 7 tipuri de articole pentru nivel de program,
-- 9 tipuri de articole pentru nivelul de echipament,
-- 11 tipuri de relații în care elementele pot fi unul cu celălalt și arătând furculițe pentru aceste relații.

Dacă aveți de gând să schimbați cumva arhitectura întreprinderii în viata reala(altfel, de ce ai început să desenezi diagrame Archimate?), atunci pentru asta poți folosi și:
-- 7 tipuri de elemente pentru a stabili obiective și a justifica schimbarea organizațională
-- 4 tipuri de elemente pentru a proiecta tranziția la o nouă arhitectură

Există, de asemenea, un comentariu și relația comentariului cu alte elemente, precum și un cadru pentru gruparea elementelor.

Asta e întregul Arhimete. Dar nu vă lăsați păcăliți de simplitatea lui. The Great and Mighty are, de asemenea, doar 33 de litere.

4. Nu avem nevoie de tine, avem nevoie de serviciul tău.

Este important ca nicio lucrare la întreprindere să nu se facă așa, toate sunt necesare de cineva dintr-un motiv oarecare. Serviciile sunt lucrări care sunt utile unor alți interpreți (mai precis, utile pentru munca acestor artiști). Pentru consumatorii de servicii este absolut neimportant modul în care este organizată execuția acestor lucrări: cine lucrează cu ce pentru a expune serviciul pentru consum extern. Pentru ei, este important doar prin ce canale ( E-mail, o fereastră cu o fată, apel telefonic etc.) și interfețele (dacă sunt programe) vor fi furnizate cu aceste servicii.

Există servicii hardware oferite programelor și servicii software oferite oamenilor. Cele trei straturi ale întreprinderii sunt lipite împreună de aceste servicii -- din fiecare strat, doar serviciile celorlalte straturi sunt în mare parte vizibile.

Adică puteți înlocui toate echipamentele, iar programele nu vor observa acest lucru dacă serviciile de echipamente rămân aceleași. La fel este și cu programele: înlocuiți-le pe toate, dar dacă serviciile rămân aceleași, atunci oamenii vor supraviețui. În principiu, acest lucru se aplică și întreprinderii în sine: dacă serviciile oamenilor pe care întreprinderea le furnizează lumii exterioare (și combinația de astfel de servicii și contractul care le conectează se numește produs) vor fi realizate într-un mod foarte diferit de oameni organizați care folosesc programe foarte diferite care rulează pe hardware foarte diferit, atunci clienții nu vor observa acest lucru. Acesta este ceea ce folosesc arhitecții de întreprindere: ei descriu întreprinderea și apoi schimbă încet software-ul și hardware-ul pentru a sprijini furnizarea de servicii critice. Aceasta este ceea ce se numește o abordare orientată spre servicii: împărțiți (diferite niveluri de muncă în serviciu) și cuceriți. Deci tot e cum să arăți: întreprinderea este lipită de servicii, dar pentru arhitect este împărțită de aceste servicii.

Dorința de a împărți și a domni între arhitecți este atât de mare încât aceștia împărtășesc servicii și lucrări chiar și de același nivel. De exemplu, este ușor să ne imaginăm programe care oferă servicii altor programe în loc de oameni. Sau echipament, a cărui rațiune de a fi este de a servi (a furniza servicii, adică „lucra pentru”) alte echipamente.

A furniza extern lucru-serviciu vizibil trebuie făcut mult din exteriorul invizibilului intern munca -- modificări aduse obiectelor de lucru de către executanți. Prezența acestei limite de considerație internă și externă („cutia neagră” cu performanți interni invizibili, locuri de muncă și obiecte versus „cutie transparentă” atunci când sunt perfect vizibile) este prezența unei granițe. sisteme. Modele archimate sisteme, separând părți/niveluri ale întreprinderii pe servicii (deși nu se spune un cuvânt despre „sisteme” în specificația Archimate).

5 oameni

Amintiți-vă punctul trei: pentru a descrie nivelul de organizare a muncii oamenilor, Archimate are tot atâtea tipuri de elemente (17) cât pentru nivelurile de programe și echipamente combinate (7 + 9) - și acest lucru nu este deloc întâmplător.

Oamenii înșiși din arhimeit nu sunt reprezentați de personalitățile lor. În arhimeit, nu o persoană pictează un loc, ci un loc care pictează o persoană. În Archimeite, interpretul este o persoană vie, dar ocupă doar o poziție organizatorică. Prin urmare, Arhimetul numește tocmai aceste locuri „oameni”, care i-ar primi acest moment completat - de o persoană, un întreg grup de oameni de la nivel organizațional (de la un sector și un departament la o sucursală într-un alt stat sau chiar întreaga companie), lucrători temporari, clienți cetățeni aleatori, firme partenere. Arhimatul înțelege că toate aceste locuri organizatorice sunt ocupate de oameni vii, dar îi numește pe acești oameni tocmai după numele locurilor organizatorice. Mântuitorul, șeful adjunct al departamentului de livrare, departamentul de livrare, sucursala din Mytishchi, clientul, auditorul - aceștia sunt „oamenii”, indiferent cine sunt angajații care se întâmplă să ocupe aceste poziții organizatorice. Un arhitect, ca de obicei, îi pasă de etern: dacă un om de mână sau un președinte se îmbolnăvește și o persoană o înlocuiește pe alta pe durata bolii, diagrama va rămâne adevărată: organizarea muncii nu se va schimba.

Oamenii Arhimetului sunt mai diverși decât acei oameni care se regăsesc în „structura organizatorică” (organigrama): în niciun caz toate relațiile dintre oamenii Arhimetului se reduc la șefi-subordonare. Deci, partenerii și clienții nu sunt de obicei menționați în structura organizatorică, dar în Archimeite afișarea lor este un lucru obișnuit.

6. Roluri

Arhitecții sunt atât de insidioși încât lucrează cu părți ale oamenilor, numindu-le „roluri”. rol se cheama acea parte din oamenii alocati in timp, care efectueaza un anumit numar de lucrari care necesita o calificare speciala. Deci, dacă un muncitor în teatru este obligat fie să cânte, fie să danseze, el are două roluri: atunci când cântă, atunci rolul este cântăreț, iar când dansează, rolul este dansator.

oameni numit asupra rolurilor, și a rolurilor numit a munci. De remarcat este faptul că arhitecții organizației sunt angajați în organizarea muncii și nu în conducere (leadership). Atribuirea oamenilor pe roluri și a rolurilor în locuri de muncă este preocuparea arhitectului organizației. Iar preocuparea liderului este a) numirea unor „oameni” vii cu nume de familie, prenume și patronimice, obiceiuri proaste și utile, anumite abilități în locurile „oamenilor” și b) vorbirea oamenilor în locurile „oamenilor” cu un morcov și un băț pentru a face munca care le este încredințată. Deci nu veți vedea nume pe diagramele lui Archimate: doar posturi, roluri, divizii, firme, „persoane responsabile”, „reprezentanți”, organisme colegiale, grupuri și asociații temporare etc.

In viata programare asupra rolurilor și muncii se reflectă de obicei în ordine, ordine, regulamente și alte „documente administrative”. Un astfel de sistem de împărțire a oamenilor este necesar nu numai pentru a arăta versatilitatea ocupațiilor oamenilor (permiteți-mi să vă reamintesc: atât persoane fizice, cât și departamente întregi - atunci când o companie mare de 1000 de angajați acționează atât ca furnizor în raport cu o singură firmă, cât și ca client în raport cu alte firme), dar și pentru ca arhitecții să-și schimbe mai puțin diagramele, iar comenzile care stabilesc organizarea muncii să fie emise mai rar.

Un exemplu tipic: o organizație începe să planteze pătrunjel, dar nu este încă clar cine va planta acest pătrunjel - autoritățile spun: „arătați ce trebuie făcut acolo, iar apoi voi numi un candidat potrivit”. Ei scriu „Regulamentul asupra pătrunjelului”, unde introduc rolul de „șef în pătrunjel” și „senior în pătrunjel” și le prescriu toată munca. Rețineți că Regulamentul nu este încă un ordin și nu este un ordin. Aceasta este o declarație a faptului că unele locuri organizaționale (șef și senior în pătrunjel) trebuie ocupate pentru ca munca (pentru plantarea pătrunjelului) să meargă. Șeful studiază acest proiect de regulament și concluzionează că inginerii și avocații ar trebui să se ocupe de plantarea pătrunjelului. Apoi scrie un ordin în care a) aprobă postul și b) prescrie ca rolul șefului de pătrunjel să fie ocupat de un inginer, iar seniorul de pătrunjel să fie avocat. Iată cum arată:

Conectorii punctați sunt „relația de destinație” dintre elemente. Există, desigur, relații între oameni și lucrări în mod direct (dacă omiteți mențiunea rolului). O astfel de relație se va numi derivată, dar încă există - putem spune că în acest caz inginerului este desemnat să asigure răsaduri, iar avocatul trebuie să se ocupe de plantare.

Vă rugăm să rețineți că acest design va funcționa chiar și atunci când inginerul Ivanov se va pensiona, iar Sidorov este angajat pentru a-l înlocui. În acest design, este ușor să schimbați inginer pentru un agronom sau pentru Direcția de pătrunjel (când activitatea crește) - acest mecanism destinaţie Roluri pentru a lucra (de exemplu, prin Regulamente), și oameni pentru roluri (de exemplu, prin ordin) funcționează și în cazul în care „oameni” este o mulțime întreagă de oameni etc. Este vorba de organizare. Toate aceste Regulamente și Ordine de obicei nu sunt marcate pe diagramă: ele convin asupra diagramelor cum va fi organizată munca și nu cu ce documente vor fi întocmite aceste acorduri.

Sugestie: Cunosc mai multe organizații în care albumele cu descrierile arhitecturale ale întreprinderii au fost aprobate de director în loc de un teanc gros de regulamente. Căci diagramele arhitecturale s-au dovedit a fi mai precise și mai expresive decât numeroasele descrieri textuale pe care au încercat apoi să le întocmească din ele.

Este clar că cei mai vioi Ivanov și Sidorov (sau angajații care sunt enumerați în Direcția de pătrunjel) lucrează în cele din urmă la plantarea pătrunjelului. Dar își vor petrece doar o parte din timpul și talentele lor în întreprindere (și doar această parte a timpului este reflectată de elementul „oameni” din arhitectura întreprinderii), iar restul timpului vor dormi, vor mânca, plimbați, studiați și distrați-vă. Ei vor petrece doar o fracțiune din timpul pe care îl petrec întreprinderii pentru rolul lor în munca de plantare a pătrunjelului - pentru că cu siguranță au multe roluri diferite, fac multe locuri de muncă diferite. Da, și un anumit număr de oameni poate fi atribuit aceluiași rol - persoane individuale sau chiar mai multe departamente.

Atât oamenii, cât și rolurile pot fi împărțite în orice număr de părți dacă doriți să arătați câteva detalii despre angajarea persoanelor care performează.

Pentru a efectua o anumită muncă, diferiți oameni se pot uni pentru o perioadă (acest lucru nu se reflectă de obicei în structura organizațională), iar o astfel de asociere temporară se numește rol colegial.

7. Lucrările oamenilor

Joburile oamenilor sunt:

• sa întâmplat deja - evoluții. Evenimentele sunt de obicei numite prin verbul formei perfecte a timpului trecut: „pătrunjel este plantat”. Aceste lucrări pot fi efectuate neintenționat („a apărut o eroare”), de către persoane din afara întreprinderii (clienți, concurenți, parteneri), iar în general această muncă nu ar fi putut fi efectuată de oameni (dar, de exemplu, programe, echipamente, sau chiar forțe ale naturii - - „Apus de soare”).
• menită să obțină un rezultat și executată într-un interval de timp (adesea - unul după altul) - proceselor. Ele sunt numite verb într-o formă nedefinită - „sapă”, „plantează”, „dezvolta”. Procesele sunt de obicei alerga eveniment, și lansa evenimente și, de asemenea, se declanșează reciproc, formând un lanț de la evenimentul inițial la evenimentul rezultat.
• obtinut ca urmare a muncii unei echipe temporare unite printr-un rol colegial -- procesele colegiale. Ele sunt numite și verbul în formă nedefinită.
• selectat pentru altceva decât o bază de timp pentru a produce un rezultat (de exemplu, solicitarea unor roluri cu anumite calificări care să le fie atribuite sau consumarea unui anumit tip de resursă) -- practici. Practicile nu sunt atât de mult efectuate de la sine, ci în momente diferite, se realizează anumite procese combinate de ele (sau fragmente de procese la care materia nu a ajuns pe diagramă, așa că au fost înfățișate fără o măturare în timp, sufoca, „în o pungă" - care este indicată "ceea ce se practică" mai degrabă decât să se facă la un moment dat). Prin urmare, practicile sunt notate nu prin verbe, ci prin substantive verbale: „a planta pătrunjel” este tocmai o practică.


• lucrări date cuiva din afară, cât de semnificative sunt și văzute din exterior -- Servicii. Servicii implementate munca internă efectuată de roluri interne și folositîn cursul muncii externe efectuate de roluri externe. În principiu, orice muncă a oamenilor este efectuată numai pentru a implementează un fel de serviciu - adică pentru ca altcineva (de exemplu, un client sau subcontractanți) să poată folosi aceste lucrări.

Arhitectura unei întreprinderi este modul în care este organizată. Cât de organizat (arhitectura) este cine lucrează la ce (cine lucrează pentru ce) responsabil), și cine are nevoie de această muncă. O întreprindere este întotdeauna organizată cumva, bună sau rea. Organizarea (arhitectura) unei întreprinderi este invizibilă (este un „obiect logic”), dar se poate face o descriere arhitecturală complet vizibilă. Dacă există o descriere arhitecturală, atunci poate fi folosită pentru a discuta despre organizarea întreprinderii de către toate părțile interesate de această organizație (inclusiv persoanele competente în probleme de organizare) - și atunci există șansa ca organizația să poată fi îmbunătățită. Dacă nu există o descriere arhitecturală documentată pe un suport de informații înstrăinat de cap, atunci toată lumea are o descriere (nu întrebați care) într-o formă (nu întrebați care) în propriul cap și chiar și în timpul unei conversații această descriere se poate schimba de trei sau de patru ori într-o singură persoană. Când se discută despre organizarea activității unei întreprinderi, toată lumea are garanția de a avea idei diferite despre acorduri, iar rezultatul muncii la astfel de acorduri este descris în fabula lui Krylov despre o lebădă, cancer și știucă. Chiar dacă au căzut de acord asupra unei „structuri organizaționale” (singurul lucru care este de obicei documentat în astfel de conversații), aceasta este doar o mică parte din ceea ce ar fi corect să fie de acord.

O descriere arhitecturală constă dintr-o serie de diagrame pe care oamenii le folosesc pentru a se învârti pentru a înțelege cum funcționează o organizație și apoi să convină asupra a ceea ce trebuie schimbat în organizație. O descriere arhitecturală este în primul rând un instrument de negociere cu oameni importanți (părți interesate -- părțile interesate) despre aspectele importante ale organizării muncii care afectează interese acești factori interesați. Nu confundați reglementările organizaționale (care conțin atât importante, cât și puțin importante, și în general multe cuvinte) cu o descriere arhitecturală care conține doar cele mai importante lucruri (că dacă schimbați, atunci va trebui să schimbați o mulțime de alte lucruri ), dar exprimate cât mai formal posibil pentru a evita erorile.

Pentru a descrie arhitectura unei întreprinderi, se folosește un limbaj special, Archimate. Acest limbaj vă permite să notați cel mai important lucru în organizarea întreprinderii - și să ignorați micile detalii.

Să facem imediat o rezervare că în Archimeite este posibil să descriem doar organizarea muncii pentru planctonul de birou. Nu pot fi descrise obiecte de producție materială reală în Archimeite, sunt descrise doar informații despre aceste obiecte. Fără gătit cartofi, fără transferuri de lingouri de la mașină la mașină - numai și exclusiv informații despre toate acestea. Archimate este ideal pentru bănci și companii de asigurări, sedii (din care atelierele reale nu sunt vizibile), birouri de proiectare (unde grinzile grele sunt doar în modele computerizate și tipărite pe hârtie) și chiar sedii de construcții (unde distribuie comenzile și înregistrează ceea ce s-a făcut). , dar ei înșiși nu fac nimic manual). Dar acele părți ale întreprinderii care nu iau în considerare strângerea piulițelor, dar strâng efectiv piulițele ruginite, după ce le-au primit din depozit, nu pot fi descrise de Archimate. Dar pentru a descrie contabilitatea depozitului sau proiectarea și contabilitatea muncii - vă rugăm.

Un arhitect este cel care vine cu o arhitectură care își atinge obiectivele, care va satisface toate părțile interesate, toate părțile interesate. El inventează această arhitectură, o descrie sub formă de diagrame Archimate și o coordonează cu diverși oameni importanți. Însuși momentul descrierii arhitecturii pe arhimeit este lipsit de importanță. Cei care pur și simplu scriu în arhimeit (spaniola, swahili) din dictare nu pot fi numiți arhitecți, sunt doar funcționari (scrii). Bine, arhiepiscopi (arhiepiscopi). Arhitecții sunt cei care vin cu ce să scrie despre organizație, și nu cum să o exprime în arhimeit cu icoane viclene.

Pentru multe persoane desemnate ca arhitecți (în special pentru cei care au venit „de la programatori” sau „de la administratori de sistem”), se dovedește a fi o surpriză totală faptul că inevitabila trecere de la prezentarea rezultatelor diverselor interviuri pe Archimate ca o „descriere arhitecturală”. așa cum este” la scrierea unei „descriere arhitecturală a fi” și imediat următoarea comunicare strânsă cu autoritățile privind transformarea diagramelor Archimate proaspăt desenate în realitatea organizatorică a întreprinderii. Archimate vă va ajuta în afacerea dvs. nu mai mult decât un verificator ortografic și capacitatea de a gestiona stilurile Cuvântului în obținerea Premiului Nobel pentru Literatură.

Ai fost avertizat.

2. Activitate, „software”, „hardware”

Archimate consideră că cel mai important lucru într-o întreprindere este prezența a trei niveluri de lucru, pe fiecare dintre care principiul uman scade: Activități, "moale"și "glandă". Activitatea fără „software” este arhaică și neputincioasă, „software” fără „hardware” este moartă. „Fierul” fără munca de programe este fier inutil și nimeni nu are nevoie de programe fără utilizarea lor în activitățile oamenilor. Deci, în arhitectura întreprinderii, trebuie prezentate toate cele trei niveluri de performanță a muncii în interconectarea lor.

Fiecare nivel are al lui executanţi de lucrări, si al lor obiecte lucrări. De fapt, munca este că interpreții schimbă cumva obiectele lucrării. Performanții de lucru și obiectele de lucru sunt de obicei reprezentate prin substantive, lucrările prin verbe și substantive verbale. Este important ca obiectele muncii în sine să nu știe să facă nimic, sunt pasive. Dar executorii sunt activi, lucrează la obiecte. „Cineva” (factor de muncă) face ceva (muncă) cu ceva (obiect de muncă).

Nivelul de activitate este semnificativ. Oamenii din spatele informațiilor văd acele obiecte ale lumii înconjurătoare pe care le înfățișează această informație. Uitați-vă la prognoza meteo și vedeți vremea de mâine (nu descrierea vremii la care se uită), uitați-vă la raportul de construcție și vedeți numărul de etaje efective (nu raportul real la care se uită), uitați-vă la declarația de venit și văd același profit (nefiind atenți dacă acest raport este pe ecran sau pe hârtie). Oamenii au interese și scopuri, pot fi responsabili (trebuie să promită că vor îndeplini unele comenzi ale altor persoane), au puteri (pot da ordine unor alte persoane pentru a îndeplini munca). Activitatea intenționată care satisface interesele și scopurile unor persoane-părți interesate există doar la acest nivel.

Nivelul „soft” este prelucrarea informațiilor conținute în date. Din unele date, programele produc alte date care diferă atât ca format, cât și ca conținut. Nimeni nu promite nimic nimănui (programele nu pot promite, doar oamenii din activitățile lor pot face acest lucru) și nu dă instrucțiuni (doar oamenii pot instrui). La acest nivel, știm ce înseamnă datele în lumea reală: este periculos să adăugați kilometri la kilograme. Sarcina principală a nivelului de program este să se asigure că datele prelucrate în mod corect sunt la momentul potrivit cu responsabilii potriviți, care îndeplinesc un anumit rol în întreprindere.

Nivelul hardware este o lume fără suflet în care nu mai există nicio prelucrare a datelor, ci doar stocarea și transmiterea datelor. Desigur, există și programe (software de sistem) la nivel hardware, dar sunt de alt fel - nimeni de aici nu știe ce înseamnă aceste date în lumea reală. Sarcina hardware-ului, ca orice echipament, este de a stoca octeți adresați cumva, fără a intra în sensul lor, de a trimite acești octeți la cererea programelor de aplicație și, de asemenea, de a stoca programele în sine și de a le permite să fie executate.

3. Elemente și relații
O întreprindere din Arhimete este descrisă ca elemente (reprezentate prin icoane diferite) care sunt într-un fel de relație între ele (relații diferite sunt descrise ca linii de legătură trasate în moduri diferite între icoanele elementelor). Archimate este valoros prin faptul că oferă totul pentru a descrie munca unei întreprinderi.
-- 16 tipuri de articole pentru nivelul de activitate,
-- 7 tipuri de articole pentru nivel de program,
-- 9 tipuri de articole pentru nivelul de echipament,
-- 11 tipuri de relații în care elementele pot fi unul cu celălalt și care arată furculițe (cum ar fi „și” și „sau”) pentru aceste relații.

Dacă aveți de gând să schimbați cumva întreprinderea în viața reală (altfel, de ce ați început să desenați diagrame Archimate care reflectă arhitectura acesteia?), atunci pentru aceasta puteți utiliza și:
-- 7 tipuri de elemente pentru a stabili obiective și a justifica schimbarea organizațională
-- 4 tipuri de elemente pentru a proiecta tranziția la o nouă arhitectură

Există, de asemenea, un comentariu și relația comentariului cu alte elemente, precum și un cadru pentru gruparea elementelor.

Acesta este întregul Archimate, 54 de concepte. Dar nu vă lăsați păcăliți de simplitatea lui. The Great and Mighty are, de asemenea, doar 33 de litere.

4. Nu avem nevoie de tine, avem nevoie de serviciul tău.

Este important ca nicio lucrare la întreprindere să nu se facă așa, toate sunt necesare de cineva dintr-un motiv oarecare. Serviciile sunt lucrări care sunt utile unor alți interpreți (mai precis, utile pentru munca acestor interpreți), vizibile „în afara” unei părți a întreprinderii. Pentru consumatorii de servicii este absolut neimportant modul în care este organizată execuția acestor lucrări: cine lucrează cu ce pentru a expune serviciul pentru consum extern. Pentru ei este important doar prin ce canale (e-mail, o fereastră cu o fată, un apel telefonic etc.) s-au desfășurat aceste activități) și interfețe (dacă este „software”) vor fi furnizate aceste servicii.

Există servicii hardware furnizate software-ului și servicii software furnizate activităților. Cele trei straturi ale întreprinderii sunt lipite împreună de aceste servicii -- din fiecare strat, doar serviciile celorlalte straturi sunt în mare parte vizibile. Pur și simplu nu puteți afișa nimic altceva decât serviciul: serviciile sunt cele care vă permit să faceți abstracție de la detaliile dispozitivului întreprinderii, serviciile sunt cele care implementează o abordare sistematică și împart întregul sistem în părți. Arhitecturile moderne sunt orientate spre servicii.

Aceste părți ale sistemului sunt atât funcționale (scopul serviciului este de a îndeplini o anumită funcție în raport cu sistemul care îl folosește, serviciile sunt așa cum arată lucrarea „în afara” subsistemului) și modulare (adică interschimbabile dacă funcția se păstrează). Deci, puteți înlocui tot „hardware-ul”, iar „software-ul” nu va observa acest lucru dacă serviciile „hardware” rămân aceleași. La fel este și cu „software”: înlocuiți-l cel puțin pe toate, dar dacă serviciile software rămân aceleași, atunci activitatea nu va observa acest lucru - toate aceleași funcții software vor fi disponibile în activitate. În principiu, acest lucru se aplică și întreprinderii în sine: dacă serviciile organizației pe care întreprinderea le furnizează lumii exterioare (și combinația dintre astfel de servicii organizaționale și acordul de nivel de serviciu care le conectează se numește produs orgservice) va fi realizată de o activitate organizată complet diferită care utilizează un „software” complet diferit, care la rândul său rulează pe un „hardware” complet diferit, clienții nu vor observa acest lucru. Acesta este ceea ce folosesc arhitecții de întreprindere: ei descriu întreprinderea și apoi schimbă încet activitatea, software-ul și hardware-ul, susținând furnizarea de servicii critice. Aceasta este ceea ce se numește o abordare orientată spre servicii: împărțiți (diferite niveluri de muncă în serviciu) și cuceriți. Companie lipite servicii, dar pentru arhitect sunt aceste servicii împărțit.

Dorința de a împărți și a domni între arhitecți este atât de mare încât aceștia împărtășesc servicii și lucrări chiar și de același nivel. De exemplu, este ușor să ne imaginăm programe care oferă servicii altor programe în loc de oameni. Sau „fier”, sensul existenței căruia este de a servi (a oferi un serviciu, adică „a lucra pentru”) alte echipamente.

A furniza extern lucru-serviciu vizibil trebuie făcut mult din exteriorul invizibilului intern munca -- modificări aduse obiectelor de lucru de către executanți. Prezența acestei limite de considerație internă și externă („cutia neagră” cu performanți interni invizibili, locuri de muncă și obiecte versus „cutie transparentă” atunci când sunt perfect vizibile) este prezența unei granițe. sisteme. Modele archimate sisteme, separând părțile/nivelurile întreprinderii pe servicii (deși nu se spune în mod explicit un cuvânt despre „sisteme” în specificația Archimate, ci doar indicii).

Aspecte teoretice arhitectura intreprinderii. Elemente cheie ale arhitecturii întreprinderii. Arhitectura unei întreprinderi este reprezentarea cea mai generală și cuprinzătoare a unei întreprinderi ca entitate economică care are obiective pe termen scurt și lung pentru desfășurarea activității sale de bază, determinate de misiunea pe piața regională și globală și strategia de dezvoltare, externă. si resursele interne necesare indeplinirii misiunii si atingerii obiectivelor stabilite, precum si regulilor stabilite pentru desfasurarea business-ului de baza. Teoretic...

Dacă această lucrare nu vă convine, există o listă de lucrări similare în partea de jos a paginii. De asemenea, puteți utiliza butonul de căutare

Introducere

1.3. Straturi în arhitectură

Bibliografie

Introducere

Recent, mediul extern s-a schimbat foarte rapid, astfel încât cerințele pentru adaptabilitatea întreprinderilor cresc de la an la an. Diverse studii analitice au arătat că majoritatea companiilor internaționale nu au timp să se adapteze la schimbările în curs, în timp ce tendința în acest domeniu este negativă. Principala problemă în asigurarea adaptabilității întreprinderilor este coordonarea și controlul schimbărilor care trebuie făcute în cadrul acesteia. Când obiectivele se schimbă, strategia se schimbă, ceea ce, la rândul său, duce la o schimbare a proceselor de afaceri și a priorităților proiectului, precum și a structurii organizaționale. Toate acestea afectează indirect nivelul de cunoștințe și autoritate în întreprindere și, ca urmare, fluxurile de informații, care la rândul lor vor necesita schimbări în sistemele informaționale existente.

Arhitectura unei întreprinderi este reprezentarea cea mai generală și cuprinzătoare a unei întreprinderi ca entitate economică care are obiective pe termen scurt și lung pentru a-și desfășura activitatea de bază, definite printr-o misiune pe piața regională și globală și o strategie de dezvoltare. , resursele externe si interne necesare indeplinirii misiunii si atingerii scopurilor stabilite. , precum si regulile stabilite pentru desfasurarea activitatii principale - afaceri.

1. Aspecte teoretice ale arhitecturii întreprinderii

1.1. Elemente cheie ale arhitecturii întreprinderii

Enterprise Architecture Management oferă un cadru pentru sincronizarea obiectelor dintr-o întreprindere, asigurând în același timp că acestea sunt modificate în mod continuu în scopuri de optimizare a afacerii.

Controlul schimbărilor și consistența tuturor elementelor arhitecturii contribuie la creșterea adaptabilității întreprinderii, care este în prezent un factor important în competiție. În același timp, sistemele informaționale pot deveni adesea un factor de descurajare la schimbare, ceea ce înseamnă că trebuie acordată o atenție deosebită sincronizării elementelor arhitecturii de afaceri și arhitecturii IT. Pentru gestionarea arhitecturii întreprinderii se folosește un ciclu standard, constând din următorii pași: descrierea arhitecturii existente, proiectarea stării sale țintă, formarea unui plan de tranziție de la arhitectura existentă la arhitectura țintă. La primul pas, este necesar să se determine ce elemente ale arhitecturii și în ce măsură ar trebui descrise.

Pe de o parte, detaliul descrierii create înseamnă un studiu mai profund, iar pe de altă parte, apar costuri inutile cu forța de muncă, atât pentru realizarea descrierii în sine, cât și pentru menținerea ei la zi. După cum se spune, „cel mai bun este dușmanul binelui”, și, prin urmare, descrierea prea detaliată a elementelor arhitecturii nu este de ajutor. În această etapă, este important să se stabilească elementele cheie ale arhitecturii întreprinderii a tuturor posibilelor și să se concentreze pe descrierea și analiza lor.

Practica arată că prima nepotrivire în arhitectura întreprinderii, de regulă, are loc între obiective, procese de afaceri și structura organizațională. În multe cazuri, mai multe ținte nu sunt acceptate resursele necesareși procesele de afaceri. Prin urmare, deja în procesul de analiză a arhitecturii, este posibil să se determine un plan de lucru pentru optimizarea activităților întreprinderii în acest domeniu. Dacă analizăm tehnologiile informaționale ale unei întreprinderi, atunci ele sunt, de asemenea, adesea incompatibile cu cele existente și cu atât mai mult cu procesele de afaceri vizate. Și aici există un domeniu vast pentru optimizarea activităților.

Pe lângă inconsecvența dintre elementele cheie ale arhitecturii întreprinderii, problemele apar adesea în cadrul unui singur element, în primul rând dublarea, precum și lacune organizaționale și informaționale etc. Cu toate acestea, nu numai numărul de modificări și cerințele pentru agilitatea întreprinderii au determinat o atenție atât de serioasă asupra problemelor de management al arhitecturii. Complexitatea sistemelor tehnologice este în creștere, ceea ce înseamnă o scădere a fiabilității acestora. În acest caz, formalizarea arhitecturii devine baza pentru asigurarea procedurilor de management al riscului operațional la întreprindere, deoarece dacă elementele sale principale sunt formalizate, atunci nu mai este dificilă identificarea riscurilor și analizarea eficacității procedurilor de control. Prin urmare, cel mai critic management al arhitecturii din companii mari care utilizează tehnologii complexe care sunt asociate cu multe riscuri operaționale și tehnologice.

În ciuda varietății metodologiilor din domeniul managementului arhitecturii, în practică, majoritatea întreprinderilor se limitează la următoarele elemente ale acesteia: obiectivele de afaceri; structura organizationala; indicatori de performanta; procese de afaceri; portofoliu de proiecte; documentele; Sisteme de informare; cunoștințele personalului. Acesta este minimul necesar care vă permite să coordonați elementele principale ale arhitecturii între ele. Cu toate acestea, dacă obiectivele, indicatorii, structura organizațională și procesele de afaceri sunt adesea deja într-un fel interconectate, atunci între procese și sisteme de informare adesea nu există o astfel de relație. În acest sens, una dintre prioritățile multor întreprinderi este trecerea de la modelele și reglementările de arhitectură de afaceri la definirea cerințelor de tehnologie a informației și construirea unei arhitecturi IT adecvate.

Decalajul de informații este cauzat de transferul de informații de la analiștii de afaceri către specialiștii IT, iar în acest moment formalizarea unor astfel de elemente ale arhitecturii precum cerințe, funcții IT, tranzacții, structura datelor împreună cu procesele de afaceri permite reducerea acestui decalaj. În această etapă, este important să folosiți corect recomandările conținute în metodologiile de descriere a arhitecturii întreprinderii, cum ar fi TOGAF.

Astfel, pentru a elimina „decalajul informațional”, este necesară extinderea descrierii arhitecturii existente a întreprinderii și, în special, a arhitecturii de afaceri în direcția arhitecturii IT, ținând cont de unitatea metodologiei de descriere utilizate pentru atât analiștii de afaceri cât și specialiștii IT. În această tranziție de la descrierea arhitecturii procesului de afaceri la descrierea arhitecturii IT, este importantă formalizarea mai multor elemente suplimentare ale arhitecturii. În primul rând, este necesar să se descrie arhitectura de date, care este construită pe baza informațiilor și documentelor care sunt utilizate în procesele de afaceri, după care ar trebui să se formeze arhitectura aplicației și infrastructura IT.

Pentru a construi o arhitectură de date, este necesară identificarea principalelor entități și agregarea pe acestea a tuturor „cantelor” de informații colectate din descrierea proceselor de afaceri. Practica arată că, pentru a rezolva această problemă, ar trebui să se folosească metodologia standard de descriere a datelor - Modelul Entitate-Relație (ERM), în cadrul căruia toate informațiile pot fi structurate clar. Următoarea etapă în formalizarea arhitecturii IT este trecerea de la arhitectura proceselor de afaceri și arhitectura de date la crearea unei arhitecturi de aplicații. În această etapă, este important să se definească clasele de sisteme informatice necesare automatizării, precum și modulele pentru fiecare sistem informatic. Baza pentru proiectarea arhitecturii aplicației și sincronizarea acesteia cu arhitectura de afaceri este harta proceselor (o reprezentare generalizată a tuturor proceselor de afaceri dintr-o întreprindere). Principalele tipuri de sisteme informaționale sunt situate pe modelul arhitecturii aplicației, care sunt detaliate în continuare pe modelul modulelor sistemului informațional și mai departe la nivelul formularelor individuale de ecran - tranzacții.

Un alt element cheie al arhitecturii în ceea ce privește relația dintre arhitectura de afaceri și arhitectura IT este cerințele sistemului informațional. De fapt, modelele de cerințe sunt funcționalitatea țintă a unei soluții IT, care este structurată pe procese de afaceri sau pe departamente. Pe baza acestor cerințe și modelelor de procese de afaceri existente, precum și luând în considerare modelele de date construite, este proiectată o nouă arhitectură de aplicație (țintă). În același timp, pe lângă metodologiile de management al arhitecturii întreprinderii, standardele din industrie trebuie să fie și ele utilizate pentru rezolvarea sarcinilor. De exemplu, în cazul companiilor de telecomunicații, pot fi folosite ca bază materiale din metodologia New Generation Operation System and Software (NGOSS), care a fost creată în 2001 de TeleManagement Forum și conține următoarele modele:

1. modelul operațiunilor companiei de telecomunicații eTOM (Enhanced Telecom Operations Map - eTOM);
2. model informativ telecomunicatiiîntreprinderilor (Cadru de informații la nivel de întreprindere, model de informații și date partajate - SID);
3. cadrul de aplicații al companiei de telecomunicații ( Cadrul de aplicații - Harta aplicațiilor de telecomunicații - TAM).

1.2. Modele și instrumente de arhitectură a aplicațiilor

Arhitectura aplicației acoperă o zonă destul de largă, care începe cu identificarea sistemelor de aplicații de care o întreprindere are nevoie pentru a efectua procese de afaceri și include aspecte precum proiectarea, dezvoltarea (sau achiziția) și integrarea sistemului de aplicații. De regulă, în arhitectura aplicațiilor se disting două domenii principale: formarea și gestionarea unui portofoliu de sisteme de aplicații pentru întreprinderi și dezvoltarea sistemelor de aplicații.

Un portofoliu de aplicații pentru întreprinderi este un plan general al modului în care nevoile proceselor de afaceri ale unei întreprinderi sunt îndeplinite de un set de sisteme de aplicații. Acesta definește domeniul de aplicare și prioritatea fiecărei aplicații, precum și modul în care va fi atinsă funcționalitatea necesară: prin dezvoltarea sistemului, prin achiziționarea de aplicații gata făcute, închirierea aplicației sau integrarea și utilizarea capabilităților existente. aplicatii. Portofoliul de sisteme de aplicații descrie aplicații concepute pentru a îndeplini funcțiile unei organizații și pentru a face schimb de informații între clienții, furnizorii și partenerii unei întreprinderi. Totodată, sunt descrise și canalele de posibilă interacțiune a utilizatorului cu aplicațiile: browsere web, o interfață grafică a unui client „gros”, dispozitive mobile etc.

Domeniul dezvoltării sistemelor aplicate descrie acele tehnologii care sunt folosite pentru a construi sisteme, a le împărți în componente funcționale, a crea interfețe, setări, precum și șabloane, manuale etc. utilizate pentru aceasta. Această zonă definește și organizarea procesului de dezvoltare, instrumentele utilizate pentru aceasta, ciclul de dezvoltare a sistemului adoptat de întreprindere, controlul versiunilor, managementul configurației, middleware-ul utilizat, instrumentele de proiectare. Sarcina principală a zonei este de a reduce costul creării sistemelor aplicate și de a îmbunătăți calitatea acestora prin furnizarea de abordări unificate ale dezvoltării. Aceasta, la rândul său, duce la o reducere a numărului total de diferite scenarii tehnice asociate cu proiectarea arhitecturii, suportul operațional, arhitectura de integrare a sistemului și formarea personalului. Aici este necesară implicarea arhitecților de sisteme de aplicații. Desigur, această zonă are sens să fie alocată doar pentru acele organizații în care se realizează dezvoltarea independentă sau rafinarea aplicațiilor, spre deosebire de modelul de outsourcing. Pe baza acestor comentarii și a separării a două domenii în arhitectura aplicației - portofoliul și dezvoltarea sistemului de aplicații - se poate spune că introducerea unui sistem nou în întreprindere, de exemplu, facturarea, face parte din managementul portofoliului de aplicații al întreprinderii. . În același timp, tehnologiile și principiile care sunt utilizate în proiectarea sistemului, precum și implementarea și întreținerea acestuia, aparțin zonei de dezvoltare. În viitor, vom vorbi despre arhitectura aplicațiilor, ținând cont, în primul rând, de portofoliul de sisteme de aplicații. În mod ideal, un portofoliu de aplicații pentru întreprinderi ar trebui să includă setul actual de aplicații și un model pentru a înțelege ce aplicații vor fi necesare în viitor pentru a satisface noile nevoi de afaceri și organizații. Portofoliul de aplicații ar trebui să definească, de asemenea, relațiile dintre componentele funcționale și tehnologice (operaționale) ale mediului de tehnologie a informației întreprinderii, de ex. explicați de ce anumite tehnologii au fost încorporate în infrastructura pentru construirea unui portofoliu de sisteme de aplicații pentru întreprinderi. Acest aspect este important deoarece investițiile în infrastructură reprezintă o parte semnificativă a cheltuielilor de capital și trebuie să fie bine justificate. În cele din urmă, portofoliul de aplicații ar trebui să ofere o idee despre cât va costa în ceea ce privește costurile financiare și cât va dura organizației să migreze la starea viitoare dorită folosind aceste sisteme de aplicații. Astfel, portofoliul de sisteme aplicate este un set integrat de SI pentru intreprindere care raspunde nevoilor afacerii si include urmatoarele aspecte:

1. Portofoliul existent de sisteme aplicate. Este un catalog de aplicații existente și o componentă care reflectă relațiile acestora cu procesele de afaceri pe care le suportă, interfețele cu alte sisteme, informațiile utilizate și necesare și modelele de infrastructură utilizate. Pentru a fi real unealtă folositoare, ar trebui, de asemenea, să ajute la identificarea acelor elemente ale portofoliului care pot fi reutilizate și reutilizate în cadrul întreprinderii și să încurajeze o astfel de reutilizare.
2. Portofoliu planificat de sisteme aplicate. Reprezintă funcționalitatea necesară pentru a oferi starea dorită a arhitecturii informaționale de afaceri și întreprinderi.
3. Plan de migrare. Procesul de trecere de la portofoliul actual la viitorul de sisteme de aplicații în cadrul proiectelor IT. Proiectele pot fi, de asemenea, combinate în portofolii de proiecte. Primul pas în planificarea unui portofoliu de sisteme de aplicații este de a evalua starea actuală a portofoliului și modul în care acesta se potrivește nevoilor organizației din punct de vedere strategic și tehnologic, de exemplu. din punct de vedere al sarcinilor, strategiilor de afaceri și din punct de vedere al stării tehnice și al strategiilor de utilizare a tehnologiilor în întreprindere. Conformitatea cu strategiile de afaceri este evaluată pe baza contribuției sistemelor de aplicații la obținerea rezultatelor afacerii, care este determinată de arhitectura de afaceri a întreprinderii. Conformitatea tehnologică este evaluată pe baza unei analize a modului în care sistemele de aplicații respectă principiile și standardele tehnologice adoptate în arhitectura tehnologică a întreprinderii. Există diferite moduri de a evalua un portofoliu și diferite clasificări ale sistemelor de aplicații ale întreprinderii. Unul dintre modele posibile Evaluarea portofoliului de sisteme aplicate este de a le evalua în funcție de două criterii - valoarea din punct de vedere al afacerii și starea tehnică. Evaluarea portofoliului servește ca punct de plecare în identificarea zonelor cu probleme și a oportunităților de a răspunde mai bine nevoilor de afaceri și de a decide dacă să investească în sisteme noi sau să le actualizeze pe cele existente. Ca rezultat al acestei evaluări, sistemele de aplicații se încadrează în una dintre cele patru categorii posibile:
   1. sistemele sunt amenințate cu dezafectarea (înlocuirea) sau consolidarea;
   2. sisteme care necesită reevaluare sau repoziționare;
   3. sisteme care necesită actualizare;
   4. sisteme care necesită întreținere și dezvoltare.

Starea tehnică este evaluată pe o serie de caracteristici, inclusiv acuratețea și corectitudinea datelor, arhitectura, structura codului, capacitatea de răspuns, timpul de nefuncționare, nivelul de întreținere, capacitatea de raportare etc. Valoarea unui sistem din punct de vedere al afacerii se referă la capacitatea sistemului de a îndeplini funcțiile esențiale ale unei întreprinderi, departament sau proces. Următorul număr va prezenta caracteristicile fiecărei categorii de sisteme în conformitate cu această clasificare.

1.3. Straturi în arhitectură

Conceptul de straturi este unul dintre modelele comune folosite de dezvoltatorii de software pentru a descompune sistemele complexe în părți mai simple. În arhitecturi sisteme informatice, de exemplu, distingeți între straturile de cod al limbajului de programare, funcțiile sistemului de operare, driverele de dispozitiv, seturile de instrucțiuni ale procesorului și logica internă a microcipului. Într-un mediu de rețea, protocolul FTP funcționează pe baza protocolului TCP, care, la rândul său, funcționează „pe deasupra” protocolului IP, situat „pe deasupra” protocolului Ethernet. Deci, să luăm în considerare principalele motive de interes pentru straturile arhitecturii sistemelor software:

Straturile sunt ușor de formalizat. Este clar intuitiv că, dacă sistemul este împărțit într-un număr de straturi, atunci stratul n este o componentă sau un set de componente ale sistemului care utilizează numai componente ale stratului n-1 și pot fi utilizate numai de componentele stratului n + 1.

Straturile au o semantică simplă și descriptivă. În general, în arhitectura unui sistem software, straturile reprezintă niveluri de abstractizare. Stratul n+1 folosește stratul n, prin urmare, abstracția conceptelor stratului n+1 este cel puțin nu mai mică decât cea a stratului n și, în mod ideal, dacă arhitectura sistemului este eficientă, nivelul său de abstractizare ar trebui să fie mai mare. În consecință, stratul n ascunde (încapsulează) logica lucrului cu conceptele definite pe acest strat, permițând astfel stratului n + 1 să implementeze lucrul cu concepte mai complexe, să organizeze o logică mai complexă folosind mijloacele expresive ale stratului de bază.

Straturile sunt larg răspândite. Într-adevăr, un număr destul de mare de sisteme software, mai ales când vine vorba de sisteme software scara întreprinderii (sisteme de întreprindere), au o structură stratificată. Desigur, destul de des există o situație în care structura strictă stratificată a sistemului este încălcată - de regulă, aceasta este o consecință a eroziunii arhitecturale (defect arhitectural) și eliminarea acesteia în majoritatea cazurilor poate aduce beneficii tangibile (aceste aspecte sunt discutate de mai jos).

Implementare alternativă. Puteți alege o implementare alternativă a straturilor de bază - componentele stratului superior sunt capabile să funcționeze fără nicio modificare a straturilor de bază, cu condiția ca interfețele să fie păstrate.

Dependența dintre straturi, adică, de fapt, interfețele furnizate de straturile inferioare cu cel superior, poate fi minimizată. Această minimizare a interfețelor - vă permite să creșteți flexibilitatea sistemului.

Schema straturilor arhitecturale are, de asemenea, anumite dezavantaje:

schimbări în cascadă. Straturile sunt bune la încapsularea mult, dar nu totul: modificarea unui strat necesită uneori modificări în cascadă la alte straturi. Un exemplu clasic din domeniul aplicațiilor software pentru întreprinderi: un câmp adăugat la un tabel de bază de date urmează să fie reprodus în interfața grafică și trebuie să găsească un afișaj corespunzător în fiecare strat intermediar.

Scădere de performanță. Prezența straturilor redundante reduce adesea performanța sistemului. Pe măsură ce treceți de la un strat la altul, datele suferă de obicei transformări de la o reprezentare la alta. În ciuda acestui fapt, încapsularea funcțiilor de bază poate obține adesea un avantaj foarte semnificativ. De exemplu, optimizarea stratului de tranzacție are ca rezultat o performanță mai bună pentru toate straturile de deasupra acestuia.

În scopul analizei sistemelor, arhitectura unei întreprinderi poate fi luată în considerare sub două aspecte:

1. static - în funcție de starea băncii la un moment fix în timp;
2. dinamic - ca proces de tranziție (migrare) a băncii de la starea actuală la o stare dorită în viitor.

Arhitectura întreprinderii luată în considerare în statică constă din următoarele elemente:

1. misiune şi strategie, obiective strategiceși sarcini;
2. arhitectura afacerii;
3. Arhitectura sistemului.

Privită ca o arhitectură dinamică a întreprinderii, este un plan coerent, coerent de acțiuni și proiecte coordonate necesare pentru a transforma arhitectura actuală a unei organizații într-o stare definită ca un obiectiv pe termen lung bazat pe actual și planificat. scopuri de afaceri și procesele de afaceri organizatii.

Astfel, arhitectura întreprinderii este în general descrisă de următoarele secțiuni dependente secvențial:

1. misiunea și strategia băncii formulate, scopurile și obiectivele strategice;
2. arhitectura de afaceri în starea actuală (așa cum este) și planificată (a fi),
3. arhitectura sistemului în starea curentă (așa cum este) și planificată (a fi);
4. planuri de acţiune şi proiecte pentru trecerea de la starea actuală la cea planificată.

Astfel, arhitectura de sistem planificată este arhitectura „a fi” doar la o anumită etapă a dezvoltării întreprinderii.

În același timp, o revenire la nivelul strategic al misiunii și a scopurilor și obiectivelor strategice nu înseamnă necesitatea revizuirii misiunii și strategiei. Însă la sfârșitul fiecărui ciclu, se efectuează în mod necesar o analiză a eficacității măsurilor dezvoltate și implementate, dacă este necesar, la a doua iterație, se ajustează arhitectura de business, arhitectura sistemului și se implementează noi planuri de migrare. Pot exista mai multe cicluri în fiecare moment de timp, fiecare astfel de ciclu nu afectează neapărat întreaga întreprindere în ansamblu, ciclul poate afecta anumite domenii, anumite probleme de afaceri și poate fi înregistrat ca un proiect separat.

La plan etapizat migrarea pentru a fixa rezultatele obținute, este posibilă construirea intermediară (migrare) una sau mai multe arhitecturi. Misiunea, strategia și obiectivele de afaceri determină direcția de dezvoltare a întreprinderii și stabilesc scopuri și obiective pe termen lung.

În arhitectura întreprinderii ar trebui să se distingă următoarele straturi:

1. Front office (Front-Office)

Front-Office (Front-office)ca sistem contabil extern (înarhitectura afacerii intreprinderii- este o colecțieprocesele de afaceri, proceduri, documente normative(regulamente), directoare, formulare tipărite, divizii organizatorice și de personal care asigură interacțiunea directă cu clientul din partea întreprinderii:

1. Primirea și introducerea pentru prelucrarea ulterioară a documentelor primare,
2. Imprimarea și furnizarea clientului cu informații și documente,
3. Apelarea clienților și trimiterea de mesaje de informare către clienți,
4. Primirea apelurilor telefonice primite, întrebări și furnizarea de informații.

Front-Office (Front office) ca sistem de contabilitate extern (înarhitectura sistemului de întreprindereeste un set de sisteme informatice, inclusiv baze de date și directoare, care vizează automatizareaprocesele de afaceriinteracțiunea cu clientul.

1. Birou de mijloc (birou de mijloc)

Birou mediu în arhitectura afacerii - acesta este un set de procese de afaceri, proceduri, documente de reglementare (regulamente), cărți de referință, formulare tipărite, unități organizaționale și de personal care asigură pregătirea și luarea deciziilor.

Exemple de divizii middle office:

Unitatea de verificare a împrumutatului în serviciu de securitate,

Divizia de management al riscului.

Birou mediu în Arhitectura sistemului -acesta este un set de sisteme informatice, inclusiv baze de date si directoare, destinate automatizarii proceselor de afaceri legate de pregatirea si luarea deciziilor.

Exemple de sisteme informatice de mediu de birou:

sistem contabil de poziție,

Sistemul de verificare a împrumutatului în biroul de istoric de credit,

Sistemul de calcul al punctajului pentru o cerere de împrumut.

1. Back Office

Back office (back office) ca sistem de contabilitate intern (înarhitectura afacerii) întreprinderile sunt un set de procese de afaceri, proceduri,documente normative (regulamente), cărți de referință, formulare tipărite, unități organizatorice și de personal care implementează contabilitatea de jurnal (registru) a operațiunilor. De obicei, contabilitatea registrului este un jurnal al tranzactiilor cu contrapartidele, fără legătură cu conturi contabile, nu este cu două fețe.

Back office în Arhitectura sistemuluiîntreprinderile sunt un set de sisteme informaționale, inclusiv baze de date și directoare, care implementează contabilitatea jurnal (registru) a operațiunilor.

1. Contabilitate

contabilitate de afaceri ( arhitectura afacerii) este un set de procese de afaceri, proceduri, documente de reglementare (regulamente), cărți de referință, formulare tipărite, unități organizatorice și de personal care implementează contabilitatea și raportarea în conformitate cu RAS (Regulamente contabile - standarde). contabilitate Rusia) și IFRS (Standarde internaționale). raportare financiară), mentinerea bilantului intreprinderii.

1. Depozitul de informații (DWH)
2. Raportare

Raportează la arhitectura de sistem - un set de sisteme informatice, inclusiv baze de date si directoare, care automatizeaza construirea de rapoarte pe baza datelor din depozitul de informatii.

Exemple de sisteme de raportare:

sistem de raportare de management,

Sistem de raportare analitică,

Sistemul indicatorilor cheie de performanță ai diviziilor întreprinderii,

Sistemul de generare a indicatorilor pentru calcularea punctajului pentru o cerere de credit.

Bibliografie

1. Vasiliev R. B., Kalyanov G. N., Levochkin G. A., Lukinova O. V. Managementul strategic al sistemelor informaționale; Universitatea de Internet de Tehnologia Informației, Binom. Laboratorul de cunoștințe - Moscova, 2013 . - 512 c.
2. Gritsenko Yu. B. Arhitectura întreprinderii: Tutorial/ Gritsenko Yu. B. - 2011. 256 p.
3. Danilin A.V., Slyusarenko A.I., Curs de pregatire– Arhitectura întreprinderii [Resurse electronice] - Mod de acces:http://www.intuit.ru/department/itmngt/entarc/
4. Kalyanov G.N. Modelarea, analiza, reorganizarea si automatizarea proceselor de afaceri. Manual: M.: Finanțe și statistică, 2006.

Pagina 17