Adnotare: Principii de creare a unui sistem informatic. Reproiectarea proceselor de afaceri. Afișarea și modelarea proceselor. Asigurarea procesului de analiză și proiectare a SI cu capacitățile tehnologiilor CASE. Implementarea sistemelor informatice.

6. Dezvoltarea și implementarea sistemului informațional

6.1. Principii de creare a unui sistem informatic

Mulți utilizatori de hardware și software de computer s-au confruntat în mod repetat cu o situație în care software-ul care funcționează bine pe un computer nu funcționează pe altul cu același dispozitiv. Sau blocurile de sistem ale unui dispozitiv de calcul nu se potrivesc în hardware-ul altuia. Sau sistemul informatic al altei companii refuza cu incapatanare sa prelucreze datele pe care le-ati pregatit in sistemul informatic de la locul de munca. Această problemă se numește problema compatibilității dispozitivelor de calcul, telecomunicații și informații.

Dezvoltarea sistemelor și mijloacelor informatice, implementarea lor extinsă în toate domeniile științei, tehnologiei, serviciilor și vieții de zi cu zi au condus la necesitatea combinării dispozitivelor de calcul specifice și a sistemelor informatice implementate pe baza acestora într-un singur sistem informatic-informatic ( ICS) și medii. În același timp, dezvoltatorii IVS s-au confruntat cu o serie de probleme.

De exemplu, eterogenitatea mijloacelor tehnice ale tehnologiei informatice în ceea ce privește organizarea procesului de calcul, arhitectura, sistemul de comandă, capacitatea procesorului și magistrala de date etc., a impus crearea de interfețe fizice care, de regulă, implementează compatibilitate reciprocă. a dispozitivelor. Odată cu creșterea numărului de tipuri de dispozitive integrate, complexitatea organizării unei interfețe fizice între ele a crescut semnificativ. Eterogenitatea mediilor programabile implementate în dispozitive și sisteme de calcul specifice, în ceea ce privește varietatea sistemelor de operare, diferențele de adâncime de biți și alte caracteristici, a condus la crearea de interfețe software între dispozitive și sisteme. În același timp, trebuie remarcat că nu a fost întotdeauna posibil să se realizeze compatibilitatea deplină a produselor software dezvoltate pentru un anumit mediu software într-un alt mediu. Eterogenitatea interfețelor de comunicație din sistemul „om-calculator” a necesitat coordonarea constantă a software-ului și hardware-ului și recalificarea personalului.

Principiul „deschiderii” a sistemului informatic

Rezolvarea problemelor de compatibilitate a condus la dezvoltarea unui număr mare de standarde și acorduri internaționale în domeniul tehnologiei informației și dezvoltării sistemelor informaționale. Conceptul de sisteme deschise a devenit un concept fundamental.

Termenul „sistem deschis” astăzi poate fi definit ca „un set cuprinzător și consistent de standarde internaționale de tehnologie a informației și profiluri de standarde funcționale care specifică interfețe, servicii și formate suport pentru a permite interoperabilitatea și mobilitatea aplicațiilor software, a datelor și a personalului”.

Această definiție, formulată de experți de la IEEE (Institute of Electrical and Electronic Engineers), unifică conținutul mediului pe care un sistem deschis îl oferă pentru utilizare pe scară largă. OASIS (Organizația pentru Avansarea Standardelor de Informații Structurate) este în prezent punctul focal general recunoscut pentru dezvoltarea și armonizarea standardelor sistemelor deschise.

Proprietățile generale ale sistemelor informatice deschise pot fi formulate după cum urmează:

extensibilitate / scalabilitate: oferind posibilitatea de a adăuga noi funcții IS sau de a schimba unele dintre cele existente cu părțile funcționale rămase ale IS neschimbate;

mobilitate/portabilitate: asigurarea posibilității de transfer de programe, date la upgrade sau înlocuire a platformelor hardware IS și posibilitatea de a lucra cu acestea pentru specialiștii care folosesc IT, fără recalificarea acestora la schimbarea IS;

interacțiune: capacitatea de a interacționa cu alte SI (mijloacele tehnice pe care este implementat sistemul informațional sunt unite printr-o rețea sau rețele de diferite niveluri: de la local la global);

standardizare: SI sunt proiectate și dezvoltate pe baza standardelor și propunerilor internaționale agreate, implementarea deschiderii se realizează pe baza standardelor (profilurilor) funcționale în domeniul tehnologiei informației;

uşurinţă în utilizare: a dezvoltat interfeţe unificate în procesele de interacţiune în sistemul „om-maşină”, permiţând utilizatorului să lucreze fără pregătire specială „computer”.

O nouă privire asupra sistemelor deschise este determinată de faptul că aceste caracteristici sunt considerate împreună, ca fiind interconectate și sunt implementate într-un complex, ceea ce este destul de natural, deoarece toate proprietățile de mai sus se completează reciproc. Numai în ansamblu posibilitățile sistemelor deschise permit rezolvarea problemelor de proiectare, dezvoltare și implementare a sistemelor informaționale moderne.

Structura mediului de sistem informatic

Structura generalizată a oricărui IS poate fi reprezentată prin două părți care interacționează:

partea funcțională, inclusiv programele de aplicație care implementează funcțiile zonei de aplicații;

mediu sau parte de sistem care asigură execuția programelor de aplicație.

Două grupuri de probleme de standardizare sunt strâns legate de această diviziune:

standarde pentru interfețele dintre programele de aplicație și mediul IS, interfața programului de aplicație (Application Program Interface - API);

standarde pentru interfețele de interacțiune între IS-ul însuși și mediul său extern (External Environment Interface - EEI).

Aceste două grupuri de interfețe definesc specificațiile descriere externă Mediul SI - arhitectura, din punctul de vedere al utilizatorului final, designer SI, programator de aplicatii care dezvolta partile functionale ale SI.

Specificațiile interfețelor externe ale mediului IS și, după cum se va vedea mai jos, specificațiile interfețelor de interacțiune între componentele mediului însuși, sunt descrieri precise ale tuturor funcțiilor, serviciilor și formatelor necesare unei anumite interfețe. Setul de astfel de descrieri constituie modelul de referință al sistemelor deschise (Reference Open System Model).

Acest model este folosit de peste 20 de ani și este definit de System Network Architecture (SNA) propusă de IBM în 1974. Se bazează pe împărțirea mediului de calcul în șapte niveluri, a căror interacțiune este descrisă de standardele relevante, și asigură conectarea nivelurilor, indiferent de construcția nivelului în fiecare implementare specifică (Fig. 6.1). Principalul avantaj al acestui model este o descriere detaliată a conexiunilor din mediu în ceea ce privește dispozitivele tehnice și interacțiunile de comunicare. Totuși, nu ține cont de relație, ținând cont de mobilitatea aplicației software.

Orez. 6.1.

Modelul de referință pentru mediul sistemelor deschise (OSE/RM) definește împărțirea oricărui sistem informațional în aplicații (programe de aplicație și pachete software) și mediul în care operează aceste aplicații. Interfețele standardizate (API) sunt definite între aplicații și mediu și sunt o parte necesară a profilurilor oricărui sistem deschis. În plus, în profilurile IS pot fi definite interfețe unificate pentru interacțiunea părților funcționale între ele și interfețe pentru interacțiunea între componentele mediului IS.

Model de creare a sistemului informatic

Este important din punct de vedere metodologic, alături de modelele considerate ale mediului SI, să se propună un model de creare a unui SI care să aibă aceleași aspecte ale grupurilor funcționale de componente (utilizatori, funcții, date, comunicații). Această abordare va oferi un proces end-to-end de proiectare și întreținere în toate etapele operațiunii SI și posibilitatea unei alegeri rezonabile de standarde pentru dezvoltarea sistemelor și documentarea proiectelor.

Firma este o structură ontologică (conceptuală) complexă, formată dintr-un anumit set de entități și relații (Fig. 6.2).

Interacțiunile dintre elementele sale, determinate de logica afacerii și consacrate într-un set de reguli de afaceri, sunt activitățile companiei. Sistemul informatic „reflectează” logica și regulile, organizează și transformă fluxurile de informații, automatizează procesele de lucru cu date și informații și vizualizează rezultatele sub forma unor seturi de formulare de raportare. Prin urmare, pentru început, ar trebui să creați un model de afaceri al întreprinderii, care este o reflectare a întreprinderii și a sistemului său de management al informațiilor.

La crearea unui model, se formează un „limbaj de comunicare” pentru managerii companiei, consultanți, dezvoltatori și viitorii utilizatori, ceea ce permite dezvoltarea unei idei comune despre CE și CUM ar trebui să facă un sistem de management al întreprinderii (sistem de management corporativ). Un astfel de model de afaceri este un rezultat tangibil, cu ajutorul căruia este posibil să se precizeze cât mai mult posibil obiectivele implementării IP și să se determine următorii parametri ai proiectului:

• principalele obiective de afaceri care pot fi atinse prin automatizarea proceselor;
• lista site-urilor și secvența de implementare a modulelor IS;
• nevoia reală de volume de software și hardware achiziționate;
• estimări reale ale momentului de desfășurare și lansare a IMS;
• utilizatorii cheie ai SI și o listă actualizată a membrilor echipei de implementare;
• gradul de conformitate a aplicației software pe care l-ați ales cu specificul afacerii companiei dumneavoastră.

Modelul se bazează întotdeauna pe obiectivele de afaceri ale întreprinderii, care determină complet compoziția tuturor componentelor de bază ale modelului:

• funcții de afaceri care descriu CE face afacerea;
• procesele principale, auxiliare și de management care descriu CUM întreprinderea își îndeplinește funcțiile de afaceri;
• structura organizatorica si functionala care determina UNDE sunt efectuate functiile si procesele de afaceri;
• faze care determină CÂND (în ce secvență) trebuie implementate anumite funcții de afaceri;
• rolurile care definesc OMS îndeplinește funcții de afaceri și OMS este „proprietarul” proceselor de afaceri;
• reguli care definesc relația și interacțiunea dintre toate CE, CUM, UNDE, CÂND și CINE.

După construirea unui model de afaceri (sau în paralel cu acesta), puteți începe să formați un model pentru proiectarea, implementarea și implementarea IS-ului în sine (Fig. 6.3).

Experiența creării și utilizării SI „personalizate” ne permite să distingem condiționat următoarele etape principale ale ciclului lor de viață:

• determinarea cerințelor pentru sistem și analiza acestora - determinarea ce ar trebui să facă sistemul;
• proiectare - determinarea modului în care sistemul va face ceea ce ar trebui să facă; proiectarea este, în primul rând, specificarea subsistemelor, componentelor funcționale și modalităților de interacțiune a acestora în sistem;
• dezvoltare - crearea de componente funcționale și subsisteme individuale, conectarea subsistemelor într-un singur întreg;
• testare - verificarea conformității funcționale a sistemului cu indicatorii determinați în etapa de analiză;
• implementare - instalarea si punerea in functiune a sistemului;
• funcționare - un proces regulat de funcționare în conformitate cu principalele scopuri și obiective ale SI;
• suport - asigurarea functionarii regulate a sistemului la intreprinderea clientului.

Determinarea cerințelor de sistem și analiza este primul pas în crearea unui SI, la care cerințele clienților sunt specificate, agreate, formalizate și documentate. De fapt, în această etapă, se dă un răspuns la întrebarea: „La ce este destinat sistemul informațional și ce ar trebui să facă?”. Aici se află cheia succesului întregului proiect.

Scopul analizei de sistem este de a transforma cunoștințele generale, vagi despre domeniul original (cerințele clienților) în definiții și specificații precise pentru dezvoltatori, precum și de a genera o descriere funcțională a sistemului. În această etapă, sunt definite și specificate următoarele:

• condițiile externe și interne ale sistemului;
• structura funcțională a sistemului;
• distribuția funcțiilor între o persoană și un sistem, interfețe;
• cerințe pentru componentele tehnice, informatice și software ale sistemului,
• cerințe de calitate și siguranță;
• alcătuirea documentației tehnice și de utilizare;
• conditii de implementare si functionare.

Dezvoltarea specificațiilor de mai sus la crearea unui IS menit să automatizeze procesele de management, în cazul general, parcurge patru etape.

Prima etapă de analiză - analiza structurală a întreprinderii - începe cu un studiu al modului în care este organizat sistemul de management al întreprinderii, cu o cercetare a structurii funcționale și informaționale a sistemului de management, determinând consumatorii existenți și potențiali de informații.

Pe baza rezultatelor sondajului, analistul din prima etapă construiește un model logic generalizat al domeniului inițial, reflectând structura funcțională a acestuia, caracteristicile activității principale și spațiul informațional în care se desfășoară această activitate (Fig. 6.4). ). Pe acest material, analistul construiește un model funcțional „As is” (As Is).

A doua etapă de lucru, la care sunt implicați în mod necesar reprezentanți interesați ai clientului și, dacă este necesar, experți independenți, constă în analiza modelului „Așa cum este”, identificarea deficiențelor și blocajelor acestuia și determinarea modalităților de îmbunătățire a sistemului de management. pe baza criteriilor de calitate identificate.

A treia etapă de analiză, care conține elemente de proiectare, este crearea unui model logic generalizat îmbunătățit care afișează un domeniu reorganizat sau o parte a acesteia care este supusă automatizării - modelul As To Be.

Procesul (etapa a patra) se încheie cu elaborarea „Hărții automatizării”, care este un model de arie tematică reorganizată, pe care sunt indicate în mod necesar „limitele automatizării”.

În cele mai multe cazuri, modelul „Așa cum este” este îmbunătățit de către analistul de sistem prin eliminarea inconsecvențelor și blocajele evidente, iar varianta de model obținută în acest fel este considerată în continuare ca un model preliminar „Așa cum ar trebui să fie”, care este completat ulterior în conformitate cu cu strategia de dezvoltare a întreprinderii (Fig. .6.5).

La etapa de analiză a cerințelor pentru sistemul de proiectat se introduc următoarele:

• clase de utilizatori și diagrame de tranzacții comerciale corespunzătoare;
• modele (diagrame) proceselor de activitate aplicate și liste corespunzătoare de sarcini funcționale SI;
• clasele de obiecte ale domeniului de subiect și diagramele entitate-relație corespunzătoare care reflectă modelul informațional al acestei discipline;
• topologia locației unităților și utilizatorilor deserviți de acest IS;
• parametrii de protecție a datelor, informațiilor și a sistemului însuși.

Documentul principal care reflectă rezultatele muncii din prima etapă de creare a unui SI este termenii de referință pentru proiect (dezvoltare), care conține, pe lângă definițiile și specificațiile de mai sus, și informații despre ordinea în care sistemul se creează, informații despre resursele alocate, termene de realizare a etapelor individuale de lucru, proceduri organizatorice și măsuri de acceptare a etapelor, protecția informațiilor despre proiect etc.

Următoarea etapă este proiectarea. În condiții reale, proiectarea este o căutare, modelare a unei metode de dezvoltare care satisface cerințele funcționalității sistemului prin intermediul tehnologiilor disponibile, ținând cont de condițiile și restricțiile inițiale date. Proiectarea sistemelor informatice începe întotdeauna cu definirea scopului proiectului. Sarcina principală a oricărui proiect de succes este să se asigure că în momentul lansării sistemului și pe toată perioada de funcționare a acestuia este posibil să se ofere:

• funcționalitatea necesară a sistemului și gradul de adaptare la condițiile în schimbare ale funcționării acestuia;
• debitul de sistem necesar și timpul minim de răspuns al sistemului la o solicitare;
• funcționarea fără probleme a sistemului în modul necesar, disponibilitatea și disponibilitatea sistemului pentru a procesa cererile utilizatorilor;
• ușurința în operare și întreținere a sistemului;
• securitatea datelor necesare și drepturile de acces ale utilizatorilor.

Performanța și fiabilitatea sunt principalii factori care determină eficacitatea sistemului. Designul bun este baza unui sistem de înaltă performanță.

Proiectarea sistemelor informatice acoperă trei domenii principale:

• proiectarea structurilor de date care vor fi implementate în baza de date;
• proiectarea de programe, formulare de ecran, rapoarte care vor asigura executarea interogărilor de date;
• proiectarea unui mediu sau tehnologie specifică, și anume: topologia rețelei, configurația hardware, arhitectura utilizată, procesarea paralelă, prelucrarea distribuită a datelor etc.

Pe baza rezultatelor analizei sistemului, în faza de proiectare preliminară se elaborează următoarele:

• proiect de implementare software și hardware, proiect de interfețe utilizator și tehnologii de lucru de utilizator în sistem;
• arhitectura sistemului distribuit și specificațiile rețelei de telecomunicații;
• modele (diagrame) ale fluxurilor de date;
• diagrame bloc funcționale ale aplicației și software-ului de sistem (cel din urmă - în conformitate cu modelele acceptate ale mediului IS și profilurile standardelor).

Etapa de proiectare preliminară poate implica prototiparea unor piese care sunt importante din punctul de vedere al utilizatorului pentru a verifica conformitatea acestora cu cerințele într-un stadiu incipient de dezvoltare.

În etapa de proiectare detaliată sunt dezvoltate:

• complexe de programe SI functionale si un proiect de implementare a mediului SI;
• structuri de date, instrumente de gestionare a bazelor de date;
• adresele de rețea, protocoalele de telecomunicații și alte componente ale mediului de schimb de informații incluse în IS proiectat;
• reguli de restricționare a accesului utilizatorilor și mijloace de implementare a acestora.

Etapa de implementare a SI prevede dezvoltarea și testarea componentelor și testarea completă a sistemului.

Etapa de operare și întreținere prevede monitorizarea funcționării SI, efectuarea modificărilor necesare la baza de informații în cursul lucrărilor curente și modernizarea funcțiilor IS de către specialiști aplicați folosind instrumente încorporate în sistem.

Etapele de dezvoltare, testare, implementare, operare și întreținere a SI sunt unite prin termenul - implementare. Implementarea SI este un proces cu mai multe aspecte extrem de complex, realizat pe baza unor seturi (profiluri) de standarde, specificații și acorduri internaționale armonizate. Această practică este o garanție că sistemul informațional creat va fi implementat ca un „sistem deschis”. Cu alte cuvinte, un astfel de IS va fi scalabil, mobil, portabil, va avea interfețe prietenoase etc.

Ciclul de viață al unui IS este format în conformitate cu principiul designului de sus în jos și, de regulă, este de natură spirală-iterativă. Etapele implementate, începând de la cele mai timpurii, se repetă ciclic în funcție de modificările cerințelor și condițiilor externe, introducerea de restricții suplimentare etc. La fiecare etapă a ciclului de viață, se generează un anumit set de soluții tehnice și documente, în timp ce documentele și soluțiile sunt inițiale pentru fiecare etapă parcursă în pasul precedent. Ciclul de viață al unui IS se încheie atunci când software-ul și suportul tehnic încetează.

6.2. Reinginiere a proceselor de afaceri

Introducerea tehnologiilor informaționale și a sistemelor informaționale implementate pe baza acestora în activitățile zilnice ale unei întreprinderi îi conferă acesteia avantaje tactice și pe termen lung în afaceri. Dorința managementului de a utiliza IT poate rămâne doar bună intenție dacă nu respectă cerințele și regulile stabilite pentru dezvoltarea, proiectarea și implementarea IT. Mai sus, am vorbit despre cerințele de bază pentru standardizarea obiectelor și a sarcinilor funcționale, fără de care sistemul implementat nu va fi un sistem deschis, ceea ce va duce ulterior la numeroase probleme în implementarea și funcționarea sa.

Urmărirea cerințelor standardelor în dezvoltarea SI duce automat la faptul că întreprinderea în sine - mediul extern pentru IS - îndeplinește și cerințele necesare: definirea și standardizarea claselor de utilizatori și obiecte, topologia datelor și fluxurilor de lucru. , arhitectura subsistemelor moștenite și dezvoltate, starea proceselor de afaceri etc.

Un proces de afaceri este un sistem de activități consistente, intenționate și reglementate în care, prin control și cu ajutorul anumitor resurse, pentru anumit timp intrările de proces sunt convertite în ieșiri - în rezultate care sunt valoroase pentru consumator și aduc profit producătorului.

Un proces standard de afaceri la nivelul întregii întreprinderi este implementat ca o rețea de procese principale, auxiliare, de suport și de management (Fig. 6.6).

În același timp, împărțirea în procese principale și auxiliare depinde într-o anumită măsură de domeniul și direcția întreprinderii: pentru o companie de producție, de exemplu, activitatea departamentului juridic este auxiliară, iar pentru o lege sau consultanță fermă este cea principală. Identificarea procesului este condiție prealabilă, fără implementarea căreia informatizarea activității este imposibilă.

Managerii de întreprindere care decid să implementeze IT ar trebui să înțeleagă cu fermitate că începerea lucrărilor la proiectarea unui sistem informațional presupune cel mai adesea o reinginerire obligatorie a proceselor de afaceri! Reingineria este un set de metode și recomandări, dintre care trebuie să le alegeți pe acelea care cel mai bun mod satisface obiectivele stabilite.

Reingineria proceselor de afaceri este un set de metode și acțiuni care servesc la reproiectarea proceselor în conformitate cu condițiile schimbate ale mediului extern și intern și/sau obiectivelor de afaceri.

Există mai multe reguli de bază care ar trebui urmate în procesul de reinginerie:

• dezvoltarea de proceduri coerente pas cu pas pentru reproiectarea procesului;
• utilizarea în proiectarea limbilor standard și a notațiilor;
• prezența unor indicatori euristici și pragmatici care vă permit să evaluați sau să măsurați gradul de conformitate a procesului sau a funcționalității reproiectate cu obiectivele specificate;
• abordarea soluționării unor probleme particulare și a totalității acestora ar trebui să fie sistemică;
• chiar și o mică îmbunătățire ar trebui să dea un efect pozitiv rapid.

Reproiectarea proceselor și funcțiilor de afaceri începe cu o revizuire a obiectivelor întreprinderii, structurii acesteia, analiza nevoilor utilizatorilor interni și a pieței, produselor și serviciilor produse (Fig. 6.7).

Reprogramarea scopurilor și obiectivelor implică revizuirea politicii întreprinderii și răspunsul la următoarele întrebări:

• Ce noi provocări ne prezintă schimbările condițiilor de afaceri?
• Ce reprezintă compania acum și ce ne dorim de la ea în viitor?
• Ce fel de clienți servim, cum le îndeplinim cerințele și așteptările și ce trebuie făcut pentru a atrage alții noi?
• Ce indicatori determină eficacitatea întreprinderii, productivitatea muncii și calitatea produsului, este această definiție completă și adecvată?
• Ce tehnologii și mijloace informaționale ne vor ajuta în acest sens?

Pentru a răspunde la aceste întrebări cheie, este necesar, în primul rând, să se efectueze o descriere detaliată a arhitecturii de afaceri a întreprinderii, a logicii sale de afaceri, să se construiască un model funcțional al interacțiunii proceselor, resurselor și personalului de afaceri și să-l reflecte în Arhitectura IS, conținutul modulelor subsistemului informațional și vizualizarea formelor de prezentare a informațiilor. De asemenea, este necesar să existe metode și instrumente pentru reorganizarea proceselor, rezolvarea problemelor aplicate și gestionarea unui proiect de reinginerie (Fig. 6.8). Descrierea arhitecturii de afaceri a întreprinderii permite:

• construiți o diagramă a principalelor fluxuri de date, munca, mișcarea finanțelor și documentelor;
• să înțeleagă modul în care informațiile sunt distribuite între departamente și cine este utilizatorul final într-un anumit proces de afaceri;
• descrie interacțiunea proceselor și modulelor sistemului informațional;
• determinarea importanței critice a tipurilor de informații pentru niveluri specifice de management al întreprinderii;
• identifica structurile și conexiunile duplicate.

Rezultatul acestei descrieri este:

• harta rețelei de proces actualizată;
• o matrice de interconexiuni între procese și departamente implicate în aceste procese;
• informații despre ce sisteme de automatizare există, ce operațiuni sunt utilizate, unde și ce date sunt utilizate, ce sisteme de automatizare și informatizare trebuie dezvoltate;
• diagrame funcționale ale fluxurilor de date (Data Flow), lucrări (Work Flow), fluxurilor financiare (Cash Flow), fluxurilor de acțiuni manageriale (Control Flow) și workflow (Doc Flow).

Modelul funcțional va ajuta la realizarea unor specificații precise ale tuturor operațiunilor, procedurilor și relațiilor dintre acestea. Un astfel de model, dacă este construit corect, oferă o descriere cuprinzătoare a unui proces de funcționare și a tuturor fluxurilor de informații în cadrul acestuia. Acest model descrie starea „Așa cum este” (Așa cum este). Pe baza rezultatelor analizei modalităților posibile de îmbunătățire, dintr-un model real, trebuie să treceți la un model care caracterizează îmbunătățirile - modelul As To Be, opțiunea este „Cum ar trebui să fie” (Fig. 6.9) .

Modelarea funcțională este o problemă destul de serioasă, completitudinea și conformitatea modelului construit depind atât de instrumentele de modelare, cât și de calificările specialiștilor care efectuează această modelare.

Reingineria proceselor de afaceri este un proiect complex și cu mai multe fațete care necesită o planificare atentă și detalii. Tabelul 6.1 prezintă principalele etape ale reingineriei.

6.3. Maparea proceselor și modelarea

Până în prezent, trei metodologii principale de modelare funcțională (și instrumentele lor însoțitoare) s-au răspândit: IDEF (Integrated DEFinition), UML (Unified Modeling Language) și ARIS (Arhitectura Sistemelor Informaționale Integrate). Pentru fiecare dintre ele, există anumite produse software care, pe lângă dezvoltare, vă permit să efectuați transformări și operațiuni pentru lucrul ulterioar cu modelele rezultate. Metodologiile IDEF și produsul software BPWin, care conține metodologiile IDEF0, IDEF3, DFD (Data Flow Diagrams) și ERWin (IDEF1x) de la Computer Associates, sunt cele mai utilizate astăzi.

Istoria metodologiei IDEF începe în anii 1970 cu metodologia SADT (Structured Analysis and Design Technique) dezvoltată de Douglas Ross (Softtech INC). Inițial, SADT a fost folosit de Departamentul de Apărare al SUA pentru modelarea practică a proceselor, ca parte a programului ICAM (Integrated Computer Aided Manufacturing). Cerința principală în dezvoltarea familiei de metodologii luate în considerare a fost posibilitatea unui schimb eficient de informații între toți specialiștii participanți la programul ICAM (Icam DEFinition). Ulterior, această metodologie a fost transformată în standardul IDEF0 (Function Modeling, FIPS No. 183). Familia IDEF include deja menționate IDEF3 (Process Description Capture) și IDEF1x (Data Modeling, FIPS nr. 184).

După ce standardele au fost publicate, acestea au fost aplicate cu succes în diverse domenii de afaceri, dovedindu-se a fi un instrument eficient pentru analizarea, proiectarea și afișarea proceselor de afaceri (apropo, este utilizat activ și în agențiile guvernamentale interne, de exemplu, în stat Inspectoratul Fiscal). Mai mult, apariția ideilor principale ale conceptului acum popular de „Business Process Reengineering” (Business Process Reengineering - BPR) este asociată cu utilizarea pe scară largă a IDEF (și a metodologiei anterioare SADT).

Procesul de informare este un proces durabil (o secvență de lucru și acțiuni cu date și informații) legat de susținerea activităților de producție și economice ale companiei și este de obicei axat pe serviciul de informare pentru crearea de valoare nouă. Un proces de afaceri include o ierarhie de acțiuni funcționale interconectate care implementează unul (sau mai multe) obiective de afaceri ale companiei și reflectă rezultatele în sistemul informațional, de exemplu, suport informațional pentru gestionarea și analiza rezultatelor produsului sau suportul resurselor pentru ieșirea produsului. (produse aici înseamnă bunuri, servicii, decizii, documente).

Lucrul folosind metoda IDEF începe cu stabilirea scopului modelării. Experiența mondială arată că erorile în stabilirea obiectivelor duc în medie la 50% din eșecurile în procesul de modelare. Formularea scopului orientează inițial munca într-o direcție dată și, prin urmare, limitează gama de întrebări pentru analiză. Munca practică începe cu definirea contextului (Context, Context Diagram), adică nivelul superior al sistemului, în cazul nostru, întreprinderea. După formularea scopului, este necesară conturarea zonei de modelare (Scope), care va determina ulterior direcțiile generale de mișcare și adâncimea detaliului (Descompunere). De fapt, metodologia IDEF în sine definește obiecte standardizate pentru operare și afișare. De exemplu, acestea includ o funcție (Activitate), un arc de interfață (Săgeată), o notă (Notă), precum și modul în care sunt localizate și interpretate (Semantică).

LA timpuri recente Pe piața rusă a apărut produsul software Business Studio, care este special conceput pentru a funcționa cu metode IDEF și are o interfață intuitivă și prietenoasă (User-friendly Interface).

Notația și metodologia IDEF0 se bazează pe conceptul de „bloc”, adică un dreptunghi care exprimă o anumită funcție de business (Fig. 6.10). În conformitate cu standardul, funcția trebuie exprimată printr-un turnover verbal.În IDEF0, rolurile laturilor dreptunghiului (sensuri funcționale) sunt diferite: partea de sus are semnificația „control”, cea din stânga - „input ", cel din dreapta - "ieșire", cel de jos - "mecanism de execuție".

Al doilea element al metodologiei și al notației este „fluxul”, denumit în standard „arcul de interfață”. Acesta este un element care descrie datele, controlul informal sau orice altceva care afectează funcția reprezentată de bloc. Fluxurile sunt desemnate printr-o frază nominală.

În funcție de ce parte a blocului este direcționat fluxul, acesta, respectiv, se numește „intrare”, „ieșire”, „control”. Elementul iconic care reprezintă fluxul este o săgeată. Un flux poate fi interpretat ca o reprezentare a unui obiect, care se referă atât la un obiect informațional, cât și la un obiect fizic real.

Un factor important este că „sursa” și „receptorul” fluxurilor (adică începutul și sfârșitul săgeții) pot fi de obicei numai blocuri. În acest caz, doar partea de ieșire a blocului poate fi sursă, receptorul poate fi oricare dintre cele trei rămase. Dacă este necesar să se sublinieze natura externă a fluxului, atunci se poate aplica metoda „tunelului” - ascunderea sau apariția arcului de interfață din „tunel”.

Și, în sfârșit, „al treilea pilon” al metodologiei IDEF0 este principiul descompunerii funcționale a blocurilor, care este o interpretare model a situației practice în care orice acțiune (mai ales la fel de complexă ca un proces de afaceri) poate fi defalcată (descompusă) în operațiuni mai simple (acțiuni, funcții de afaceri). Sau, cu alte cuvinte, acțiunea poate fi reprezentată ca o colecție de funcții elementare.

Un exemplu de model funcțional al procesului de expediere și livrare a produselor este prezentat în fig. 6.11.

Gradul de formalizare a descrierii proceselor de afaceri poate fi diferit în funcție de sarcinile care se rezolvă. Un limbaj specializat BPEL (Business Process Execution Language) a fost dezvoltat pentru a descrie procesele informaționale. BPEL se bazează pe XML pentru o descriere formală a proceselor de afaceri și a protocoalelor pentru interacțiunea lor între ele. BPEL extinde modelul de interacțiune a serviciilor Web pentru a include suport pentru tranzacții.

În prezent, se dezvoltă în mod activ metodologia BPMS (Business Process Management System) - o clasă de software pentru gestionarea proceselor de afaceri și a reglementărilor administrative. (Sunt folosiți și termenii sistem BPM și pur și simplu BPM.) Utilizarea BPMS vă permite să organizați interacțiunea eficientă între manageri și specialiști IT, să utilizați mai bine subsistemele existente și să accelerați dezvoltarea altora noi.

Principalele funcții ale BPMS sunt modelarea, execuția și monitorizarea proceselor de afaceri. Pe baza datelor de monitorizare, întreprinderile identifică blocajele și își îmbunătățesc procesele de afaceri. Bucla de control este închisă atunci când procesele de afaceri modificate sunt rapid puse în funcțiune cu ajutorul BPMS.

Metodele moderne de proiectare și dezvoltare a software-ului IS încearcă pe deplin să se concentreze pe posibilitatea unor schimbări automate prompte. Cel mai dificil a fost procesul de standardizare a limbajului BPEL pentru a unifica utilizarea acelorași constructe de către software de la diferiți producători. IBM și Microsoft au definit două limbi destul de similare: WSFL (Web Services Flow Language) și, respectiv, Xlang.

Creșterea popularității BPML și mișcarea deschisă a BPMS către utilizatori au determinat Intalio Inc., IBM și Microsoft să fuzioneze aceste limbi în Limba noua; limbaj nou BPEL4WS. În aprilie 2003, BEA Systems Corporation, IBM, Microsoft, SAP și Siebel Systems au transmis BPEL4WS versiunea 1.1 la OASIS pentru standardizare de către Comitetul Tehnic BPEL pentru Servicii Web. Deși BPEL4WS a apărut în versiunile 1.0 și 1.1, comitetul tehnic WS-BPEL OASIS a votat pe 14 septembrie 2004 denumirea specificației WS-BPEL 2.0. Această modificare a fost făcută pentru a alinia BPEL cu alte standarde de servicii Web care încep cu „WS-” ca parte a „Convenției de denumire”.

Active Endpoints, Adobe, BEA, IBM, Oracle și SAP au publicat specificațiile de consens BPEL4 People și WS-HumanTask, care descriu modul în care interacțiunea procesului cu oamenii poate fi implementată în sistem și în notațiile BPEL. Ar trebui să adauge semantică la BPEL sub formă de WS-HumanTask și diverse alte completări.

6.4. Asigurarea procesului de analiză și proiectare a SI cu capacitățile tehnologiilor CASE

Termenul CASE (Computer Aided Software/System Engineering) este utilizat în prezent într-un sens foarte larg. valoarea inițială Termenul CASE, limitat la problemele de automatizare a dezvoltării numai a software-ului (SW), a dobândit acum sens nou acoperind procesul de dezvoltare a SI complex în general.

Acum, termenul CASE-tools se referă la instrumente software care sprijină procesele de creare și întreținere a SI, inclusiv analiza și formularea cerințelor, proiectarea software-ului aplicației (aplicații) și baze de date, generarea de cod, testare, documentare, asigurare a calității, management al configurației și managementul proiectelor, precum și alte procese. Astfel, instrumentele moderne CASE, împreună cu software-ul de sistem și instrumentele de suport tehnic, formează un mediu complet de dezvoltare IS.

Apariția tehnologiei CASE și a instrumentelor CASE a fost precedată de cercetări în domeniul metodologiei de programare. Programarea a dobândit caracteristicile unei abordări sistematice cu dezvoltarea și implementarea de limbaje de nivel înalt, metode de programare structurală și modulară, instrumente de modelare vizuală și proiectare bazate pe UML (Unified Modeling Language), instrumente pentru suportul acestora, limbaje formale și informale ​​pentru descrierea cerințelor și specificațiilor sistemului etc. În plus, următorii factori au contribuit la apariția tehnologiei CASE:

• formarea analiștilor și programatorilor receptivi la conceptele de programare modulară și structurată;
• introducerea pe scară largă și creșterea constantă a performanței computerelor, ceea ce a făcut posibilă utilizarea instrumentelor grafice eficiente și automatizarea majorității etapelor de proiectare;
• introducerea tehnologiei de rețea, care a făcut posibilă combinarea eforturilor interpreților individuali într-un singur proces de proiectare prin utilizarea unei baze de date partajate care conține informațiile necesare despre proiect.

Tehnologia CASE este o metodologie de proiectare IS, precum și un set de instrumente care vă permit să modelați vizual domeniul subiectului, să analizați acest model în toate etapele dezvoltării și întreținerii SI și să dezvoltați aplicații în conformitate cu nevoile de informații ale utilizatorilor. Majoritatea instrumentelor CASE existente se bazează pe metodologiile de analiză și proiectare structurală (în mare parte) sau orientate pe obiecte, folosind specificații sub formă de diagrame sau texte pentru a descrie cerințele externe, relațiile dintre modelele de sistem, dinamica comportamentului sistemului și arhitectura software. [Vendrov A. M., http://www.citforum.ru/database/case/index.shtml].

Instrumentele CASE vă permit să creați nu numai un produs care este aproape gata de utilizare, ci și să asigurați procesul „corect” al dezvoltării acestuia. Scopul principal al tehnologiei este de a separa proiectarea software-ului de codificarea, asamblarea, testarea acestuia și de a „ascunde” cât mai mult posibil de viitorii utilizatori toate detaliile dezvoltării și exploatării software-ului. În același timp, eficiența muncii proiectantului este crescută semnificativ: timpul de dezvoltare este redus, numărul erorilor software este redus, modulele software pot fi utilizate în următoarele dezvoltări.

Majoritatea instrumentelor CASE se bazează pe metodologia/metoda/notația/structura/paradigma instrumentului.

Metodologia stabilește linii directoare pentru evaluarea și selectarea unui proiect de dezvoltare software, etapele și succesiunea de lucru, reguli de aplicare a anumitor metode.

Metodă - o procedură sistematică sau o tehnologie pentru generarea de descrieri ale componentelor software (de exemplu, o descriere a fluxurilor și a structurilor de date).

Notațiile sunt menite să descrie sistemul în ansamblu, elementele sale: grafice, diagrame, tabele, diagrame bloc, algoritmi, limbaje formale și limbaje de programare.

Structurile sunt un mijloc de implementare a analizei structurale și de construire a structurii unui anumit sistem.

Instrumente - instrumente tehnologice și software pentru sprijinirea și îmbunătățirea metodelor.

Tehnologiile CASE au următoarele avantaje principale care le permit să fie utilizate pe scară largă în dezvoltarea sistemelor informaționale:

• accelerarea procesului de proiectare și dezvoltare colectivă;
• permite crearea unui prototip al sistemului comandat cu proprietățile specificate într-un timp scurt;
• eliberați dezvoltatorul de munca de rutină, lăsând timp pentru creativitate;
• asigura eficienta si calitatea software-ului dezvoltat prin automatizarea controlului intregului proces de dezvoltare;
• sprijină întreținerea și dezvoltarea sistemului la un nivel înalt.

Trebuie remarcat faptul că, în ciuda tuturor posibilităților potențiale ale instrumentelor CASE, există destul de multe exemple de implementare nereușită a acestora, în urma cărora instrumentele CASE devin software de „raft” (Shelfware).

În acest sens, trebuie avute în vedere următoarele:

• Instrumentele CASE nu dau neapărat un efect imediat, acesta poate fi obținut doar după ceva timp;
• costurile reale de implementare a instrumentelor CASE sunt de obicei mult mai mari decât costurile de achiziție a acestora;
• Instrumentele CASE oferă oportunități pentru beneficii semnificative numai după finalizarea cu succes a procesului lor de implementare, instruirea eficientă a utilizatorilor și utilizarea regulată.

De asemenea, puteți enumera următorii factori care complică determinarea posibilului efect al utilizării instrumentelor CASE:

• o mare varietate de calitate și capabilități ale instrumentelor CASE;
• timp relativ scurt de utilizare a instrumentelor CASE în diverse organizații și lipsă de experiență în aplicarea acestora;
• o mare varietate în practica de implementare a diferitelor organizații;
• lipsa unor metrici și date detaliate pentru proiectele deja finalizate și în derulare;
• o gamă largă de domenii ale proiectului;
• grad diferit de integrare a instrumentelor CASE în diferite proiecte.

Unii analiști consideră că beneficiul real al utilizării anumitor tipuri de instrumente CASE poate fi obținut doar după unul sau doi ani de experiență. Alții cred că impactul poate apărea de fapt în faza operațională a ciclului de viață IC, când îmbunătățirile tehnologice pot duce la costuri de operare mai mici.

În cele ce urmează sunt enumerate principalele tipuri și secvența de lucru recomandate la construirea modelelor logice ale domeniului subiectului în cadrul tehnologiei CASE pentru analiza unui sistem de management al întreprinderii.

1. Efectuarea unui studiu funcțional și informațional al sistemului de management (activități administrative și manageriale) al întreprinderii (Fig. 6.1.2):
   • determinarea structurii organizatorice a întreprinderii;
   • determinarea structurii funcționale a întreprinderii;
   • determinarea listei de funcții țintă ale elementelor structurale (divizii și funcționari);
   • determinarea sferei și ordinii de examinare a elementelor structurale ale sistemului de management în conformitate cu funcțiile țintă formulate;
   • examinarea activităților elementelor structurale identificate;
   • realizarea unei diagrame FD a sistemului de control indicând elementele structurale și funcțiile, a cărei implementare va fi modelată la nivel de DFD.
2. Dezvoltarea modelelor de activitate pentru elementele structurale și sistemul de management în ansamblu:
   • selectarea unui set de obiecte externe care au un impact semnificativ asupra activității unui element structural;
   • specificarea fluxurilor de informații de intrare și de ieșire;
   • identificarea principalelor procese care determină activitatea unui element structural și asigură implementarea funcțiilor țintă a acestuia;
   • precizarea fluxurilor de informații între principalele procese de activitate, clarificarea legăturilor dintre procese și obiectele externe;
   • evaluarea volumelor, intensității și a altor caracteristici necesare ale fluxurilor de informații;
   • dezvoltarea unei ierarhii de diagrame de flux de date care formează un model funcțional al activității unui element structural;
   • combinând modelele DFD ale elementelor structurale într-un singur model al sistemului de management al întreprinderii.
3. Dezvoltarea modelelor informaționale ale elementelor structurale și a unui model al spațiului informațional al sistemului de control:
   • definirea entităților model și a atributelor acestora;
   • efectuarea de analize de atribute și optimizare a entităților;
   • identificarea relațiilor dintre entități și definirea tipurilor de relații;
   • analiza si optimizarea modelului informatic;
   • combinarea modelelor informaţionale într-un singur model al spaţiului informaţional.
4. Elaborarea de propuneri de automatizare a sistemului de management al întreprinderii:
   • determinarea limitelor automatizării - întocmirea unei liste de elemente structurale automatizate, împărțind procesele activității principale în automate, automatizate și manuale;
   • alcătuirea unei liste de subsisteme și stații de lucru logice (stații de lucru automate), stabilirea modalităților de interacțiune a acestora;
   • elaborarea de propuneri privind succesiunea de proiectare și implementare a subsistemelor și stațiilor de lucru logice individuale care fac parte din SI;
   • dezvoltarea cerințelor pentru mijloacele de suport tehnic de bază al SI;
   • dezvoltarea cerințelor pentru software-ul IS de bază.

Modelul logic care reflectă activitățile sistemului de management al întreprinderii și spațiul informațional în care se desfășoară această activitate este un „instantaneu” al stării de lucruri (structura funcțională, rolurile funcționarilor, interacțiunea între departamente, tehnologiile acceptate de procesare a informațiilor de management, procese automatizate şi neautomatizate etc. .) la momentul examinării. Acest model vă permite să înțelegeți ce face întreprinderea și cum funcționează ea din punct de vedere al analizei sistemului, să formulați propuneri de îmbunătățire a situației.

Dezvoltarea unui model logic al domeniului de studiu, transformarea sa consecventă într-un model țintă IS, va permite integrarea propunerilor promițătoare din partea conducerii și a angajaților de conducere ai întreprinderii, experți și analiști de sistem și formarea unei viziuni a unui nou, reorganizat și activitatea automatizată a întreprinderii (Fig. 6.12).

Modelul construit este un rezultat complet din următoarele motive.

1. Include un model al tehnologiei existente neautomatizate adoptată de întreprindere. O analiză formală a acestui model face posibilă identificarea blocajelor în managementul întreprinderii și formularea de recomandări pentru îmbunătățirea acestuia (indiferent dacă este de așteptat sau nu dezvoltarea ulterioară a unui sistem automatizat).
2. Este independent și separabil de dezvoltatori specifici, nu necesită întreținere și poate fi transferat fără durere altora. În plus, dacă dintr-un motiv oarecare întreprinderea nu este pregătită să implementeze proiectul în acest moment timp, modelul poate fi „raft” până la nevoie.
3. Permite formarea eficientă a noilor angajați în domenii specifice ale întreprinderii, deoarece tehnologiile relevante sunt conținute în model.
4. Cu ajutorul acestuia, este posibilă realizarea de modelări preliminare a domeniilor promițătoare ale activității întreprinderii pentru a identifica noi fluxuri de date, procese de interacțiune și elemente structurale.
5. Asigură diseminarea experienței acumulate în alte întreprinderi, face posibilă unificarea activităților administrative, manageriale și financiare ale acestor întreprinderi.

Modelul nu este doar o implementare etapele inițiale lucru și baza pentru formarea specificațiilor tehnice pentru etapele sale ulterioare. Este un rezultat independent de mare importanță practică, deoarece permite utilizarea în continuare a tehnologiilor CASE pentru proiectarea și dezvoltarea reală a SI.

6.5. Implementarea sistemelor informatice

Introducerea SI corporativă, dezvoltată independent sau achiziționată de la un furnizor, este adesea însoțită de o întrerupere (reproiectare) a proceselor de afaceri existente în întreprindere. Trebuie să le reconstruiți pentru a îndeplini cerințele standardelor și logica sistemului implementat. Observăm imediat că introducerea IP rezolvă o serie de probleme manageriale și tehnice, dar naște probleme asociate cu factorul uman.

Introducerea unui sistem informatic, de regulă, facilitează foarte mult managementul unei întreprinderi, optimizează fluxurile de informații interne și externe și elimină blocajele în management. Totuși, după ce sistemul a fost instalat cu succes, „rodat” în funcțiune și și-a demonstrat eficacitatea, unii angajați manifestă o reticență de a folosi IS în munca lor. Ca urmare a reinginerării, devine clar că unii angajați dublează în mare măsură munca altora sau nu sunt deloc necesari. În plus, introducerea CIS este însoțită de pregătire obligatorie, dar, după cum arată experiența rusă, nu sunt atât de mulți care doresc să se recalifice. Spărgerea vechilor abilități și insuflarea altora noi este un proces lung și dificil!

Trebuie să se înțeleagă clar că IP corporativă este concepută pentru a simplifica managementul organizației, a îmbunătăți procesele, a consolida controlul și a oferi beneficii competitive. Numai din acest punct de vedere este posibil să se evalueze beneficiile implementării sale.

Urmând această logică, devine clar că, deși SI-ul corporativ este în general menit să ofere tuturor utilizatorilor informațiile necesare, gestionarea dezvoltării și implementării CIS este apanajul conducerii de vârf a companiei! Înțeleg managerii asta?

Și aici trebuie să se confrunte cu stereotipuri tenace. „De ce am nevoie de un sistem de întreprindere dacă întreprinderea merge bine oricum?” „De ce să spargi ceva dacă totul funcționează?”. Dar de cele mai multe ori nu trebuie spart. În prima etapă, este necesar doar să se oficializeze și să se transfere în mod competent și corect procesele identificate în cadrul cărora întreprinderea trăiește către IS-ul corporativ. O astfel de formalizare nu va face decât să perfecționeze, să șlefuiască descoperirile de marketing și producție de succes, să optimizeze procesul de management și control și să permită efectuarea unor schimbări specifice în viitor.

Introducerea unui nou IS este un proces complex, care durează de la câteva luni pentru SI mici până la câțiva ani pentru SI ale companiilor mari distribuite cu o gamă largă de produse și un număr mare de furnizori. Succesul proiectului pentru dezvoltarea (achiziția) și implementarea SI depinde în mare măsură de disponibilitatea întreprinderii de a conduce proiectul, de interesul și voința personală a conducerii, de un program real de acțiune, de disponibilitatea resurselor, de personal instruit. , și capacitatea de a depăși rezistența la toate nivelurile organizației existente.

Până în prezent, a fost dezvoltat un set standard de metode pentru implementarea IP. Regula principală este de a efectua fazele obligatorii în succesiune și de a nu sări peste niciuna dintre ele.

Următorii factori sunt critici pentru implementare:

• disponibilitatea obiectivelor de proiect clar definite și a cerințelor IP;
• disponibilitatea unei strategii pentru implementarea și utilizarea IP;
• efectuarea unui studiu înainte de proiect al întreprinderii și construirea modelelor „Așa cum este” și „Așa cum va fi”;
• planificarea muncii, resursele și controlul asupra implementării planului de implementare;
• participarea managementului superior la implementarea sistemului;
• efectuarea lucrărilor de implementare a SI de către specialiști în integrarea sistemelor împreună cu specialiști ai întreprinderii;
• monitorizarea periodică a calității muncii prestate;
• primirea rapidă a rezultatelor pozitive, cel puțin în parte din modulele IS implementate sau în procesul de funcționare de probă a acestuia.

Înainte de a începe dezvoltarea unui proiect de implementare, trebuie să:

• formalizează pe cât posibil obiectivele proiectului de implementare a PI;
• estimați costurile și elementele de cheltuieli minime necesare;
• stabiliți o prioritate ridicată pentru proiectul de implementare față de alte proiecte în derulare;
• acordați managerului de proiect cât mai multă autoritate;
• desfășoară activități educaționale în masă cu personalul întreprinderii pentru a aduce tuturor importanța și necesitatea schimbărilor viitoare;
• dezvoltarea măsurilor organizatorice pentru aplicarea noilor tehnologii informaționale;
• distribuie responsabilitatea personală pentru toate etapele implementării și operațiunii de probă.

De asemenea, este necesar să se determine zonele funcționale pentru implementarea modulelor sistemului informațional:

• management organizațional;
• suport organizatoric si administrativ;
• managementul proceselor de afaceri;
• management, planificare, financiar și contabilitate;
• managementul personalului;
• managementul documentatiei;
• managementul logisticii;
• gestionarea relatiilor cu clientii si mediul extern.

În plus față de cele enumerate mai sus, este necesar să se stabilească cerințe tehnologice pentru implementarea SI:

• platformă de sistem: implementare și adaptare a unei soluții gata făcute de la producător sau dezvoltare personalizată în conformitate cu specificațiile tehnice ale clientului.
• integrabilitate: datele sunt stocate și procesate într-un singur spațiu informațional- acest lucru asigură integralitatea, consistența, fiabilitatea și reutilizarea acestora; sistemul poate include tehnologii și aplicații nou dezvoltate și deja utilizate.
• adaptabilitate: sistemul este configurat în conformitate cu cerințele clientului și cu caracteristicile câmpului de informații al clientului.
• distribuție: sistemul poate funcționa eficient în divizii și sucursale ale întreprinderii îndepărtate geografic.
• scalabilitate: sistemul poate fi implementat ca un cadru care conține module de bază și completat în conformitate cu cerințele unui mediu extern și intern în schimbare.

Principalele faze ale implementării sistemului informațional

Etapa „Lucrări preliminare la pregătirea proiectului de implementare a PI”. În timpul studiului înainte de proiect al întreprinderii (Fig. 6.1.4), se colectează informații detaliate despre organizarea structurală a organizației, relațiile funcționale, sistemul de management, despre principalele procese de afaceri, despre fluxurile din cadrul întreprinderii (Flux de control, Doc Flow, Data Flow, Work Flow, Cash Flow) necesare pentru a construi modelele adecvate și a selecta obiecte pentru automatizare. Sunt estimate termenii, resursele, tipurile și volumele de muncă, gama și costul software-ului, hardware-ului și telecomunicațiilor, costul pregătirii personalului etc.

Faza „Pregătirea proiectului”. După finalizarea primei faze, se realizează planificarea preliminară și formarea procedurilor de lansare a proiectului:

• formarea de proiecte și grupuri de experți;
• repartizarea puterilor și responsabilităților;
• determinarea cerințelor organizatorice și tehnice pentru procesul de implementare;
• clarificarea specificațiilor și a așteptărilor clienților;
• instruirea grupului de implementare, format din specialiști din întreprinderea clientului.

Ultima este foarte punct important din anumite motive, este adesea omis atunci când se elaborează un plan de implementare. Dar succesul întregului proiect depinde în mare măsură de el! După începerea finanțării, proiectul se consideră lansat spre execuție.

Faza „Implementarea proiectului”. În timpul lucrărilor principale de implementare, mediul de sistem este creat, instalat și configurat, sunt determinate procedurile de administrare a sistemului și sunt instalate principalele sisteme și aplicații software și hardware. Sistemul stabilește structurile organizatorice și de personal, precum și structurile organizatorice și funcționale ale întreprinderii folosind astfel de unități organizatorice ca ramură, departament, departament, grup de lucru etc.

Se realizează instalarea, configurarea și configurarea instalațiilor de rețea și telecomunicații, datele sunt transferate de la sistemele locale anterioare și se formează interfețe cu sistemele vechi și externe. În același timp, toate modelele create, planurile, produsele software de lucru, documentația sunt plasate în depozitul end-to-end al proiectului de implementare (Fig. 6.17).