Cap

1

3.ARHITECTURA SISTEMELOR INFORMATIONALE SI MODELAREA IN MANAGEMENT Obiective : 1.Elemente formale si arhitecturale in realizarea SI, pe durata ciclului de viata 2.Bazele modelarii intr-o firma orientata pe realizarea de produse si servicii 3.Tipurile de fluxuri si factorii de productie utilizati in productie 4.Grade si niveluri de abstractizare folosite in modelare (elemente/instantieri, clase, meta-clase) 5.Arhitectura SI si realizarea lor ca sisteme deschise 6.Standarde utilizate in modelarea SI

2

Arhitectura, în cadrul sistemelor informaţionale (SI), se poate defini ca un cadru general în care se prezintă corelarea diferitelor componente care stau la baza construcţiei SI, prin proprietăţile funcţionale şi tipologia lor. Dacă în primele două capitole s-au prezentat principalele noţiuni, concepte şi tendinţe, legate de precizarea rolului SI în management, în acest capitol se va urmării prezentarea modului în care problematica managementului şi a proceselor decizionale este descrisă şi specificată, pentru a corespunde cât mai precis utilizării posibilităţilor oferite de noile tehnologii informaţionale şi de comunicare (TIC). Această descriere şi specificare a problematicii managementului, o numim modelare, urmărind obţinerea soluţiilor impuse de managementul modern, prin utilizarea standardelor ţi orientărilor bazate pe noile TIC. Ţinând seama de diversitatea formelor în care se prezintă modelarea problematicii managementului, în raport cu utilizarea tehnologiilor informaţionale şi de comunicaţii, se face opţiunea pentru o prezentare inspirată din ceea ce considerăm a fi o lucrare de succes [SCHE 99], mai ales ca formalismul şi elementele de arhitectură folosite, rezultă din pragmatismul asocierii lor cu produse software standard şi metodologii, standarde şi norme, folosite de cele mai reprezentative firme din domeniul TIC în lume (ORACLE, SAP, IBM, SUN etc.). În Figura3.1 se prezintă structura conexiunilor între problematica managementului, descrierea cerinţelor necesare pentru SI, specificaţiile de proiectare şi construcţia ce rezultă din acestea pentru SI, urmate de problematica implementării, exploatării şi dezvoltării în timp. În acest mod este ilustrat şi ciclul de viaţă al SI.

Definirea cerintelor cu suport TIC

Specificatiile de proiectare si constructia SI

Cerintele puse de problemele managementului unei firme

Potentialul TIC în rezolvarea problemelor de management ale unei firme

Problematica managementului unei firme

Implementarea, exploatarea si dezvoltarea SI

Tehnologiile informationale de comunicatii

Figura 3.1. Structura conexiunilor în realizarea SI pentru management pe durata ciclului de viaţă a SI

3

Cele trei etape de bază ale ciclului de viaţă, vor fi analizate în detaliu în capitolele următoare, pentru a încerca să sugerăm soluţii privind reducerea eforturilor în realizarea, implementarea, exploatarea si dezvoltarea SI. Până în anii `90, efortul principal se concentra în primele doua etape (1 şi 2).Etapa a treia (3) şi parţial a doua, ca efort, se află în raport de 5:1 cu prima. Acest raport era impus de conţinutul, profesionalismul şi de responsabilitatea celor care erau implicaţi în analiza firmei, în definirea cerinţelor şi orientarea concepţiei în proiectarea SI, profesiile din această zonă aflându-se în partea superioară a scării valorii (analiştii şi proiectanţii de sisteme şi aplicaţii complexe, bazate pe TIC). După anii `90 a căpătat o mare amploare utilizarea software-ului standard, a mediilor de programare, a metodelor şi instrumentelor profesionale, care au redus costurile elaborării şi implementării programelor. Aceeaşi tendinţă s-a manifestat şi pe prima parte a ciclului de viaţă, prin utilizarea modelelor de referinţă şi a tehnicilor de evaluare a specificaţiilor tehnice de detaliu, a documentaţiilor. Conceptul ARIS ( Architecture of Integrated Information Systems) la care facem referinţă în acest capitol, are succes deoarece include metodele şi instrumentele (ARIS Toolset) care permit abordarea sistematică pe ansamblul etapelor de realizare a SI, urmărind ritmul implementării şi reducând efortul de adaptare a software-ului standard. Ceea ce Prof. Scheer A.W. numeşte „ARIS house of business engineering” (HOBE), asigură realizarea unei arhitecturi a managementului firmei, folosind fluxurile informaţionale şi de cunoaştere specifice, strâns legate de software-ul standard („building blocks ”/ business objects). După o prezentare a bazelor modelării într-o firmă, se va trece la definirea arhitecturii SI integrate (ca fluxuri informaţionale şi materiale), cu orientările şi elementele de standardizare specifice SI. 3.1.Bazele modelării într-o firmă orientată pe realizarea de produse şi servici Pentru implementarea SI, folosind TIC, trebuie în primul rând realizat un model pentru procesele ce caracterizează ansamblul activităţilor firmei. În realizarea unui produs, se parcurg diferite etape, în timp, care presupun următoarele conexiuni (corelări), aşa cum se arată în Figura 3.2: - o comandă este preluată de la un client pe baza unei analize a posibilităţii de a fi realizat produsul în condiţiile impuse de client; comanda acceptată, declanşează un proces de aprovizionare, în relaţie cu furnizorii şi o planificare a fabricaţiei, pe baza graficului convenit de aprovizionare şi a disponibilităţii capacităţii de fabricaţie; - fabricaţia se realizează conform planificării şi programării realizării produsului pe liniile de fabricaţie; - expedierea produsului la client, după fabricaţie, testare şi certificare. Pentru realizarea unui serviciu, conexiunile sunt similare, fabricaţia fiind înlocuită de realizarea lui, iar expedierea cu acceptarea lui de către client.

4 Produsul comandat Comanda

Client (Piata)

Fonduri

Marketing (Vânzari)

Comanda de fabricatie

Dispozitie pentru aprovizionare

Fabricatie

Livrare produs

Expeditie si livrari

Livrarea materialelor si subansamblelor Comanda

Aprovizionare

Fonduri

Furnizori

Figura 3.2. Sistemul de conexiuni în realizarea unei comenzi pentru un produs Reţinând ceea ce este general în sistemul de conexiuni prezentat, ne putem referi la: • unităţile organizatorice reprezentate de clienţi, firmă şi furnizori; • conexiuni care pot fi de natură informaţională, nemateriale (cum ar fi informaţiile care se schimbă reciproc între unităţi, inclusiv plăţile prin documente), sau de natură materială (cum ar fi materiale şi subansamblele aprovizionate de la furnizori şi produsele expediate clienţilor, însoţite de documente şi documentaţii). În această generalizare sau formalizare a conexiunilor, care sunt necesare realizării unui produs, putem remarca trei tipuri de fluxuri: - un flux al funcţiilor (activităţilor), care sunt asociate cu diferite unităţi în care se află resursele (umane, materiale) necesare realizării lor; - un flux al ieşirilor, care se realizează ca urmare a unei activităţi, în interiorul firmei, între diferite unităţi şi în relaţiile cu clienţii şi furnizorii; - un flux informaţional, prin care se realizează servicii de informare la cerere sau programate, între unităţi, în cadrul firmei sau cu mediul exterior (clienţi, furnizorii, bănci etc.) Oricare din aceste fluxuri nu poate modela complet activităţile unei firme, de aceea este nevoie de o integrare şi asociere a lor în funcţie de cerinţele care se impun în spaţiu şi timp. De obicei, ca bază este folosit fluxul funcţiilor, asociat activităţilor de bază care se realizează în unităţile organizatorice ale firmei. Orientarea de tip obiect sau agent, care se va prezenta în capitolele următoare, poate fi considerată de baza, de asemenea, în cadrul fluxurilor informaţionale. În realitate, fluxurile prezentate mai sus au o complexitate care necesită o analiză aprofundată a realităţii, urmată de o simplificare şi o generalizare a ei printrun sistem care sa permită valorificarea mediilor de programare folosite la implementarea SI. De exemplu, în fluxul funcţiilor avem o mulţime de evenimente, care se referă la condiţiile de realizare a activităţilor asociate unei funcţii, care se pot prezenta prin expresii relaţionale simple (cu operatori logici elementari) sau complexe (cu asocieri de operatori logici şi relaţionali). Evenimentele comunică între ele (început, sfârşit)

5

prin mesaje, care se constituie intr-un flux de control al execuţiei activităţilor şi funcţiilor. Un eveniment poate fi „plan de fabricaţie realizat”, sau altul „comandă de aprovizionare asigurată”, acestea asociindu-se prin operatorul logic „SI”, în declanşarea evenimentului „fabricaţie produs”, condiţionat de realizarea simultană a celor două evenimente care îl preced. La realizarea unui produs, se pot evidenţia evenimentele majore care determină realizarea lui în cadrul unui flux funcţional, care reprezintă cheia modelării, fiind nominalizat distinct ca „lanţ al evenimentelor directoare (de bază) în procesul de fabricaţie” (event-driven process chain – EPC). În modelare, trebuie consideraţi factorii de produţie, prin a căror combinare şi utilizare în timp se realizează un produs. În acest sens trebuie să avem în vedere: • resursele operaţionale, reprezentate de maşini, utilaje, inclusiv calculatoare etc.; • resurse umane, asociate ca „intrări” sau „ieşiri” în realizarea produselor sau a unor servicii; • resurse materiale, considerate ca materiale obţinute prin aprovizionare, necesare realizării unui produs; • managementul, care asigură coerenţă în desfăşurarea proceselor pentru obţinerea obiectivelor stabilite. Ţinând seama de evoluţiile din ultimii ani, se poate considera ca factor de producţie informaţia (implicit cunoaşterea). De asemenea, facem remarca legată de noţiunea „proces productiv”, care este asociat în prezent nu numai cu realizarea de produse / obiecte fizice, dar şi a serviciilor, care au ca rezultat un produs intangibil, cum sunt şi informaţia sau cunoaşterea. În ultimii ani, tot mai frecvent, firmele apelează la realizarea unor servicii de către parteneri externi (outsourcing), externalizând serviciile proprii nerentabile, pentru a obţine avantaje competitive faţă de concurenţă. În final, putem spune ca în modelarea proceselor legate de realizarea unui produs sau serviciu intervin următoarele fluxuri: 1. Fluxul organizaţional, ce caracterizează responsabilităţile şi managementul unităţilor organizaţionale componente. 2. Fluxul obiectivelor, conceptuale sau de execuţie, care trebuie atinse prin activităţi, la diferite niveluri. 3. Fluxul de control, destinat urmăririi realizării funcţiilor şi activităţilor prin evenimente şi mesaje. 4. Fluxul ieşirilor, care pot fi tangibile (materiale) sau intangibile (servicii, inclusiv cele financiare, prin documente scrise sau electronice). 5. Fluxul resurselor materiale, reprezentat de maşini, utilaje, roboţi, calculatoare etc. 6. Fluxul resurselor umane, cu toate elementele ce definesc această resursă. 7. Fluxul informaţional, constând din ansamblul informaţiilor (ca intrări/ieţiri) legate de realizarea funcţiilor, obiectivelor şi controlului accesului în sistemul firmei.

6

O generalizare în realizarea modelării proceselor într-o firmă se realizează prin orientarea – obiect, bazată pe abstractizări la diferite niveluri, care pleacă de la natura şi caracteristicile proceselor de bază. Tehnologia orientării obiect şi agent în modelarea şi implementarea SI se va prezenta în capitolul următor, însă acum, pe baza exemplului tratat, ne vom referi la noţiunile de bază ale orientăriiobiect pentru acest exemplu, relativ la o comandă de execuţie a unui produs. În reprezentarea din Figura 3.2, în vederea abstractizării şi generalizării tratării comenzilor de fabricaţie, putem face următoarele aprecieri. - Elementele sau instanţierile, care stau la baza proceselor şi activităţilor, sunt date de caracteristicile clienţilor, furnizorilor, comenzilor, resurselor umane etc. Ansamblul acestor caracteristici constituie mediul descriptiv, al elementelor sau instanţierilor asociate unui nivel superior de abstractizare. - Clasa aplicaţiilor este constituită din elemente sau instanţieri asociate, care o definesc, constituindu-se in nivelul 2, de tip.La acest nivel, clientul, de exemplu, este caracterizat de atribute specifice (cod, nume, adresă, credit de finanţare, interval de plată etc.). Instanţierile clasei client , reprezentate de atributele menţionate, se află la nivelul 1. La nivelul 2 mai putem vorbi de clasele: furnizor, comandă, resursă etc., fiecare cu instanţieri plasate la nivelul inferior. - Meta-clasa, care se constituie pe abstractizările care se pot face în sistemul de relaţii al aplicaţiilor şi care constituie clasele din nivelul 2. În acest fel, clasele devin elemente sau instanţieri ale meta-clasei din nivelul 3. La acest nivel se constituie obiecte pe baza cărora putem instanţia şi opera cu clasele de la nivelul inferior sau cu atribute sau caracteristici de bază, ce constituie instanţieri ale clasei. De exemplu, la nivelul 3 se poate vorbi de „produs material”, bazat pe instanţieri de tipul „materii prime”, „componente”, „subansamble”, din nivelul 2 cu caracteristicile individuale, de bază, din nivelul 1. În acelaşi mod se poate defini meta-clasa „servicii informaţionale” , bazată pe „comandă”, „certificare”, fiecare cu detalii la nivelul 1( comandă preluată, lansată, terminată, certificare realizată / verificată etc.) Gradul de abstractizare poate fi extins la niveluri superioare, pentru care metaclasele devin instanţieri. Această abordare este utilă mai ales când se impun restructurări la nivelul firmei, urmate de modificări ale instanţierilor care se propagă în tot sistemul, pe toate nivelurile de abstractizare. 3.2. Arhitectura sistemelor informaţionale Modelarea proceselor unei firme / organizaţii chiar la nivelul 3 de abstractizare, reprezentat de meta-clase, cu multiplele relaţii care există între clase şi în cadrul fiecărei clase, conduce la structuri complexe, ce pot fi însă reduse prin grupări semantice a acestor relaţii, reprezentând anumite proiectii / vederi asupra proceselor / activităţilor. Deoarece implementarea modelelor se face prin TIC, meta-clasele si clasele trebuie transformate în obiecte specifice sistemelor informaţionale (SI), etapă cu etapă, pe tot ciclul lor de viaţă. Descrierea acestor

7

obiecte ce compun SI, trebuie realizată într-un limbaj cât mai general, care sa unifice modul de descriere şi prezentare a modelelor, folosind metodologii specifice. 3.2.1 Gruparea claselor şi relaţiilor Gruparea claselor şi relaţiilor pe baza unor criterii definite prin „similarităţi de corelare semantice”, reprezentând proiecţii sau puncte de vedere, le vom numi viziuni, utilizabile atunci când se pune problema implementării, folosind TIC. Aceste viziuni se pot realiza pe baza fluxurilor definite în paragraful 3.1: - Viziunea funcţională, în care noţiunile de funcţie, proces şi activitate sunt folosite ca sinonime, fiind caracterizate de un scop/obiectiv, realizat ca ieşire, pe baza unor intrări. În acest fel, de exemplu, software-ul aplicativ, prin care se asistă realizarea proceselor şi activităţilor, este asociat acestei viziuni. - Viziunea organizaţională, în care se defineşte o structură ierarhică, cu scopul de a fixa responsabilităţile în execuţia diferitelor obiecte. Aceste entităţi cu responsabilitate în execuţie pot fi diferite unităţi organizaţionale, cu rezultatele (ieşirile) obţinute din utilizarea resurselor umane, maşinilor/ utilajelor, resurselor financiare. - Viziunea asupra prelucrării datelor, care se referă la funcţiile ce definesc mediul de prelucrare a datelor / informaţiilor / cunoaşterii, asociat cu obiecte specifice, cu mesaje ce pot caracteriza serviciile informaţionale necesare în SI. - Viziunea asupra ieşirilor, („produselor”, în engleză outputs) care se referă la intrările şi ieşirile tangibile şi intangibile care intervin în realizarea diferitelor funcţii, inclusiv cele privind resursele financiare - Viziunea asupra controlului, care se referă la relaţiile care există între diferitele viziuni, în creearea unui cadru de verificare sistematică a relaţiilor bilaterale ce intervin în descrierea proceselor, activităţilor sau exercitarea funcţiilor în sistem. Dacă primele patru proiecţii sau viziuni se referă în principal la structura statică a sistemului, controlul asigura coerenţa acestei structuri în timp, prin aspectele dinamice ale diferitelor fluxuri. Se obţine în acest mod o viziune de ansamblu asupra modelării denumită „ARIS house” în [SCHE99] cu o reprezentare simplificată în Figura 3.3. 3.2.2.Arhitectura bazata pe TIC Prezentarea arhitecturii SI făcută până acum, s-a bazat mai mult pe o viziune asociată managementului, fară a ne referi la tehnologiile informaţionale şi de comunicaţii decât în termenii generali, folosind numai noţiunile de calculator, program aplicativ, prelucrarea datelor, fară a preciza conţinutul lor.

8

Viziunea organizationala (unitati organizationale, resurse etc.)

Viziunea asupra prelucrarii datelor (mediu de prelucrare, mesaje etc.)

Viziunea asupra controlului si desfasurarii în timp a proceselor

Viziunea functionala (obiective, functii, software aplicativ etc.)

Viziunea asupra iesirilor produselor (intrari si iesiri tangibile sau intangibile)

Figura 3.3. Gruparea claselor şi relaţiilor pe baza unor proiecţii/viziuni în cadrul „ARIS house” Dacă se are în vedere structura de realizare a SI pe toată durata ciclului de viaţă din Figura 3.1, putem construi „ARIS house” cu evidenţierea principalelor faze care trebuie parcurse în conceperea, proiectarea şi implementarea celor cinci componente ale acestei construcţii, prezentate în Figura 3.3, obţinând astfel o reprezentare pe faze a modelării firmei, utilizând TIC. În acest mod, plecând de la viziunea arhitecturală a claselor şi relaţiilor, se parcurg etapele care transformă obiectivele strategice ale firmei, în obiecte construite şi implementate pe baza noilor tehnologii informaţionale şi de comunicaţii (TIC): • Stabilirea orientării strategice în realizarea obiectivelor, tinând seama de potenţialul oferit de noile TIC. De exemplu, se poate stabili un mod de funcţionare a firmei ca organizaţie virtuală, în cadrul unui cluster, folosind celule flexibile de fabricaţie sau sisteme de fabricaţie integrate pe baza de calculator, cu un sistem integrat, cu mare distribuţie geografică, pentru desfacere. • Definirea cerinţelor pentru toate aplicaţiile, în detaliu, ţinând seama de modelele realizate şi folosind un limbaj de descriere a corelaţiilor între diferite obiecte şi clase, cât mai aproape de posibilitatea utilizării noilor TIC. • Conceperea SI şi realizarea specificaţiilor de proiectare, pe baza descrierii cerinţelor şi a modelelor avute în vedere la etapa precedentă. În această fază se vor folosi metodologii şi instrumente bazate pe TIC, în structura aplicaţiilor, a

9

datelor, informaţiilor şi cunostiinţelor necesare acestora, a interfeţelor cu diferite categorii de utilizatori(locali sau la distanţă) etc. • Descrierea implementării, cu documentarea şi pregătirea unei infrastructuri hardware şi software adecvată specificaţiilor de proiectare, cu procurarea produselor TIC standard şi pregătirea utilizatorilor pentru asimilarea lor . • Exploatarea şi întreţinerea SI, care se realizează dupa implementarea şi pregătirea personalului în vederea trecerii la noul sistem. Din exploatarea noului sistem pot rezulta anomalii şi cerinţe de îmbunătăţire-dezvoltare care pot impune corecţii în concepţie-proiectare, sau chiar în faza de definire a cerinţelor. Dezvoltarea SI se poate realiza pe baza unor orientări strategice noi şi ca urmare a apariţiei unor TIC mai performante. O prezentare a ceea ce s-a numit „ARIS house”, pe baza etapelor şi fazelor ce caracterizează construcţia asociată acestei arhitecturi, se face în figura 3.4. Strategia si executia generala a SI

Definirea cerintelor Conceptie si proiectare Implementare si operare

Definirea cerintelor

Definirea cerintelor

Definirea cerintelor

Conceptie si proiectare

Conceptie si proiectare

Conceptie si proiectare

Implementare si operare

Implementare si operare

Implementare si operare

Definirea cerintelor Conceptie si proiectare Implementare si operare

Tehnologiile informationale si de comunicatii

Figura 3.4. Arhitectura „ARIS house”, cu realizarea SI pe etape şi faze

10

În această prezentare s-au avut în vedere primele trei etape ale realizării SI şi parţial etapa a 4-a, cu faza de demarare a operării sau a punerii în funcţiune, urmată de exploatare şi dezvoltare, ca fiind etapele esenţiale în construcţia SI. Se remarcă de asemenea conexiunile cu cerinţele orientării strategice a firmei şi evoluţiile în domeniul TIC, cu o dinamică ce impune realizarea SI ca sistem deschis, capabil sa preia atât cerinţe noi, cât şi dezvoltări curente impuse de sistem prin exploatare sau de apariţia unor noi TIC 3.3 Standarde privind modelarea în SI Din câte am văzut până acum, modelarea urmăreşte descrierea activităţilor întro firmă/organizaţie, pe bază unui proces creativ şi pe baza unor reguli şi convenţii general acceptate. În acest sens, se vorbeşte despre „principii general acceptate în modelare”, care au rezultat din proiecte de cercetare, fiind susţinute de instrumente suport pentru realizarea lor [ex. ARIS tools]. Între aceste principii amintim [SCHE99]: - Principiul corectitudinii, care se referă la semantica şi sintaxa modelelor, specificate prin studii de simulare - Principiul relevanţei, referitor la cantitatea de informaţie necesară modelării, care nu trebuie să depăşească anumite limite de acceptabilitate - Principiul clarităţii, prin care se asigură inţelegerea şi utilizarea lui de către destinatar - Principiul respectării unui raport cost/beneficiu acceptabil, pentru a motiva utilizarea modelului pe o perioadă de timp cât mai lungă - Principiul comparabilităţii, prin care se asigură că modelele create prin diferite limbaje şi meta-modele rezultate, pot fi comparate - Principiul structurii sistematice, prin care se asigură integrarea modelelor realizate pe baza unor viziuni diferite, deci creearea unui meta-model dezvoltat pe baza mai multor viziuni  Conceptul ARIS prezentat, a fost gândit să fie independent de aplicaţie la nivelul 3 (meta-nivel) unde se pot constitui obiecte tip, cu instanţieri la nivelurile inferioare: • nivelul 3 (meta-level) cu modelele de tip pentru: unitate organizaţională funcţie, entitate, proces/control, ieşire; • nivelul 2 (application-level) cu: filiala, comandă, client, prelucrare comandă, produs; • nivelul 1 (instance-level) cu elemente de concretizare pentru filială, comandă, client, produs.  Conceptul

CIMOSA (Computer Integrated Manufacturing Open System Arhitecture ) a urmărit realizarea unei arhitecturi şi metodologii pentru furnizorii independenţi, având ca rezultat ceea ce se numeşte „CIMOSA cube”, prezentat în Figura 3.5. În acest cadru de modelare se disting trei dimensiuni:



11 -

Dimensiunea orizontală se referă la conceptualizarea treptată, exprimată de cerinţe generice, cerinţe parţiale cu specific de ramură şi cerinţe particulare pentru o firmă / organizaţie dată Instantieri / Particularizare

Niveluri pentru faze de realizare

sis Vizi tem une ulu a a i in sup for r ma a tio na l

Generice Organizare (O) Resursa (R) Informatie (I)

Partiale

Viziune (O) Viziune (R)

Viziune (I)

Functie (F)

Viziune (F)

Nivelul de modelare pt. determinarea cerintelor (DC)

Blocuri constructive generice pentru DC

Odele partiale pentru DC

Modele particulare pentru DC

Nivelul de modelare pentru conceptie si proiectare specificatii (CPS)

Blocuri constructive generice pentru CPS

Odele partiale pentru CPS

Modele particulare pentru DC

Blocuri constructive generice pentru I

Odele partiale pentru I

Modele particulare pentru DC

Nivelul de modelare pentru implementare (I)

Particulare

Arhitectura de referinta

Arhitectura particulara

Figura 3.5. Arhitectura de modelare CIMOSA Dimensiunea verticală se referă la modelele corespunzătoare celor trei faze de realizare a SI: de definire a cerinţelor, de concepţie şi proiectare specificaţii şi de implementare - Dimensiunea a 3-a, de profunzime, se referă la diferite viziuni asupra SI: organizaţională, asupra resurselor, asupra informaţiei şi asupra funcţiilor, cu semnificaţia prezentată şi în conceptul ARIS. În conceptul CIMOSA metodele de modelare sunt clasificate şi descrise prin meta-modele, asemănătoare modelelor procedurale din ARIS, orientate pe evenimente şi procese (EPC), fapt ce conduce la considerarea întreprinderii ca ansamblu de agenţi multipli care comunică între ei. Această tehnologie ca şi cea orientată obiect, se prezintă în capitolul următor. Conceptul CIMOSA, neavând o susţinere cu un set de instrumente de implementare, nu a căpătat o răspândire comparabilă cu ARIS. Ţinând seama de amploarea pe care a luat-o cerinţa de certificare a calităţii în realizarea de bunuri şi servicii, „sistemele de management al calităţii (QM)”, prezintă un interes deosebit. În acest sens, standardele ISO 900X si ISO 14000 sunt adaptate frecvent, de aceea vom prezenta o analiză a implementării lor folosind un model procedural pentru SI susţinut de un set de instrumente ARIS [SCHE99]. -

12  Modelul

procedural pentru certificarea sistemelor QM, constă din descrierea a opt faze esenţiale care se înlănţuie, începând cu planificarea strategică în firmă şi terminând cu realizarea sistemului TQM (Total Quality Management) aşa cum se arată şi în Figura 3.6: 1. Analiza strategiei firmei, care se exprimă prin obiectivele strategice, a mediului în care se desfăşoară activităţile, a domeniului de activitate, cu o concluzie asupra modului în care se face certificarea pentru asigurarea unui management al calităţii totale (TQM), ca un obiectiv strategic. 2. Pregătirea pentru managementul calităţii, care se referă la pregătirea personalului în legătură cu asimilarea standardelor şi normelor privind asigurarea calităţii, în special ISO 900X şi ISO 10014, referitor la efectele economice ale calităţii pentru a motiva personalul. În această faza, se numeşte managerul pentru calitate şi se defineşte politica pe care acesta o va aplica în realizarea TQM. 3. Analiza sistemului existent în QM,(QM As-Is-Study), care presupune evaluarea documentelor existente în sistemul QM, cu o confruntare a lor în Analiza strategiei QM

Pregatire pentru QM

Analiza sistemului existent QM

Definirea conceptiei de realizare

Managementul total al calitatii TQM

Certificarea sistemului QM

Aplicarea si verificarea sistemului QM

Definirea structurii sistemuluiQM

Figura 3.6. Fazele modelului procedural pentru sistemul de asigurare a calităţii

raport cu standardele internaţionale din domeniul de activitate şi cu evidenţierea necesităţilor de viitor, cu propuneri de restructurare a proceselor existente şi definirea altora noi în cadrul SI al firmei. 4. Definirea concepţiei de realizare a QM, prin evidenţierea cerinţelor de calitate plecând de la clienţi, pe diferite niveluri şi în cadrul lanţului sau traseului valorii-adăugate, cu sublinierea proceselor cheie în cadrul EPC (Event-driven Process Chain) şi a responsabilităţilor în unităţile organizaţionale. Se are în vedere, în sinteză, succesiunea: Organigrame → lanţul valorii adăugate → EPC 5. Definirea structurii sistemului QM, conform arhitecturii de modelare a

firmei, cu o parcurgere top-down pe lanţul valorii şi evidenţiind procesele esenţiale care vor fi ilustrate în EPC. În această fază, din fiecare funcţie evidenţiată în EPC şi pentru fiecare pas în desfăşurarea proceselor, se definesc responsabilităţi la nivelul fiecărei unităţi organizaţionale, aşa cum se ilustrează în Figura 3.7. Modelul organizaţional, după cum se vede, se află într-o corespondenţă directă cu procesele, ceea ce evidenţiază direct responsabilităţile pentru fiecare activitate în cadru sistemului QM, în mod

13

diferit (ca execuţie a unei funcţii, ca responsabilitate pentru execuţie, ca informare despre acea funcţie etc.). 6. Aplicarea şi verificarea sistemelor QM, începe imediat după ce s-au stabilit toate procedurile şi documentele impuse de standardul de calitate. În această fază se derulează în primul rând auditul intern, cu scopul de a obişnui personalul cu noul sistem şi documentaţia necesară sau eliminarea erorilor care pot apărea. Prin această activitate se poate ajunge şi la propuneri de dezvoltare prin îmbunătăţirea sistemului existent. După această fază, se trece la certificare. 7. Certificarea sistemului QM, se face pe baza unui contract cu o organizaţie acceptată sau acreditată pentru această operaţie. La început se face o preauditare şi după aceea verificarea îndeplinirii cerinţelor de calitate impuse de standard. Certificarea este valabilă 3 ani, cu verificări anuale prin încercări, din partea certificatorului. Recertificarea la 3 ani, subliniază importanţa menţinerii documentaţiei la zi. 8. Managementul Total al Calităţii (TQM), corespunde stabilirii unei obişnuinţe în firmă pentru asigurarea calităţii ţinând seama în permanenţă de cerinţele clienţilor. Acest mod de lucru obligă la dezvoltării continuii, printr-o atitudine critică faţă de activităţile si procesele curente.  Standardul STEP (STandard for the Exchange of Product Model Data), destinat

definirii modelului de date pentru produs este cuprins în norma ISO 10303. Prin această normă s-a urmărit asigurarea şi reprezentarea datelor / informaţiei despre un produs în cadrul integrării proceselor de concepţie, proiectare, fabricaţie, întreţinere şi dezvoltare a produselor, asigurând baza trecerii de la „întreprinderea închisă” la o întreprindere extinsă sau virtuală (se prezintă într-un capitol următor), în care există posibilitatea partajării resurselor de tipul date / informaţii / cunoaştere,între unităţile organizaţionale amplasate pe arii geografice mari. Originalitatea standardului constă in promovarea a două idei complementare: o proiectarea şi realizarea / fabricaţia produselor trebuie să se realizeze în jurul unei baze de date / informaţii complete, unice, partajată de către toţi cei care au responsabilităţi în desfăşurarea proceselor (persoane sau maşini); o conţinutul semantic al informaţiei partajate trebuie sa constituie obiectul unei reprezentări structurate, uşor de recunoscut de către toţi cei care partajează această resursă (persoane sau maşini). Arhitectura care se bazează pe aceste idei trebuie să fie deschisă, iar aplicaţiile trebuie sa partajeze resursele informaţionale comune fără intervenţia umană. Această arhitectură se prezintă în Figura 3.8, în care sunt evidenţiate trei niveluri:

14 Schema interna

Nivel fizic

Protocol de aplicatie Model conceptual general

Baza de date/ informatii

Schema interna

Nivelul fizic

Nivelul logic

Protocol de aplicatie

Nivelul aplicatie

Figura 3.8. Arhitectura generală STEP - Nivelul aplicaţie, care conţine descrierea particulară a unui domeniu sau aplicaţie dată, din punct de vedere al utilizatorului, în forma unor aşa numite protocoale de aplicaţie (aplicarea normei STEP la o aplicaţie dată). Această descriere se referă la: • un caiet de sarcinii (specificaţii) care defineşte aplicaţia; • un model de referinţă al aplicaţiei bazat pe o analiză a semanticii ei; • un model de aplicaţie, reprezentând o corespondenţă între modelul de referinţă şi modelul conceptual; • criteriile de testare a conformităţii la verificarea soluţiilor software ce corespunde implementării protocolului aplicaţiei. O ilustrare a acestui nivel, care în arhitectura generală apare ca „protocol de aplicaţie”, se prezintă în Figura 3.9: - Nivelul logic, care conţine modelul conceptual general, cu informaţii despre produs, în cadrul unor descrieri formale neambigue şi neredundante. Acest model constituie referinţa de definire a tipurilor de date, de calităţi, atribute, funcţii, proceduri şi reguli, validată cu ajutorul limbajului EXPRESS. - Nivelul fizic, care conţine schemele interne de realizare pentru fiecare utilizator / aplicaţie şi „mediu maşină”, destinat implementării aplicaţiei. Acest nivel este definit prin două straturi: unul logic, independent de suportul fizic al datelor – informaţiilor, reprezentând de fapt o „corespondenţă” (tabel) între modelul de referinţă şi cel interpretat, precum şi un strat fizic ce corespunde caracteristicilor fizice particulare ale suportului fizic utilizat.

15

Nivelul aplicatie

Utilizatori (domenii, meserii)

Specificatii Model de activitati Model de referinta

Tabel de corespondenta

Nivelul logic

Nivelul fizic

Model conceptual general

Format fizic (stratul logic si fizic)

Model de interpretare

Criterii de conformitate la implementare

Figura 3.9. Structura protocolului de comunicaţie în arhitectura STEP Protocolul de comunicaţii prezentat ca structură în Figura 3.9, trebuie să precizeze: • domeniul acoperit şi contextul utilizării; • definirea datelor / informaţiilor, văzute de utilizator ca model de referinţă; • specificarea elementelor de bază pentru testele de conformitate; • ansamblul resurselor utilizate şi completările necesare pentru a satisface cerinţele particulare Rolul normei STEP, de a oferi o soluţie tehnică generală pentru schimburile de date / informaţii, se consideră a fi dificil, datorită limitărilor capacităţii umane de a face sinteze de subansamble (în abordarea „down top”) şi de a preveni un proces natural divergent, prin specificaţii care au nevoie de protocoale. În plus, această normă nu are asociat un set de instrumente, cum este cazul modelului ARIS, care sa faciliteze utilizarea unor produse software standard de largă utilizare. ***********************

Termeni si notiuni de baza • • • • • •

Arhitectura SI Modelarea SI Fluxuri (utilizate in modelare) Conexiuni Lant de evenimente (FPC – Event-driven Process Chain) Elemente si instantieri

• • • • • • • •

16 Clase Meta-clase si obiecte Clase si relatii pe baza de proiectii Arhitectura ARIS House Principii in modelare Arhitectura de modelare CIMOSA Modelul procedural pentru certificarea sistemelor QM Standardul STEP

Intrebari si teme recapitulative 1.Cum definiti arhitectura SI ? 2.Cum definiti modelarea intr-o firma ? 3.Ce tipuri de fluxuri si factori de productie se folosesc in modelare ? 4.Definiti clasele si nivelurile de abstractizare folosite in modelare ! 5.Prezentati cateva arhitecturi de referinta folosite in modelare sau standarde utilizate in realizarea SI !

Tema de casa Identificati sistemul de conexiuni si tipurile de fluxuri folosite in realizarea unui produs sau serviciu pe baza de comanda.

***********************************