Material de sinteză privind conceptul de intreprindere virtuală şi modul de implementare a mecanismelor care susţin funcţionarea acesteia

Transcription

1 Investeşte în oameni! Proiect cofinanţat din Fondul Social European prin Programul Operaţional Sectorial Dezvoltarea Resurselor Umane Axa prioritară 2 Corelarea învăţării pe tot parcursul vieţii cu piaţa muncii Domeniul major de intervenţie 2.1 Tranziţia de la şcoală la viaţa activă Cod contract: POSDRU/90/2.1/S/64051 Titlul proiectului: Învaţă Automatica Beneficiar: Universitatea Tehnică din Cluj-Napoca Material de sinteză privind conceptul de intreprindere virtuală şi modul de implementare a mecanismelor care susţin funcţionarea acesteia pag. 1 / 109

2 Partenerul P5, SC IPA SA, dispune de cunoştinţe avansate privind intreprinderile virtuale, cunostinţe care au fost dobândite în activitatea de cercetare desfasurată. Partenerul a coordonat proiectul denumit Platformă Inteligentă Colaborativă pentru Dezvoltarea şi Susţinerea Mecanismelor Intreprinderilor Virtuale INVITE care s-a desfăşurat pe baza unui parteneriat cu: Universitatea Tehnică din Cluj-Napoca, Universitatea Babea Bolyai Cluj-Napoca şi SC HyperMedia SRL in cadrul PNCDI II - Programul PARTENERIATE IN DOMENIILE PRIORITARE. Una din acţiunile de diseminare ale rezultatelor acestui proiect este constituită de acest material de sinteză care prezintă pentru studenţii automatişti implicaţi în proiectul Învaţă Automatica: o analiză comparativă a conceptelor, tehnologiilor şi soluţiilor privind platformele de dezvoltare ale intreprinderilor virtuale; consideraţii privind proiectarea şi implementarea unor unelte software care gestioneză funcţionarea unei intreprinderi virtuale din domeniul transferului tehnologic. Noţiunile cuprinse în acest material vor fi utile atât automatiştilor care îşi vor desfăşura activitatea în astfel de nuclee virtuale cât şi celor care vor dezvolta software care să le deservească. pag. 2 / 109

3 CUPRINS 1. Prezentarea conceptului de intreprindere virtuală, a tehnologiilor şi soluţiilor privind platformele de dezvoltare Conceptul întreprinderii virtuale Caracteristici cheie ale întreprinderii virtuale Principalele elemente ale Intreprinderii Virtuale Procesul de restructurare în întreprinderea virtuală. Rutine de schimbare Analiza conceptelor de business în cadrul întreprinderilor virtuale Conceptul de Enterprise Architecture Modelarea unei firme virtuale folosind Entreprise Arhitecture Modele de management a proceselor de business Tipuri de întreprinderi virtuale Proiecte europene care au studiat cadrul legal al întreprinderilor virtuale Analiza comparativă a tehnologiilor de dezvoltare a întreprinderilor virtuale Analiza tehnologiilor de proiectare şi dezvoltare a proceselor de business în cadrul unei întreprinderi virtuale Aplicaţii pentru managementul conţinutului informaţional şi a fluxului operaţional Tehnologii web utilizate în dezvoltarea sistemelor de tip întreprindere virtuală Tehnologii multimedia utilizate în dezvoltarea sistemelor de tip întreprindere virtuală Tehnologii agenţi inteligenţi, multi-agent în formarea şi operarea întreprinderilor virtuale Arhitecturi utilizate în dezvoltarea sistemelor de tip întreprindere virtuală Proiectarea sistemelor de tip IV având la bază arhitectura multi-tier Proiectarea sistemelor de tip IV având la bază arhitectura SOA Proiectarea sistemelor de tip IV având la bază arhitectura LAMP Prezentarea unor soluţii de intreprinderi virtuale existente pe plan mondial Proiectul AVE (Agents in Virtual Enterprises) C(ollaborative)-Project GLOBEMEN Concluziile capitolului Consideraţii privind implementarea unei platforme integrate care susţine funcţionarea unei intreprinderi virtuale Privire de ansamblu asupra cerinţelor platformei integrate Cerinţe generale ale platformei INVITE din punct de vedere tehnic Cerinţe generale ale platformei INVITE din punct de vedere al funcţionalităţilor oferite utilizatorilor Cerinţe specifice privind sistemele multiagent în cadrul platformei INVITE Definirea cerinţelor şi proiectarea componentelor Web interactive Modelul Rich Internet Application (RIA) Modelul experimental pentru colaborare interpersonală şi interprocese Cerinţe specifice privind componentele de suport colaborativ Cerinţe specifice privind sistemele de asistare a deciziilor Cerinţe specifice privind managementul workflow-ului şi al proceselor de afaceri Definirea funcţiilor de anvelopă. Condiţii tehnice Concluziile capitolului Bibliografie pag. 3 / 109

4 1. Prezentarea conceptului de intreprindere virtuală, a tehnologiilor şi soluţiilor privind platformele de dezvoltare 1.1. Conceptul întreprinderii virtuale Există în literatura de specialitate mai multe definiţii pentru întreprinderea virtuală, dintre care cele mai des utilizate şi acceptate sunt: - Întreprinderea virtuală (IV) se bazează pe abilitatea de a crea cooperări temporare şi de a realiza valoarea unei oportunităţi de afaceri pe care partenerii n-o pot (sau pot, dar într-o mai mică măsură) surprinde singuri (Katzy & Schultz, 1998). - IV este o alianţă temporară de întreprinderi care vin împreună pentru a-şi împărţi calificările şi competenţele şi resursele pentru a răspunde mai bine oportunităţilor de business, şi a căror cooperare este susţinută de reţele de calculatoare (Camarinha-Matos şi alţii, 2005) Caracteristici cheie ale întreprinderii virtuale Scopul întreprinderii virtuale este de a oferi o nouă soluţie pentru o oportunitate neprevăzută. Aşadar, intreprinderea virtuala poate fi văzută mai mult ca şi o acţiune, decât ca o instituţie. Agilitatea IV face posibilă crearea de soluţii pentru oportunităţi imediate, pe baza a trei caracteristici principale, care vor fi dezvoltate in continuare: În întreprinderea virtuală valoarea este creată, şi nu adăugată. Acest lucru face ca IV să fie diferită de abordările de management tradiţionale. Oportunitatea nou apărută poate deriva dintr-o nouă piaţă, dintr-un nou produs / tehnologie, dintr-o nouă cooperare industrială. IV este capabilă de a identifica aceste oportunităţi, dar aceasta presupune utilizarea unui set de metodologii de management diferit de managementul tradiţional al corporaţiilor. Întreprinderea virtuală este o cooperare temporară în scopul atingerii unor obiective specifice. IV este o alternativă la diferenţierea şi integrarea muncii în condiţii dinamice. Această cooperare este realizată pentru o perioadă limitată de timp, cu un scop clar definit, şi cu costuri indirecte minime pentru coordonare. Din nou, această caracteristică face ca IV să fie diferită de paradigmele existente, unde stabilitatea oferă suport pentru executarea sarcinilor. IV îşi expune nucleul operaţional incertitudinilor din exterior, fiind strâns legat de adaptarea sa la noua oportunitate. Aşadar, în IV aspectul managerial este de a dezvolta rutinele necesare pentru această inovare structurală. Intreprinderea virtuală facilitează restructurarea permanentă. Pentru că IV se adaptează permanent soluţiile care o sprijin trebuie să aibă caracteristici dinamice. Restructurarea IV este un proces de schimbare, o distrugere creativă, bazată pe şabloane de schimbare în timp. Cu alte cuvinte, IV se defineşte prin prisma manevrelor sale, şi nu prin structura de comandă, prin operaţii şi nu prin modul de organizare Principalele elemente ale Intreprinderii Virtuale IV se restructurează din interior, cu sopul de a capta valoarea din oportunităţile emergente. Trei elemente de bază (definitorii) caracterizează acest sistem (Katzy & Schultz, 1998): 1) valoarea oportunitatea, motivul restructurării, 2) procesul virtual rezultatul restructurării 3) reţeaua sursa restructurării. pag. 4 / 109

5 Figura prezintă esenţa IV. Agilitatea oferă capabilitatea IV de a prospera în condiţii de schimbare neprevazută. Figura Estenţa IV este restructurarea din interior Se vor analiza cele trei elemente definitorii ale IV prezentate în Figura Figura Cele trei elemente ale IV Valoarea Valoarea potenţială este motorul IV, care împinge IV către restructurare. Această valoare este cuprinsă în constelaţia viitoarelor reţele şi pieţe, dar nu este încă exploatată. Valoarea în condiţii de competiţie dinamică - Sursa valorii pentru IV este exploatarea proactivă a competiţiei dinamice. În abordarea tradiţională, valoarea este văzută ca şi transformarea materialelor brute în produse; este definită prin munca depusă şi resursele consumate. IV, în schimb, crează structuri industriale din competenţe, resurse şi parteneri care nu au existat înainte. Aşadar, valoarea este creată în IV atunci când apar noi oportunităţi şi sunt create noi structuri pentru a exploata aceste oportunităţi. Potenţiale surse de valoare dinamică - Strategii focusate pe client pot fi sursele unor potenţiale valori în IV. Printre acestea, amintim: produsele specifice pentru anumiţi clienţi, noi servicii industriale, dezvoltarea pieţei existente. Altă sursă de potenţiale valori în condiţii de competiţie dinamică este reprezentată de oferirea a noi servicii de manufacturare, dificil de imitat. Valoarea este creată cu procese virtuale eficiente - Extinzând principiul care spune că valoarea potenţială duce la restructurarea proceselor virtuale, se aşteaptă ca procesele virtuale să fie foarte pag. 5 / 109

6 diferite. Aşadar, procesele virtuale se vor mula foarte bine pe oportunităţile de piaţă pentru care au fost create. Întrucât trendul este de a se deconcentra valorile, decuplarea proceselor virtuale este deasemenea prezentă, pentru fiecare componentă a valorii. Procesul virtual Procesele virtuale sunt acele procese care combină competenţe, şi resurse pentru perioada necesară pentru a dezvolta valoarea unei oportunităţi de afaceri. Întrucât eficienţa şi efectivitatea procesului virtual reprezintă nucleul IV, cei doi termeni sunt utilizaţi interşanjabil. Oportunităţi şi riscuri pentru procesele virtuale - Pentru a fi competitivă, IV trebuie să ofere procese la fel de eficiente ca şi cele din organizaţiile tradiţionale. Procesele virtuale sunt o formă intensivă de externalizare. Ierarhiile tradiţionale şi legislaţia privind proprietatea nu sunt cerinţe esenţiale pentru operaţiunile virtuale între partenerii distribuiţi la nivel global. Relaţiile tradiţionale de business, în totalitate, se vor înlocui cu tehnologii informaţionale şi de telecomunicaţii. Upton (Upton, 1996) defineşte intreprinderea virtuală ca fiind o reţea Internet îmbunătăţită, cu brokeri de informaţii care planifică şi controlează operaţiile virtuale cu ajutorul sistemelor de calcul. Organizaţiile virtuale funcţionează ca şi un tablou de distribuţie care conectează resursele (regăsite în reţeaua virtuală) în procese virtuale integrate, conferindu-i flexibilitate maximă. Deşi procesele virtuale au unele avantaje vădite faţa de procesele de business din organizaţiile tradiţionale, acestea sunt totuşi purtătoare de riscuri. Certitudinile pe care se bazează deciziile de management sunt mai slabe, în contextul globalizării şi societăţii informaţionale. Integrarea proceselor virtuale - Procesele virtuale sunt integrate pentru a capta valoarea dintr-o oportunitate de afaceri. Integrarea în contextul virtual necesită un proces de structurare cum este structurarea unui proiect, de exemplu. Succesul procesului virtual depinde de gradul în care partenerii independenţi pot fi unificaţi pe perioada necesară captării valorii oportunităţii de afaceri. Operarea / funcţionarea proceselor virtuale - Procesele virtuale îndeplinite cu succes reprezintă activităţi inter-parteneri eficiente, efectiv integrate. Două principii ale IV pot fi identificate: - optimizarea se extinde la întreg lanţul de valori: obiectivul planificării centrale este de a ajunge la optimul lanţului de valori, şi nu la optimul fiecărei companii; - principiul de succedere al operaţiilor devine mai relevant decât ierarhiile în cadrul companiilor. Reţeaua virtuală Reţeaua virtuală este văzută ca fiind un rezervor de parteneri. Relaţiile dintre parteneri, resursele existente, cât şi rutinele şi procesele din modelul reţelei pot fi reconfigurate. Figura Reţeaua virtuală pag. 6 / 109

7 Atunci când reţelele se utilizează pentru a exploata o nouă oportunitate în piaţă, se pot reduce investiţiile. Companiile care cresc rapid se bazează pe structurile existente, şi costurile devin astfel mai mici. Reţele de intreprinderi, în funcţie de scopul acestora, şi aria economică în care activează, au diferite caracteristici. Mai mult, graniţele acestora sunt definite în funcţie de criterii variate. Aşadar, pentru a se determina şi exploata reţeaua virtuală, este util ca înainte să se determine o listă cu criteriile relevante şi limitele de construcţie a reţelei. Câteva faţete ale reţelei sunt prezentate în continuare: - Regiunile geografice recapătă importanţă în econimia informaţională globală; acest lucru este evident pentru reţele de companii mici, unde graniţele regionale sunt importante. - Graniţele reţelei pot deriva din frontierele industriale. - O altă graniţa a reţelei poate deriva din formele de proprietate sau posesiuni ale structuri; acesta este cazul marilor companii multinaţionale. Reţeaua apare ca o formă descentralizată a unei companii (anterior) integrate. - Din perspectiva marketingului, reţeaua este o sursă de relaţii industriale valoroase; reţelele industriale nu au graniţe sau ciclu de viaţă strict definite. Ele păstrează memorii ale activităţilor desfăşurate în comun de membrii reţelei, ca pe un capital de business valoros şi dificil de imitat. În primul rând relaţiile pot fi exploatate, iar în al doilea rând, reţelele pot fi restructurate pentru a umple golurile structurale. - Tehnologiile informaţionale şi de comunicaţii permit indivizilor dispersaţi geografic să lucreze împreună ca şi o echipă. Se crează astfel echipe şi reţele de business virtuale. Caracteristicile prezentate anterior subliniază elementele necesare pentru ca o reţea să exploateze potenţialul structurilor industriale existente. Mai trebuie adăugat însă şi un management eficient, pentru ca intreprinderea virtuală să se restructureze cu succes. Procesul de restructurare este chiar nucleul intreprinderii virtuale Procesul de restructurare în întreprinderea virtuală. Rutine de schimbare Întreprinderea virtuală se bazează pe abilitatea de a crea cooperări temporare şi de a realiza valoarea unei oportunităţi de afaceri, ea fiind un concept dinamic. Gândirea dinamică nu poate fi îngrădită în structuri stabile. Aşadar conceptul intreprinderii virtuale duce la şabloane observabile ale schimbării de-a lungul timpului, sau rutine de schimbare. Atunci când apare o nouă oportunitate, intreprinderea virtuală oferă acces la capacităţi şi competenţe disparate, care reprezintă mijloace de creştere virtuală a companiilor. Literatura de specialitate (Van de Ven şi Poole 1995) propune patru blocuri ale procesului de schimbare în cadrul intreprinderii virtuale: - ciclul de viaţă: o secvenţă liniară a schimbării inerente a unui sistem; - teleologia, finalismul: cauza finală a schimbării este un scop iar procesele de schimbare pornesc de la identificarea scopurilor; - dialectica: bazată pe o vedere pluralistă a lumii; interesele contradictorii sunt în competiţie pentru dominare, sau produc situaţii de caştig reciproc; - evoluţia: preluată de la un model biologic, un ciclu continuu de variaţie, selecţie, şi retenţie. Din aceste blocuri constructive ale procesului de schimbare se pot construi rutine de schimbare. Se aplică diferite cadre de timp pentru diferite rutine de schimbare. Potenţialul intreprinderii virtuale este acela că poate ca, temporar, să creeze un mai puternic succes în afaceri în condiţii economice normale, prin sincronizarea rutinelor de schimbare. Trei rutine de schimbare par să aibă un impact în succesul intreprinderii virtuale: interacţiunea cu clientul, restructurarea permanentă, şi evoluţia reţelei. pag. 7 / 109

8 Interacţiunea cu clienţii Realizarea rapidă a unei noi oportunităţi de afaceri necesită un proces sistematic pentru identificarea unei noi oportunităţi în mediul de afaceri. Interacţiunile cu potenţialii clienţi facilitează crearea intreprinderii virtuale. În ceea ce priveşte interacţiune cu clienţii în intreprinderea virtuală valoarea unei oportunităţi poate fi creată prin dialog cu clientul. Co-makeship, sau co-design, sunt alte concepte introduse în vederea creării de plus valoare prin dialog cu clienţii. Astfel, valoarea unei oportunităţi de business nu este neapărat valoarea produsului de pe raft, ci valoarea relativă într-un anumit context. Restructurarea permanentă Restructurarea este nucleul organizaţiilor virtuale şi astfel este un model organizaţional pentru succesul în condiţii de competiţie dinamică. Procesle de restructurare cuprind de la schimbări organizaţionale manageriate deliberat, până la comutarea instantă şi oportunistă a resurselor. În ceea ce priveşte restructurarea, mecanismele de piaţă devin importante pentru procesul virtual. Costurile tranzacţiilor economice includ, în cazul intreprinderilor virtuale, căutarea partenerului potrivit din reţeaua de parteneri, sau operarea proceselor virtuale. Cu ajutorul tehnologiilor informaţionale şi de comunicaţii aceste costuri se pot reduce dramatic. Tehnologiile de tipul realităţii virtuale, sau inteligenţă artificială pot automatiza parţial restructurarea IV. Totuşi, în ciuda avansului tehnologiei informaţionale, restructurarea operaţiilor virtuale rămâne o sarcină de management dedicată în special operatorilor umani. Evoluţia reţelei În unele cazuri, reţeaua, privită ca fiind platforma pentru restructurarea operaţiilor virtuale a evoluat de-a lungul unui proces lent, în timp îndelungat. În alte cazuri, reţelele au apărut în perioade mai scurte de timp. Cu toate acestea, şablonul evoluţional de schimbare al reţelei, formarea acesteia, cât şi schimbarea structurii sale de conducere, necesită un considerabil orizont de timp. Formarea reţelei poate avea diferite traiectorii evoluţionale: - Cooperare intensivă a intreprinderilor mici şi mijlocii - poate evolua de la proiecte comune sau de la acţiuni comune la care au participat partenerii. Pot apărea cooperările definite în moduri mai dinamice, care duc la un cadru pentru formarea de parteneriate prin setarea unor reguli acceptare a membrilor şi reguli de business comune. Reţeaua nu este condusă neapărat de către companii; alte instituţii, cum sunt programe guvernamentale, sau proiecte universitare, care urmăresc stimularea activităţii economice, joacă un rol important în evoluţia reţelelor. - Restructurarea industriilor care prezintă o cooperare verticală intensivă - Producătorii din diferite segmente industriale îşi restructurează relaţiile cu furnizorii. Relaţii intensive sunt stabilite cu câţiva furnizori agreaţi, care sunt furnizori de nivel 1 pentru subansamblele produselor. Pe măsură ce furnizorii de nivel 1 preiau tot mai multe funcţii, cum sunt proiectare, aprovizionare sau service, aceştia îşi construiesc, în mod similar, propriile reţele verticale, de nivel 2 sau Analiza conceptelor de business în cadrul întreprinderilor virtuale În domeniul afacerilor există mai multe accepţiuni referitoare la organizaţia virtuală: o organizaţie care îşi externalizează complet activităţile; o organizaţie care care îşi partajează resursele pentru a-şi atinge scopurile; open business care descrie afacerile care se desfăşoară pe baza unor standarde deschise. Organizaţiile virtuale sunt entităţi organizate în structuri semipermanente, parţial dependente, repartizate geografic, care îşi măresc performanţele pe baza receptivităţii la pag. 8 / 109

9 schimbările pieţei, prin abilităţile ICT, adaptându-şi continuu forma de organizare (Ghilic şi Stoica, 2004). Există o varietate de taxonomii ale organizaţiei virtuale: Din punct de vedere, al unor atribute cum ar fi, personal, tipuri de proiecte, sau scopuri se disting: echipe virtuale, proiecte virtuale, organizaţii virtuale permanente şi organizaţii virtuale temporare. Din punct de vedere corporativ se disting: Întreprinderea virtuală, care coagulează mai multe întreprinderi reale pentru obţinerea unor oportunităţi sau evitarea unor probleme. O astfel de întreprindere trebuie să se coaguleze, dacă apar condiţii favorabile şi să se desfiinţeze rapid odată cu dispariţia acestor condiţii. Corporaţiile virtuale sunt, în aceeaşi accepţie orientate spre consultanţă tehnologică în domenii cum ar fi managementul proiectelor sau sprijin tehnologic. Platforme industriale virtuale, denumite şi fabrici virtuale, care modelează în mediu virtual, permiţând unui număr mare de firme, cu o repartiţie georgafică şi temporară extinsă, să acţioneze ca o platformă industrială reală. Activitatea într-un mediu virtual, denumită de unii (Ghilic şi Stoica, 2004) şi birou virtual are o varietate de forme dintre care amintim: o activitatea la domiciliu, în care fiecare angajat lucrează la propriul domiciliu şi organizaţia funcţionează pe baza unei platforme care asigură legătura; o activitatea mobilă în care angajaţii au o activitate mobilă legătura fiind realizată prin mijloace mobile; în SUA 70-80% din domeniul marketing şi vânzări lucrează astfel; o activităţi în medii parţial virtuale, dintre care amintim: naveta virtuală ocazională, în care angajaţii au un birou dar ocazional lucrează la domiciliu în regim de organizaţie virtuală sau în centre de navetă virtuală; naveta virtuală aleatoare hoteling angajatul lucrează în regim de mediu virtual dar trebuie să participe la reuniuni de tip face-to-face, el nu are un birou în cadrul organizaţiei ci îşi rezervă unul analog cu o rezervare hotelieră; angajaţi dependenţi de birou, care trebuie să fie de exemplu dimineaţa la birou, după care lucrează în regim mobil folosind mediul virtual. Ca nouă formă de abordare a afacerilor, întreprinderea virtuală se prezintă ca şi o manifestare particulară de organizaţie colaborativă în care entităţile independente (dar interdependente) comunică, colaborează şi iau decizii de grup pentru obţinerea de avantaje competitive. Prin urmare, analiza tehnologiilor, metodologiilor şi a conceptelor care vizează dezvoltarea unei platforme care să susţină implementarea unei întreprinderi virtuale trebuie să cuprindă cu necesitate o analiză comparativă a tehnologiilor de proiectare şi dezvoltare a sistemelor colaborative, a sistemelor de asistare a deciziilor precum şi o analiză a tehnologiilor de dezvoltare a sistemelor de management a workflow-ului şi a proceselor de business. Toate acestea trebuie coroborate cu o tehnologie ICT adevată. Există la momentul actual şi întreprinderi virtuale simulate (ex. Virtual Enterprise California). Aceste intreprinderi virtuale simulate funcţionează ca şi o sală de clasă în care studenţi din diferite locaţii ale globului se reunesc pentru a crea o afacere (determină natura business-ului, produsele şi serviciile, structura managerială şi rulează zilnic operaţiunile de business specifice), sub îndrumarea unui profesor. Deşi nu tranzacţionează cu adevărat, nici nu vând produse reale, scopul acestei întreprinderi virtuale simulate este de a învăţa studenţii cum să pornească şi cum să conducă o afacere, şi mai ales cum să foloseasca software-ul existent de comunicare şi tranzactionare în afaceri pe Internet. Aplicaţii asemănătoare există şi la noi, de exemplu la UTCN pentru a simula managementul sau marketingul unei întreprinderi virtuale. Conceptul de business, sau afacere, trasează în mare pentru o afacere, deci şi pentru cele virtuale, un plan a ceea ce urmează să fie făcut pentru a satisface cu succes o oportunitate de business. Acesta constituie fundamentul tuturor activităţilor care vor fi întreprinse şi conţine: pag. 9 / 109

10 o delimitare a consumatorilor ţintă, o descriere clară a caracteristicilor serviciului / produsului oferit, o delimitare a beneficiilor pe care le aduce participanţilor la afacere strategii de introducere a serviciului / produsului) pe piaţă. Organizarea economică şi legală a întreprinderilor virtuale diferă de cea a unei întreprinderi tradiţionale. Întreprinderea tradiţională se constituie ca o organizaţie stabilă care încearcă în mod continuu să creeze noi şi noi oportunităţi de business. Deşi porneşte de la o idee de business, poate să o schimbe în timp în încercarea de a se adapta la condiţiile schimbătoare ale climatului economic. Acest lucru nu este valabil pentru întreprinderile virtuale care se constituie în jurul unei oportunităţi de business prin unirea forţelor unor organizaţii independente, ca modalitate de a răspunde cu succes oportunităţii respective. ICT, aşa cum s-a menţionat reprezintă roata motrice a întreprinderii virtuale, asigurând o comunicare şi colaborare uşoară între partenerii business-ului şi în plus permit unor organizaţii mici să participe la un proiect naţional / internaţional de anvergură. Datorită naturii sale virtuale, întreprinderea beneficiază de o mare flexibilitate în ceea ce priveşte adaptarea la modificările oportunităţii de business căreia i se adresează. Din punct de vedere legal, conceptul de business al întreprinderii virtuale diferă din nou faţă de cel al unei organizaţii tradiţionale. Întreprinderea virtuală poate funcţiona legal chiar dacă nu are personalitate juridică. Obţinerea unei personalităţi juridice nu se numără de regulă printre scopurile întreprinderii virtuale, care de multe ori, dispare la fel de repede precum aparut ca să speculeze o oportunitate de business şi în care de regulă partenerii se schimbă repede, în funcţie de modificările pe care le induce evoluţia oportunităţii de business Conceptul de Enterprise Architecture Pornind de la definiţia dată de specialiştii de la Carnegie Mellon University, arhitectura întreprinderii (Enterprise Architecture - EA) este o modalitate de descriere a structurii şi a proceselor afacerii care conectează structurile de business. Se consideră, în general, că arhitectura întreprinderii este practica prin care se aplică metode inteligente şi riguroase de descriere a structurii şi proceselor prezente şi viitoare ale afacerii, a sistemului informatic şi a subunităţilor astfel încât să se alinieze la strategia companiei. O definiţie mai complexă a fost dată de U.S. Government's Office: o bază strategică de informaţii cumulate care defineşte afacerea, informaţiile necesare pentru operaţiunile de business, tehnologia necesară pentru suportul operaţiilor şi procesul de tranziţie necesar pentru implementarea noilor tehnologii în raport cu evoluţia necesităţilor afacerii. Apariţia conceptului legat de arhitectura întreprinderii se datorează unui articol publicat în IBM Systems Journal în 1987, a lui J. A. Zachman. Mai târziu, Zachman va redenumi acesta cadru de lucru, framework, pentru arhitectura de întreprindere, iar acum este denumit simplu Zachman Framework. În 1994, Departmentul Apărării al Statelor Unite a introdus Framework-ul pentru Arhitectura Tehnică a Managementului Informaţiilor (TAFIM), care va fi proclamat drept noul standard de arhitectură de întreprindere pentru activitatea de apărare. După dispariţia acestui standard în anul 2000, o parte din el va fii adoptat de către The Open Group Architectural Framework (TOGAF). TOGAF va deveni astfel cel mai popular framework open source de arhitectură de întreprindere în sectorul privat, urmat îndeaproape de Zachman. Arhitectură complexă a unui sistem extins de management cuprinde următoarele funcţionalităţi: Resurse Umane, Plăţi efectuate, Plăţi încasate, Facturi, Imobilizări, Casierie şi Salariaţi. În acest caz nu trebuie creat un design, respectiv un proiect, unic şi complex, fiind recomandat să se creeze câte un subsistem pentru fiecare modul. În cadrul metodologiei de realizare a arhitecturii, apar următoarele etape: pag. 10 / 109

11 Definirea designului arhitecturii de business Definirea designului arhitecturii tehnice Implementarea, Testarea, Dezvoltarea. O arhitectură de întreprindere bine definită poate constitui un suport valid pentru găsirea unor soluţii viabile pentru procesele critice de afaceri. În perioada actuală există câteva exemple de framework-uri care domină aria de cercetare şi aplicare: Zachman Framework pentru EA, Open Group Architecture Framework (TOGAF), Federal Enterprise Architecture (FEA), Gartner. Un proiect de creare a unei arhitecturi, bazat pe EAF (Entreprise Architecture Framework) trebuie doar să folosească suficiente informaţii tehnice şi de business pentru a oferi un context global. O arhitectură de întreprindere va ţine cont de aspectul contextual, de cel conceptual, de cel logic, de cel fizic. Nivelul contextual reprezintă baza arhitecturii adunând date şi oferind documentaţie de business. În timp ce nivelul conceptual detaliază serviciile şi interacţiunile drept suport pentru principiile definite în nivelul contextual, modelul definit la nivelul conceptual rămâne stabil în condiţiile în care nu are loc o modificare fundamentală a strategiei de business. Nivelul logic descrie soluţia adoptată ca şi produs independent, reflectând schimbările topdown, cum ar fi oportunităţile oferite de tehnologie. Nivelul fizic detaliază principiile de design, standardele, componentele de grupare şi oferă un framework funcţional. La acest nivel poate fi utilizată soluţia Microsoft Systems Architecture (MSA), pentru a accelera dezvoltarea arhitecturii fizice, îmbunătăţirea calităţii arhitecturii şi reducerea riscurilor la care este supus proiectul. Ţinând cont de faptul că termenul arhitectură poate fi privit şi separat de aspectul de business şi de IT, apare uneori confuzia dintre termenul de arhitectură şi cel de design, deşi ele oferă perspective diferite, dar complementare asupra soluţiei. În tabelul se realizează o parţială analiză SWOT, între arhitectură şi design (conform Cap Gemini Ernst & Young). Tabel Analiza comparata arhitectură design ( Oferă Nu oferă Cerinţe non-funcţionale Prototipuri Scopuri şi responsabilităţi funcţionale Cerinţe funcţionale inteligente Arhitectura Key design Design la un nivel înalt Restricţii de design Analiza detaliată a datelor Sisteme construite şi implementate Design Modul de atingere a cerinţelor funcţionale Analiza detaliată a datelor şi un model Documentaţie de design Sisteme construite şi implementate Soluţie Vision Cerinţe non funcţionale inteligente Arhitectura de securitate şi de legislaţie EA devine tot mai importantă la nivelul de complexitate actual şi la nivelul de colaborare dintre business şi sistemul funcţional, şi este nevoie de o şi mai strânsă corelare între sistemul de business şi costurile efective, utilizând ICT ca formă de obţinere a beneficiilor. Obiectivul cheie al arhitecturii întreprinderii este acela de a înţelege părţile relevante ale întregii afaceri, procesele end-to-end, necesităţile non-funcţionale, incluzând securitatea şi legislaţia. pag. 11 / 109

12 Modelarea unei firme virtuale folosind Entreprise Arhitecture Arhitectura întreprinderii reprezintă, în sens larg, descrierea comportamentului prezent şi/sau viitor al proceselor dintr-o organizaţie, ţinând cont de scopul şi direcţia strategică a organizaţiei. Principalele ţinte practice în modelarea arhitecturii întreprinderii sunt: optimizarea afacerii, îmbunătăţirea managementului de performanţă şi a structurii organizaţiei, precum şi arhitectura proceselor. Scopul principal în realizarea arhitecturii este acela de a alinea strategia de business cu investiţia în domeniul IT. Modelarea întreprinderii este legată de dezvoltarea de modele pentru diferite aspecte ale unei întreprinderi. Pentru susţinerea diferitelor activităţi de modelare se pot utiliza următoarele categorii de modele: Modelele datelor, care descriu datele utilizate în cadrul întreprinderii Modelele proceselor, care redau procesele care au loc într-o întreprindere Modelele activităţilor, care descriu activităţile care se produc în şi de către întreprindere Aceste modele diferite ale întreprinderii, integrate, pot furniza o mai bună cunoaştere şi gestionare a complexităţii întreprinderii, favorizează simularea de soluţii alternative ale aspectelor şi susţin controlul şi monitorizarea operaţiilor întreprinderii. La modul informal, modelele trebuie integrate pentru a da o imagine coerentă asupra întreprinderii şi pentru a susţine un management eficient al operaţiilor între diferitele părţi ale întreprinderii. Ca urmare, aceste modelele prezintă următoarele caracteristici: - Informaţia transportată între modele trebuie să fie consistentă pentru a asigura acurateţea; - Termenii utilizaţi la modelare nu trebuie să fie ambigui, pentru a oferi o înţelegere deplină a modelelor şi a le valida consistenţa; - Conexiunile logice dintre elementele modelelor trebuie bine identificate şi întreţinute pentru a valida implicaţiile modificărilor ce survin în model, ce se vor propaga şi în alte modele. În procesul de integrare a modelelor, pot apărea următoarele impedimente: Numărul mare de metode de modelare, cu informaţii de diferite tipuri; Numărul extins de instrumente de modelare; Numărul contextelor diferite în care are loc modelarea. În scopul eliminării acestor impedimente pot fi utilizate o serie de soluţii cum ar fi: - pasul iniţial pentru rezolvarea primului impediment al integrării modelului este de a capta o descriere a tipului de informaţie gestionată de diferite metode de modelare existente şi a interelaţiilor acestora, de a le descrie şi a le face neambigue. Specificarea ontologiei unei metode dă atât definirea formală cât şi pe cea informală a categoriilor semantice de bază şi a legăturilor logice dintre aceste categorii. - abordare importantă pentru cel de al doilea impediment al integrării modelelor întreprinderii este de a furniza un mediu neutral computaţional, în care informaţia conţinută în diferitele modele şi a interelaţiilor, să poată fi reprezentată şi menţinută. Pentru a face posibilă o astfel de soluţie, este necesar să se aleagă o cale prin care să se poată descrie modul în care informaţia stocată în instrumentele de modelare poate fi reprezentată într-un mediu natural. Practica modelării arhitecturii organizaţiei necesită dezvoltarea unui framework care să cuprindă descrierea business-ului, aplicaţiile existente, tehnologiile şi datele utilizate. Acest framework ar oferi o taxonomie riguroasă care să identifice procesele care funcţionează în parametrii optimi şi detaliile execuţiei acestor procese. O abordare bazată pe valoare pentru o nouă arhitectură este recomandată mai ales în cazul etapei iniţiale a unei afaceri. O echipă riscă să piardă adevăratul scop al procesului, dacă pierde foarte mult timp cu documentarea. Implementarea unei arhitecturi organizaţionale începe de obicei cu studierea şi documentarea în ceea ce priveşte strategiile firmei. O parte a acestei munci este Modelul de Operare, care descrie planurile de lucru ale organizaţiei. Rezultatul intermediar al implementării arhitecturii organizaţiei este un inventar de strategii de business, procese de business, grafice organizaţionale, inventare tehnice, diagrame de sistem şi de interfaţă, topologii pag. 12 / 109

13 de reţele şi toate legăturile între aceste elemente. Inventarele şi diagramele sunt instrumente suport pentru procesul decizional la toate nivelele întreprinderii. Organizaţia trebuie să proiecteze şi să implementeze procese care asigură dinamica între situaţia actuală şi cea viitoare. Pentru planificarea situaţiei viitoare, se consideră că aceasta ar trebui să reprezinte o combinaţie între următoarele elemente: Situaţia strategiei organizaţionale curente şi suportul posibil oferit de IT Situaţia dintre strategia viitoare previzionată şi posibilitatea de suport oferită de IT Arhitectura întreprinderii este în legătură directă cu ingineria performanţelor, managementul ICT şi metadatele, în sensul informatic al noţiunilor. Arhitectura de întreprindere este complexă şi se structurează pe trei nivele, fiecare nivel fiind caracterizat de parametrii specifici: scopul, detalierea, impactul şi audienţa (Figura 1.2.1). Figura Arhitectura intreprinderii ( adaptare 2006 FEA Practice Guidance of US OMB) Având în vedere termenul de EA poate avea diferite sensuri, de multe ori putem observa că sunt analizate doar anumite aspecte. Astfel, din punct de vedere al aspectelor ICT, arhitectura organizaţiei este văzută drept o activitate mult mai structurată, cu mai multe părţi dinamice, cum ar fi: arhitectura strategiei, pattern-urile, principiile, designul, arhitectura de business şi legislaţia de ICT. Alţi profesionişti analizează arhitectura întreprinderii preponderent din punct de vedere tehnic şi mai puţin din cel de business, iar o altă parte a analiştilor văd arhitectura întreprinderii strict ca un aspect de IT. Dincolo de aceste abordări este considerat esenţial faptul că arhitectura trebuie să fie privită atât din punct de vedere al afacerii cât şi din cel de ICT, după cum a definit termenul Gartner. În figura sunt prezentate principalele instrumente utilizate de specialişti în modelarea unui framework pentru enterprise architecture. Analiza utilizării diferitelor instrumente este mai importantă decât utilizarea proceselor, deoarece procesele diferă de la o organizaţie la alta, dar instrumentele sunt aceleaşi. Scenariul de utilizare a instrumentelor Microsoft este foarte important, deoarece acestea sunt mai accesibile tuturor categoriilor de specialişti. Din acest punct de vedere, se consideră că există multe posibilităţi de utilizare a instrumentelor existente fără prea mari eforturi sau costuri, ceea ce va aduce un câştig substanţial. Pentru a analiza arhitectura, se pot crea de asemenea template-uri Microsoft Word pentru o analiză secvenţială, definind astfel elementele şi workflow-urile. Se creează astfel un nivel consistent de documentare facilitând procesul decizional. Centralizând apoi informaţia vom obţine un depozit de informaţii legate de arhitectura întreprinderii, facilitând astfel managementul informaţiilor, securitatea şi legalitatea. pag. 13 / 109

14 Figura Unelte de decizie în firme (sursa Forrester Research EA tools used in the enterprise) O arhitectură acţionabilă promovează inovaţia şi viteza de reacţie. Prin ea, organizaţiile au acces la informaţii esenţiale pentru optimizarea mecanismului de funcţionare internă pe toate palierele de activitate: de la strategii de investiţii ICT până la analiza proceselor de afaceri pentru a identifica redundanţele sau oportunităţile de dezvoltare. Modelarea arhitecturii trebuie să facă faţă unor bariere organizaţionale, şi anume: legătura pozitivă între cei care modelează arhitectura şi cei care o vor utiliza resursele bugetare, de personal şi de business influenţarea proceselor existente. Sistemele ERP suport de dezvoltare a întreprinderilor virtuale Existenţa unei întreprinderi este derulată printr-o activitate tot mai complexă şi mai diversificată, care necesită tot mai multe aplicaţii specifice rezolvării tuturor problemelor apărute în desfăşurarea proceselor economice în cadrul unei întreprinderi virtuale. Enterprise Resource Planning (ERP) reprezintă sisteme bazate pe arhitectură client/server dezvoltate pentru prelucrarea tranzacţiilor şi facilitarea integrării tuturor proceselor, din faza planificării, dezvoltării producţiei, până la relaţiile cu furnizorii, clienţii sau alţi parteneri de afaceri, ERP fiind considerate expresia fidelă a interdependenţei dintre economic şi tehnologia informaţională (Fotache şi Hurbean, 2004). Într-o definiţie orientată tehnologic, se poate afirma că ERP reprezintă un sistem informaţional contabil bazat pe interfeţe grafice utilizator, baze de date relaţionale, limbaje de generaţia a IV-a, instrumente CASE şi arhitectură client-server. Deşi tehnologia este esenţială în realizarea ERP, definirea acestora trebuie să scoată în evidenţă ariile funcţionale acoperite de aceste sisteme: contabilitate, producţie, vânzare, aprovizionare, stocuri, control de calitate, etc. Din acest punct de vedere, sistemele ERP sunt pachete de aplicaţii formate din mai multe module care sprijină toate ariile funcţionale: planificare, resurse umane, producţie, vânzare, marketing, distribuţie, contabilitate, financiar, gestiunea proiectelor, stocuri, service, logistică şi e-business. Mai trebuie adăugat şi faptul că arhitectura sistemului facilitează integrarea modulelor, asigurând fluxul informaţiilor între toate funcţiunile întreprinderii într-o manieră transparentă (Fotache şi Hurbean, 2004). pag. 14 / 109

15 O Leary apreciază că sistemele ERP reprezintă sisteme computerizate, care asigură prelucrarea integrată şi în timp real a tuturor tranzacţiilor din întreprindere şi optimizează întregul lanţ de activităţi, de la planificare la service postvânzare (O Leary, 2000). Datele generate de tranzacţiile economice specifice sunt stocate în baze de date iar rezultatul prelucrării lor este oferit utilizatorilor sub forma rapoartelor, fie display-uri fie imprimate sau sub forma fişierelor de export către alte medii de lucru. După cum se poate observa în figura 1.2.3, principalele părţi componente ale unui sistem ERP sunt: Financiar-contabilitatea, Producţia, Stocurile, Vânzările şi Analiza managerială, modul care ia o amploare tot mai mare în sistemele integrate apărute pe piaţă. Figura Schema conceptuală a unui sistem ERP (adaptare după Rashid, M., Hossain, L., Patrick, J.D., Enterprise Resource Planning:global opportunities and challenges, Idea Group Publishing, 2002, pag. 3) (Fotache şi Hurbean, 2004). Tendinţa actuală este de a lega sistemul ERP de sistemele CRM(Customer Relation Management) şi SCM (Supply Chain Management), prin sisteme de comerţ electronic. Producătorii soluţiilor ERP urmăresc continuu să adopte platformele e-business în cadrul soluţiilor proprii. Aceste transformări au început în 1999, odată cu înglobarea tuturor avantajelor oferite de Internet şi au continuat cu facilităţile oferite de Intranet, reţele de calculatoare, culminând cu suitele e-business ERP. Pachetele Enterprise Resource Planning sunt atuurile marilor companii multinaţionale, dar încep să acapareze şi segmentul companiilor medii şi mici, lucru dovedit şi de multitudinea articolelor şi a materialelor prezente în literatura de specialitate. Succesul noilor soluţii depinde şi de capacitatea lor de a se extinde prin integrarea modulelor din categoria Customer Relation Management, Supply Chain Management şi Business Intelligence. Scopul principal al ERP este acela de a integra toate departamentele şi funcţiile dintr-o companie utilizând un singur sistem de calcul care poate rezolva toate nevoile individuale ale fiecarui departament. Pentru buna sa funcţionare, ERP are nevoie de sisteme de adoptare a deciziilor performante şi de o bună punere în practică, bazate pe cercetari prealabile complexe. Sistemele ERP nou apărute, promovate şi utilizate de companii, oferă o serie de avantaje, menite să eficientizeze activităţile departamentelor componente şi totodată să crească pag. 15 / 109

16 productivitatea afacerii. Printre aceste avantaje se numără automatizarea activităţilor personalului, îmbunătăţirea controlului asupra activităţii şi posibilitatea luării măsurilor necesare, în timp util, în cazul apariţiei unor probleme, creşterea eficienţei şi a rapidităţii cu care se desfăşoară fluxul de activităţi, accesul mai rapid şi mai bun la informaţia necesară, prin partajarea acestor informaţii şi a cunoştinţelor, interfaţa mult mai uşor de utilizat, toate acestea ducând la recuperarea unor mari părţi din investiţia făcută de către companie prin achiziţionarea acestui sistem. Din punct de vedere logic se creează o singură bază de date, în care datele se preiau o singură dată şi se unesc toate practicile economice într-o singură grupă de module software. Dintre tehnologiile utilizate la crearea sistemelor se numără: Workflow; Workgroup; Internet; Intranet; Extranet; EDI (Electronic Dată Interchange) şi Data Warehousing. ERP sau Entreprise Resource Planning Software urmăreşte realizarea unui singur soft care să satisfacă în aceiaşi măsură nevoile celor de la departamentul Financiar, a celor de la departamentul de Vânzări dar şi ale celor de la Resurse Umane, sau Personal. În mod normal fiecare din departamentele unei întreprinderi are un sistem bine pus la punct, care rezolvă problemele specifice departamentului respectiv. Dar ERP combină toate aceste sisteme într-un singur program soft, integrat, care utilizează o singură bază de date, astfel încât toate departamentele pot împărţi, cunoaşte şi dispune de toate informaţiile legate de activitatea întregii unităţi. Acest sistem poate avea un aport deosebit la beneficiul întreprinderii, dacă el este corect instalat şi utilizat. Luând exemplul cel mai banal, al unei comenzi făcute de către un client al firmei, aceasta este purtată prin diferite sisteme de calcul ale diferitelor departamente, atâta timp cât acestea nu sunt integrate, ceea ce duce la o întârziere în preluarea şi onorarea comenzii, neluând în calcul risipa de timp şi resurse necesară. Rezolvarea acestei probleme spinoase o oferă ERP, integrând într-un singur sistem de calcul, sistemele de calcul individuale ale fiecarui departament. Acest soft integrat este împărţit în module corespunzatoare activităţii specifice departamentelor. Deci fiecare departament va avea în continuare propriul sistem, doar că acestea vor fii legate între ele, astfel încât softul unui departament poate fi utilizat şi de alte departamente, în scopul eficientizării activităţii. În general, software-ul ERP este flexibil şi permite instalarea doar a unor module, nefiind necesară instalarea întregului pachet. Din aceste motive, unele firme producătoare de soft ERP oferă mai multe tipuri de pachete, cu preţul diferind în funcţie de numărul şi complexitatea modulelor pe care le conţine fiecare pachet Modele de management a proceselor de business Managementul proceselor de business (MPB) reprezintă o ramură a managementului care se concentrează asupra asigurării eficienţei unui business în acelaşi timp cu păstrarea flexibilităţii, inovaţiei şi integrării business-ului cu tehnologiile de ultimă oră. MPB pune la dispoziţie metode, tehnici şi unelte care ajută la proiectarea, managementul şi analiza operaţională a proceselor de business. MPB încearcă să îmbunătăţească continuu procesele de business; este procesul care defineşte, măsoară şi optimizează aceste procese. Exista cinci activităţi care stau la baza ciclului de viaţă al managementului proceselor de business: proiectare, modelare, execuţie, monitorizare şi optimizare. Deşi este conceput ca un process ciclic, MPB se rezumă în realitate la una sau câteva iteraţii datorită unor constrângeri economice sau de timp. Modelul NIH de management al proceselor de Workflow/Business Acest model exemplifică utilizarea de unelte de management a proceselor de business în scopul implementării de procese de business. Se bazează pe interfeţe Web pentru accesul securizat la uneltele de management a proceselor de business. pag. 16 / 109

17 Acest model permite o mare flexibilitate la nivelul utilizatorului care poate construi aplicaţii specifice nevoilor sale care să interfaţeze cu sistemul de management prin intermediul API-urilor puse la dispoziţie de sistem. În acest model, uneltele MPB permit utilizatorului construirea de modele de business, execuţia acestora şi rafinarea lor. Mai mult, modelarea şi simularea permit pre-execuţia şi post-execuţia de activităţi. Este un model care se axează pe modelarea şi execuţia de procese de business. Modelul ARIS (Architecture of Integrated Information Systems) Modelul se concentrează pe analiza şi cerinţele fazei de definiţie din cadrul proiectării sistemelor informaţionale manageriale. Oferă suport extins pentru proiectarea organizaţională şi optimizarea proceselor de business. ARIS utilizează un sistem grafic de modelare susţinut de unelte software care permit modelarea mişcării de date şi task-uri Tipuri de întreprinderi virtuale În ceea ce urmează ne vom referi la câteva modele de arhitecturi de întreprindere virtuală şi cum se prezintă acestea în ceea ce priveşte conceptul de business adoptat. Literatura de specialitate deosebeşte următoarele modele de organizare existente pe piaţă: firma tehnologică, firma dispersată geografic, firma externalizată, cyberîntreprindere, reţea temporară, cea de tip Plug & Play. Aceste modele de organizaţii virtuale se diferenţiază la nivelul următoarelor dimensiuni: natura participanţilor la întreprindere, interacţiunea dintre participanţi, frontierele care delimitează participanţii natura mijloacelor de comunicare şi durata de viaţa a întreprinderii. Întreprinderea virtuală de tip firmă tehnologică Mulţi autori în domeniul teoriei întreprinderilor virtuale afirmă că acestea au apărut ca şi o consecinţă a evoluţiei tehnologiilor de comunicare şi informare şi definesc o întreprindere virtuală ca şi o firmă care foloseşte aceste tehnologii informaţionale în scopul eficientizării capacităţii de a satisface o oportunitate de business. Acest model se diferenţiază de modelul clasic de organizaţie prin nivelul tehnologic care permite virtualizarea tuturor activităţilor din cadrul organizaţiei. Un canal de creare de valori conţine de regulă două categorii de activităţi: - principale (precum producţie, logistică, comercializare şi vânzări, servicii); - de susţinere (precum aprovizionare, dezvoltare tehnologică, gestiunea resurselor umane şi servicii de administrare şi de gestiune). ICT acţionează prin creşterea valorii la nivelul fiecărui tip de activitate mergând până la susţinerea automatizării unor activităţi precum logistica sau activităţi legate de colectarea, stocarea şi distribuirea fizică a produselor finite. În producţie, ICT accelerează procesul efectiv de producţie şi oferă unelte informatice care favorizează comunicarea dintre cercetători şi ingineri. La nivelul dezvoltării tehnologice, se pot automatiza conceperea şi informatizarea integrală a cercetării şi dezvoltării. La nivelul activităţilor de susţinere, un sistem Electronic Data Interchange asigură rentabilizarea aprovizionării prin stabilirea de legături directe între organizaţiile participante la întreprinderea virtuală. pag. 17 / 109

18 Conceptele de business vehiculate în cadrul unei întreprinderi virtuale de tip firmă tehnologică nu se modifică cu nimic faţă de cele ale unei organizaţii clasice, deoarece virtualitatea întreprinderii se simte la nivel de activitate. Întreprinderea virtuală de tip firmă dispersată geografic Mulţi autori văd întreprinderea virtuală ca şi o firmă a cărei angajaţi sunt dispersaţi în timp şi spaţiu într-o structură de tip reţea. Acest model se bazează pe mobilitatea spaţio-temporală a angajaţilor întreprinderii care sunt legaţi de un interes comun pe termen lung şi care comunică şi colaborează. Toate acestea sunt posibile numai datorită mijloacelor ICT care asigură colaborarea dintre angajaţi indiferent de limitele de spaţiu şi timp. Astfel, prin intermediul unor sisteme precum cel de videoconferinţă şi mesagerie electronică, angajaţii pot să lucreze în orice locaţie, fie acasă, fie la sediul unui client, etc. Datorită obiectivului şi interesului pe termen lung al întreprinderii de acest tip, este nevoie de grupuri de lucru şi întâlniri faţă-în-faţă pentru ca relaţiile dintre angajaţi să reziste în timp. Întreprinderea virtuală dispersată geografic trece astfel de limitele modelului clasic, tradiţional al organizaţiei văzută ca flux de valoare între furnizori, fabricanţi şi utilizatori finali prin descentralizarea muncii. Întreprinderile virtuale în general sunt descentralizate şi non-ierarhice datorită inexistenţei unor reguli clare după care informaţia se transferă şi se partajează între participanţi. Întreprinderea virtuală de tip firmă externalizată Una din schimbările organizaţionale cel mai des întâlnite în prezent este externalizarea. Dacă la început erau focalizate pe funcţii secundare, politicile de externalizare evoluează spre funcţii strategice. Cu toate acestea, funcţiunile externalizate rămân printre cele periferice, în timp ce funcţiunile care oferă avantaj competitiv rămân în continuare să fie dezvoltate în interiorul firmei (site4). Gradul de virtualitate al unei firme depinde de gradul de externalizare a funcţiilor acesteia. Astfel, o firmă se consideră virtuală dacă activitatea de producţie a bunurilor sau a serviciilor este externalizată. Întreprinderea virtuală bazată pe externalizare se prezintă ca o reţea de membri interconectaţi electronic între ei şi la un nucleu central care reprezintă organizaţia generatoare de proiecte, cea care încearcă valorificarea canalelor sale valorice. Controlul şi coordonarea diferitelor activităţi în cadrul întreprinderii virtuale nu se poate realiza eficient fără ICT care reduc drastic costurile tranzacţiilor dintre firmele colaboratoare şi nucleu. De menţionat outsourcing-ul ca ultima tendinţă în ceea ce priveşte externalizarea serviciilor de orice fel. Companiile de outsourcing au ajuns să ofere o gamă foarte largă de servicii, care pornesc de la aplicaţii de birou, sisteme de până la implementarea de reţele mari, de nivel corporativ. Întreprinderea virtuală de tip cyberîntreprindere După unii autori, cyberîntreprinderea este văzută ca o interconexiune electronică între persoane sau grupuri de persoane ce are ca misiune colectarea de comenzi şi alegerea modului de management a activităţilor de dirijare a produsului către client (site4). Ca manifestare de comerţ electronic, cyberîntreprinderea activează în cyberspatiu şi utilizează o platformă de lucru cibernetică construită în jurul Internetului (de regulă o pagină Web). Acest mod de funcţionare a unei întreprinderi virtuale a revoluţionat regulile de concurenţă pe plan mondial. Marketingul devine accesibil şi firmelor mici în spaţiul virtual al Internetului. Cyberîntreprinderea oferă servicii şi nu produse deoarece vinde produsele altor firme producătoare şi prezintă marele avantaj de a funcţiona 24 de ore din 24 de ore, 7 zile pe săptămână din 7. De asemenea, nu prezintă bariere spaţiale sau temporare, fiind accesibilă oricărei persoane pag. 18 / 109

19 care acces la Internet. Deoarece se adresează unor situaţii de business aproape imateriale, un atribut necesar pentru succesul unei cyberîntreprinderi este încrederea între participanţii la business. Întreprinderea virtuală de tip reţea temporară În acest model de întreprindere virtuală organizaţii independente se reunesc în jurul unui proiect comun ca să formeze o reţea temporară de colaborare ce se dizolvă imediat ce proiectul se termină. Participanţii la reţea lucrează pe aceeaşi platformă informaţională şi se interconectează prin tehnologii de tipul videoconferinţelor, mesageriei electronice. Acest tip de întreprindere nu are ierarhie şi nici integrare verticală şi se bazează exclusiv pe buna colaborare dintre participanţi (site4). Cooperarea în astfel de reţea este extrem de flexibilă şi informală datorită faptului că e dificilă delimitarea frontierelor fiecărui participant. Unul din atributele esenţiale ale acestui tip de întreprindere este încrederea fără de care întreprinderea nu poate funcţiona eficient şi nu se poate prin urmare adresa repede oportunităţii de business căreia proiectul se adresează. Întreprindere virtuală de tip Plug & Play Acest concept de business se bazează pe o suită de tehnologii de comunicare şi informare inovatoare care formează o platformă software pe care entităţi independente comunică şi colaborează la creşterea potenţialului lor de business. Caracteristica fundamentală a unui astfel de business o constituie dinamicitatea, în sensul în care o organizaţie poate părăsi oricând business-ul dar mai ales poate intra în el atâta timp cât specifică şi îi sunt validate resursele (capacitatea de producţie, reţeaua de distribuţie, capitalul intelectual, etc.) (site3). Deşi participanţii la comunitate au un ţel comun, acela de a creşte business-ul pentru care întreprinderea virtuală există, business-ul de tip Plug & Play trebuie să stimuleze totodată inovaţia fără să interfereze cu scopurile de business individuale ale entităţilor participante la întreprindere. Interoperabilitatea sistemelor informatice pe care funcţionează participanţii la întreprindere constituie conceptul central al business-ului de tip Plug & Play care rezolvă problemele inerente comunicării între entităţi eterogene, autonome şi care pot prezenta conflicte de interese. Interacţiunea între participanţii la o întreprindere virtuală de tip Plug & Play este bazată pe roluri. Fiecare participant joacă cel puţin un rol în funcţie de competentele sale iar rolul de antreprenor este pe cât posibil automatizat în cadrul business-ului, punându-se accentul pe inovaţie şi pe rapida transformare a acesteia într-o idee de business. Apariţia întreprinderii virtuale începe printr-o chemare la comunicare din partea unei organizaţii care are o idee inovatoare şi se consideră încheiată în momentul în care se cristalizează o colaborare solidă între participanţi Proiecte europene care au studiat cadrul legal al întreprinderilor virtuale O caracteristică interesantă a conceptul de business al unei întreprinderi virtuale este că întreprinderea nu trebuie să dispună de personalitate juridică ca să existe şi să funcţioneze legal. În general, acesta nici nu se numără printre scopurile întreprinderii virtuale care de regulă se constituie rapid pentru a răspunde eficient şi rapid unei oportunităţi de business. Aşa cum experienţa şi studiile au arătat, încrederea reciprocă între participanţii la întreprindere este ingredientul principal al eficienţei întreprinderii. Cu ajutorul noilor tehnologii informaţionale care susţin flexibilitatea şi informalitatea comunicării şi colaborării între parteneri, se creşte încrederea în parteneri precum şi eficienţa în colaborare şi astfel se pune pe un plan secund nevoia de a legaliza fiecare interacţiune dintre parteneri. Exista în derulare proiecte la nivel european care se concentreaza asupra unor aspecte ridicate de implementarea unei intreprinderi virtuale: pag. 19 / 109

20 BIDSAVER - Business Integrator Dynamic Support Agents for Virtual Enterprise are ca scop proiectarea şi dezvoltarea unei platforme pe care să se constituie şi să opereze întreprinderi virtuale la care să participe societăţi mici şi mijlocii căutate pe Internet cu ajutorul unor agenţi inteligenţi, ALIVE - Advanced Legal Issues in Virtual Enterprise - are ca scop studiul şi trasarea unor criterii de rezolvare a aspectelor legale care apar în cadrul întreprinderii virtuale între societăţile constitutive văzute ca indentităţi legale distincte, LEGAL-IST - Legal issues for the advancement of Information Society Technologiesand - are ca scop analiza şi rezolvarea aspectelor legale ce apar odată cu adoptarea de tehnologii şi metodologii inovative în cadrul Societăţii Informaţionale, aspecte care blochează implementarea tehnologiilor respective, ECOLEAD - European Collaborative networked Organizations LEADership initiative - are ca scop crearea fundamentelor solide şi a mecanismelor necesare constituirii celei mai avansate reţele colaborative de societăţi industriale din Europa. Există studii asupra aspectelor legale ce apar în funcţionarea unei întreprinderi virtuale. De exemplu, proiectul ALIVE susţinut de UE a avut chiar acest scop, acela de identificare şi clasificare a aspectelor legale care apar în cadrul întreprinderii virtuale între societăţile constitutive văzute ca identităţi legale distincte. În conformitate cu aspectul global al unei întreprinderi virtuale, proiectul a luat în considerare în studiul său şi întreprinderile virtuale din Statele Unite. Rezultatul primar al proiectului este o taxonomie a aspectelor legale se apar în constituirea şi funcţionarea unei întreprinderi virtuale. Un grup de interes s-a format în timpul derulării proiectului, grup care după finalizarea acestuia continuă să existe şi să formeze o comunitate virtuală de organizaţii care studiază aspectele legale care apar în cadrul întreprinderii virtuale. O altă încercare care vizează aspecte legale din cadrul întreprinderii virtuale, altele decât cele organizaţionale, îl reprezintă proiectul LEGAL-IST, proiect susţinut tot de UE şi care are ca scop identificarea, analiza şi clasificarea aspectelor legale ce apar odată cu adoptarea de tehnologii şi metodologii noi în cadrul Societăţii Informaţionale, aspecte care blochează implementarea imediată a tehnologiilor respective. Printre rezultatele proiectului se numără: consolidarea studiilor existente despre aspectele legale referitoare la tehnologiile emergente în Societatea Informaţională, suport şi recomandări pentru implementarea noilor tehnologii sau modele de business apărute în cercetare prin studiul aspectelor legale care pot afecta adopţia completă a rezultatelor, creşterea gradului de conştientizare asupra existenţei acestor aspecte legale care afectează adopţiile complete şi imediate de tehnologii Analiza comparativă a tehnologiilor de dezvoltare a întreprinderilor virtuale Internetul oferă tuturor posibilitatea schimbului rapid de informaţii grupate tematic, în jurul acestor teme creându-se comunităţi virtuale formate din membri care au interese comune. Aceste comunităţi îşi desfăşoară activitatea într-o manieră independentă în timp şi spaţiu. Comerţul electronic poate fi încadrat uşor în acest scenariu, un magazin virtual putând fi considerat o entitate într-o comunitate virtuală. În mod similar, fluxul operaţional poate fi distribuit în cadrul unei organizaţii sau chiar în afara acesteia, prin intermediul Internetului. Acest aspect deschide noi orizonturi de afaceri, de la munca la distanţă (de acasă, sau de pe teren utilizând echipamente şi reţele mobile) la procese complexe care compun o întreprindere virtuală. Cooperarea între agenţi economici care activează în acelaşi domeniu, au obiective similare şi sunt dispuşi la reconfigurare dinamică funcţie de cerinţele unei pieţe dinamice aduce în timp pag. 20 / 109

21 progresul aşteptat atât în ceea ce priveşte productivitatea cât şi creşterile economice. Produsele şi serviciile inovative obţinute în urma îmbinării avantajelor tehnologiilor de comunicaţii cu cele de comerţ electronic şi automatizare a proceselor de business garantează servicii ieftine dar eficiente orientate spre nevoile utilizatorului. De asemenea, informaţiile cu privire la procesele inovative în cadrul cărora utilizatorul este participant direct şi procesele care definesc fluxul operaţional fiind stocate într-o bancă de date se pot genera de rapoarte şi statistici care ilustrează eficinţa şi nivelul de competenţă a activităţilor realizate în fiecare sector Analiza tehnologiilor de proiectare şi dezvoltare a proceselor de business în cadrul unei întreprinderi virtuale Modelarea întreprinderii înseamnă un pas înainte spre externalizare, spre acumularea şi împărtăşirea cunoştinţelor de care dispune întreprinderea, lucru care reprezintă un suport vital pentru evoluţia sistemului din întreprindere. O problemă crucială în evoluţia sistemului din întreprindere este aceea că managementul nu cunoaşte foarte bine procesele care au loc şi nu conştientizează importanţa explicării şi detalierii lor prin modelare. Importanţa modelării întreprinderii se percepe mai ales în interesul vădit manifestat în ceea ce priveşte construirea arhitecturii de întreprindere, ceea ce a dus la revitalizarea cercetărilor în domeniu. Fiecare organizaţie (companie sau entitate publică) poate fi privită din punct de vedere al aspectelor statice (care se referă la structura organizaţiei) şi al aspectelor dinamice (organizarea fluxului de date). Organizaţia structurală cuprinde atât entităţi cât şi persoane şi implică obiective, sarcini, resurse şi relaţii. Acest aspect se caracterizează prin existenţa condiţiilor limitative pentru procesele de lucru. Reglarea proceselor de lucru ţine cont de fluxul de date al organizaţiei şi defineşte paşii de lucru, repartizarea lor pe axa temporală, diviziunea muncii, participanţii, obiectivele şi rezultatele muncii şi dependenţele dintre aceşti factori. Organizarea fluxului defineşte modul de realizare a muncii atât în întreprinderi cât şi în instituţiile publice. Procesele de business definesc foarte bine procesele de producţie în organizaţie, caracterizate prin diviziunea muncii între multiplii participanţi la activitate, la diferite momente de timp în diferite locuri şi sunt repetate în mod continuu de aceiaşi manieră, ţinând cont de totalitatea regulilor de validare, iar direcţionate pe utilizator arată doar câteva similarităţi sau repetiţii, în funcţie de regulile în continuă schimbare. Situaţia reală arată clar faptul că procesele de business orientate pe organizaţie sunt eficiente dacă dispun de anumite grade de flexibilitate pentru a putea rezolva situaţiile neprevăzute. Procesele de business orientate pe utilizator sunt supuse permanent reglării. Totalitatea proceselor de business sunt caracterizate prin atribute, ca de exemplu, numărul clienţilor, numărul comenzilor, datele şi documentele, fluxurile de date sau persoanele şi entităţile implicate. Managementul fluxurilor suportă definirea şi dezvoltarea proceselor sau şabloanelor utilizate pentru a surprinde similarităţile din procesele controlate din organizaţie. Repetiţia este suportată de automatizarea proceselor de execuţie în mediul de dezvoltare în care specificaţiile fluxurilor de producţie sunt reguli. Toate sistemele de management al fluxurilor fac distincţie între dezvoltarea şabloanelor de flux şi execuţia fluxurilor de producţie. Diferitele sisteme de management al fluxurilor folosesc soluţii diferite pentru definirea fluxurilor, instrumente diferite şi interfeţe. Pentru integrare, management şi redefinirea proceselor de e-business sunt folosite două sisteme diferite: Workflow Management Systems (WfMS) Enterprise Resource Planning (ERP). Ambele tehnologii tratează automatizarea proceselor de business, transferul de date şi vizualizarea colectivă a datelor. În industrie şi tehnologia academică, viitorul sistemelor WfMS şi ERP este pag. 21 / 109

22 diferit. Ambele pot fi utilizate independent sau împreună pentru dezvoltarea de aplicaţii pentru organizaţie via intranet sau internet. Diferenţele între sistemele WfMS şi ERP generează diferenţe între fluxul logic şi funcţiile logice, folosite pentru rezolvarea proceselor complexe. În sistemele ERP cele două componente sunt unificate, dar în sistemele WfMS sunt tratate separate şi explicit. Fluxul logic este captat în modelul de flux, reprezentat de obicei grafic, iar funcţiile logice sunt captate în aplicaţii, date şi oameni implicaţi în acest model. Sistemele WfMS permit dezvoltatorilor să separe fluxurile în funcţie de componentele sistemului (aplicaţii, date şi oameni) din modelul de flux. Sistemele de fluxuri sunt orientate pe procese insistând pe managementul funcţiilor logice prin intermediul unei infrastructuri omogene de date destinată pentru suportul unor aplicaţii multiple. Infrastructura fluxurilor poate fi dezvoltată în diferite domenii de la bio-informatică până la telecomunicaţii, sănătate, armată sau administraţie şcolară, calculatoare mobile, sisteme de management, baze de date multiple, dezvoltarea aplicaţiilor Internet, sisteme de operare şi managementul tranzacţiilor (Leymann şi Roller, 2000). Sistemele WfMS analizate sub acest aspect pot fi văzute ca platforme middleware care integrează diverse aplicaţii precum sisteme ERP şi aplicaţii independente la nivelul unei întreprinderi (Basu şi Kumar, 2002). Unele organizaţii internaţionale Workflow Management Coalition (WfMC) şi Workflow and Reengineering International Association (WARIA) au dezvoltat specificaţii pentru soft care vor permite diferitelor produse de management al fluxurilor sa interopereze în arii variate de activitate. Modelul dezvoltat de WfMC descrie arhitectura pentru sistemul de management al fluxurilor şi interfaţa între diferitele entităţi ale modelului. Distribuitorii de sisteme ERP încearcă să integreze sistemele WfMS în sistemele ERP. Unii vânzători îşi construiesc propriile sisteme de management al fluxurilor prin integrarea componentelor de fluxuri care conlucrează cu aplicaţiile ERP şi automatizează procesele, stabilesc reguli de business personalizate şi modelează procesele de afaceri utilizând constructorul grafic de fluxuri. În literatura de specialitate sistemele utilizate pentru dezvoltarea acestor tipuri de fluxuri sunt denumite generic Enterprise Application Integration (EAI) şi sisteme sau instrumente de Business Process Management (BPM) (Rupietta, 2005). Aceste sisteme sunt etichetate adesea drept a doua generaţie WfMS deoarece oferă o integrare mai mare faţă de sistemele WfMS tradiţionale. Metodologia de modelare a întreprinderii se concentrează pe responsabilităţile de business asociate rolurilor fiecărei părţi implicate. Un model de întreprindere este o reprezentare a structurii, activităţilor, proceselor, informaţiilor, resurselor şi comportamentului, a strategiilor şi a restricţiilor firmei şi a legăturilor cu exteriorul. În scopul obţinerii unei integrări complete a întreprinderii este necesar ca reprezentarea cunoştinţelor să fie făcută la un nivel minim de ambiguitate şi la un nivel maxim de înţelegere şi precizie în comunicare. Se consideră că un model generic, reutilizabil ca model de date pentru întreprindere, are următoarele caracteristici: Oferă o terminologie comună pentru întreprindere uşor de înţeles de către toţi utilizatorii Defineşte înţelesul fiecărui termen într-o manieră cât mai puţin ambiguă Implementează semantica care permite găsirea de răspuns la întrebările despre întreprindere Defineşte o simbolistică care explică orice termen, concept construit grafic. Din punct de vedere al designului, un model trebuie să ofere un limbaj care să definească explicit întreprinderea şi să determine impactul schimbărilor la toate nivelele întreprinderii. Din punctul de vedere al operaţiilor, un model trebuie să redea ceea ce este planificat, realizat şi s-ar putea realiza. La fel de importantă ca şi integrarea structurii întreprinderii pe baza proceselor este şi integrarea comportamentelor şi a informaţiilor. Evaluarea unui model de întreprindere se face în pag. 22 / 109

23 funcţie de şase criterii: completitudinea funcţională, generalitatea, eficienţa, perspicacitatea, precizia granularităţii, minimalitatea. Putem considera că modelul de întreprindere ca o reprezentare a structurii organizaţiei de business, cuprinde atât structura internă cât şi relaţiile cu mediul. Un model de întreprindere poate fi static sau dinamic. Un model static este un instantaneu al organizaţiei la un anumit moment. Un model dinamic reprezintă evoluţia organizaţiei în timp şi schimbările la care este supusă. Un model de întreprindere suportă următoarele activităţi : - Identificarea şi implementarea strategiilor de business cele mai potrivite pentru întreprindere în contextul evoluţiei ei; - Identificarea şi implementarea strategiilor radicale legate de evoluţie şi de management; - Justificarea costurilor, aprovizionării şi implementării tehnologiilor IT. În cadrul unui model de întreprindere se pot include concepte precum: organizaţie, agent, rol, process de business, valoare sau contract. În acelaşi timp, trebuie să menţionăm că un rol important în modelarea unei arhitecturi îl au uneltele de prelucrare a datelor şi de reprezentare a rezultatelor. Figura Artitectura multitier Data warehouse (Prelucrare dupa Jian Han Micheline Kamber, Intelligent Database System Research, Simon Fraser University, 2004, Ari Visa, Data Mining, Concepts and Techniques, textbook, Tampere University of Technology, 2004) Service Oriented Architecture (SOA) sau Arhitectură software bazată pe servicii presupune structurarea funcţionalităţii aplicaţiei în unităţi mai mici, distincte - numite servicii - care pot fi distribuite în reţea şi pot fi utilizate împreună pentru a crea aplicaţii destinate afacerilor. Capacitatea mare cu care pot fi reutilizate aceste servicii în aplicaţii diferite este o caracteristică a arhitecturilor software bazate pe servicii. Aceste servicii comunică între ele trimiţându-şi. În acest context, SOA este deseori văzută ca o evoluţie a programării distribuite si a programării modulare. În acelaşi timp, SOA este considerată de specialişti ca fiind o arhitectură flexibilă şi standardizată ce contribuie la o mai bună conectare a diverselor. SOA unifică procesele de business structurând marile aplicaţii într-o colecţie de module mai mici numite servicii. Serviciile sunt unităţi funcţionale neasociate care nu au apeluri unele către altele. În mod tipic, în cadrul acestor servicii sunt implementate funcţionalităţi pe care majoritatea utilizatorilor le recunosc ca şi servicii informatice obişnuite. Serviciile au comunicaţia între ele implementată prin protocoalele. Privită din punctul de vedere al proiectanţilor de aplicaţii, SOA este o paradigmă pentru proiectarea, dezvoltarea, implementarea şi administrarea serviciilor într-un mediu informatic. Ea pag. 23 / 109

24 impune dezvoltatorilor să proiecteze o aplicaţie ca pe o colecţie de servicii, chiar dacă beneficiile acestora nu sunt evidente imediat şi cere programatorilor să gândească dincolo de graniţele aplicaţiilor, adică să ia în considerare refolosirea serviciilor existente sau să analizeze oportunitatea refolosirii serviciilor create de ei (Allen, 2006). SOA ajută companiile să înţeleagă când şi de ce sunt folosite serviciile pe care le furnizează, permiţând astfel administratorilor sau analiştilor să optimizeze procesele de afaceri. SOA nu este doar o metodologie de dezvoltare, ea are şi aspecte administrative. Aplicaţiile pentru afaceri, realizate pe baza unei arhitecturi SOA, cu resurse distribuite Internet sunt proiectate şi dezvoltate utilizând medii de dezvoltare care să asigure pe de o parte eficienţa echipelor de proiectanţi, iar pe de altă parte utilizarea simplă, sigură şi la nivelul aşteptărilor oamenilor de afaceri, ai acestor aplicaţii. Aplicaţiile pentru afaceri realizate pe baza tehnologiilor internet cresc flexibilitatea în afaceri a firmelor, transparenţa şi integrarea impusă de societatea informaţională. În concluzie, SOA este o modalitate deosebit de eficientă, eficace din punctul de vedere al costurilor, de integrare a sistemelor IT eterogene şi de creştere a abilităţii în afaceri. Intreprinderea virtuală şi sistemele de asistare a deciziilor Grupurile au o pondere foarte mare în luarea de decizii iar într-o întreprindere virtuală rezolvarea unor probleme complexe necesită colaborare între oameni, acest lucru ducând necesitatea formării de grupuri de lucru (workgroup). Colaborarea presupune ca oamenii conlucrează şi comunică în mod activ, aflaţi în locaţii diferite şi în intervale orare diferite. A fost subliniată astfel necesitatea de a studia întreprinderea virtuală din perspectiva teoriei sistemelor de asistare a deciziilor precum şi a teoriei sistemelor colaborative. Conceptual, un sistem de asistare a deciziilor (SAD) e un sistem simplu, robust, uşor de folosit care susţine şi îmbunătăţeste luarea de decizii manageriale într-un timp cât mai scurt, cu precădere acelea care nu se bazează în totalitate pe un algoritm precis. Un SAD este construit în jurul unui set de proceduri clare de prelucrate a unor date şi aduce sub o interfaţă comună analiza ad-hoc a datelor şi modelarea deciziilor. Un SAD tinde să susţină managerul în luarea deciziilor şi nu să-l înlocuiască. Cele mai uzuale implementări de SAD-uri rulează distribuit pe servere şi mainframe-uri şi sunt accesate printr-o varietate mare de reţele de pe calculatoare staţionare şi dispozitive mobile (notebook-uri, PDA-uri, telefoane, tablet PC-uri). Arhitectura unui SAD conţine trei componente fundamentale: sistemul de management al bazei de date, sistemul de management al modelelor, interfaţa utilizator de interacţiune cu sistemul. Alte arhitecturi includ şi o componentă de motor de cunoştinţe, iar altele vorbesc despre o bază de cunoştinte care conţine toate datele cu care lucrează sistemul, de la datele asupra cărora se construiesc modele, la modele în sine respectiv cele de optimizare. Un standard de-facto în implementarea unui SAD a devenit accesul cu ajutorul Webbrowser-ului preferat (sau a unei aplicatii de tip GUI) la un server care accesează datele necesare şi distribuie procesul de soluţionare a problemelor analitice de mari dimensiuni la mai multe servere şi ulterior propune utilizatorului unul sau mai multe modele. Utilizarea browserelor Web în conjuncţie cu serviciile Web tinde să devină o soluţie extrem de utilizată de implementare a arhitecturilor web-based de tip client-server şi prin urmare şi a SAD-urilor deoarece: - un serviciu Web beneficiază de avantajul de a putea fi accesat din orice locaţie prin Internet prin respectarea unui protocol de comunicare (SOAP) şi se efectuarea operaţiilor de cerere şi răspuns, specificate într-un WSDL (Web Service Definition Language), - serviciile Web se bazează pe standarde deschise (HTTP/IP, XML), care deschid calea interoperabilităţii. pag. 24 / 109

25 Pentru o interfaţare şi mai prietenoasa cu serviciul Web se va alege o aplicatie de tip GUI care vine să raspunda unor eventuale nevoi specifice ale SAD-ului. În ceea ce priveşte platforma colaborativă, pentru unificarea comunicării şi colaborării (sincrone sau asincrone) între entităţi independente, printre componentele de nucleu ale acesteia trebuie să se numere cu necesitate: componenta de mesagerie (comunicare asincronă) oferă suport pentru: , calendar şi orar, lista de contacte, componenta de colaborare în grup care oferă suport pentru: sincronizarea de fişiere, idei, notiţe, managementul task-urilor, componenta de colaborare în timp real (comunicare sincronă) care oferă suport pentru: mesagerie în timp real, conferinţa Web, confeinţe video şi audio. Printre implementarile existente de platforme colaborative amintim: - centrate pe informatie tip wiki: Socialtext, pbwiki, MindTouch, JotSpot, BrightSide Software, Wetpaint, - WebEx Connect: platforma de socializare care permite personalizarea de widgeturi, - Microsoft SharePoint: platforma pentru socializare in retea, platforma de management de documentes; prezinta si o unealta de management si automatizare a proceselor de business. Instrumente de modelare a unei întreprinderi virtuale - Visual Paradigm pentru UML Mediul VP-UML conţine, pentru a lucra cu sistemele orientate-obiect, o colecţie de meniuri, toolbar-uri şi ferestre care permit, într-un mediu evoluat, creearea diferitelor tipuri de diagrame într-un mod complet vizual. VP-UML oferă verificare continuă a sintaxei UML. Un obiect este un auto-conţinut, entitate cu caracteristici bine definite şi comportamente, caracteristicile şi comportamentele sunt reprezentate de atribute. O clasă este o definiţie generică pentru un set de obiecte similare. Prin urmare, un obiect este o instanţă a clasei. Un obiect oferă un model conceptual ţinând cont de o cerere. Două tipuri de obiecte modele sunt suportate: - unul, numit obiect model de generare de Java API şi model.net este model API, - altul, numit Enterprise JavaBeans, este modelul utilizat pentru a genera Enterprise JavaBeans. Principala diferenţă între aceste două modele este capacitatea de a construi o distanţă şi distribuţie de aplicare. Vizualizarea modelării pentru obiect este oferită, nu numai pentru a crea un nou obiect model, dar şi pentru transformarea datelor de la un model. Maparea obiectelor-relaţionale este automatizată, baza de date şi codul de strat pot fi generate. În mediul de lucru, este permisă configurarea conexiunii la bazei de date pentru dezvoltarea proiectelor. Cum baza de date a fost configurată înainte de generarea codurilor persistente, clasele Java persistente ORM şi un set de fişiere ORM sunt generate împreună; în timp ce un set de fişiere ORM configurează mediul pentru conectarea claselor persistente generate. Prin urmare, este permis să se acceseze baza de date direct prin clasa persistentă Java, fără a folosesi orice fel de cod pentru setarea conexiunii bazei de date. Alături de notările standard UML, se pot extinde posibilităţile de diagrame şi modele ce încorporează imagini la diagrame prin Visio Shapes şi Image Shapes. Visio este un instrument universal de diagrame ce furnizează multe forme (shapes) pentru afaceri şi diagrame tehnice. Cu integrarea Visio, se pot crea diagrame UML cu desene Visio în VP-UML. Shape este o formă care afişează o imagine pe diagramă şi reprezintă cel mai convenabil mod de adăugare imagini la diagrame, la documente şi de adnotare a ideilor importante. Uneltele (Tools) puse la dispozitie permit generarea de rapoarte in format HTML, PDF, MS Word, crearea de rapoarte ad-hoc, publicarea proiectelor Visual Paradigm in documente Web accesate în orice browser Web, conversii de fisiere in modele VP-UML. In acest mod se oferǎ posibilitatea editǎrii codului sursǎ într-o varietate de limbaje, dar şi integrarea facilǎ a aplicaţiilor pag. 25 / 109

26 existente cu cod nativ prin conversii de fisiere Java şi fisiere clasa în modele VP-UML, fişiere C++, librarii (dll) sau exe din format.net, sau fişiere PHP 5.0 în modele VP-UML sau chiar implementarea unor soluţii distribuite prin convesii de fisiere CORBA IDL în modele VP-UML. Soluţiile de portabilitate şi semantic Web sunt tratate prin convertsi fisiere Ada 9X, XML sau scheme XML, Hibernate XML în modele VP-UML iar la nivelul tabelelor din baze de date JDBC in modele VP-UML. Modelele VP-UML permit generarea automatǎ a codului Java, C#, Visual Basic.NET, PHP, ODL, ActionScript, IDL, Delphi, Perl, scheme XML, cod Phyton Objective-C. Prin Object-Relational Mapping (ORM) sunt gestionate sarcinile automate precum generarea de cod din bazele de date, generarea de cod şi bazele de date de tip ERD, bazele de date JDBC (drivere şi conexiuni), conversii din baza curenta de date în Entity Relationship Diagram (ERD), din clasele Java în Clase Diagram sau conversii de fişierele XML Hibernate în modele VP-UML sau de obiecte Enterprise Framework in modele VP-UML. Sincronizarea bidirecţionalǎ a fisierul ERD curent cu Diagrama de Clase, generarea unei baze de date din fisierul ERD existent, generarea de clase persistente pentru conservarea datelor dintr-o aplicaţie prin ORM, sau integrarea cu Eclipse, Jbuilder, NetBeans, IntelliJ IDEA, Jdeveloper sau WebLogic Photoshop, prin opţiunea IDE Integration sunt facilitǎţi ce permit dezvoltarea unor aplicaţii complexe folosind soluţii de interoperabilitate şi coduri reutilizabile Aplicaţii pentru managementul conţinutului informaţional şi a fluxului operaţional Clasele de aplicaţii pentru managementul conţinutului informaţional şi gestionarea fluxului operaţional îşi pun amprenta, tot mai pronunţat, asupra manierei în care actorii economici îşi joacă propriul rol pe piaţă, aceştia fiind dispuşi la o serie de concesii de ordin material şi tehnologic care să le garanteze reale avantaje atât în cazul procesului de producţie cât şi în ceea ce priveşte promovarea şi vânzarea de noi produse şi servicii. Ader (2001) ilustrează în studiile sale noi metode de reorganizare a muncii utilizând tehnologiile digitale, descrie maniera în care noile tehnologii pot afecta condiţiile de muncă, demonstrează modalitatea prin care acestea fac posibilă competiţia între întreprinderile virtuale şi cele tradiţionale, schiţează scenarii posibile de creare a întreprinderilor virtuale şi defineşte condiţiile de funcţionare a organizaţiilor virtuale. Toate acestea conduc la noi forme de anteprenoriat economic în cadrul căruia mai mulţi agenţi econimici îşi partajează cunoştinţele, instrumentele şi resursele pentru a oferi servicii asemeni unei instituţii tradiţionale. Acest tip de parteneriat se bazează pe strategii de dezvoltare economică pe termen lung care permit: Lansarea noilor produse şi servicii pe piaţă, mai accesibilă pentru instituţiile mici care, pe această cale, au posibilitatea de a intra în competiţie cu organizaţiile tradiţionale Identificarea, în condiţii de costuri minime, a unor parteneri pentru crearea unei întreprinderi virtuale, care permite cooperări internaţionale şi intensifică mobilitatea la nivel internţional şi inter-regional. Noi forme de anteprenoriat econimic, cu scopul de a spori interesul pentru inovare şi diversificarea produselor şi serviciilor, condiţii de bază pentru dezvoltare economică durabilă. Creşterea concurenţei pentru organizaţiile tradiţionale din partea unor concurenţi nontradiţionali, care are menirea de a constrânge întreprinderile tradiţionale la adoptarea unor noi metode de organizare a fluxului operaţional pentru creşterea competitivităţii propriilor produse şi servicii. Ader (2001) prezintă conceptul de reorganizare a muncii în cadrul întreprinderilor virtuale prin prisma celor două aspecte fundamentale care-l definesc: managementul conţinutului informaţional şi managementul fluxului operaţional. Componentele de management al conţinutului informaţional constă într-o serie de instrumente pentru gestionarea conţinutului (stocarea, pag. 26 / 109

27 modificarea sau accesarea conţinutului informaţional în diferite formate) cum ar fi: instrumente de managementul documentelor, instrumente pentru gestionarea băncilor de date, instrumente lingvistice care oferă suport pentru interogara băncilor de date în limbaje naturale, etc. Componentele de managementul fluxului operaţional au la bază o serie de instrumente dedicate fluxului de producţie cum ar fi: instrumente de comunicare între persoane care au sarcini comune, instrumente de planificare a activităţilor colective care permit şi partajarea resurselor comune, forum de discuţii pentru abordarea anumitor teme de real inters, instrumente colaborative care furnizează acces simultan la diferite resurse cu scopul de a îmbunătăţi procesul de producţie, instrumente de management al fluxului operaţional care gestionează întreg ciclul de operaţiuni, etc. Dacă instrumentele din prima clasă de aplicaţii, pentru managementul conţinutului informaţional, sunt utilizate pentru a decide ce să se producă şi cum, cele din a doua clasa de aplicaţii, pentru managementul fluxului operaţional, ajută la finalizarea cu succes a sarcinilor de producţie. Aplicaţii pentru managementul conţinutului informaţional Tehnologiile utilizate în cadrul aplicaţiilor de management al conţinutului informaţional constă într-un set de instrumente pentru indexarea şi accesul selectiv la informaţie, în orice formă s-ar găsi aceasta: - Documente managementul documentelor prevede proiectarea unei biblioteci virtuale menită să stocheze orice tip de document şi să ofere acces selectiv la documentele stocate în baza unui profil de acces. Managementul documentelor prevede, de asemenea, implementarea unor componente inteligente pentru eficientizarea accesului la biblioteca virtuală. - Text funcţionalităţile de management al informaţiei de tip text sunt implementate de către entităţi sotfware care au în componenţă structuri inteligente de indexare şi citire selectivă a textului din bănci de date. Aceste entităţi sunt completate cu structurile inteligente de căutare avansată funcţie de textul solicitat. - Format multimedia caracteristicile de management al informaţiei multimedia sunt furnizate de către componente care asigură indexarea informaţiei multimedia în bănci de date cu grad sporit de complexitate sau accesul rapid la aceste informaţii. Băncile de date cuprind, de asemenea informaţiile semantice care caracterizează fiecare element multimedia stocat, aspect menit să eficientizeze accesul selectiv la informaţiile solicitate. Figura Componentele unei aplicaţii de management al conţinutului informaţional pag. 27 / 109

28 Există o serie de componente lingvistice care cresc eficienţa sistemelor de management al conţinului informaţional prin metodele avansate de interfaţare cu utilizatorul realizate în baza conceptului de rich client (interfeţe multimodale om-maşină) şi a conceptului de interogare a băncilor de date prin intermediul limbajului natural. Instrumentele inteligente de căutare avansată au ca şi obiectiv specific interpretarea cerinţelor pieţei şi a doleanţelor utilizatorilor, fapt care aduce valoare adăugată sistemului de tip întreprindere virtuală. Conceptul Datawarehouse Există o serie de metode de stocare a conţinutului informaţional, cele mai populare prevăd indexarea informaţiilor în baze de date relaţionale, baze de date distribuite orizontal şi vertical sau baze de date obiectuale. Conceptul de bancă de date (datawarehouse) oferă, în plus, posibilitatea de a stoca diferite date în formate compacte şi un set de instrumente pentru acces rapid la date, elaborarea de rapoarte de analiză şi statistici cu privire la datele stocare şi accesarea lor de către diferite componente din cadrul sistemului. Dat fiind volumul mare de date stocate în baca de date, instrumentele inteligente de acces rapid îşi demonstrează utilitatea iar instrumentele inteligente pentru generarea de statistici şi analize conlucrează perfect cu instrumentele inteligente de interpretare a cerinţelor pieţei şi utilizatorilor sistemului. Băncile de date prezintă o serie de caracteristici dintre care se amintesc: Băncile de date sunt orientate pe subiect, de exemplu banca de date orientată pe vânzări care ajută utilizatorul în elaborarea rapoartelor şi analizelor complexe cu privire la situaţia vânzărilor Băncile de date permit integrarea transparentă a datelor de la surse diferite într-un format consistent fără a genera conflicte (de exemplu, conflict de nume, etc.) Băncile de date sunt nevolatile datele stocate în bănci de date nu pot fi schimbate Băncile de date sunt variante în timp. Accesul la informaţii într-o manieră rapidă şi dinamică în vederea elaborarii de statistici şi analize este furnizat de către componentele de gestionare a băncii de date care implementează o serie de algoritmi de accesare a datelor şi de sortare a datelor şi integrare a lor pentru a fi procesate şi prezentate la utilizator. Datele pot fi accesate prin intermediul unei componente de acces la banca de date care funcţionează la nivel local sau într-o manieră distribuită, în concordanţă cu modul de organizare al băncii de date. Băncile de date oferă soluţii de sortare avansată cu funcţionalităţi de extragere, transport, transformare şi încărcare a datelor. De asemenea, conţin componente de tip OLAP engine care înglobează un set de funcţionalităţi pentru business intelligence sau instrumente de analiză şi raportare care ajută la prezentarea datelor într-o formă cât mai sugestivă (reprezentări grafice, etc.). Contrar conceptului OLTP (online transaction processing) unde datele sunt arhivate, OLAP permite stocarea datelor pe parcursul funcţionarii unui sistem (luni, ani, etc.). Conceptul de bancă de date este implementat pe o arhitectură stratificată în care se remarcă: - operational database layer (ODL) ce cuprinde sursa băncii de date - informational access layer (IAL) cu informaţiile şi instrumentele pentru elaborarea de rapoarte şi analize - data access layer (DAL) definit de instrumentele de sortare, prelucrare şi încărcare a datelor din banca de date implementând metodele de interfaţare între cele două nivele ODL şi IAL - metadata layer (MDL) ce cuprinde dicţionarele pentru întreaga bancă de date În figura este ilustrată arhitectura stratificată a unei bănci de date: sursa băncii de date constă în sisteme operaţionale, structuri de fişiere, etc, dicţionarele băncii de date compun stratul MDL, funcţionalităţile de manipulare a datelor brute şi acces la sursele de date sunt implementate de către componentele nivelului DAL iar instrumentele găzduite de stratul IAL au ca şi obiectiv elaborarea de rapoarte şi analize pornind de la date compacte. pag. 28 / 109

29 Figura Arhitectura unei bănci de date Simplificarea funcţionalităţilor de managementul al băncii de date şi compactizarea datelor procesate implică o serie de componente pentru formatarea şi procesarea datelor brute înainte de a fi stocate, prin intermediul unor componente care compun Staging Area. Astfel, arhitectura băncii de date va avea formatul din figura de mai jos. Figura Arhitectura unei bănci de date cu Staging Area Pentru îmbunătăţirea timpului de răspuns la furnizarea datelor solicitate de utilizator, se introduc structuri de date de tip Data Marts focalizate pe anumite funcţionalităţi de business. Data Marts reprezintă o soluţie mult sub costurile unei bănci de date este uşor de creat şi configurat. În cazul implicării unor structuri de tip Data Marts pentru îmbunătăţirea performanţelor, arhitectura unei bănci de date arată ca şi în figura de mai jos: pag. 29 / 109

30 Figura Arhitectura unei bănci de date cu Staging Area şi Data Marts Procesul de proiectare a unei bănci de date pentru stocarea informaţiilor utilizate în cadrul unui sistem E-Business cuprinde următoarele etape: definirea conţinutului informaţional specific definirea relaţiilor între şi în cadrul grupurilor informaţionale definirea infrastructurii fizice specifică sistemului E-Business definirea relaţiilor de transformare a datelor definirea aspectelor privind frecvenţa de actualizare a datelor definirea relaţiilor logice dintre obiecte (design logic) definirea aspectelor privind indexarea şi sortarea, transportul şi arhivarea datelor (design fizic) Design-ul logic al unei bănci de date ilustrează banca de date la nivel conceptual. Modelarea relaţiilor între entităţile unui sistem E-Business şi proprietăţile acestora este privită ca modelare a conţinutului informaţional din cadrul organizaţiei/organizaţiilor care participă activ la procesele de business. Luând exemplul bazelor de date relaţionale, entitatea mapează, de obicei, un tabel iar un atribut al entităţii face referire la o coloană a unui tabel. În cazul băncilor de date, identificatorii unici folosiţi în design-ul logic garantează consistenţa datelor iar motorul OLAP permite modelarea dimensională a băncii de date. Există două abordări privind stocarea datelor într-o bancă de date: abordarea dimensională şi abordarea normalizată. În cazul abordării dimensionale, tranzacţiile sunt divizate în entităţi de tip fact şi dimension. De exemplu, o tranzacţie din cadrul unui sistem de vânzări poate fi divizată în entităţi de tip facts cum ar fi numărul de produse comandate şi preţul plătit şi entităţi de tip dimension ca, de exemplu, data achiziţionării, cod de identificare produs, numele vânzătorului, etc. Această abordare prezintă avantaje notabie: banca de date are o structură uşor de înţeles şi utilizat, sau, accesul la datele stocate şi operaţiile de sortare se realizează rapid. Ca şi principale dezavantaje se remarcă: dificultăţile întâlnite la modificarea structurii băncii de date sau în cazul populării băncii de date cu date din alte sisteme operaţionale în condiţii de integritate a datelor. Abordarea normalizată specifică faptul că stocarea datelor respectă normalizarea Codd proiectarea structurilor de date (de exemplu, tabele) se face în aşa fel încât se evită duplicarea informaţiilor şi se asigură, totodată, securitatea conţinutului informaţional stocat. Pentru aceasta, structurile de date sunt grupate pe categorii de date (produse, finanţe, clienţi, etc.). Principalul avantaj oferit de abordarea normalizată privind stocarea datelor într-o bancă de date constă în uşurinţa cu care se adaugă noi informaţii. Ca şi dezavantaj se remarcă numărul mare de structuri de date folosite care îngreunează accesul utilizatorilor la diferite surse de date în cazul în care nu există o imagine reală a sursei de date. pag. 30 / 109

31 Diagrama unei bănci de date este o colecţie de obiecte incluzând tabele, indecşi, etc. Obiectele respectă modele caracteristice băncilor de date. Cele mai multe bănci de date respectă modelul dimensional şi implementează diagrama stea considerată cea mai simplă diagramă de bancă de date unde punctul central al diagramei este o entitate de tip fact. Conceptul Data Mining Data Mining reprezintă procesul de extragere a modelelor din structurile complexe de date. Altfel spus, identificarea structurilor informaţionale dintr-un volum mare de date (bancă de date) se realizează prin intermediul tehnicilor de recunoaştere a modelelor de date având la bază funcţii de corelaţie între structurile de date. În urma validărilor corespunzătoare, modelele identificate prin procesul de data mining se transformă în cunoştinţe utilizate ulterior pentru a fundamenta luarea deciziilor. Modelele de data mining implementează metodele statistice clasice şi promovează ideea de extindere a acestora incluzând elemente de inteligenţă artificială. De exemplu, o component de management al pacienţilor din cadrul unui sistem E-Health implementează funcţionalităţi de identificare a procedurilor medicale pentru fiecare pacient şi predicţia privind noile strategii de îngrijire a sănătăţii, factorul de risc în cazul unor pacienţi cu probleme sau fraude în sistemul sanitar. Structura tipică de date potrivită pentru data mining conţine observatiile (cazurile, de exemplu referitoare la pacienti) plasate pe linii iar variabilele plasate pe coloane. Domeniile sau intervalele de valori pentru fiecare variabilă vor fi definite precis, evitându-se exprimările vagi. Formatul pe linii ce corespund observaţiilor sau cazurilor şi coloane ce corespund variabilelor, similar cu cel al unui fisier Excel, este reprezentativ pentru data mining. Înainte de a aplica instrumente de data mining unor structuri de date, este necesară o pregătire prealabilă a acestor date care cuprinde: Preprocesarea datelor se elimină datele care nu sunt necesare, se verifică consistenţa datelor (unităţilor de măsură), se detectează datele eronate şi se elimină valorile extreme; Integrarea datelor se prevăd metodele de combinare a unor variabile; Transformarea variabilelor cuprinde standardizarea şi trecerea la scală logaritmică; Separarea bazei de date în trei categorii de date: categoria de antrenament, validare şi testare; Folosirea statisticilor descriptive clasice simple: media, mediana, amplitudinea, abaterea standard, cuartilele; Folosirea diagramelor simple: histograme ale frecvenţelor, box plot-uri, diagrame cu bare, diagrame radiale (rozeta). Metodele data mining de învăţare pot fi grupate în două categorii: cele nesupervizate şi supervizate. Metodele de învăţare nesupervizate includ: Analiza Componentelor Principale (ACP) cu scopul de a reduce dimensionalitatea datelor prin integrarea variabilelor corelate, transformând liniar variabilele iniţiale în variabile necorelate; Analiza Factoriala (Factor Analysis) cu obiectivul de a extrage un numar mic de factori ascunşi; Analiza Clasificarii (Cluster Analysis) cu scopul de a grupa cazurile (observaţiile) în clustere (grupuri, categorii). Principalele metode de învatare supervizata implică: Regresia Liniara Multipla are ca şi obiectiv descrierea asociaţiilor între doua seturi de variabile, prin intermediul unor formule liniare. Aceste formule sunt folosite ulterior pentru predicţia valorilor variabilelor de raspuns când se cunosc valorile variabilelor predictor; Regresia Logistica prevede răspunsul ca o variabilă binară sau ordinală (nu una continuă); Reţelele Neuronale cu rolul de a clasifica datele dintr-o bancă de date funcţie de diferiţi parametri de intrare. O reţea neuronală conţine de obicei mult mai mulţi parametri decât un model statistic clasic, are nevoie de mult mai mult timp pentru antrenare, iar rezultatele obţinute nu pot fi interpretate cu usurinţă; Analiza Funcţiilor Discriminante este o metodă folosită pentru a determina care dintre variabilele predictor discriminează corect între mai multe grupuri formate natural. pag. 31 / 109

32 Componente de tip Business Intelligence Business Intelligence face referire, în primul rând, la informaţii despre afaceri, informaţii care contribuie decisiv la procesele de adoptare a deciziilor privind derularea afacerii, fie ele strategice, fie legate de operaţiunile de zi cu zi. Acest aspect este privit de multe ori cu scepticism de către personalul care gestionează o anumită afacere, mai ales dacă există deja un sistem ERP implementat în cadrul organizaţiei respective iar acesta furnizează o serie de funcţionalităţi avansate pentru managementul proceselor de business. Totuşi, există o serie de probleme pe care le ridică mediul de business şi la care sistemele ERP clasice nu au răspunsuri. Dintre acestea cele ami stringente ar fi: Care este cel mai profitabil produs pe care organizaţia îl comercializează? Care este evoluţia marjei de profit pe un anumit produs de-a lungul ultimilor ani? Cum pot fi reduse eficient cheltuielile operaţionale fără a afecta performanţa afacerii? Cum pot fi reduse pierderile pe lanţul de aprovizionare sau pe circuitul de producţie? Care este volumul de afaceri pe care propria organizaţie îl face cu furnizorul anume şi ce discount se poate solicita în perioada următoare de la acest furnizor? Care este cel mai performant agent de vânzări din organizaţie? Cum se pot automatiza procesele în cadrul blocurilor functionale şi între acestea? Cum se pot gestiona blocurile funcţionale distribuite în cadrul concernelor internaţionale sau întreprinderilor virtuale? Răspunsurile la aceste probleme vin de la componentele de tip business inteligence care implementează funcţionalităţi de management al conţinutului informaţional şi automatizare a proceselor de business din cadrul unei organizaţii. Ideea de performanţă maximă cu costuri minime reprezintă o prioritate în afaceri. Cu atât mai mult, în perioadă de recesiune economic, acest principiu primează în logica celor care administrează organizaţii şi doresc nu doar să supravieţuiască perioadei ci şi să progreseze aducând pe piaţă noi produse şi servicii la preţuri competitive. Informaţia detaliată şi precisă devine crucială pentru procesele de adoptare a deciziilor chiar dacă acestea sunt sub stricta îndrumare a factorului uman. Nici un specialist nu contestă faptul că o organizaţie poate să-şi desfăşoare activitatea în bune condiţiuni şi fără a beneficia de serviciile furnizate de componentele de tip business intelligence, doar că rapoartele de analiză necesită personal specializat (analişti) care sunt supuşi erori (eroarea umană), au nevoie de timp pentru a desfăşura activităţi repetitive de extragere a datelor, de formatare a acestor date, sau de definire a diverselor formule şi calcule necesare finalizării sarcinilor specifice. Capacitatea acestor persoane nu este pusă la îndoială dar activităţile repetitive, de multe ori plictisitoare, pot fi făcute fie în grabă, fie cu neatenţie şi se finalizează cu erori. De multe ori informaţiile îşi pierd integritatea, acurateţea, confidenţialitatea şi credibilitatea în astfel de procese, dat fiind faptul că sunt partajate între departamente, fără a se lua măsurile de securitate necesare transferului de date pe reţeaua locală/internet. Un sistem de gestiune automată a datelor asigură o serie de avantaje pentru asistarea factorului uman în luarea unor decizii sau realizarea unor sarcini repetitive consumatoare de resurse. În implementarea unui sistem de asistare a deciziilor (SAD) se ţine cont de următoarele: Clasificarea datelor şi transformarea lor în cunoştinţe specifice sectorului unde organizaţia respectivă îşi desfăşoară activitatea; Accesul selectiv la aceste cunoştinţe într-o manieră securizată; Generarea de rapoarte şi analize complexe; Reducerea timpilor morţi pentru activităţi de raportare periodică sau alte activităţi periodice; Reducerea rolului departamentului IT în generarea de rapoarte Reducerea timpului necesar adoptării unei decizii În literatură sunt întâlnite mai multe definiţii ale deciziei, câteva dintre acestea fiind redate în cele ce urmează: pag. 32 / 109

33 Alegerea unei direcţii de acţiune (Simon, 1960); O alegere conducând la un anume obiectiv dorit (Churchman 1968); O formă specifică de angajare într-o acţiune (Minzberg 1980); Alegerea uneia dintr-un număr de alternative; cunoştinţe care indică o angajare într-o anumită direcţie de acţiune (Holsapple, Whinston 1996); O alocare de resurse (Spradlin 1996); Alegerea uneia din mai multe alternative; o afirmaţie care arată angajarea într-o direcţie de acţiune (Power, 2000). Din definiţiile prezentate anterior se pot distinge elementele de bază care definesc decizia. Astfel se poate afirma că decizia este rezultatul unei activităţi conştiente (se bazează pe cunoştinţe) de alegere, de către o persoană sau un grup de persoane care dispun de autoritatea necesară, a unei direcţii de acţiune din mai multe alternative posibile identificate sau proiectate şi angajarea în direcţia de acţiune aleasă, care de obicei presupune şi alocarea de resurse urmărindu-se atingerea obiectivelor propuse în anumite situaţii date. Un aspect important îl constituie evidenţierea diferenţei între acţiunea generată de o decizie şi ceea ce se numeşte în psihologia cognitivă comportament pur, care semnifică o reacţie la stimuli. Decizia la modul general este o activitate specific umană, nefiind exclusă însă şi decizia automată luată de un sistem, cu implicaţii atât în viaţa particular cât şi în cea profesională. Decizia în domeniul economic şi financiar este definită ca fiind un proces de alegere care face referire la determinarea unor obiective, la stabilirea unei poziţii în raport cu o problemă cu care se confruntă întreprinderea sau la gestionarea resurselor întreprinderii şi anume modificarea şi combinarea internă a resurselor, sau căutarea şi achiziţionarea de noi resurse. Decizia este un act de conducere luat fie de echipa mangerială, fie de persoanele cărora le-a fost delegată puterea de decizie. O decizie este numită logic implicită dacă aceasta se impune în funcţie de judecăţile de valoare care o preced şi corespunde unei speranţe de utilitate maximală. Un sistem de timp SAD este menit să asiste factorul de decizie sau să opereze automat în elaborarea unei imagini de ansamblu a obiectivelor propuse, în funcţie de configuraţiile pe care le suportă organizaţia. Acesta furnizează informaţii într-un anumit domeniu în baza modelelor analitice de decizie şi a informaţiilor culese din băncile de date la care are acces. Sistemul decizional trebuie organizat de o manieră raţională pentru a putea fi capabil să ia decizii optime în intervale de timp acceptabile ţinând însă cont de importanţa acestora. Procesul decizional în viziunea clasică este un proces complex prin care se identifică, colectează şi evaluează informaţiile despre o anumită situaţie analizată, se identifică nevoia unei decizii, se identifică sau se definesc evoluţiile alternative relevante, se alege cea mai bună acţiune iar apoi se aplicǎ soluţia aleasă. Procesul de decizie poate fi analizat din mai multe perspective şi anume: Analiza procesului decizional pe baza modelului informatic; Analiza procesului decizional pe baza modelului matematic; Analiza procesului decizional pe baza modelului sociologic; Analiza procesului decizional pe baza modelului sistemic. Analiza procesului de decizie pe baza modelului informatic are la bază faptul că procesul de decizie este asimilat unui computer, el regrupând trei elemente principale: Memoria asimilată ansamblului de informaţii disponibile şi stocate Aplicaţiile de prelucrare a informaţiilor disponibile în memorie pentru a se ajunge la o decizie. Există două tipuri de prelucrări: o Prelucrări algoritmice care au la bază operaţii elementare care conduc în etape succesive şi iterative la soluţia problemei. o Prelucrări euristice care presupun rezolvarea problemei prin tatonări succesive; pag. 33 / 109

34 Procesorul este asimilat decidenţilor întreprinderii, cei care prelucrează informaţia. Eficienţa acestor prelucrări depinde de capacitatea de prelucrare a decidentului, de calitatea informaţiilor disponibile şi de calitatea aplicaţiilor disponibile. Abordarea procesului decizional, evidenţiază două condiţii de bază: necesitatea existenţei informaţiilor disponibile şi de calitate şi cunoaşterea gradului de competenţă a decidentului. Deciziile inapte se pot datora mai multor situaţii. Se consideră exemplul informaţiilor incomplete şi eronate de care dispune decidentul, a erorilor de concepere a funcţionalităţilor de prelucrare a datelor, a erorilor de execuţie în prelucrarea datelor, sau a imposibilităţii execuţiei prelucrărilor algoritmice. În aceste cazuri se va aplica metoda de prelucrare euristică. Analiza procesului decizional pe baza modelului matematic aşa cum o sugerează şi titlul se bazează pe algoritmi matematici. Aceste modele se caracterizează prin: Identificarea variabilelor ce vor fi luate în calcul Evidenţierea relaţiilor între variabile (stabilirea ecuaţiilor de estimare a modelului) Identificarea criteriilor de decizie, apoi formularea funcţiilor de optimizat Stabilirea procedurii de rezolvare a problemei (sistemului de ecuaţii şi inecuaţii componente ale modelului) În literatură, modelele matematice au fost împărţite în două mari categorii şi anume: modelele deterministe şi modelele aleatoare. Cele din prima categorie pleacă de la premiza că toate elementele problemei de tratat sunt cunoscute cu certitudine şi nu sunt afectate de factori perturbatori (modelul Du Pont de analizǎ a rentabilităţii financiare). Cele din a doua categorie, modelele aleatoare au la bază ideea că anumite elemente ale problemei de tratat nu sunt cunoscute de o manieră certă, dar pot fi estimate cu o anume probabilitate de realizare (legea probabilităţilor). Acest tip de model poate fi utilizat în cadrul unor aplicaţii din domeniul activităţilor de exploatare a programelor de producţie, de aprovizionare, sau determinarea investiţiilor. Analiza procesului decizional în baza modelului sociologic a făcut obiectul de studiu a mai multor sociologi dintre care se distinge Hebert A. Simon laureat al premiului Nobel care a lansat teoria raţionalităţii limitate. H.A. Simon (1960) a arătat că toate deciziile se elaborează în trei etape: Identificarea problemei. Se face analiza domeniului de studiat, se identifică problemele focalizându-se pe acelea care sunt dificil de identificat şi de perceput. Problemele întreprinderii trebuie identificate prin diverse sisteme de reglare prin anticipare, Identificarea alternativelor posibile este faza cea mai delicată din cadrul procesului de elaborare a unei decizii. Această fază este abordată în momentul în care problema de rezolvat a fost percepută ca urmare a fazei anterioare. Aşa cum s-a precizat, această etapă este una foarte delicată mai ales în condiţiile aplicării teoriei raţionalităţii limitate dezvoltate de Simon. Decidentul nu studiază decât un număr limitat de soluţii, datorită lipsei de timp şi de informaţii şi de asemenea datorită experienţei limitate de care dispune. Selecţia soluţiei este ultima fază a procesului de elaborare a deciziei şi reprezintă rezultatul schimbării graduale progresive a situaţiei iniţiale. Trebuie însă precizat că nu există decizie ideală iar alegerea se face ţinând cont de constrângerile formulate. Pentru aceasta se vor determina clar obiectivele de atins, criteriile de evaluare a diferitelor soluţii obţinute, se vor studia sau măsura consecinţele fiecărei alternative, se vor valorifica consecinţele în raport cu criteriile de evaluare reţinute şi se vor alege între diferitele soluţii obţinute. Elaborarea şi adoptarea unei decizii nu înseamnă că problema decizională a fost soluţionată. Aceasta presupune şi implementarea şi evaluarea deciziei adoptate. Implementarea deciziei, adică aplicarea efectivă a deciziei, presupune în general o schimbare a stării actuale a sistemului dar şi păstrarea stării actuale poate fi considerată o decizie posibilă. Evaluarea se efectuează în primul rând pentru a descoperi şi acumula noi cunoştinţe care vor fi apoi utilizate în pag. 34 / 109

35 procesele decizionale viitoare. În cadrul procesului de elaborare a deciziei un aspect foarte important îl constituie formularea obiectivelor actorilor participanţi la procesul decizional. Distingem trei categorii de obiective şi anume: Obiectivele organizaţiei care corespund obiectivelor întreprinderii, adică acele obiective generale şi permanente ale întreprinderii pentru o perioadă relativ lungă care urmăresc dezvoltarea întreprinderii. Obiectivele funcţionale care corespund obiectivelor specifice fiecărei funcţii din cadrul întreprinderii (de exemplu, financiară: rentabilitate, tehnică: calitatea produselor). Obiectivele personale care corespund obiectivelor diferiţilor membri din cadrul întreprinderii luaţi individual sau colectiv. Aceste obiective pot fi însă în contradicţie cu obiectivele generale ale întreprinderii. Această contradicţie poate induce efecte negative în cadrul procesului de elaborare a deciziei. Analiza procesului decizional pe baza modelului sistemic pleacă de la ideea că în toate sistemele (decizionale, informaţionale etc.) există trei tipuri de componente funcţionale şi anume cele de gestionare a intrărilor, cele de elaborare a deciziilor adică cele care efectuează transformările efective realizate de sistem şi cele de comandă care gestionează ieşirile din sistem. Variabilele de intrare provin din sistemele informaţionale ale întreprinderii. Analiza variabilelor de intrare permite distingerea a trei tipuri: Variabilele strategice provenite din sistemele de reglare prin anticipare; datele sunt bazate pe studii previzionale ale mediului în care îşi desfăşoară activitatea întreprinderea şi evoluţia acestui mediu. Variabilele tactice de gestiune provenite din sistemele de reglare prin alertă care indică faptul că au apărut disfuncţionalităţi interne în întreprindere; Variabilele operaţionale provenite din sistemele de reglare prin eroare, fiind informaţii de natură operaţională şi care se referă la activitatea de exploatare. Acestea sunt utilizate pentru deciziile privind activitatea de exploatare. Rolul principal al componentei funcţionale de decizie este de a stabili un model explicativ al fenomenului studiat, adică să identifice variabilele şi să determine relaţiile între aceste variabile. Automatizarea procesului decizional presupune utilizarea tehnologiilor informaţiei în acest domeniu care permite analizarea naturii situaţiei în condiţii optime. Un proces automat de decizie trebuie să se desfăşoare fără nici o intervenţie umană, procedurile de luare a deciziei fiind programate utilizându-se algoritmi bazaţi pe modele cantitative, logice sau euristice. Decidentul uman determină regulile, modelele şi metodele utilizate pentru luarea deciziei şi completează scopurile deciziei în situaţiile decizionale programate. Teoretic programul de decizie automată se auto-perfecţionează (învăţă din succesele şi eşecurile întâlnite) îmbunătăţindu-şi procedurile şi regulile de lucru. Domeniul automatizării deciziei prevede un set de concepte, tehnologii, metode şi instrumente utilizate atât în proiectarea sistemelor decizionale cât şi în implementarea acestora. Odată cu dezvoltarea tehnologiilor avansate şi instrumentelor de proiectare, automatizarea deciziilor a luat amploare, scopul primordial al automatizării deciziilor fiind acela de a înlocui factorul uman în procesul de luare a deciziei mai ales în domenii care implică activităţi repetitive sau analiza rapidă a unor importante cantităţi de informaţii greu de memorat şi transformat în cunoştinţe. Aplicaţii pentru managementul fluxului de producţie Tehnologiile care stau la baza implementării componentelor de management al fluxului de producţie constă într-o serie de instrumente menite să asiste factorul uman în cadrul procesului de producţie. Aceste instrumente oferă suport pentru: comunicare asincronă ( , forum, mesagerie multimedia), programarea activităţilor (agenda electronică), comunicare sincronă (video telefon, pag. 35 / 109

36 video conferinţă, comunicare în grupuri mici), activităţi colaborative sincrone, activităţi colaborative asincrone, managementul resurselor (managementul documentelor şi dispozitivelor periferice necesare activităţilor), managementul aplicaţiilor, managementul fluxului operaţional. Figura Tehnologii pentru managementul procesului de producţie Instrumentele de tip , forum, sau mesagerie multimedia, permit utilizatorilor să comunice într-o manieră asincronă în vederea rezolvării unor sarcini comune din cadrul procesului de producţie. De exemplu, colaboratorii într-un proiect dezvoltat în regim outsourcing nu vor fi în contact direct pe toată durata unei săptămâni de lucru. Echipa de management programează întâlniri periodice când toţi membri pot participa la sesiuni colaborative, în rest, se va comunica prin intermediul mesageriei multimedia şi . Agenda electronică reprezintă componenta principală a aplicaţiilor de tip dashboard şi permite funcţionalităţi de management al activităţilor. Agenda electronică permite fiecărui utilizator gestionarea propriului program în funcţie de sarcinile pe care le are în cadrul organizaţiei. Prezintă o componentă de intrfaţare cu instrumentele de planificare a activităţilor şi completează automat programul zilnic al utilizatorului cu sarcini culese din resursele de planificare la care are acces. Componentele de tip video telefon, video conferinţă, comunicare în grupuri mici asigură funcţiile de comunicare sincronă atât în cadrul procesului de producţie cât şi în relaţia interdepartamentală, acolo unde este cazul. Aceste instrumente sunt considerate nucleul aplicaţiilor de tip Collaborative Commerce (CC), Computer-Supported Collaborative Work (CSCW), sau a aplicaţiilor pentru suport tehnic (CRM). Conceptul de collaborative work reprezintă o abordare generică a proceselor întâlnite în cadrul sistemelor E-Services, permite managementul serviciilor şi utilizatorilor în funcţie de tipurile de activităţi pe care aceştia le exercită şi asigură suportul necesar derulării proceselor colaborative care implică unul sau mai mulţi actori. Mediile colaborative permit utilizatorilor să conlucreze în cadrul unor activităţi comune iar beneficiile muncii în echipă sunt rapide şi uşor de observat. Cooperarea inter-aplicaţii la nivel funcţional Pentru realizarea unui mediu distribuit care să permită utilizarea eficientă a aplicaţiilor întro manieră colaborativă, se propune reprezentarea aplicaţiilor sub formă obiectuală şi interacţiunea fizică între aceste obiecte. Spaţiile unde aceste obiecte vor fi reprezentate interpretează metodele de interacţiune între aceste obiecte. Metodele de interacţiune între obiectele ce reprezintă aplicaţiile partajate sunt: Abordarea unui obiect, Atingerea unui obiect, Împingerea unui obiect, Mişcarea unui obiect sau a unei părţi din acel obiect. Când se operează asupra unui obiect reprezentând o aplicaţie, din partea unui utilizator sau a unei alte aplicaţii, spaţiul partajat conţinând acest obiect detectează metoda de interacţiune şi se pag. 36 / 109

37 desemenază ce procese vor fi partajate. Aplicaţia trimite mesajele corespunzătoare tipului de interacţiune menţionat aplicaţiei sau utilizatorului care o accesează. aplicaţia care recepţionează mesajele procesează aceste mesaje şi returnează rezultatele pentru a fi partajate în sistem. Obiecte partajate. Partajarea aplicaţiilor în cadrul spaţiului virtual Proiectarea şi implementarea sistemelor virtuale care oferă funcţionalităţi colaborative pentru partajarea de aplicaţii au la bază conceptul de obiecte partajate. Componentele server-side oferă un mecanism de invocare la distanţă a metodelor. Blocurile client din cadrul sistemelor distribuite pot să invoce metode implementate de către blocul server şi blocul server invocă metode pe partea de client. Rezultatele invocării metodelor pot fi transmise fiecărei instanţe client conectate la un obiect pe server prin intermediul unui stream media. Blocul client poate accesa metodele prin intermediul unui proxy de servicii care aparţine altei instanţe. Mediile virtuale partajate au în componenţă 3 blocuri fundamentale: blocul space sharing server care implementează conceptul de shared space. Acesta trebuie să identifice şi să medieze interacţiunile între obiectele reprezentând aplicaţii. De asemenea, trebuie să memoreze stările participanţilor sau aplicaţiilor şi să furnizeze informaţiile cu privire la eventuale schimbări ce au loc în cadrul unuia din participanţi în timp real. blocul application server memorează procesele corespunzătoare fiecărei aplicaţii deoarece fiecare proces returnează informaţii în concordanţă cu tipul de interacţiune recepţionat de la blocul space sharing server. blocul client oferă funcţionalităţi de comunicare cu blocul server (compus din blocurile application server şi space sharing) şi de reprezentare a spaţiului virtual partajat la utilizator. Componentele blocului client actualizează dinamic informaţiile la utilizator reflectând fiecare schimbare pe parte de client sau datorată blocurilor funcţionale care compun aplicaţia partajată. Partajarea spaţiului virtual se realizează astfel: blocul client execută o cere blocului server pe care-l notifică de faptul că vrea să participe la activităţile colaborative, şi primeşte o confirmare a serverului care oferă blocului client toate informaţiile de care are nevoie pentru a reprezenta în formatul dorit informaţiile şi resursele partajate. Dacă există deja participanţi în mediul virtual partajat, blocul server recepţionează cererea de la noul client şi furnizează acceptul de participare, apoi informează toţi participanţii existenţi în mediul partajat despre noul client în sistem. Blocul server alocă un fir de execuţie fiecărui bloc client din sistem utilizat în deservirea cererilor. Odată stabilit protocolul de comunicaţie client/server, are loc notificarea tuturor participanţilor la scena partajată ori de câte ori starea unuia generează un anumit eveniment tratat prin modificări ale stărilor resurselor partajate. Partajarea aplicaţiilor în cadrul spaţiului virtual se realizează astfel: dacă un utilizator doreşte partajarea unei aplicaţii în cadrul unei sesiuni colaborative, ceilalţi participanţi vor fi notificaţi de faptul că unul dintre ei partajează o aplicaţie iar obiectele care reprezintă aplicaţia respectivă sunt prezentate la fiecare dintre participanţi. Când se execută o operaţie, mediul virtual colaborativ identifică operaţia respectivă şi tipul de interacţiune aferentă acesteia, apoi blocul sharing space server notifică blocul application server în legătură cu intercţiunea corespunzătoare. Ca şi rezultat în urma cererii de la client, aplicaţia solicită serverului să schimbe locaţia, forma sau textura obiectului de reprezentare. Această cerere este procesată de către blocul server şi reflectată în cadrul spaţiului partajat prin distribuirea între toţi participanţii. Instrumente pentru Computer-Supported Collaborative Work (CSCW) Laso-Ballesteros (2006) prezintă principalele aspect pentu care multe instrumente colaborative sunt cu adevărat folosite rar, în majoritatea situaţiilor, colaborarea se reduce la comnicare prin intermediul poştei electronice. Această ipoteză pleacă de la problemele de integrare şi interoperabilitate a noilor instrumente colaborative cu mediile electronice existente. Schimbările pag. 37 / 109

38 privind interacţiunea utilizator-sistem reprezintă o altă problemă dat fiind faptul că utilizatorul aşteaptă un avantaj vizibil imediat ce utilizează aceste instrumente colaborative. Caporuscio (2003) face o trecere în revistă a principalelor caracteristici ale sistemelor colaborative şi încearcă o descriere a funcţionalităţilor instrumentelor colaborative din prima generaţie: Kronika, Mocca, MOTION şi YACO, implementate în baza arhitecturilor CORBA, J2EE, sau SIENA. SIENA (Scalable Intermet Event Notification Architecture), arhitectura utilizată pentru implementarea sistemului YACO, dezvoltat de Caporuscio, promovează conceptul de event notification service. Entităţile server SIENA sunt interconectate asemeni unei reţele virtuale menite să ofere acces rapid la servicii entităţilor client prin intermediul unor puncte de acces. Kuroda (2008) aduce în sfera aplicaţiilor colaborative conceptele de realitate virtuală şi insistă pe avantajul creat prin reprezentarea colaboratorilor (Symbiotic Collaborative Work), chiar aflaţi la distanţă, în acelaşi mediu, fie el virtual, fără a neglija aspectele legate de partajarea resurselor, comunicare interactivă sau partajarea aplicaţiilor. Componenta de tip virtual blackboard oferă utilizatorilor acces partajat la resurse iar componenta virtual laser proiectează cursorul mouse-ului în spaţiul virtual. Pentru a realiza un mediu eficient, se propune un sistem complex care permite colaborarea la nivelul aplicaţiilor în concordanţă cu interacţiunile fizice între obiectele care definesc aplicaţiile. Reprezentarea proceselor distribuite în reţea se realizează asemeni obiectelor 3D în spaţiul virtual. Figura Conceptul de Symbiotic Computing Instrumente pentru Collaborative Commerce Ader (2001) prezintă ideea că fiecare activitate poate fi împărţită în 3 dimensiuni: inteligenţă, contabilitate, producţie. În cazul activităţiilor din procesul de vânzare: producţie înseamnă, de fapt, activitatea efectivă de vânzare care constă în întâlnirile cu potenţialii cumpărători, editarea de oferte, negocierea condiţiilor de vânzare, comandarea produselor şi serviciilor, furnizarea lor, tratarea problemelor apărute la client, furnizarea suportului tehnic, etc. contablitate include inventarul, facturarea, componenta e-commerce, componenta de plata electronică, statistica de vânzări, etc. inteligenţa implică activităţie de segmentare a pieţei, stastică pe vânzări, statistică pe calitatea serviciilor, strategie de preţuri, identificarea potenţialilor clienţi, gestionarea noilor instrumente de vânzări, etc. pag. 38 / 109

39 Soluţiile colaborative aduc un plus componentelor e-commerce prin personalizarea suportului oferit clienţilor acestora. De exemplu, IBM integrează WebShere Commerce cu Lotus Instant Messaging pentru a spori satisfacţia cumpărătorului şi a creşte vânzările. Componentele de tip Business Intelligence cresc eficienţa sistemelor e-commerce prin automatizarea proceselor care implementează scenariul Business to Business. Componentele de tip Business Intelligence ajută la elaborarea de analize şi studii de piaţă în ceea ce priveşte unul sau mai multe produse şi servicii pe care magazinul virtual le oferă clienţilor. Instrumente pentru managementul fluxului operaţional Ader (2001) dă o mare importanţă producţiei şi alocă peste 70% din costuri procesului de producţie, activităţilor de contabilitate doar 10% iar celor inteligente 20%. El prezintă ipoteza că majoritatea sistemelor de management al informaţiei sunt concentrate pe automatizarea activităţilor de contabilitate şi foarte puţin pe celelalte activităţi astfel, nu exclude posibilitatea reorientării dezvoltatorilor software spre automatizarea proceselor de producţei sau de automatizare a activităţilor inteligente. În cazul organizaţiilor tradiţionale, activităţile efectuate sunt de obicei activităţi interactive operate de către factorul uman de la staţii de lucru. Aceste activităţi ar putea fi automate şi executate de către o componentă rulând pe maşina server dat fiind faptul că ele se realizează prin intermediul unei aplicaţii, de la consolă. Activităţile derulate în cadrul unei organizaţii respectă o metodă de abordare orientată pe cerinţele clientului. Instrumentele de analiză a proceselor au scopul de a gestiona corect rapoartele, de a monitoriza procesele, de a simula soluţii alternative sau de a evalua corect eficienţa şi costurile pe fiecare soluţie. Instrumentele pentru managementul fluxului de producţie permit automatizarea proceselor, monitorizare şi control atât în cadrul organizaţiei cât şi în afara acesteia iar statisticile, rapoartele de analiză şi deciziile sunt elaborate având la bază ipoteza precedentă. Integrarea aplicaţiilor şi persoanelor implicate în procesele de business într-un cadru de lucru flux operaţional - aduce beneficii substanţiale nu doar companiei ci şi clienţilor şi angajaţilor acesteia: Beneficii ale companiei: o optimizarea fluxului operaţional permite controlul producţiei; o beneficii la nivelul echipei managerial fluxul operaţional prezintă managerilor informaţiile corecte utilizate în luarea deciziilor. Componenta de monitorizare permite controlul proceselor la orice nivel; o beneficii pentru analişti fluxul operaţional furnizează o serie de statistici care permit analiştilor să elaboreze rapoartele cu privire la costuri, perioade de vârf, sau alte caracteristici economico-financiare. Beneficii ale clientelei îmbunătăţirea calităţii serviciilor, timp de răspuns mai bun, informaţii clare despre tranzacţia solicitată, sau consultanţi disponibili în timp util; Beneficii ale angajaţilor fiecare angajat are o listă cu sarcini alocate pentru ziua respectivă. Fluxul operaţional permite angajaţilor flexibilitate în organizarea muncii, rezolvarea mai rapidă a sarcinilor pe care le are şi garantează un nivel de conform optim; Dintre caracteristicile furnizate de instrumentele de management al fluxului operaţional, cele mai importante sunt: Alertarea personalului de specialitate în cazul în care procesul nu se realizează la parametri optimi şi identificarea problemelor apărute. Raportarea cu privire la starea actuală a procesului care permite celor din call center să ofere informaţii corecte clienţilor Elaborarea de statistici cu privire la procesul în sine şi afişarea lor la client oferindu-i acestuia posibilitatea de a avea o imagine clară asupra procesului de business Elaborarea unui raport de analiză privind costurile pe fiecare tip de process de business pag. 39 / 109

40 Îmbunătăţirea continuă a proceselor în funcţie de rapoartele de analiză şi statistici. După crearea întreprinderii virtuale şi evaluarea setului de servicii care vor fi oferite, se vor defini procesele în baza cărora se implementează serviciile respective cu ajutorul instrumentelor business process reengineering (BPR). Instrumentele de simulare permit determinarea resurselor necesare acestor procese, sau estimarea timpului total alocat lor după care, prin intermediul instrumentelor BPR se reprezintă mai multe versiuni de definire a proceselor, şi se evaluează eficienţa la nivel global a acestor versiuni. După definirea proceselor, fiecărei activităţi şi fiecărui proces i se atribuie o serie de resurse. De exemplu, activităţile din cadrul relaţiei cu furnizorii ar putea fi asignate la o bancă de date, fără a specifica locaţia şi numele ei. La sfârşitul acestei etape, se generează o listă cu activităţile şi resursele necesare realizării fiecărei activităţi. Pentru definirea precisă a resurselor alocate şi a specificaţiilor activităţilor se utilizează instrumente de selectare şi asignare a resurselor pentru fiecare proces. Unul dintre principiile întreprinderii virtuale constă în identificarea resurselor externe care implică servicii de acces la banca de date, call center, producţie, asamblare, contabilitate, sau e-commerce şi selectarea furnizorului optim pentru fiecare dintre aceste resurse. O întreprindere virtuală se caracterizează prin investiţii minime costuri mici cel puţin în primele etape iar utilizarea serviciilor externe într-un cadru competitive garantează costuri minime în condiţii de eficienţă sporită. Configurarea acestor servicii şi resurse pentru a funcţiona împreună ca un tot unitar se realizează într-un timp foarte scurt comparat cu organizaţiile tradiţionale. Odată ce resursele sunt alocate corect proceselor specificate în scenariul de funcţionare a organizaţiei, încep atribuţiunile echipei de management care are sarcina de a pune la dispoziţia membrilor întreprinderii virtuale aceste resurse. Instrumentele pentru managementul fluxului operaţional permit invocarea proceselor la distanţă sau transferul unei activităţi la o anumită resursă pentru a fi executată în concordanţă cu regulile de business. Monitorizarea membrilor unei organizaţii virtuale impune verificarea sarcinilor pe care fiecare membru trebuie să le finalizeze într-un interval de tip în cadrul parteneriatului. Instrumentele de management al fluxului operaţional permit stocarea informaţiilor cu privire la fiecare eveniment tratat în sistem (log pe fiecare acţiune cu data, ora, activitate, rezultat), informaţii necesare în elaborarea de statistici pentru monitorizare şi control a calităţii serviciilor pe fiecare agent economic implicat în întreprinderea virtuală. Instrumente colaborative pentru dezvoltarea resurselor umane Formarea profesională continuă şi intersul pentru cunoaştere primează în majoritatea organizaţiilor orientate pe cerinţele consumatorului. Competitivitatea unei instituţii depinde de capacitatea de inovare a personalului iar capacitatea de inovare are la bază perfecţionarea continuă a personalului din fiecare departament. Resursele umane reprezintă o prioritate a organizaţiei iar dezvoltarea acestora garantează un proces de producţie de înalt nivel tehnologic. Pentru dezvoltarea resurselor umane, o organizaţie modernă are implementat un sistem de formare profesională continuă bazat pe metode educaţionale avansate care impune o serie de instrumente interactive pentru studiu individual şi instrumente colaborative pentru organizarea sesiunilor de training la distanţă. Cisco WebEx Training Center este o soluţie elearning de top care aduce avantajele instrumentelor WebEx în sfera sistemelor educaţionale. Cuprinde trei componente, Online Classroom, Training Assist şi Presentation Studio, şi permite organizarea de sesiuni educaţionale pe diferite domenii de activitate. Cisco WebEx Training Center pune la dispoziţia utilizatorului un set de instrumente cu ajutorul cărora instructorii pot programa şi susţine procesul educaţional de tip training la cerere, sesiuni colaborative de tip webminar, dezvoltare profesională continuă sau faceto-face classroom. Webex Training Center implementează funcţionalităţi de streaming media şi partajare de resurse/desktop/aplicaţii, permite activităţi colaborative, generarea de statistici sau evaluare online, integrare ecommerce. pag. 40 / 109

41 NUCLEO este un mediu educaţional pilot dezvoltat la Compluense University din Madrid pe principiul combinării avantajelor a două abordări privind procesul educaţional, cel având la bază conceptul de collaborative learning (Computer Supported Collaborative Learning - CSCL) şi cel de tip problem-based learning (PBL). În acest context, cursanţii îşi însuşesc noi cunoştinţe prin intermediul a două procese: proceduri de rezolvare a problemelor - tutorii propun cursanţilor probleme complexe a căror prezentare respectă stilul metaforei de joc video redată într-un spaţiu virtualş proceduri colaborative - sarcinile trasate de către tutor, sub formă de misiuni, sunt rezolvate în echipă după instrucţiuni clare. Prin combinarea conceptelor PBL şi CSCL într-un mediu virtual se obţin îmbunătăţiri vizibile ale modului de gândire a cursanţilor. Această combinaţie conduce la dezvoltarea gândirii critice şi asimilarea informaţiei pentru o perioadă lungă de timp. Învăţământul colaborativ dezvoltă abilităţile sociale şi comunicative ale cursanţilor şi promovează ideea de prezentare a conţinutului educaţional într-o manieră interactivă şi aplicând un set de abordări instructive simultane procesului educaţional: - lumea virtuală şi ideea de joc în cadrul procesului educaţional promovează conceptul de comunitate educaţională; - structurarea interacţiunii între cursanţi prin intermediul scripturilor colaborative creşte considerabil capacitatea de asimilare a informaţiei; - adaptarea dinamică a serviciilor permite formarea echipelor din membri cu nivele de cunoştinţe similare şi acelaşi stil de învăţare Tehnologii web utilizate în dezvoltarea sistemelor de tip întreprindere virtuală Adobe Flex - Majoritatea aplicaţiilor web au la bază interfeţe grafice în format HTML cu nivelul de prezentare a informaţiei constând în componente: PHP, JSP, ASP, Servlets, CFM. Interfaţa grafică cu utilizatorul, formuri HTML şi funcţii JavaScript, nu sunt interactive, browserul web de pe maşina client execută o cerere la serverul web, acesta rulează resursa web şi furnizează rezultatul in format HTML. Excepţie fac aplicaţiile dezvoltate cu ajutorul framework-ului AJAX care utilizează funcţii JavaScript pentru partea de client si structuri de date XML pentru comunicaţia browser-server web, prin intermediul protocolului HTTP. Adobe Flex prezintă un real avantaj faţă de tehnologiile web tradiţionale prin faptul că permite dezvoltarea de aplicaţii web interactive. Blocul client este unul de tip stateful permiţând modificări ale componentei vizuale fără a executa o cerere la server prin simpla notificare recepţionată de la componentele server-side. Adobe Flex este un framework complex dedicat dezvoltării de aplicaţii web cu un grad mare de interactivitate. Din punct de vedere a flexibilităţii, Flex este compatibil cu majoritatea sistemelor de operare şi cu cea mai mare parte a browserelor web. De asemenea, Adobe Flex oferă suport pentru implementarea de aplicaţii desktop cu grad sporit de complexitate. Adobe Flex are la bază MXML, un limbaj declarativ bazat pe standardul XML utilizat pentru a descrie comportamentul şi maniera de prezentare a informaţiei în cadrul interfeţei grafice cu utilizatorul. În implementarea aplicaţiilor complexe, se utilizează ActionScript 3, un limbaj de programare orientat pe obiecte dedicat lucrului cu elementele multimedia: suport pentru audio/video, grafică, imagini, text, etc. Adobe Flex conţine o bibliotecă de peste 100 de componente pentru dezvoltarea aplicaţiilor RIA (Rich Internet Application) cu scupul de a porta avantajele aplicaţiilor desktop în sfera sistemelor web şi furnizează o nouă abordare privind integrarea componentelor RIA cu partea de server prin intermediul bibliotecii Flex Server Side. Flex beneficiază de avantajele furnizate de Adobe Flash Platform şi, ca şi în cazul Flash, prezintă pag. 41 / 109

42 elementele de grafică vectorială şi permite elaborarea rutinelor ActionScript 3.0 pentru diferite funcţionalităţi pe partea de client cum ar fi interfaţarea cu reţeaua, tratarea evenimentelor generate de acţiunile utilizatorului, sau interpretarea notificărilor primite de la componentele nivelului de business. ActionScript este un limbaj folosit în principal pentru dezvoltarea de funcţionalităţi în cadrul animaţiilor Adobe Flash prin generarea fişierelor cu extensia.swf rulat de Adobe Flash Player. El a fost creat pentru implementarea funcţionalităţilor grafice şi de control din cadrul animaţiilor vectoriale 2D, dar de-a lungul vremii s-a dezvoltat pentru a realiza aplicaţii Web complexe, jocuri şi prezentări interactive. Action Script 3 este interpretat de ActionScript Virtual Machine (AVM) parte integrantă din Flash Player 9. Flash Player 9 include doua masini virtuale AVM1 şi AVM2; AVM1 execută codul scris în alte versiuni ale limbajului în timp ce AVM2 prelucrează codul scris în Action Script 3. Action Script utilizeaza un model single-thread, cel putin din perspectiva programatorului, evitând astfel multe din problemele pe care mecanismele Java Swing le cauzează în comunicaţia client/server. Blocul client transmite serverului o cerere specificând numele componentei de tip handler şi îşi continuă execuţia fără să aştepte răspunsul. Prelucrarea datelor de răspuns se va face doar în momentul recepţionării lor, astfelse evită momentele în care aplicaţia se blochează până la recepţionarea datelor. MXML este un limbaj declarativ ce se aseamana cu HTML. Ca şi acesta, MXML conţine tag-uri care definesc maniera de interfaţare cu utilizatorul, componentele vizuale care definesc interfaţa cu utilizatorul. Structura MXML este mult mai amplă şi mai complexă, fiind disponibil un set mult mai mare de componente (ex. abori, grid-uri, tab-uri pentru navigare sau componente meniu). De asemenea, tag-urile MXML definesc şi componente non-visuale, componente de tip conexiune, legaturi de date sau logica de prezentare a informaţiei la utilizator (animaţii, grafică, etc.). Dezvoltatorul poate extinde componentele sau creea propriile tag-uri MXML, în funcţie de logica de prezentare a informaţiei şi elementele de interacţiune utilizator-sistem necesare. CSS (Cascade Style Sheet) are acelasi rol şi sintaxă în proiectele Flex ca şi în proiectele web tradiţionale şi reprezintă constrangeri grafice (fonturi utilizate, culori, stil, etc.). În Flex desemnarea stilului CSS în mod static, prin crearea unui fisier.css sau prin utilizarea tagului corespunzator pentru stil, permite încapsularea automată a fişierului css în aplicaţie. Modificările în cadrul acestui fişier sunt vizibile doar după recompilarea întregului proiect. Există şi metoda dinamică de asignare a stilului CSS care presupune instanţierea unui obiect de tip Style pus la dispoziţei de biblioteca ActionScript 3. PHP - Hypertext Preprocessor este un limbaj de scripting de uz general, open source, utilizat pe scară largă şi care este potrivit în special pentru dezvoltarea aplicaţiilor web. Este unul din cele mai importante limbaje de programare web open-source şi server-side pe piaţa software. PHP ruleaza pe diferite sisteme de operare şi servere web. Poate fi utilizat pe toate sistemele de operare majore: Linux, multe variante Unix (inclusiv HP-UX, Solaris şi OpenBSD), Microsoft Windows, Mac OS X, RISC OS. Majoritatea serverelor web existente oferă suport pentru PHP: Apache, Microsoft Internet Information Server, Personal Web Server, server-ele Netscape şi iplanet, server-ul Oreilly Website Pro, Caudium, Xitami, OmniHTTPd şi multe altele. Fiind vorba de un limbaj structurat, procesul de implementare a aplicaţiilor web implică atât tehnici de programare procedurală cât şi orientată pe obiecte (POO), inclusiv o combinaţie a acestora. În PHP 3 şi 4 obiectele erau tratate ca un tip de dată de bază, însemnand că, de fiecare dată când o variabilă era asignată sau folosită într-o funcţie, se copia tot obiectul. Cu toate că în PHP 4 nu sunt implementate toate facilităţile programării orientate pe obiecte, multe biblioteci de cod şi aplicaţii mari sunt implementate utilizând tehnici de programare orientată pe obiecte. Felul în care obiectele sunt tratate a fost complet rescris în PHP 5 iar acum obiectele sunt referenţiate printr-un vector intern şi nu după valoarea pe care o au. PHP 5 a introdus metode private şi protejate, clase abstracte, constructori şi destructori, functionalităţi similare cu cele din alte limbaje pag. 42 / 109

43 de programare orientată pe obiecte. Aplicaţiile web care au la baza PHP integrează usor alte tehnologii web ( ex: HTML, Flash, Flex, JavaScript, AJAX). În locul unei mulţimi de comenzi pentru a afişa formul HTML (cum este cazul în C sau Perl), paginile PHP conţin cod HTML încorporat. În momentul incărcării unei pagini web care conţine PHP şi HTML se execută rutina PHP pe server care generează elementele dinamice din pagina web Tehnologii multimedia utilizate în dezvoltarea sistemelor de tip întreprindere virtuală Transportul datelor multimedia Orice tip de date care se modifică substanţial într-un interval de timp este un element multimedia dependent de timp. Clipurile audio, secvenţele MIDI, clipurile video sunt elemente multimedia comune dependente de timp obţinute de la diferite surse cum ar fi fişiere locale sau resurse în reţea, microfoane, camere video, camere web. Elementele multimedia temporale sunt procesate şi expuse într-un interval de timp. Odată ce datele încep să fie expuse, sfârşitul lor coincide cu un moment bine definit în timp. Un element multimedia dependent de timp are asociate functionalităţi de streaming media, deoarece este transmis ca un stream de date stabil recepţionat, procesat şi reprodus într-un anumit interval de timp. Stream-ul de date reprezintă un canal de comunicaţie între două entităţi: o entitate care emite şi o entitate care recepţionează. Stream-urile pot fi de două feluri: stream-uri de scriere şi stream-uri de citire. Stream-urile de date multimedia se întâlnesc peste tot în Internet, numărul portalurilor care oferă fncţionalităţi multimedia (transmisii radio şi TV) fiind într-o continuă creştere. Un stream media poate să conţină mai multe canale (track-uri audio sau video). Un stream media care conţine mai multe canale se numeşte stream media complex sau multiplexat. Individualizarea unui singur canal dintr-un stream media complex se numeşte demultiplexare. Există două clase de aplicatii pentru transmisia/recepţia stream-urilor media: Pull Transferul este iniţiat de blocul client iar controlul este minimal (cunoscut ca şi progressive download care impune transferul datelor prin intermediului protocolului HTTP) Push Serverul iniţiază transferul de date şi controlează fluxul datelor (transferul se realizează prin intermediul protocoalelor RTP, RTSP sau RTMP) Tipurile de date multimedia dependente de timp sunt în general prezentate la utilizator prin intermediului monitorului (video) sau boxelor/căstilor (audio). Calitatea prezentării datelor la utilizator depinde de metodele de compresie, capacitatea de procesare a sistemului şi lăţimea de bandă de transfer disponibilă. Procesarea stream-urilor constă în demultiplexarea, decodarea, conversia (la alt format) şi filtrarea acestora. Termenul de streaming media constă în două operaţii fundamentale: transmia pe reţea ( Intranet / Internet) a datelor multimedia şi recepţia şi procesarea acestora în timp real. Transmisia datelor multimedia necesită o anumită lărgime de bandă. În transmisia datelor multimedia se acceptă pierderea pachetelor, dar nu şi apariţia întârzierilor. Această regulă vizează diferenţele între procesarea datelor locale (statice), de exemplu un fişier, pentru care cel mai important lucru este să ajungă la destinaţie, şi accesarea datelor multimedia în timp real. În cazul transmisiei live a unei secvente audio/video aplicaţia client începe procesarea datelor înainte ca secvenţa audio/video să fie transmis în întregime. Acest aspect evidenţiază noţiunea de buffering. Dacă, însă, secvenţa audio/video nu are o durată precisă, procesarea datelor înainte de aducerea întregului stream pe maşina client ar fi imposibilă. Manipularea datelor multimedia cu ajutorul tehnologiilor Adobe Tehnologiile Adobe promovează conceptul de stream media iar pachetele ActionScript 2.0 oferă suport pentru manipularea streamurilor de date. De exemplu, componentele părţii client utilizează obiecte de tip NetStream pentru a crea şi manipula elementele multimedia temporale, în pag. 43 / 109

44 timp ce pe partea de server se utilizează instanţe ale clasei Stream. Pe partea de client publicarea streamurilor media se realizează prin intermediul obiectelor de tip NetConnection şi NetStream. Streamul media este asociat cu un identificator unic (URI Uniform Resource Identifier). Acest identificator poate fi utilizat de toate componentele din cadrul unei aplicaţii, astfel, un stream publicat poate fi accesat de orice componentă din cadrul aplicaţiei. Într-un mod similar streamurile pot fi transmise şi între mai multe instanţe de tip server media (Flash Media Server) prin acelaşi mecanism de publicare şi prezentare a datelor ca şi între un bloc server şi unul client. Mai mult, Flash Media Server oferă suport pentru clustering, într-o manieră transparentă din punct de vedere al componentelor parţii client. Capturarea datelor audio/video se realizează cu ajutorul obiectelor de tip NetStream deoarece obiectele de tip Stream nu oferă suport pentru capturarea datelor multimedia. Prin obiectele de tip Stream se realizează manipularea streamurilor şi crearea obiectelor de tip Playlist. Publicarea streamurilor - Metoda NetStream.publish poate fi utilizată pentru a transmite (publica) stream-uri live sau înregistrate. De asmenea se poate folosi pentru a adăuga date pe un stream media existent. Pentru a avea control asupra modului de transmisie a unui stream media, dezvoltatorul specifică acest aspect prin intermediului celui de-al doilea parametru al metodei ce poate lua valorile live, record sau append. Când parametrul ia valoarea live sau record orice înregistrare precedentă cu acelaşi URI este ştearsă şi rescrisă. Specificarea parametrului append duce la concatenarea unui stream existent cu datele transmise. In cazul înregistrării unui clip (de exemplu, secvenţă audio/video pentru comunicaţie asincronă) streamul transmis va fi salvat cu extensia.flv într-un subdirector asociat instanţei aplicaţiei curente. Directoarele şi subdirectoarele se creează automat în rădăcină pe server pe parcursul execuţiei aplicaţiei. Streamurile sunt controlate şi utilizate eficient deoarece un stream media este o resursă foarte costisitoare iar gestionarea eficientă a proceselor creşte performanţele sistemului multimedia distribuit. De exemplu, în cadrul unei sesiuni colaborative moderatorul captează atenţia participanţilor într-o proporţie destul de mare astfel, banda este partajată după rolul fiecărui actor în sistem. Prezentarea streamurilor - Mediile colaborative fac parte din gama aplicaţiilor interpersonale sincrone consumatoare de resurse care necesită putere de calcul atât pe parte de client cât şi pe parte de server (solicită o largime de bandă care creşte odata cu numărul de utilizatori, se accesează resurse considerabile, etc.). Un calcul simplu privind numărul de streamuri recepţionate şi, implicit, lărgimea de bandă necesară transmisiei datelor multimedia în cadrul unei sesiuni colaborative este detaliat în cele ce urmează: blocul client publică un singur stream şi recepţionează n-1 streamuri, unde n reprezintă numărul de participanţi (moderator şi participanţi); cu alte cuvinte, numărul de streamuri necesare unui participant este n iar numărul total de streamuri pe sesiune este n 2 ; astfel, banda necesară poate varia între 32 kbps, în cazul unei sesiuni colaborative între un moderator şi un participant, şi 20 MBps, în cazul unei sesiuni colaborative între un moderator şi 50 de participanţi; alocarea benzii se poate face într-o manieră dinamică prin optimizarea numărului de streamuri pe sesiune; de exemplu, în majoritatea sesiunilor colaborative, moderatorul de sesiune emite continuu iar participanţii sunt activi doar când li se permite acest lucru de către moderator; cu alte cuvinte, moderatorul controlează sesiunea colaborativă şi decide care dintre participanţi ia cuvântul la un moment dat. În acest caz, avem de a face cu 2 streamuri transmise (participantul activ şi moderatorul) şi n streamuri recepţionate, adică n+1 streamuri pe sesiune. Codarea datelor multimedia - Codarea datelor video utilizând tehnologiile Adobe se realizează prin intermediul codecului Sorenson Spark. Acesta permite Player-ului de Flash să controleze dispozitivul de captura (webcam, camera video, etc.) sau să prezinte datele video prin intermediul monitorului. Sorenson Spark realizează compresia în două modalităţi: CBR (opţiune pag. 44 / 109

45 pentru datele de tip live permite codarea datelor video în funcţie de o constantă de dimensiune a datelor pe cadru) sau VBR (opţiunea este sensibilă la modificarea conţinutului video, iar datele pe cadru vor avea dimensiune variabilă). Datele audio capturate de la microfon, cu ajutorul obiectelor de tip Microphone, sunt codate MP3 şi transmise pe reţea, în cazul aplicaţiilor live sau stocate în fişiere FLV, în cazul înregistrărilor audio/video Tehnologii agenţi inteligenţi, multi agent în formarea şi operarea întreprinderilor virtuale Cercetările din domeniul întreprinderilor virtuale au fost iniţial puternic orientate înspre tehnologie. În ultimii ani însă, se observă contribuţii integrate de la tot mai multe discipline, cum sunt: teoria organizaţională, sociologie, management, drept, economie, etc. Se pare că definiţia larg acceptată pentru IV este dată de Camarinha-Matos şi alţii (2005), care afirmă că întreprinderea virtuală este o alianţă temporară de întreprinderi care vin împreună pentru a-şi împărţi calificările şi competenţele şi resursele pentru a răspunde mai bine oportunităţilor de business, şi a căror cooperare este susţinută de reţele de calculatoare. Două elemente cheie stau la baza acestei definiţii: reţeaua şi cooperarea. Aşadar se întrevede în mod clar o tendinţă de a descrie întreprinderea virtuală ca fiind o reţea de întreprinderi cooperante. Termenul Organizaţie virtuală reprezintă o generalizare a conceptului de întreprindere virtuală, pe măsură ce primul conţine reţele colaborative care nu sunt limitate la întreprinderi, ci pot cuprinde şi alte tipuri de organizaţii (entităţi guvernamentale sau ne-guvernamentale). O serie de caracteristici ale IV le fac posibile candidate pentru aplicarea tehnicilor multiagent. Printre aceste caracteristici se pot enumera (Camarinha-Matos, 2002): o IV este compusă din alianţe de componente eterogene, distribuite, o situaţie care poate fi mapată foarte intuitiv peste sisteme multi-agent; rezolvarea problemelor prin cooperare şi distribuţie a sarcnilor poate deasemenea fi pusă în seama unor sisteme multi-agent; luarea deciziilor în situaţia în contextul deţinerii unor informaţii incomplete, şi în cazul implicării unor entităţi autonome care formează reţeaua, care pot avea interese diferite în anumite situaţii, este un alt punct comun; execuţia efectivă şi supervizarea proceselor de business distribuite necesită reacţii rapide ale membrilor întreprinderilor. Reţelele de calculatoare fiind mediul privilegiat de comunicare, fiecare companie are nevoie de un reprezentant în reţea. Această nevoie poate fi acoperită de un agent software; dezvoltările recente în domeniul IV mută accentul de la modelarea şi schimbul de informaţii înspre modelarea contractelor / relaţiilor sociale şi a rolurilor, adresând aspecte de distribuire a responsabilităţilor, capacităţilor şi cunoştinţelor, care dealtfel sunt teme comune în cercetările despre sistemele multi-agent; faza de formare (creare) a IV, în care trebuie selectaţi partenerii şi distribuite sarcinile, sunt teme de cercetare re au fost atinse de ceva vreme în domeniul sistemelor multi-agent; un consorţiu care formează o întreprindere virtuală este o organizaţie dinamică, unde poate fi nevoie de reconfigurări dinamice, astfel flexibilitatea este un punct cheie în modelarea arhitecturii unei IV; Este necesar astfel mai multă flexibilitate decăt poate oferi un sistem calsic, client server, care să permită schimbul de roluri între membrii IV; funcţionalităţile care susţin mecanismele IV trebuie să interacţioneze cu mediul local (aplicaţii, utilizatori, etc.); interacţiunea cu mediul înconjurător este o caracteristică definitorie a agenţilor; pag. 45 / 109

46 proprietatea de scalabilitate a sistemelor multi-agent poate fi privită ca un suport pentru IV dinamice, în care apar diferite nivele de cooperare, cu diferite seturi de parteneri, în diferite momente de timp (sau faze de execuţie); pe de altă parte, fiecare întreprindere poate fi văzută ca o reţea de entităţi semi-autonome (departamente); evoluţia continuă a modelelor economice, a paradigmelor organizaţionale, precum şi a condiţiilor pieţei economice, necesită susţinerea efectivă a evoluţiei şi o modularitate de grad înalt a infrastructurilor; noi forme de muncă în echipă apar în contextul IV; agenţii pot juca un rol important în asistarea modului în care actorii umani îşi joacă rolul în comunităţile virtuale; sistemele multi-agent pot oferi o alternativă viabilă în implementarea unor soluţii la problemele legate de comportament cooperativ versus autonomie, generate de comportamentul entităţilor reţelei IV; datorită faptului că entităţile componente ale întreprinderii virtuale sunt proiectate şi dezvoltate independent, este dificil a se garanta coordonarea acestora, dacă nu sunt adoptate nişte reguli comune ( legi de comportament social ). Fundamentele teoretice ale societăţii agenţilor pot fi combinate cu dezvoltările actuale pentru a crea un cadru legal pentru întreprinderi / organizaţii virtuale. În cele ce urmează se va prezenta utilizarea agenţilor inteligenţi, ca o metodologie de inginerie software pentru proiectarea şi operarea intreprinderilor virtuale. Agenţii pot îndeplini sarcini variate în procesele cooperative derulate în timpul formării intreprinderile virtuale prin Internet, realizând sarcini cum sunt prezentarea, regăsirea şi extragerea de informaţii, participarea la licitaţii pe pieţele electronice. Agenţii inteligenţi, conform definiţiei date în (Wooldridge, Jennings, 1995), sunt sisteme computerizate, care îndeplinesc sarcini în mod autonom într-un mediu deschis, sunt re- sau proactivi, şi sunt capabili să interacţioneze cu alţi agenţi. Rolul agenţilor în formarea intreprinderii virtuale Deoarece într-o întreprindere virtuală, întreprinderile individuale îndeplinesc doar o parte din lanţul de valori pentru a dezvolta un produs, problema majoră în ceea ce priveşte asamblarea (formarea) IV este aceea de a mapa procesele parţiale la întreprinderile individuale. Această problemă se poate rezolva în două etape; în primul rând, se defineşte o partajare a proceselor economice. În cea de-a doua fază, lanţul de proces al întreprinderii virtuale este asamblat şi instanţiat. Problema care trebuie considerată în prima fază este: la ce poziţie a lanţului valoric, astfel de partiţionare este sensibilă. Soluţia este facilitată prin aplicarea metodologiei ARIS (Scheer, 1994), care este un cadrul de lucru uniform pentru descrierea proceselor economice. În cea de-a doua fază, sunt selectaţi partenerii IV. Acest proces se poate diviza în patru sub-faze: identificarea potenţialilor parteneri; generarea de mapări alternative de la parteneri la potenţiale procese; evaluarea riscului respectiv a intereselor strategice; finalizarea parteneriatului şi maparea proceselor parţiale. Fischer şi alţii (1996) au studiat rolul agenţilor inteligenţi în această a doua fază a formării întreprinderii virtuale, în cadrul proiectului AVE (Agents for Virtual Enterprises). Aceştia utilizează propria arhitectură de agenţi, InteRRaP (Figura 1.3.8), pentru a proiecta agenţii în proiectul AVE. Această arhitectură descrie un agent prin: interfaţa cu lumea, unitatea de control, şi o bază de cunoştinţe (KB Knowledge Base). Unitatea de control are trei nivele: nivelul pentru comportament (BBL Behavior-Based Layer), nivelul de planificare locală (LPL Local Planning Level), şi nivelul de planificare a cooperării (CPL Cooperative Planning Level). Baza de pag. 46 / 109

47 cunoştinţe a agenţilor este şi ea structurată corespunzător, în modelul lumii (world model), modelul mental (mental model) şi modelul social (social model). Figura Arhitectura InteRRaP, utilizată pentru proiectarea agenţilor în proiectul AVE Aceste nivele corespund diferitelor nivelelor funcţionale ale agenţilor. Scopul implementării nivelului BBL este de a permite agentului să reacţioneze în anumite condiţii critice şi să se comporte normal în situaţii de rutină. Reactorii sunt declanşaţi de evenimente recunoscute de către modelul lumii, care încorporează cunoştinţele la nivel de obiect ale agentului despre mediul său înconjurător. Nivelul LPL dă agentului abilitatea de a negocia pe termen lung. Acesta are ca suport informaţiile din modelul lumii, dar în plus utilizează atât obiectivele curente ale agentului şi intenţiile locale, prinse în modelul mental, parte a bazei de cunoştinţe, cât şi mecanismele de planificare specifice domeniului de activitate. Nivelul CPL extinde funcţionalitatea de planificare a unui agent la planificare comună, aceasta însemnând faptul că se pot planifica activităţi pentru mai mulţi agenţi, care permit rezolvarea conflictelor şi cooperarea. Înafară de cunoştinţele despre modelul lumii şi de modelul mental, CPL utilizează informaţii despre scopurile, calificările şi angajamentele celorlalţi agenţi, stocate în modelul social al bazei de cunoştinţe. O piaţă electronică a IV - Reţelele de comunicaţii globale permit existenţa unor pieţe de informaţii pentru schimburi de informaţii, servicii şi produse. Această dezvoltare este îndreptată înspre consilii de comerţ specifice, întreţinute de către noduri de Internet, aşa numitele servere de informaţii. Un server de informaţii poate rezolva probleme generale din cadrul regăsirii şi filtrării de informaţii ( extragerea informaţiilor relevante din mari cantităţi de date): i) prin intermediul unor motoare de căutare sau agenţi software, care caută în mod activ prin reţea, ii) permiţând clienţilor care intenţionează să ofere informaţii prin Internet să se înregistreze la aceste servere de informaţii. În cazul managementului IV, aceste servere pot fi utilizate de către întreprinderile individuale pentru a anunţa sau pentru a obţine informaţii relevante. Funcţiile importante ale unui consiliu de administraţie inteligent al unei întreprinderi virtuale sunt: colectarea specificaţiilor cu privire la scop şi oferte (filtrare/regăsire off-line autonomă de informaţii); răspunsul on-line la cereri de oferte; pag. 47 / 109

48 informarea automată a cererilor, în cazul în care cererile precedente au fost potrivite cu succes cu noile oferte. În figura se ilustrează arhitectura sistemului unei pieţe IV electronice inteligente (Fischer, 1996). Centrul sistemului este un server nformaţional care menţine consiliul de administraţie al IV, precum şi serviciile care pot fi accesate de diferitele companii din reţeaua întreprinderii virtuale. Există şi software de nivel înalt, care suportă activităţile IV, de exemplu, există agenţi asistenţi inteligenţi (IAA Intelligent Assistant Agents) care oferă suport în procesul de decizie. Figura Arhitectura unui sistem al pieţei IV electronice inteligente Agenţii asistenţi sunt opţionali; utilizatorii umani care nu au un astfel de agent trebuie să poată şi ei utiliza serviciile pieţei IV. Serverele de informaţii trebuie să ofere formulare standard care să fie completate de către utilizatori prin intermediul unor browser-e web comerciale. O funcţie importantă în formarea întreprinderii virtuale este aceea îndeplinită de managerul de producţie, care coordonează selecţia partenerilor şi împărţirea sarcinilor partenerilor pentru procesele parţiale. Aceste activităţi necesită un nivel înalt de coordonare şi comuncare cu ceilalţi aprteneri ai IV. Nu se poate presupune faptul că toate informaţiile necesare pentru procesul de decizie sunt la dispoziţia managerului de producţie, astfel încât, rolul acestuia este cel al unui coordonator în cadrul unui sistem descentralizat, care este expert în domeniul asamblării întreprinderii virtuale. În exemplul din figura , întreprinderea A îndeplineşte rolul de manager de producţie. Bineînţeles, acest rol poate fi îndeplinit şi de către mai multe organizaţii, fiind distribuit diferiţilor parteneri ai IV. Managerul de produs poate fi ajutat prin utilizarea tehnologiilor agenţilor inteligenţi. Entităţilor IAA le pot fi atribuite sarcini semiautomate, cum sunt identificarea potenţialilor parteneri, şi maparea partenerilor la procesele parţiale. Aceste lucruri se pot implementa sub forma unor mecanisme de licitaţie. Managerul de producţie poate iniţia licitaţii, iar organizaţiile înregistrate la serverul de informaţii pot să liciteze asupra acestor procese parţiale. Mullen şi Wellman (1996) descriu rolurile care pot fi îndeplinite de agenţii inteligenţi în piaţa IV electronică: identificarea bunurilor şi serviciilor (similară cu sarcinile de regăsire, filtrare şi extragere a informaţiilor, îndeplinite de către agenţii asistenţi inteligenţi). pag. 48 / 109

49 Ideea de bază a abordării problemei de formare a IV este aceea de a ne uita la acest proces ca fiind o problema de decizie în sisteme multiagent. Soluţia acestei probleme constă în rezolvarea a patru paşi: - specificarea scopurilor: descrierea procesului global, adică produsul sau serviciul care trebuie asigurat de către întreprinderea virtuală; - descompunerea: maparea specificaţiei globale a scopului IV în procese parţiale; - alocarea: selecţia potenţialilor parteneri şi maparea partenerilor la procesele parţiale identificate în pasul anterior; - sinteza: definirea procesului global prin compunerea proceselor parţiale instanţiate în pasul de alocare. Specificarea scopului. Întreprinderile virtuale sunt create cu scopul oferirii unui produs sau serviciu. Astfel, descrierea IV este dată de specificarea atributelor produsului sau serviciului oferit. Atribute relevante sunt: costul, calitatea, preţul, piaţele de desfacere, timpul de livrare, cât şi constrângeri impuse potenţialilor participanţi în cadrul IV. Specificarea scopului IV este o sarcină ce trebuie îndeplinită de un expert, de aceea ne aşteptăm ca formalizarea acestui proces să fie destul de dificilă, greu de automatizat, chiar şi parţial. Cu toate acestea, IAA pot ajuta managerul de produs în proiectarea specificaţiei scopului IV, îndeplinind funcţii de asistare: de exemplu, în majoritatea cazurilor, specificaţiile se fac pe baza unui proces de cooperare şi implică interacţiunea cu alte intreprinderi. Această cooperare poate fi asistată de instrumente CSCW sau Groupware. Descompunerea. Pornind de la specificaţiile produsului / serviciului IV, procesele parţiale relevante sunt identificate şi formalizate utilizând o tehnică de modelare adecvată, cum este ARIS. Majoriatea acestor sarcini vor fi îndeplinite de către experţi umani, asistaţi de agenţi inteligenţi. În funcţie de complexitatea acestui proces, pasul de descompunere, poate fi îndeplinit în mod centralizat sau descentralizat, ultimul implicând activităţi inginereşti cooperative. Alocarea. După pasul de descompunere, procesele parţiale trebuie distribuite agenţilor care ar putea contribui la implementarea acestora. În acest sens, trebuie să se realizeze alocarea proceselor parţiale către partenerii potenţiali. Aceasta implică următoarele activităţi: - selecţia poteţialilor parteneri; - distribuirea (anunţarea) proceselor parţiale către potenţialii parteneri; - selecţia partenerilor care să se ocupe de fiecare proces individual; Prima activitate poate fi susţinută de către agenţi informaţionali care interacţionează cu agenţii asistenţi inteligenţi (IAA), care reprezintă fiecare întreprindere. Celelalte două activităţi definesc problema alocării într-un mod strict. O soluţie centralizată la problemele de alocare descrise în literatura de specialitate este reprezentată de mecanismele de licitaţie. În activităţile de distribuire şi de alocare a subproceselor, managerul de producţie poate fi asistat de către un agent, ale cărui funcţii pot fi: i) regăsirea informaţiilor relevante, însemnând anunţurile IV existente care se potrivesc cu posibilităţile (competenţele) întreprinderilor din reţea, ii) formularea de noi oferte, iii) suport pentru procesele de licitaţie: oferte şi evaluare a ofertelor, şi iv) efectuarea în mod autonom a unor sarcini soecifice, legate de negociere. Pasul de alocare poate să se desfăşoare în două moduri: în alocarea orizontală, întreprinderile individuale sunt complementare în ceea ce priveşte serviciile oferite, adică diferite întreprinderi acoperă diferite părţi ale procesului. În modul de alocare verticală, un singur proces parţial este acoperit de un grup de întreprinderi. Sinteza. Ultimul pas presupune compunerea proceselor parţiale - care au fost mapate la partenerii potriviţi - într-un proces care reflectă valoarea adăugată toatală a întreprinderii virtuale. O problemă practică majoră în acest context este aceea că procesele parţiale care trebuie conectate se derulează în diferite medii geografice şi instituţionale, în cadrul diferitelor întreprinderi din cadrul întreprinderii virtuale. Aşadar, conectarea a două procese parţiale nu poate fi realizată doar pag. 49 / 109

50 prin simpla lor compunere, ci este, mai degrabă, un proces de re-inginerie economică, având în vedere faptul că cele două procese trebuie modificate pentru a putea fi îmbinate într-o manieră căt mai eficientă. Această sarcină poate fi mult simplificată prin utilizarea unui formalism de descriere uniformă, sau prin modele de referinţă predefinite. Pentru a face faţă provocărilor din piaţa globală de azi, flexibilitatea şi reacţia rapidă la cererile clienţilor sunt chestiuni obligatorii pentru întreprinderile de succes. Pentru a susţine aceste provocări, este nevoie de instrumente pentru planificare adaptivă, inteligentă, şi de sisteme de control. Sistemele multi-agent oferă perspective favorabile în definirea unor soluţii adecvate. Un sistem multi-agent este o reţea slab interconectată de entităţi care rezolvă probleme lucrând împreună pentru a găsi soluţii la probleme a căror rezolvare depăşeşte capacităţile sau cunoştinţele individuale ale entităţilor. Maheshwari, (2005) punctează câteva contribuţii ale agenţilor individuali şi ale sistemelor multi-agent în cadrul intreprinderilor virtuale. Principalul rol identificat al agenţilor individuali în IV este în generarea scopului IV. Aceştia utilizează diferite seturi de reguli pentru a reprezenta scopurile şi încrederea, cu o prioritate descrescătoare. Regulile prin care este definită încrederea conţin informaţiile despre starea curentă. Regulile prin care se definesc scopurile reprezintă informaţii despre stările viitoare. Pe baza acestor reguli, agentul îşi va planifica următoarele acţiuni. Din perspectiva agentului individual, sistemele multi-agent diferă de sistemele cu agenţi individuali prin prisma faptului că dinamica mediului înconjurător poate fi determinată de către alţi agenţi. În plus faţă de incertitudinea care poate fi prezentă, alţi agenţi pot modifica intenţionat mediul în moduri imprevizibile. Aşadar, toate sistemele multi-agent pot vi privite ca având medii dinamice. Pot să existe oricâţi agenţi, cu diferite grade de eterogenitate, având sau neavând capabilităţi de comunicare directă. Caracteristicile sistemelor multiagent: distribuţia şi natura flexibilă a acestora imprimă robusteţe, scalabilitate, şi adaptabilitate arhitecturilor de IV care se bazează pe astfel de sisteme. În intreprinderile virtuale, colaborarea este cheia succesului. Având zeci de entităţi care lucrează împreună utilizând diferite strategii pentru a atinge obiectivul general al IV, este necesar ca toate entităţile să lucreze coordonat. În timp ce paralelismul este atins prin delegarea anumitor sarcini unor agenţi, robusteţea este adevăratul beneficiu al sistemelor multi-agent care au agenţi redundanţi. Dacă funcţiile de control şi responsabilităţile sunt îndeajuns de bine împărţite între diferiţii agenţi, sistemul devine mai tolerant la posibilele erori ale unuia sau a mai multor agenţi. Alt beneficiu al sistemelor multi-agent este scalabilitatea acestora. Întrucât ele sunt prin definiţie modulare, ar trebui să fie destul de uşor să se adauge noi agenţi la un sistem multi-agent. În abordarea bazată pe agenţi a intreprinderilor virtuale, există însă şi câteva limitări: nu există un control al întregului sistem o soluţie bazată pe agenţi nu poate fi adecvată pentru domenii în care trebuie menţinute nişte constrângeri globale, în domenii în care trebuie evitate orpirile parţiale sau totale ale activităţii; nu există o perspectivă globală luarea deciziilor pe baza cunoştinţelor limitate la nivel local de către agenţi individuali poate duce la decizii globale sub nivelul optim; încrederea şi delegarea pentru ca indivizii să fie împăcaţi cu ideea de a delega sarcini la agenţi software, trebuie ca cei dintâi să aibe încredere în cei din urmă. Rocha (1999) propune un alt exemplu de aplicare a agenţilor în formarea IV. Se presupune că există o piaţă electronică virtuală unde întreprinderile, reprezentate de agenţi, care sunt distribuite geografic şi nici nu sunt dinainte cunoscute, se pot întâlni şi coopera pentru a îndeplini împreună un scop economic comun. O arhitectură multi-agent este propusă pentru a modela piaţa economică în vederea susţinerii mecanismelor de formare a IV. Pe lângă agenţii care reprezintă întreprinderile individuale, există şi un agent coordonator broker care este creat şi introdus în comunitatea agenţilor atunci când este descoperită o oportunitate de business. Acesta coordonează aplicarea unui protocol, pentru a realiza contractele între parteneri în modul următor: pag. 50 / 109

51 - agentul broker trimite invitaţii în piaţa electronică, corespunzătoare fiecărui sub-scop al întreprinderii virtuale; - primeşte ofertele de la agenţii economici şi le analizează; - utilizând un mecanism de selecţie în funcţie de mai multe criterii şi negocieri bazate pe anumite constrângeri, se vor selecta cele mai favorabile oferte; (exemple ale unor criterii sunt: costul, calitatea, disponibilitatea, etc. Se asociază valori ale utilităţii fiecărui criteriu şi e utilizată o combinaţie liniară a valorilor atributelor ponderate cu valorile de utilitate corespunzătoare); - au loc apoi mai multe runde de negociere; la sfârşitul fiecărui runde, licitatorii sunt notificaţi cu privire la pierderea, sau câştigul licitaţiei; notificarea conţine şi scurte precizări calitative, iar licitatorii pot să-şi modifice parametrii ofertei. Li şi alţii (2000) propun o abordare asemănătoare; ei prezintă în plus o analiză mai detaliată a problemei de descompunere a scopului întreprinderii virtuale, care duce la o ierarhizare a scopurilor IV. Ei adaugă, pe lângă agenţii care reprezintă intreprinderile individuale şi agentul broker, agent informaţional care va păstra informaţiile publice referitoare la regulile organizaţionale şi operaţionale comune, mediul pieţei, întreprinderi şi produsele / serviciile oferite. Este deasemenea explicit introdusă nevoia de o ontologie comună, care să susţină comunicarea între agenţi şi este implementat un proces de selecţie / negociere bazat pe anumite constrângeri. Davidrajuh şi Deng (2000) propun utilizarea unor agenţi mobili care sunt trimişi să verifice capabilităţile potenţialilor furnizori. Aceşti agenţi efectuează o selecţie la faţa locului, pe baza unei analize calitative estimative; informaţiile aduse de aceştia sunt analizate mai detaliat de către transmiţător. Ca parte a procesului de selecţie, este făcută şi o estimare a performanţei parteneriatului candidaţilor bazată pe istoricul cooperărilor anterioare. Shen şi Norrie (1998) identifică nevoia existenţei unor agenţi cu rol similar al paginilor aurii, responsabili cu acceptarea measajelor pentru înregistrarea serviciilor (în mod similar cu serverul de informaţii descris anterior). Deasemenea se consideră conceptul de Arie Locală, o diviziune cvasi-fizică a reţelei care este controlată de către un controller de local. Alte limitări ale agenţilor în soluţiile propuse - Limitări ale soluţiilor, care îngreunează implementarea acestora în practică sunt identificate tot de către Camarinha-Matos (2002): nu există standarde şi ontologii comune, ceea ce crează o situaţie dificil de trecut în contextul unui univers global al întreprinderilor; nici una dintre aceste propuneri nu ia în considerare faţete caracterizate de subiectivitate, legate de încredere, angajament, istorie a cooperării, etc.; în general, nu se acordă suficientă atenţie aspectelor de implementare şi management al pieţei; aspectele legate de securitate în cadrul proceselor de negociere nu sunt adresate corespunzător; este un punct critic întrucât agenţii sunt doar în mod parţial cooperativi (aceştia pot fi competitivi, pot avea interese personale, şi pot chiar să exercite un comportament antagonic); încercarea de a atinge un proces complet automat de luare a deciziilor, deşi interesantă din punct de vedere academic, este o aspiraţie puţin ne-realistă, în domeniul de aplicaţie. În termeni practici, deşi împuternicirea electronică, selecţia şi căutarea partenerilor sunt recunoscute ca fiind necesităţi esenţiale, este încă mult de lucru în sensul standardizării directoarelor cu furnizorii şi brokerii, oferind reprezentări comune şi mai avansate ale competenţelor precum şi informaţii adiţionale necesare pentru selecţia partenerilor. Motoarele de căutare asociate acestor directoare trebuie deasemenea să ofere interfeţe pentru accesul de la distanţă a aplicaţiilor sau a agenţilor mobili. Interfeţele uzuale, orientate înspre utilizatori umani via browsere web, sunt foarte eterogene. Cu doar câteva excepţii, informaţia prezentată în astfel de directoare este limitată. Procesele de negociere constând în mai mulţi paşi sunt parte a selecţiei partenerilor; găsirea potenţialilor parteneri într-un director este doar primul pas al procesului, care poate implica mai multe interacţiuni între iniţiatorul întreprinderii virtuale şi potenţialii parteneri, pag. 51 / 109

52 în scopul strângerii a cât mai multe informaţii şi de a perfecta un acord asupra formei şi termenilor cooperării. Înţelegerea acestui proces, modelarea sa şi dezvoltarea unor instrumente suport sunt încă provocări deschise. Un aspect important în formarea / crearea IV este acela că agilitatea şi dinamismul necesare pentru ca organizaţiile din reţea să răspundă rapid oportunităţilor de afaceri sunt în contrast cu procesul de construcţie a încrederii reciproce. Crearea pe termen lung a unor clustere de întreprinderi industriale sau de servicii este o abordare care poate depăşi aceste obstacole şi poate susţine formarea rapidă a IV, în funcţie de oportunităţile de business. Conceptul de cluster de întreprinderi, care nu trebuie considerat ca fiind acelaşi ca şi întreprinderea virtuală, reprezintă un grup, sau un rezervor de întreprinderi şi instituţii suport anexe, care au atât potenţialul cât şi dorinţa de a coopera unele cu altele prin stabilirea unui acord de cooperare pe termen lung. Relaţiile cumpărători furnizori, tehnologiile comune, pieţe sau canale de distribuţie comune, resurse comune, sunt elemente care, tipic, încheagă clusterul de întreprinderi. Întreprinderile din cluster sunt înregistrate într-un director, unde sunt declarate capabilităţile lor de bază. Pe baza acestor informaţii, iniţiatorul / creatorul IV, care, de obicei, este un membru al cluster-ului poate selecta partenerii atunci când este identificată o oportunitate de business. Un cluster, prin prisma faptului că reprezintă o organizaţie pe termen lung, este un mediu adecvat pentru stabilirea unor acorduri de colaborare, a unor infrastructuri comune, ontologii comune, şi încrederea mutuală; toate acestea facilitează formarea unei întreprinderi virtuale. În Figura sunt prezentate două abordări în ceea ce priveşte formarea unei IV. Figura Două principii de abordare a modului de formare a unei IV Proiectul MASSYVE (Rabelo, 1999) este un exemplu de aplicare a sistemelor multi-agent în cadrul unui cluster industrial format din douăsprezece companii. Clusterul este reprezentat legal de către o entitate broker, care susţine un expert uman responsabil cu descoperirea şi analiza oportunităţilor de business. Prin intermediul unui agent broker, oportunitatea este transformată într- pag. 52 / 109

53 un proces economic distribuit care este apoi distribuit către potenţialii contractori ai subproceselor care fac parte din cluster. La finele întregului proces se formează un set de posibile echipe de întreprinderi (IV potenţiale) care pot răspunde oportunităţii de afaceri; urmează ca agentul să propună cea mai competitivă echipă, însă decizia finală aparţine expertului uman. Aspectul distinctiv al proiectului MASSYVE este adoptarea unei filosofii hibride / semiautomate, în care agenţii sunt utilizaţi ca şi asistenţi ai experţilor umani. Faptul că abordarea MASSYVE este concentrată înspre un cluster de întreprinderi, adică un univers multi-agent controlabil (după cum este ilustrat în figura XX), face ca soluţia să fie una fezabilă din punct de vedere al implementării, întrucât un cadru comun de modelare poate fi agreat de către toţi membrii cluster-ului (alianţei pe termen lung). Cercetările actuale se întreaptă înspre modelarea şi planificarea diferitelor forme organizaţionale a contactelor şi a mecanismelor de punere în practică. Alt aspect important în ceeea ce priveşte formarea IV este specificarea sarcinilor necesare a fi efectuate pentru îndeplinirea obiectivului economic al întreprinderii virtuale. Activităţile realizate de către o companie sunt de obicei organizate în grupuri de activităţi interconectate, denumite procese de afaceri, care pot fi văzute ca un set de activităţi, reguli şi constrângeri care specifică paşii de urmat, precum şi condiţii care trebuie satisfăcute, pentru a îndeplini un anumit obiectiv. Părţile componente ale fiecărui proces sunt proiectate pentru a atinge un scop (parţial) specific. Atunci când un proces de afaceri este executat într-o IV, anumite părţi ale procesului descompus (sub-procese) sunt desemnate diferitelor întreprinderi (şi astfel diferitor agenţi), ceea ce duce la formarea unui proces economic distribuit (DBP Distributed Business Process). Dacă aceste sub-procese sunt orchestrate în mod corect, combinaţia acestora duce la îndeplinirea scopului global al IV. Problema supervizării şi coordonării proceselor econimice distribuite şi a diferitelor nivele de descompunere este deosebit de importantă, având în vedere faptul că definirea şi adoptarea acestora se face nu în contextul unei organizaţii singulare, ci în nişte noduri eterogene, autonome şi distribuite care trebuie să colaboreze. Agenţi în operarea IV În ceea ce proveşte operarea întreprinderii virtuale, cele mai multe abordări găsite în literatura de specialitate consideră faptul că nişte mecanisme simple de cooperare inter-agenţi sunt suficiente. Totuşi, înainte ca sistemele multi-agent să fie aplicate pentru operarea întreprinderii virtuale, trebuie să fie îndeplinite mai întâi câteva condiţii estenţiale: - acordurile de cooperare şi contractele, care definesc cadrul de lucru pentru condiţiile de operare generale, trebuie stabilite dinainte; - trebuie să existe modelele proceselor de business distribuite şi mecanismele care stabilesc alocarea şi secvenţiunea sarcinilor care vor fi îndeplinite de către comunitate; - trebuie garantate următoarele: schimb eficient de date, servicii de comunicaţie, funcţionalităţi de management al serviciilor distribuite, suportul pentru autonomie/confidenţialitate noduri, calitate a serviciilor, auditarea şi contabilitatea; Procesul de luare a deciziilor este unul hibrid; este importantă combinarea deciziei umane cu unele funcţionalităţi automate. Însă, în mod independent de centrul de decizie, este nevoia de a oferi mecanisme care să ofere mecanisme de susţinere a coordonării proceselor, supervizării şi controlul informaţiei schimbate şi împărtăşite. În cadrul proiectului MIAMI (Broos, 2000), s-a dezvoltat o platformă de agenţi mobili pentru IV care susţine o piaţă virtuală pentru formarea IV şi un serviciu de monitorizare folosit în timpul operării IV pentru a superviza procesele şi pentru a oferi informaţiile despre starea subproceselor partenerilor care au permisiunea adecvată. Coordonarea globală este realizată cu ajutorul unui sistem de management al workflow-ului. Alt exemplu de aplicare a tehnologiei agenţilor este proiectul MetaMorph II, în cadrul căruia s-a realizat o arhitectură multi-agent pentru susţinerea integrarea întreprinderilor şi managementul lanţului de aprovizionare. Şi în proiectul MASSYVE se regăsesc funcţionalităţi care oferă suport pentru operarea IV. Nodurile - agenţi pag. 53 / 109

54 reprezintă fie întreprinderi, atunci când este discutată problema de planificare la nivelul întreprinderii virtuale, fie resurse de fabricaţie interne ale unei companii, atunci când se pune problema planificării interne a sarcinilor într-o companie. Un mecanism de contractare este utilizat pentru asignarea sarcinilor agenţilor şi o metodă de negociere este utilizată pentru rezolvarea conflictelor care pot avea loc atât în faza de planificare cât şi în cea de execuţie, la nivele intra şi inter întreprinderi. Se propune o integrare a sistemelor multi-agent şi a managementului federativ al informaţiilor. Fiecare agent este dotat cu un sistem de management federativ al informaţiilor (FIMS Federated Information Management System), cu ajutorul căruia interoperează şi schimbă informaţii cu alţi agenţi. Cu toate acestea, având în vedere autonomia agenţilor, accesul la informaţii este controlat puternic prin intermediul unor drepturi de vizibilitate a informaţiei definite printre agenţi, care, în schimb se bucură de autonomie. Aşadar un agent în cadrul proiectului MASSYVE este văzut ca un tandem de arhitecturi, compus dintr-un agent normal şi al său FIMS. Un concept esenţial introdus în această arhitectură este acela că datele nu sunt trimise de la un agent la altul prin intermediul unui protocol de nivel înalt aşa-numita strategie push, ci printr-o strategie pull, prin accesarea FIMS al agentului respectiv. Aşadar, protocolul de nivel înalt este utilizat pentru scopuri de coordonare / control. În Figura se ilustrează acest concept. Pentru exemplificare, să considerăm faptul că un agent (B) procesează nişte informaţii şi generează un rezultat (să spunem data finală pentru producţia componentei P ) care este necesar unui alt agent (A), conform unor clauze de supervizare predefinite în contractul IV. Urmând contractul, agentul B trimite un mesaj către agentul A (săgeata 1 din figură), comunicându-i faptul că datele referitoare la data finală de producţie a componentei P este la acea întreprindere. Acest mesaj de control de la B la A informează A că data este disponibilă şi că poate fi accesată de către A (prin intermediul schemei sale de import a datelor). Figura Schimbul de date conform strategiei pull Drepturile de acces pentru datele împărţite între noduri sunt configurate în mod dinamic şi bilateral şi sunt păstrate de către schemele de import-export, un mecanism de bază în cazul abordării federative a managementului informaţiilor, în funcţie de rolul agenţilor în cadrul de colaborare şi de nevoile acestora. Odată mesajul primit la A, oricând va dori A, va putea să acceseze informaţiile actualizate de la B. Schimbul de mesaje este conform notaţiilor 2 5 din Figura Platforma JADE JADE (Java Agent Development Framework) este un framework care oferă suport pentru implementarea aplicaţiilor intelgente implementat în totalitate în limbajul Java în concordanţă cu specificaţiile FIPA (Foundation for Intelligent Physical Agents). Modelul standard al unei platforme de agenţi, în conformitate cu specificaţiile FIPA este ilustrată în firgura de mai jos. pag. 54 / 109

55 Funcţiile de management al platformei şi de control al accesului la serviciile furnizate intră în sarcina agentului de tip AMS (Agent Management System). O platformă multi-agent gestionează un singur agent AMS, la un moment dat. Acest agent gestionează ciclul de viaţă al celorlalţi agenţi de pe platformă prin intermediul unei baze de date ce conţine identificatorii (AID) tuturor agenţilor activi în cadrul platformei şi starea acestora. În momentul rulării, un agent activ se înregistrează la agentul AMS şi obţine obţine un identificator valid care va fi stocat în baza de date de pe platformă alături de starea agentului. Funcţiile de căutare şi identificare a agenţilor sunt implementate de către agentul DF (Directory Facilitator). Acesta permite căutări în cadrul platformei pentru a stabili existenţa unui anume agent. Sistemul de transport al mesajelor (Message Transport System), denumit şi canal de comunicaţie inter-agent (Agent Communication Channel), este componenta software responsabilă cu controlul inter-schimbului de mesaje în cadrul platformei, inclusiv mesaje primite de la sau transmise la alte platforme. Figura Modelul standard al unei platforme de agenţi JADE respectă în totalitate arhitectura şi specificaţiile FIPA. În momentul lansării unei platforme JADE, sunt instanţiaţi, în mod automat, agenţii AMS şi DF iar modulul ACC este iniţializat în vederea transmiterii mesajelor. Platforma de agenţi inteligenţi poate fi împărţită pe mai multe sisteme, pe fiecare sistem rulând o singură maşină virtuala Java (JVM). Fiecare maşină virtuală reprezintă un container pentru agenţi, şi oferă un mediu de rulare acestora, permiţând în acelaşi timp existenţa mai multor agenţi simultan pe acelaşi sistem gazdă. Conteinerul principal este cel care găzduieşte agenţii AMS şi DF şi unde se crează registrul RMA folosit de către platforma JADE. Celelalte containere sunt conectate la containerul principal şi oferă un mediu de funcţionare pentru orice set de agenţi JADE. Figura de mai jos ilustrează modul de interconectare a mai multe platforme JADE, realizând în acest mod o platformă multi-agent distribuită. Conform specificaţiilor FIPA, agenţii DF şi AMS comunică folosind limbajul FIPA-SL-0, ontologia fipa-agent-management şi protocolul de interacţiune fipa-request. JADE oferă implementări pentru fiecare din acest componente: Limbajul SL-0 este implementat în cadrul clasei jade.lang.sl.sl0codec. Posibilitatea folosirii în mod automat a acestui limbaj poate fi adăugată oricărui agent folosind metoda Agent.registerLanguage(SL0Codec.NAME, new SL0Codec()); Conceptele de ontologie (exceptând Agent Identifier, ce este implementat de către jade.core.aid) sunt implementate cu ajutorul claselor din pachetul jade.domain.fipaagentmanagement. Clasa FIPAAgentManagementOnthology defineşte vocabularul cu toate simbolurile şi constantele de ontologie. Posibilitatea folosirii în mod automat a aceste ontologii poate fi adăugată oricărui agent folosind următoarul cod: Agent.registerOntology(FIPAAgentManagementOntology.NAME, FIPAAgentManagementonthology.instance()); Protocolul de interacţiune fipa-request este implementat în cadrul pachetului jade.proto. pag. 55 / 109

56 Figura Modul de realizare a unei platforme distribuite folosind JADE Protocoalele de comunicare inter-agent au la bază un mod flexibil de schimb de mesaje, JADE crează şi administrează o coadă de aşteptare a mesajelor ACL ce se primesc, pentru fiecare agent în parte, iar agentul accesează această coadă de aşteptare în diferite moduri: cu blocare, selectiv, cu limită de timp sau după o anumită schemă. JADE implementează modelul de comunicare FIPA iar componentele sale au fost integrate în totalitate: protocoale de interacţiune, împachetări, mesaje ACL, limbaje de conţinut, scheme de codare, ontologii şi protocoale de transport. În particular, mecanismul de transport este unul flexibil, deoarece se adaptează fiecărei situaţii, alegând în mod transparent protocolul disponibil. Protocoalele clasice de transport sunt HTTP şi IIOP, în amblele cazuri metoda de comunicaţie implică notificări generate în urma unor evenimente. Se pot adăuga foarte uşor şi alte protocoale precum SMTP, sau WAP. Majoritatea protocoalelor definite de către FIPA sunt deja disponibile. pag. 56 / 109

57 1.4. Arhitecturi utilizate în dezvoltarea sistemelor de tip întreprindere virtuală Proiectarea sistemelor de tip IV având la bază arhitectura multi tier În cadrul unui sistem informaţional de tip enterprise componentele pot fi găzduite pe diferite servere în diferite locaţii. Orice sistem informaţional complex poate fi divizat în straturi, în concordanţă cu funcţia fiecărei părţi componente a acestuia: nivelul de prezentare a informaţiei, nivelul de business şi nivelul de date. Nivelul de prezentare a informaţiei este distribuit între părţile client şi server. Partea de client constă în componentele HTML (în cazul sistemelor web) generate dinamic de către componentele părţii server, componente Java Applet, ActiveX, SWF, iar componentele părţii de server au la bază tehnologii puternice capabile să gestioneze cererile de la client, să transforme aceste cereri în comenzi interne şi să le transmită componentelor logicii de business (care implementează, de fapt, logica aplicaţiei). De asmenea, componentele părţii de server încapsulează datele primite de la nivelul de business (din model), conform logicii de prezentare a informaţiei pentru a fi afişate la utilizator. Logica de asamblare a informaţiei pentru a fi afişată la utilizator respectă conceptul de template. Conceptul de template are în vedere două aspecte importante ce pagină trebuie afişată şi cum va fi asamblată informaţia pentru a fi afişată la utilizator. Acestea se bazează pe următoarele tipare de proiectare: ScreenView care implementează funcţionalitaţile de asamblare a informaţiilor pentru a fi afişate la utilizator. CompositeView care are sarcina de a asambla componentele de vizualizare (banner, bottom, menu, payload) într-o singură componentă, utilizând o singură locaţie pentru layout-ul paginii. ScreenFlowManager care desemnează componenta ce trebuie încărcată, în baza cererii primite de la client. Figura Arhitectura multi-tier Componenta FrontController va recepţiona o cerere HTTP executată de către componenta client, va converti această cerere într-un eveniment şi va transmite acest eveniment unei componente EJB de tip sesiune, EJBTierController, care-l va converti în comandă internă, prin intermediul altor două componente, CommandFactory şi CommandHandler. Cu alte cuvinte, componenta Controller se împarte între straturile Web şi EJB. Mecanismul de tratare a cererilor de la clienţi trebuie să ţină cont de faptul că fiecare utilizator va solicita diferite cereri de serviciu, prin intermediul aplicaţiei client. Acest mecanism poate fi centralizat sau descentralizat, depinde de pag. 57 / 109

58 dezvoltator ce concepte foloseşte şi pentru ce tehnologii optează. Prezentarea informaţiei constrânge proiectantul implementarea accesului la servicii într-o manieră centralizată care oferă suport pentru integrarea serviciilor, funcţionalităţi de accesare rapidă şi eficientă a informaţiilor din banca de date, funcţionalităţi de management a componentelor care asigură prezentarea informaţiei sau funcţionalităţi de navigare rapidă în sistem. Componenta business delegate defineşte maniera de acces la serviciile EJB ale clienţilor şi asigură transparenţa serviciilor. Componenta session façade este o componentă EJB de tip sesiune folosită ca faţadă pentru a încapsula întreg setul de interacţiuni între obiectele de business găzduite de containerul EJB. Această componentă implementează funcţionalităţi de management al obiectelor de business şi furnizează acces uniform la servicii clienţilor. Data Access Object abstractizează şi încapsulează accesul la sursa de date. DAO gestionează conexiunea cu sursa de date pentru stocarea sau citirea informaţiei. Figura Sistem colaborativ. Componente middleware Un sistem IV proiectat pe o arhitectură multi-tier este compus din următoarele module: Modulul de management al utilizatorilor cu rol în autorizarea accesului şi managementul utilizatorilor (profilul utilizatorului, etc); Modulul de business compus din componentele de management al conţinutului informaţional şi componentele de management al fluxului de producţie; Modulul de control al sesiunilor colaborative interpresonale şi interprocese; Platforma de agenţi inteligenţi care constituie bazele componentelor de tip business intelligence şi data mining; Proiectarea sistemelor de tip IV având la bază arhitectura SOA SOA devine un concept de vârf în proiectarea platformelor de servicii integrate. Este o arhitectură software flexibilă în cadrul căreia funcţionalităţile sunt grupate în jurul proceselor de business şi împachetate în cadrul serviciilor interoperabile. De asemenea, SOA descrie infrastructura IP care permite dfiferitelor componente în cadrul aceluiaşi proces interschimbul de date. Serviciile furnizate sunt independente de platformă şi limbajul de programare utilizat în procesul de implementare sau alte tehnologii folosite. SOA permite proiectatului să separe funcţionalităţile în unităţi distincte sau servicii mai accesibile care pot fi combinate şi reutilizat cu uşurinţă. SOA unifică procesele de business prin restructurarea aplicaţiilor complexe ca şi colecţie de servicii. Acestea comunică unele cu altele prin interschimbul direct de date sau prin coordonarea unei activităţi între două sau mai multe module/servicii. Serviciile pot fi utilizate de către personalul din organizaţie şi colaboratori externi atât în interiorul cât şi în afara instituţiei (intranet sau internet). Aplicaţiile noi, create prin utilizarea acestor servicii oferă un grad ridicat de flexibilitate. SOA oferă un framework pentru soluţii rapide şi economice de dezvoltare şi îmbunătăţire a sistemelor existente. Cu toate astea, o serie de probleme pot apare când se aplică SOA în cadrul sistemelor care oferă funcţionalităţi colaborative în timp real. Aceste probleme includ timpul de răspuns, suport pentru mai multe fire de execuţie, tratarea evenimentelor şi a altor pag. 58 / 109

59 mecanisme paralele, suportul pentru interacţiune multimodală om-maşină, sau stabilitatea sistemului. SOA poate fi definit ca un grup de servicii şi componente care comunică unele cu altele. Procesul de comunicare implică interschimb simplu de date între două sau mai multe servicii în cadrul aceluiaşi proces. Serviciile sunt considerate unităţi funcţionale care nu prevăd noţiunea de apel, ele comunică prin intermediul protocoalelor de comunicaţii. Serviciile sunt de obicei implementate cu ajutorul limbajelor de programare şi tehnologiilor consacrate. Principalul obiectiv al arhitecturii SOA este de a permite posibilitatea proiectării rapide a unui nou sistem având la bază componente deja existente care conlucrează împreună pentru a furniza noi servicii. Costurile de creare a unei noi aplicaţii sunt practic nule, deoarece toate componentele software există deja, fiind nevoie doar de scenariul de implementare a funcţionalităţilor oferite iar acest aspect defineşte regulile de funcţionare ale noului sistem, adică orchestraţia acestuia. Figura Elementele SOA Sistemele IV implică o serie de procese simple ca, de exemplu, colaborare interpresonală, colaborare interprocese, managementul conţinutului informaţional, integrarea instrumentelor colaborative, iar funcţionalităţile sunt implementate în cadrul unor componentelor (module) independente. Acest aspect promovează conceptul de arhitectură orientată pe servicii însă nu neglijează nici utilizatorul, indiferent de domeniile unde organizaţia virtuală oferă servicii. De exemplu, în cadrul colaborării pe producţie software se întâlnesc următorii actori: un responsabil de produs, un director de proiect, dezvoltatori software, analişti, graficieni, şi ingineri de sistem şi se optează pentru urmatoarele tipuri de servicii: Servicii ontologice care furnizează informaţiile ontologice (descrieri, definiţii); Servicii informaţionale trebuie să returneze setul de informaţii necesare fiecărui actor în procesul colaborativ; Servicii de procesare responsabile pentru fiecare flux de servicii invocate la fiecare acţiune. De asemenea, negociază cu partea de orchestraţie în vederea optimizării acţiunii; Servicii funcţionale autorizează accesul la servicii pentru fiecare participant la procesul colaborativ şi realizează sincronizarea între participanţii la sesiunea colaborativă. SOA este o arhitectură asincronă iar procesele colaborative se desfăşoară, de obicei, în mod sincron, pentru a partaja resurse în timp real, a corecta eventuale erori, etc. Servicii de interacţiune cu utilizatorul transformă fiecare gest al participantului într-o comandă internă caracteristică sistemului. Fiecare gest al participantului generează un eveniment iar acest eveniment trebuie menţionat printr-o comandă internă. pag. 59 / 109

60 Figura Procesul colaborativ de producţie software având la bază arhitectura SOA Calitatea serviciilor (QoS), managementul optimizat al serviciilor şi resurselor şi securitatea sistemului sunt aspecte considerate importante în cadrul arhitecturii SOA unde participanţii la procesul colaborativ partajează resurse şi informaţii în cadrul unui mediu integrat de lucru Proiectarea sistemelor de tip IV având la bază arhitectura LAMP Un număr mare de site-uri web sunt dezvoltate utilizând PHP şi MySQL pe platformă Linux: Apache web server, MySQL server de baze de date. Această combinaţie este cunoscută sub numele de arhitectură LAMP. Apache, PHP şi MySQL sunt, de asemenea, disponibile pe platformă Windows sub două forme: WAMP (Windows, Apache, MySQL şi PHP) şi WIMP (serverul web IIS va fi folosit în locul serverului Apache). Cu toate că LAMP este o arhitectură foarte populară, puţine publicaţii ilustrează caracterisiticile acesteia, mai ales la nivel de aplicaţii. In realitate LAMP descrie orice arhitectură care are la bază un sistem de operare open source, server web open source, server de baze de date open source iar procesul de implementare implică utilizarea unui limbaj de programare open source. De fapt, arhitectura deschisă înseamnă optimizarea costurilor în condiţii de performaţe ridicate. Web browser Client block HTTP Session TCP/IP Flash plug-in Apache MySQL server Figura Arhitectura LAMP În figura este ilustrată arhitectura LAMP şi blocurile sale principale: Serverul de baze de date MySQL care stochează informaţiile cu privire la utilizatori, servicii, conţinut informaţional, etc. pag. 60 / 109

61 Serverul web Apache găzduieşte componentele web care implementează logica aplicaţiei, logica de prezentare a informaţiei şi managementul sistemului. Blocul client, reprezentat de către browserul web care permite utilizatorilor accesul la servicii. Arhitectura LAMP oferă o serie de avantaje dintre care se amintesc cele mai importante: Optimizarea costurilor. Costurile de implementare a unui astfel de sistem sunt foarte mici dat fiind faptul că fiecare nivel din stiva LAMP este, de fapt, o componentă open source. Astfel, costurile se împart între platforma hardware şi procesul de implementare, nefiind nevoie de licenţe software. Flexibilitate sporită. Un sistem creat având la bază arhitectura LAMP este uşor de întreţinut şi extins şi rapid de adaptat la cerinţele aplicaţiei. De exemplu, furnizarea serviciilor în sfera dispozitivelor mobile, se realizează fără a recompila sistemul, deoarece accesul la servicii se face via HTTP iar clientul pentru dispozitive mobile comunică prin intermediul protocolului HTTP cu blocul server. Scalabilitate. Arhitectura LAMP este scalabilă orizontal. Se pot adauga noi componente în sistem fără a fi nevoie de modificarea celor existente. De exemplu, adaugarea serviciilor media (video conferinţă, video telefonie, suport pentru lucru partajat, înregistrare audio/video, etc.) se realizează prin introducerea unui server media (open source media server) în arhitectura sistemului. Aşa cum s-a mai precizat, LAMP este o arhitectură deschisă, căreia i se pot adăuga noi componente. Tendinţele Web 2.0 orientate spre sisteme sincrone, mult apropiate, ca şi funcţionalităţi, de aplicaţiile desktop, şi funcţionalităţile multimedia (necesare în cazul sistemelor IV) duc la extinderea arhitecturii LAMP prin adăugarea de noi componente. Figura ilustrează arhitectura unui sistem de tip IV care oferă suport pentru colaborare sincronă şi asincronă în cazul dezvoltării de produse software în regim outsourcing. Figura Arhitectura LAMP extinsă Părţile componente ale unei astfel de arhitecturi cuprind: Baza de date MySQL care stochează informaţiile cu privire la utilizatorii intreprinderii virtuale (responsabili de produs, responsabili de project, dezvoltatori, designeri, etc.), conţinutul informaţional, strategii privind procesele de business, etc. pag. 61 / 109

62 Serverul web Apache găzduieşte componentele web care implementează logica aplicaţiei, logica de prezentare a conţinutului informaţional şi managementul instrumentelor de producţie. Modulul de conversie care implementează funcţionalităţi de conversie a documentelor în format specific pentru a fi stocat în biblioteca virtuală. Biblioteca virtuală care conţine materialele în diferite formate: documente, materiale multimedia (slideshow, clipuri video, etc) şi înregistrările sesiunilor colaborative. Serverul media care furnizează suport pentru colaborare sincronă: video conferinţă, video telefonie, spaţii partajate, înregistrări audio/video, etc. Blocul client, reprezentat de către browserul web permite utilizatorilor accesul la servicii Prezentarea unor soluţii de intreprinderi virtuale existente pe plan mondial Proiectul AVE (Agents in Virtual Enterprises) Proiectul AVE este o colaborare a două instituţii din Germania: German AI Research Centre (DFKI) şi Institut fur Wirtschaftsinformatik (IWI), care urmăreşte să aplice tehnologia agenţilor inteligenţi în toate mecanismele majore întâlnite la întreprinderile virtuale, de la formare până la operare. Prima sarcină majoră este aceea de a mapa specificaţiile (mai degrabă formale) ale produsului sau serviciului oferit de IV într-o specificaţie a procesului de business care descrie IV. Modelarea proceselor economice se face în proiectul AVE utilizând metodologia ARIS (Architecture for Integrated Information Systems) (Scheer, 1994). ARIS este un cadrul de lucru pentru managementul proceselor economice integrate şi pentru re-ingineria proceselor economice. ARIS combină metode de modelare, re-inginerie şi implementare a informaţiilor corespunzătoare într-un sistem informatic respectând conceptul integrării. ARIS este susţinut de un instrument de lucru computerizat, numit ARIS Toolset. Sarcina de descompunere presupune cercetarea modului în care procesul global poate fi descompus în bucăţi adecvate, care vor putea fi alocate la parteneri individuali. Se poate porni de la modelul întreprinderilor clasice (producţie, marketing, vânzări, distribuţie, etc.) şi se poate ajunge în acest mod la o descompunere a sarcinilor; există însă şi metode mai complexe de descompunere. Procesle parţiale generate în faza de descompunere sunt modele generice de referinţă; instanţierea acestora se va face în faza de alocare. În faza de alocare, adică de atribuire a sarcinilor către partenerii care vor forma întreprinderea virtuală, agenţii inteligenţi joacă un rol important în proiectul AVE. Agenţii sunt proiectaţi conform modelului InteRRaP, descris în Fiecare proces parţial din cadrul procesului global este instanţiat în urma unei proceduri de licitaţie desfăşurate în etapa de alocare. Instanţierea este în mare măsură bazată pe evaluarea alternativelor de modelare. Dezvoltarea unei funcţii utilitate care permite agenţilor individuali să evalueze calitatea unui candidat care licitează pentru un proces parţial include dezvoltarea unor cifre de clasificare care permit cuantificarea solidă a calităţii proceselor, bazată pe o descriere formală a acestora. Acestea conectează vederile economice şi tehnice ale proceselor. O altă abordare a proiectului AVE în ceea ce priveşte managementul IV este aceea de a combina arhitecturi de agenţi cu instrumente din domeniul Groupware sau CSGW, susţinând astfel negocierile între factorii umani şi planificarea electronică a întâlnirilor. Agenţii, în acest caz, adoptă funcţii de asistenţă. pag. 62 / 109

63 C(ollaborative) Project Deoarece întreprinderea virtuală trebuie să poată fi activată într-o perioadă scurtă de timp. este bazată pe ICT care pot fi implementate rapid. Din punct de vedere al arhitecturii, doar ceea ce trebuie împărţit va fi împărţit pentru asigurarea colaborării între întreprinderile IV. Aceasta înseamnă ca orice resurse ICT interne, specifice întreprinderilor individuale, cum este, de exemplu, un sistem ERP, trebuie să fie lăsate în domeniul acelei intreprinderi. Aplicaţia de la nivelul superior, dedicată IV, ar trebui să maximizeze exploatarea sistemelor ICT generice deja disponibile la nivelul întreprinderilor individuale, şi din acestea să creeze un flux de informaţii specific pentru IV. Această gândire stă la baza dezvoltării şi implementării prototipului C-Project (Collaborative- Project), proiectat pentru a fi accesibil printr-un browser web (van den Berg, 2002). O altă caracteristică a acestui prototip este aceea că oferă posibilitatea de a fi uşor integrat cu aplicaţiile existente care execută procesele intra-companii. C-Project nu înlocuieşte aplicaţiile existente, ci oferă funcţionalităţi pentru a conecta diferitele întreprinderi implicate în reţeaua proiectului, pentru a susţine şi îmbunătăţi procesele inter-companii. C-Project este independent de orice sistem intern al întreprinderilor, şi poate fi folosit în mod stand-alone, fără nicio legătură cu sistemele ERP, de exemplu. C-Project este o aplicaţie multi-tier, ceea ce înseamnă că diferite întreprinderi, la diferite nivele ale lanţului valoric al proiectului pot utiliza aceeaşi aplicaţie, creându-se astfel vizibilitate maximă între companii. În timp ce majoritatea aplicaţiilor de lucru colaborativ sunt centrate pe întreprindere, C-Project este orientat înspre reţea. Aplicaţiile orientate înspre întreprindere pot distinge doar între ceea ce este în interiorul şi exteriorul întreprinderii, în ceea ce priveşte resursele umane, procesele şi produsele. Aceasta aduce o dificultate în plus aplicaţiilor inter-întreprinderi, care trebuie să lucreze atât cu entităţi care sunt în interior, cât şi cu entităţi care sunt în exteriorul întreprinderii, însa totuşi în interiorul întreprinderii virtuale din care aceasta face parte. Pentru aceasta, C-Project are prevăzut un motor de modelare, descris de Zwegers şi alţii (2002), care încearcă să se ocupe de unele dintre aceste nuanţe, referitoare la relaţiile economice şi nevoia de a împărţi anumite date între intreprideri. Principalele componente ale sistemului sunt: - reţeaua de intreprinderi; - motorul de modelare a relaţiilor economice dintre întreprinderi; - aplicaţia C-Project; - sistemele individuale ale partenerilor; - nivelul de interoperabilitate, care adaptează sistemele de mai sus; Modulele sistemului C-Project sunt ilustrate în figura Figura Modulele componente ale sistemului C-Project pag. 63 / 109

64 Componenta cu privire la reţeaua de întreprinderi conţine informaţii cu privire la un grup de întreprinderi (reţeaua), cu potenţialul şi capacitatea acestora în cadrul unei (potenţiale) întreprinderi virtuale. Funcţionalitatea prototipului include afişarea competenţelor membrilor reţelei şi disponibilitatea acestora la un anumit moment de timp, lucruri necesare în selecţia partenerilor IV. În plus, documente cum sunt acorduri generale, proceduri, şi aşa mai departe, pot fi stocate pentru a putea fi mai târziu folosite în timpul fazei de formare a IV. Funcţionalitatea acestei componente nu este legată de specificul unei anumite IV. Componenta de modelare a relaţiilor (ERM Enterprise Relationship Modeller) este locul în care toate întreprinderile şi relaţiile acestora din cadrul uneia sau mai multor IV sunt modelate, pe baza unor structuri de descriere a lucrului, structuri de descriere a organizaţiilor, diagrame ale proiectelor, note de necesitate pentru materiale, etc. Acest model este baza pentru orice alt proces economic şi serviciu oferit de sistemul C-Project. Aplicaţia specifică C-project constă dintr-un număr de servicii oferite întreprinderilor cu sarcini specifice într-unul sau mai multe proiecte. Câteva exemple de astfel de servicii sunt: împărţirea de documente, planificare colaborativă a proiectelor, monitorizarea desfăşurării proiectelor. Serviciul care este disponibil depinde de rolul entităţii în IV, modelat cu ajutorul componentei de modelare a relaţiilor întreprinderilor. Partea de comunicaţii şi interoperabilitate a C-Project constă într-o interfaţă către Internet şi posibil, produse standard integrate. Prin intermediul unui browser web este posibilă accesarea serviciilor oferite de sistem. Aplicaţia pilot a C-Project Pentru demonstrare, autorii proiectului au imaginat o IV care să se ocupe de construcţia unei clădiri de birouri. Denumirile întreprinderilor care formează IV sunt imaginare, şi sunt date în scop ilustrativ. Aşadar, principalul contractor al proiectului SkyHigh Construction PLC va proiecta şi construi scheletul clădirii de birouri pentru beneficiar, ABC International, urmând să subcontracteze către RockSolid Building Company construcţia fundaţiei. Aceasta, la rândul său, va subcontracta proiectarea fundaţiei către Archimedes Engineering, iar producţia şi furnizarea de beton la Kricon Suppliers. Detaliile despre rezultatele şi acordurile legate de această structură pot fi stocate în C- Project. Există o interfaţă către proiectul MS, pentru a simplifica încărcarea detaliilor proiectului. In acest exemplu, contractorul principal găzduieşte aplicaţia C-Project. Este deasemenea posibil să se ruleze aplicaţia printr-un ASP (Application Service Provider), fiecare dintre participanţii IV concentrându-se asupra compentenţelor lor. În acest caz, fiecare dintre aceştia este doar un utilizator al aplicaţiei şi plăteşte o anumită taxă pentru serviciile oferite de aplicaţie. Gazda aplicaţiei controlează drepturile de acces pentru ceilalţi parteneri ai IV şi pentru client. Pentru partenerii de afaceri din imediata vecinătate (aşa-numitul nivel 1) controlul este direct. Pentru ceilalţi, controlul este indirect, însemnând faptul că partenerii direcţi ai gazdei au posibilitatea să ajusteze drepturile de acces în limita propriilor drepturi, stabilite de gazdă. În acest caz, SkyHigh poate da personalului abilitat din cadrul ABC posibilitatea de a urmări progrezul proiectului şi poate da anumitor persoane din cadrul RockSolid posibilitatea de a actualiza informaţiile legate de mersul construcţiei fundaţiei. În schimb, RockSolid poate oferi subcontractorilor săi drepturi de acces la informaţii despre sub-procesele relevante pentru activitatea acestora. Desigur, anumite persoane pot avea mai multe roluri în proiect, iar C-Project deosebeşte numele persoanelor de rolul acestora. Pe parcursul desfăşurării proiectului, informaţiile despre progresul acestuia vor fi actualizate. Acest lucru poate fi făcut manual, de persoane autorizate, sau printr-o conexiune dedicată cu sistemele existente în companiile partenere. De exemplu, SkyHigh poate să obţină informaţii despre starea fundaţiei de la sistemul ERP al RockSolid. Odată cu fiecare schimbare a informaţiilor disponibile în C-Project, se va emite în mod automat o atenţionare către factorii care au nevoie de această informaţie (şi doar către aceştia). Spre deosebire de aplicaţiile tradiţionale de pag. 64 / 109

65 management al lanţului de furnizori, C-Project acorda companiei SkyHigh posibilitatea de a verifica starea proiectului fundaţiei dincolo de limitele subcontractorului RockSolid. Se poate, de exemplu, arăta faptul că livrarea de beton este în întârziere, datorită unor probleme de control al calităţii. Această orientare multi-tier a aplicaţiei face mult mai uşor contractorului principal să urmărească stadiul proiectului, reprerând problemele oriunde acestea apar şi putând face astfel ajustările necesare, pentru a menţien proiectul pe direcţia bună GLOBEMEN Proiectul GLOBEMEN, derulat între 2000 şi 2003 sub egida IMS (Intelligent Manufacturing Systems o iniţiativă internaţională pentru sprijinul proiectelor de cercetaredezvoltare site 36) a avut ca şi obiectiv principal definirea unei arhitecturi de referinţă pentru IV, reunind parteneri din spaţiul UE, Australia, Japonia şi Elveţia. În proiectul GLOBEMEN se consideră faptul că o reţea de întreprinderi este tărâmul de creştere al viitoarelor IV (Tolle şi Vesterager, 2003). În partea de formare a reţelei de întreprinderi, fiecare entitate va trebui să execute nişte paşi pregătitori, în vederea formării unor IV particulare. IV sunt formate din interiorul reţelei pe baza competenţelor existente şi a cererilor clienţilor. Competenţe ale sub-furnizorilor, sau ale contractorilor locali pot fi deasemenea incluse în IV, după cum se poate observa şi în Figura Figura Conceptul întreprinderii virtuale, adoptat în proiectul GLOBEMEN Pregătirea Modele de referinţă şi metodologii Un aspect central al formării IV într-un mod continuu, dinamic şi rapid, este conceptul pregătirii. Potenţialul avantaj competitiv al unei IV faptul că este capabilă să configureze înalte competenţe într-un sistem de livrare a serviciilor şi produselor este de multe ori ameninţat de timpul necesar formării IV, mai ales atunci când IV este alcătuită din parteneri necunoscuţi unul altuia înaintea formării întreprinderii virtuale. Atunci când se formează o reţea de întreprinderi, unul dintre aspectele cheie care trebuie luat în seamă este gradul şi tipul de pregătire în reţea şi între parteneri. Modelele de referinţă (RM Reference Models) captează caracteristici / concepte pag. 65 / 109

66 care sunt comune cătorva entităţi, scopul acestora fiind de a capitaliza cunoştinţele anterioare premiţând dezvoltarea unor biblioteci de modele care pot fi ulterior reutilizate într-o maniera plug-and-play (GERAM). Aşadar, RM fac procesul de modelare mai eficient. Modelele de referinţă sunt utilizate pentru conversia sarcinii de formare a IV într-o sarcină de configurare / reutilizare a unor modele, rezultând astfel o formare rapidă, cu costuri reduse şi sigură a IV. VERAM Virtual Enterprise Reference Architecture Methodology VERAM a fost creată ca şi parte a proiectului GLOBEMEN, scopul său fiind acela de a structura un corp de cunoştinţe care să susţină munca viitoare în domeniul producţiei şi ingineriei globale în reţele de întreprinderi. O parte din aceste cunoştinţe este, de fapt, aceeaşi tot timpul ori de câte ori o IV este creată sau operează, putând astfel fi standardizată şi re-utilizată. VERAM poziţionează aceste elemente care susţin modelarea, crearea, managementul şi instrumentele ICT ale IV, cum sunt modelele de referinţă şi instrumentele şi infrastrucutrile suport. Interconexiunile între aceste elemente sunt ilustrate în Figura Figura VERAM Virtual Enterprise Reference Architecture and Methodology Una dintre părţile centrale ale VERAM este nivelul intermediar, denumit VERA (Virtual Enterprise Reference Architecture). VERA captează conceptul IV descris anterior, conţinând trei entităţi recursive: reţeaua, întreprinderea virtuală, şi produsul (după cum se vede în Figura ). În figura se observă faptul că reţeaua, în faza sa operaţională, crează IV, iar IV duce la îndeplinire activităţile ce ţin de ciclul de viaţă al produselor, indicate prin săgeţi duble. Partea albă din VERA reprezintă partea particulară, adică partea care este legată de specificitatea reţelei, a întreprinderii virtuale, respectiv a produsului. În acelaşi mod, părţile închise la culoare desemnează părţile generice, re-utilizabile. Aşadar, modelele de referinţă sunt localizate în partea întunecată a desenului arhitecturii de referinţă VERA, iar atunci când sunt utilizate, sunt instanţiate cu informaţiile aferente unui caz particular. pag. 66 / 109

67 Figura VERA Virtual Enterprise Reference Architecture VE Methodology (VEM) VEM Metodologia întreprinderii virtuale dezvoltată în cadrul GLOBEMEN, prezintă activităţile cheie care trebuie considerate atunci când se formează reţelele de întreprinderi, respectiv întreprinderile virtuale. Această metodologie constă din două părţi: - prima parte adresează ciclul activităţilor necesare atunci când se construieşte şi se manageriază o reţea de întreprinderi; - partea a doua constă în adresarea aceloraşi probleme, atunci când se doreşte formarea şi managementul unei IV. Există două moduri de utilizare a ghidurilor precizate în VEM, în funcţie de rezultatul dorit: 1. Uzul general (pas-cu-pas): Utilizând ghidul pas cu pas, de sus în jos, o întreprindere este învăţată să formeze o reţea de întreprinderi formalizată. Acest lucru este valabil şi în cazul în care întreprinderea este deja parte a unei reţele de întreprinderi, însă are nevoie de mai multe pregătiri şi clarificări ale mediului, înainte de a fi capabilă să formeze în mod eficient întreprinderi virtuale (în condiţii avantajoase de timp, costuri şi calitate). În mod alternativ, poate fi vorba de o întreprindere care îşi doreşte explorarea competenţelor sale într-un nou mod, de exemplu aplicându-şi competenţele pentru noi tipuri de soluţii unde este nevoie de noi şi necunoscute comptenţe, deci şi de noi parteneri. 2. Utilizare selectivă (alegerea activităţilor relevante): ca şi alternativă la utilizarea ghidului pascu-pas, selectarea şi realizarea unor anumite activităţi poate fi utilizată pentru susţinerea unor anumite sub-procese. Acesta este scenariul de utilizare pentru cazul în care o reţea formală de întreprinderi există deja. Astfel, ghidul Vem poate fi utilizat pentru deducerea modului în care reţeaua trebuie restructurată în vederea configurării pentru a face faţă unei noi provocări. Formarea şi managementul reţelelor de întreprinderi. În Figura se ilustrează activităţile cheie specificate în ghidul VEM, legate de formarea şi managementul unei reţele de întreprinderi, conform lui Tolle şi Vesterager (2003). pag. 67 / 109

68 Figura Activităţi pentru formarea şi managementul reţelei de întreprinderi, conform VEM Activităţile sunt descrise în tabelul Tabelul Activităţile necesare pentru formarea şi managementul reţelei de întreprinderi Activitate Descriere Identificarea Scopul este de a identifica scopul reţelei, tipul acesteia, şi graniţele sale, în reţelei raport cu mediul interior şi exterior. Principala realizare va fi identificarea Selecţia partenerilor Determinarea scopului şi ierarhiei Formarea reţelei Obţinerea gradului de pregătire clară a pieţei şi produselor vizate Selecţia nu trebuie să prevadă doar extinderile viitoare, ci trebuie să ia în considerare şi relaţiile deja existente, adică partenerii care deja beneficiază de un anumit grad de încredere. Pentru a participa într-o IV, companiile trebuie să prezinte două tipuri de competenţe: funcţionale şi de colaborare. Pentru a evita potenţialele conflicte între partenerii reţelei, ar trebui făcute eforturi înspre asigurarea faptului că partenerii au o anumite scopuri comune, şi, pe cât posibil împărtăşesc aceleaşi viziuni, strategii şi obiective. Principala provocare atunci când se formează o reţea de întreprinderi este de a forma o IV competitivă într-o perioadă de timp relativ scurtă. Un mijloc pentru a îndeplini acest deziderat este de a pregăti partenerii. După ce reţeaua a determinat tipul şi gradul de pregătire dorit, şi după ce au fost determinate şi pregătite modelele, acestea vor trebui implementate atât în cadrul reţelei cât şi în cadrul fiecărui partener. Vânzări şi În timpul operării reţelei de întreprinderi, trebuie realizate şi activităţi de marketing marketing şi de vânzări. Acestea includ căutarea de noi clienţi, răspunsul la cererile clienţilor, negocierile de contracte cu clienţii, activităţi de marketing Operarea IV Aceasta este cea mai importantă sarcină, si este detaliată în tabelul Managementul reţelei Acest management include toate tipurile de sarcini de management la toate nivelele cunoscute din managementul tradiţional: monitorizarea directă şi indirectă, decizii la nivel tactic, strategic şi operaţional. Monitorizarea directă include monitorizarea deciziilor la nivel operaţional, şi luarea de măsuri adecvate pentru atingerea scopurilor: formarea unei IV capabilă să răspundă eficient nevoilor clienţilor, rezolvarea disputelor dintre parteneri. Monitorizarea indirectă caută eventuale scăpări în pregătirea reţelei şi ia eventualele măsuri de corecţie, cum este reconfigurarea reţelei sau a IV. pag. 68 / 109

69 În Figura sunt ilustrate activităţile cheie în ceea ce priveşte operarea IV Figura Activităţi cheie legate de operarea IV, conf. VEM Activităţile sunt detaliate în tabelul Tabelul Activităţi de management şi formare a IV Activitate Descriere Analiza cerinţelor Atunci când un partener al reţelei este confruntat cu o nevoie a clientului, clientului prima activitate este de a estima dacă reţeaua trebuie să îndeplinească acea Selecţia partenerilor Structura de împărţire a muncii Formarea IV Obţinerea gradului de pregătire Planificarea cerinţă, adică să clarifice daca aceasta se încadrează în scopul reţelei Selecţia partenerilor care participă în IV include estimarea capabilităţilor partenerilor. Cele mai multe consideraţii în ceea ce priveşte selecţia partenerilor sunt descrise în tabelul precedent, Bineînţeles, cu cât s-a făcut o selecţie mai riguroasă în partea de formare a reţelei, cu atât se va uşura sarcina în această fază, de asamblare a întreprinderii virtuale. O structură de împărţire a muncii (WBS Work Breakdown Structure) trebuie creată în paralel cu selecţia partenerilor. WBS captează descompunerea produsului VE (procesul global) în subprocese pe care partenerii selectaţi trebuie să le execute Formarea IV depinde în mare măsură de nivelul de pregătire la care s-a ajuns în formarea reţelei, conform tabelului precedent. Procesul de formare a IV include: definirea infrastructurii IV, definirea regulilor IV, a şabloanelor ce vor fi folosite, a modelelor de referinţă care vor fi instanţiate, rezolvarea aspectelor contractuale, organizare IV în funcţie de specificul proiectului Aceasta este deasemenea o activitate similară cu cea din tabelul precedent; cu cât s-a mers mai adânc la pasul de formare a reţelei, cu atât se simplifică sarcina similară în formarea IV Odată ce IV începe să funcţioneze, este nevoie de planificare mai detaliată. Fiecare partener va trebui să-şi facă propriul program de lucru, şi să decidă dacă la rândul său va subcontracta unele din sarcinile care-i revin. Managementul IV În mod similar cu managementul reţelei, managementul IV include metode de monitorizare directă şi indirectă pag. 69 / 109

70 Monitorizare şi estimare Colectarea experienţei Închiderea Monitorizarea proiectului, împreună cu raportarea progresului acestuia, este o activitate importantă de management al proiectului, care asigură faptul că proiectul se încadrează în bugetul şi în limita de timp alocate. Deasemenea, în timpul dezvoltării proiectului, partenerii ar trebui să estimeze dacă unele din procesele desfăşurate pot fi reutilizate în proiectul de faţă sau în alte proiecte, completându-se astfel modelele de referinţă Odată ce proiectul a fost finalizat, înainte de distrugerea IV, partenerii pot să aloce puţin timp pentru captarea noilor experienţe acumulate în timpul desfăşurării proiectului. Proiectul este închis, iar partenerii îşi recapătă locul în reţeaua de întreprinderi, aşteptând alte oportunităţi În concluzie, VERA oferă o structură generică, care permite o abordare sistematică a sarcinilor complexe şi multidimensionale asociate pregătirii întreprinderilor virtuale. Pentru a susţine realizarea IV, este nevoie de o metodologie cuprinzătoare pentru managementul şi ingineria IV. Metodologia VEM aplică arhitectura de referinţă VERA ca şi structură suport, ambele fiind create în cadrul proiectului GLOBEMEN. Aceste concepte/soluţii propuse sunt mijloace importante pentru realizarea unor IV mai agile şi mai eficiente. 1.6 Concluziile capitolului În cadrul capitolului sintezat studenţii automatişti vor descoperi noţiunile cu care se operează în domeniul intreprinderilor virtuale pornind de la cele mai larg acceptate definiţii ale acesteia acceptate de literatura de specialitate. În ceea ce priveşte conceptul întreprinderii virtuale, s-au analizat caracteristicile cheie şi elementele principale care fac obiectul acesteia. S-au analizat conceptele de business în cadru IV, detaliindu-se conceptul Enterprise Architecture, şi modul de utilzare a acestuia la modelarea unei firme virtuale. Se prezintă două modele de management al proceselor de business, NIH şi ARIS. Se trec în revistă tipurile de întreprinderi virtuale. Deasemenea, se studiază şi cadrul legal al IV, obiect al unor proiecte europene importante. Analiza comparativă a tehnologiilor de dezvoltare, şi identificarea tendinţelor de cercetare implică: tehnologii de management al fluxului de producţie şi de management al proceselor de business, instrumente de modelare a unei IV, sisteme de asistare a deciziilor, aplicaţii pentru managementul conţinutului informaţional, tehnologii web şi multimedia, sisteme de agenţi şi sisteme multi-agent. Se prezintă trei tipuri de arhitecturi utilizabile în proiectarea IV: arhitecturi orientate înspre servicii, arhitecturi LAMP şi arhitecturi multi-tier. În cadrul analizei unor soluţii de dezvoltare / implementare a IV pe plan mondial, se descriu sistemele ERP şi trei proiecte ample, care au avut ca scop obţinerea unor platforme şi modele de referinţă pentru dezvoltarea IV, fiecare cu tehnici specifice. pag. 70 / 109

71 2. Consideraţii privind implementarea unei platforme integrate care susţine funcţionarea unei intreprinderi virtuale În acest capitol se vor trece în revistă cerinţele şi scenariile de utilizare pentru principalele instrumente prin care platforma integrată INVITE asigură suportul în toate cele trei faze importante ale ciclului de viaţă ale întreprinderii virtuale (IV): formare, operare şi disoluţie Privire de ansamblu asupra cerinţelor platformei integrate În ziua de azi, întreprinderile cooperează intensiv unele cu altele pe parcursul întregului interval de viaţă al produsului. Alianţe temporare între diferite întreprinderi se formează tot timpul, la fel ca în cazul întreprinderilor virtuale. Dificultăţile apar la formarea şi operarea întreprinderilor virtuale, mai ales din pricina aspectelor de integrare. Proiectul INVITE a avut drept scopul crearea unei platforme integrate care să ofere suport pentru mecanismele IV, implementând instrumente care să ajute la rezolvarea problemelor de integrare a proceselor de afaceri, asistând formarea şi operarea unei IV în cadrul unei reţele dinamice de întreprinderi din domeniul transferului tehnologic. Ideea unor organizaţii dinamice, care se formează în urma unor oportunităţi de afaceri apărute pe piaţă, la fel şi păstrarea acestora în funcţiune pe tot timpul existenţei oportunităţii, aduce o serie de beneficii, dintre care se pot enumera (Camarinha-Matos, 2003): - Agilitate: abilitatea de a recunoaşte, de a reacţiona rapid şi de a face faţă schimbărilor neprevăzute în mediul de afaceri, pentru a obţine un răspuns mai bun la oportunităţile apărute, pentru a scurta timpul de apariţie pe piaţă a unui produs şi pentru a obţine o calitate mai bună cu investiţii mai puţine. Formarea unei IV este determinată de nevoia de a asocia cel mai adecvat set de competenţe şi de resurse ale mai multor organizaţii distincte. Când şi dacă va fi necesar, IV se poate reorganiza, prin includerea sau excluderea unor membri sau prin realocarea sarcinilor şi a rolurilor partenerilor. - Roluri complementare: întreprinderile caută complementarităţi (crearea de sinergii) care să le ajute în exploatarea noilor oportunităţi. - Câştig în dimensiune: în special în cazul întreprinderilor mici şi mijlocii, parteneriatul cu alte organizaţii permite acestora atingerea unei mase critice, apărând astfel în piaţă cu o dimensiune aparentă mai mare. - Competitivitate: se obţine o eficacitate a costurilor prin divizarea sarcinilor la organizaţii cooperante şi deasemenea se obţine un răspuns de actualitate prin acumularea rapidă a competenţelor şi resurselor necesare. - Optimizarea resurselor: întreprinderile mai mici îşi împart infrastructura, cunoştinţele, şi riscurile. - Inovarea: fiind parte a unei reţele de întreprinderi, se deschid oportunităţi pentru schimbul şi confruntarea de idei În timpul formării, operării şi reconfigurării întreprinderilor virtuale apar diverse de probleme, datorită nivelelor diferite de integrare care care privesc nu doar aspectele tehnice ci şi aspecte economice, sociale, legale sau organizaţionale. Pentru a exploata însă beneficiile potenţiale ale paradigmei IV, este nevoie de o infrastructură generică care să asigure suport pentru întreg ciclul de viaţă al IV, de la fazele de formare, până la operare şi în sfârşit disoluţie. Dezvoltarea unei asemenea infrastructuri este încă o provocare majoră. Figura prezintă ciclul de viaţă al IV, precum şi principalele servicii suport ce trebuie asigurate de către platforma integrată. pag. 71 / 109

72 Fig Ciclul de viaţă al întreprinderii virtuale şi principalele servicii suport În continuare se vor identifica şi analiza cerinţele generale ale platformei INVITE atât din punct de vedere tehnic / tehnologic cât şi al funcţionalităţilor ce trebuie oferite utilizatorilor Cerinţe generale ale platformei INVITE din punct de vedere tehnic Deşi avantajele IV sunt binecunoscute la nivel conceptual, implementarea practică a acestora este încă departe de aşteptări, cu excepţia unor reţele constituite pe termen lung, destul de stabile, reprezentând lanţuri de aprovizionare. Fazele de început, planificarea şi formarea IV, precum şi aspecte referitoare la faza intermediară, de operare funcţionare propriu-zisă, sunt în continuare dificile şi este necesar un efort mare pentru adaptarea la condiţiile unei IV, chiar şi pentru întreprinderi competitive şi avansate tehnologic. Dintre obstacolele întâlnite se pot evidenţia lipsa de modele de referinţă şi a unor instrumente suport pentru: căutarea şi selecţia partenerilor, negocierea şi parafarea contractelor, managementul resurselor şi competenţelor, alocarea distribuită a sarcinilor, practici pentru managementul proceselor de afaceri bine puse la punct, monitorizarea şi execuţia sarcinilor conform contractelor, estimarea performanţelor, mecanisme şi protocoale de integrare a informaţiilor, etc. Alte probleme mai apar din cauza lipsei unor ontologii comune între organizaţiile cooperante, suport adecvat pentru aspecte socio-organizaţionale. Un aspect interesant, discutat de către Camarinha-Matos (2005) este acela că dezvoltările orizontale, cele care se ocupă de stabilirea bazei de tehnologii, mecanisme şi instrumente generice pentru susţinerea IV, sunt destul de puţine, majoritatea eforturilor fiind concentrate înspre dezvoltări verticale, însemnând adresarea unor probleme şi nevoi specifice anumitor sectoare, cum ar fi proiectarea cooperativă în industrie, managementul dinamic al lanţului de aprovizionare în industrial prelucrătoare şi agricultură, federalizarea serviciilor în turism, etc. Lipsa unor modele de referinţă sau infrastructuri acceptate pe scară largă forţează proiectele de dezvoltări verticale să aloce resurse importante pentru proiectarea şi dezvoltarea propriei infrastructuri, pe care să îşi testeze conceptele, generându-se rezultate aplicabile doar în cadrul proiectului respectiv. pag. 72 / 109

73 Infrastructura ICT joacă de obicei un rol intermediar acela de a da posibilitatea interoperării diferitelor componente. ICT, infrastructura integratoare, ar trebui să joace rolul de sistem de operare al IV, ascunzând detaliile reţelei colaborative. Apariţia şi dezvoltarea unui mare număr de standarde şi tehnologii reprezintă factori potenţiali care permit dezvoltarea platformelor suport pentru IV: - Protocoale de reţea deschise subiacente interoperabile: TCP/IP, CORBA-IIOP (Common Object Request Broker Architecture), RMI (Java Remote Method Invocation), SOAP (Simple Object Access Protocol, este o specificaţie pentru schimbul structurat de informaţii în implementarea serviciilor Web; bazată pe XML-Extensible Markup Language, pentru formatul mesajelor, şi pe protocoale de la nivelul de aplicaţie RPC- Remote Procedure Call şi HTTP pentru negocierea şi transmisia mesajelor); - Servicii la nivel middleware orientate înspre obiect, deschise, distribuite: framework-urile J2EE (Java 2 Platform Enterprise Edition este o platformă care oferă posibilitatea de a executa aplicaţii Java pe partea de server), ActiveX (ActiveX este un model specific pentru o platformă, scris şi compilat pentru un anumit hardware şi sistem de operare), CORBA (Common Object Request Broker Architecture defineşte un standard care permite interacţiunea între obiecte realizate în diferite mediii de dezvoltare şi care funcţionează pe diferite platforme); - Mecanisme şi instrumente pentru schimbul de informaţii / obiecte: XML, ebxml, WSDL (Web Services Description Language este un limbaj bazat pe XML care oferă un model de descriere a serviciilor Web); - Modele standardizate pentru procesele, componentele şi obiectele de business: EJB - Enterprise JavaBeans (EJB) este nucleul arhitecturii de componente Java, care permite dezvoltarea de parţi reutilizabile, interactive, portabile şi compacte cu ajutorul căruia se pot asambla aplicaţii specifice, OMG - Object Management Group este un consorţiu de firme de soft non-profit care au elaborate standardul CORBA care este un cadru de dezvoltare a aplicaţiilor distribuite în medii eterogene. CORBA se bazează pe OMA (Object Management Architecture), model propus de OMG, pentru transbordarea într-un mediu distribuit a programării orientate pe obiecte, ceea ce implică o dezvoltare rapidă, reutilizarea şi protecţia eficientă a datelor sau OAG The Open Applications Group este o organizaţie non-profit orientată pe dezvoltarea unor standarde pentru dezvoltarea mediilor bazate pe limbaje de business pentru aplicaţiile de tip B2B (Business-to-business) şi A2A (Account-to-Account). - Modele şi limbaje de modelare a proceselor de afaceri: UML Unified Modeling Language este un limbaj vizual de modelare, destinat vizualizării, specificării, construirii şi documentării sistemelor de aplicaţii, UEML - Unified Enterprise Modelling Language este un limbaj în dezvoltare care defineşte teorii, tehnologii şi unelte pentru integrarea întreprinderilor utilizând limbaje diferite, WfMC - Workflow Management Coalitionse se bazează pe următoarele elemente: Workflow Reference Model, Workflow Engine, componentele modelului şi interfetele, XML-WfMC este metoda ideală prin carese descrie metoda prin care un motor BPM invocă un alt proces corespunzător altui motor BPM (Business process management), PSL - Process Specification Language este limbajul prin intermediul căruia se asigură comunicarea dintre diferite arhitecturi de limbaj stabilindu-se o abordare tehnică astfel încât să existe o colaborare eficientă între procese; - Sisteme de management al workflow-ului, standarde şi modele pentru managementul proceselor de afaceri: WfMC şi variaţii ale acestuia, multe produse comerciale; - Interfeţe standard la baze de date federative (ODBC - Open Database Connectivity şi JDBC - Java Database Connectivity reprezintă interfaţe de programare a aplicaţiilor pentru accesul la bazele de date); - Agenţi inteligenţi (FIPA - Foundation for Intelligent Physical Agents este o asociaţie non-profit care a dezvoltat specificaţii de funcţionare a agenţilor inteligenţi, MOA - Mobile Objects and Agents standard proiectat de către Open Group Research Institute pentru a susţine migrarea, pag. 73 / 109

74 comunicarea şi controlul agenţilor, OMG-Masif - Mobile Agent System Interoperability Facility este un standard pentru un system de agenţi mobile care a fost adoptat de către consorţiul OMG; - Tehnologii de integrare Web (Servlet tehnologia servletelor constă într-un ansamblu de API java care permit programatorului să adauge conţinut dinamic unui server Web bazat pe tehnologia java, JSP Java Server Pages sunt pagini Web interpretate la nivel de server pentru a genera răspunsuri HTML care vor fi apoi trimise la client (browserul web), ASP.NET - tehnologie oferită de Microsoft pentru dezvoltarea de aplicaţii Web, XSL - EXtensible Stylesheet Language este un limbaj de descriere a stilului de prezentare a documentelor XML reprezentat de două tehnologii: XSLT (extensible Stylesheet Language Transformation) şi XSL/FO (extensible Stylesheet Language Formatting Objects). Majoritatea acestor tehnologii sunt în continuă schimbare, de accea tehnologiile şi soluţiile tehnice adoptate în cadrul proiectului pentru dezvoltarea platformei integrate INVITE au fost alese cu grijă, pentru a respecta următoarele cerinţe: - efort de integrare cât mai scăzut: pe parcursul proiectului este de dorit ca eforturile să se concentreze pe partea de dezvoltare orizontală, în sensul găsirii unor noi concepte şi soluţii la problemele IV, decât pe partea de implementare a sistemului; - fiabilitate, mentenaţă: atunci când infrastructura de bază a IV utilizează tehnologii, componente sau instrumente de la mai mulţi furnizori depanarea este un proces dificil şi costisitor; - utilizabilitate (acceptabilitate, utilizare prietenoasă): este de dorit obţinerea unui echilibru între complexitatea funcţiilor oferite de platformă în ceea ce priveşte posibilităţile de configurare şi efortul necesar pentru rularea acestor funcţii; deasemenea, este de dorit o interfaţă prietenoasă, care să câştige acceptul utilizatorilor, având în vedere faptul că sesiunile de training ar fi destul de costisitoare, mai ales pentru întreprinderile mici. Aşadar, punerea în funcţiune a unei infrastructuri suport pentru IV reprezintă un efort major al cărui rezultat să fie o structură flexibilă şi cât mai generică. Flexibilitatea, înţeleasă prin prisma capabilităţii sistemului de a se adapta rapid la procese variate este o cerinţă necesară pentru a face faţă varietăţii modelelor de comportament în cadrul organizaţiilor colaborative. Generalitatea este altă cerinţă, care va permite sistemului să răspundă nevoilor diferitelor domenii de afaceri. Platforma INVITE, din punct de vedere tehnic, trebuie să joace rolul de potenţator, al interoperării şi integrării diverşilor participanţi pe mai multe nivele: - integrarea aplicaţiilor, suportul pentru interoperabilitarea aplicaţiilor fiecărei întreprinderi; - integrarea afacerilor, inclusiv suport pentru coordonarea proceselor de afaceri distribuite; - integrarea echipelor de lucru, incluzând facilităţi şi instrumente de lucru colaborativ; - comunicaţii şi al schimbului de informaţii, incluzând probleme de securitate, tranzacţii specifice proceselor de afaceri sau proceselor tehnice; Din punct de vedere al ingineriei software, se regăsesc două abordări în ceea ce priveşte proiectarea infrastructurilor suport pentru mecanismele IV: arhitecturi ierarhice orientate înspre tranzacţii şi arhitecturi cu sisteme multi-agent. Prima abordare presupune adăugarea unui nivel de cooperare platformelor IT existente în intreprinderi. Cooperarea inter-întreprinderi este apoi implementată cu ajutorul interacţiunii (orientată înspre tranzacţii) prin aceste nivele. A doua categorie include acele abordări care reprezintă întreprinderile ca nişte agenţi, iar cooperarea între întreprinderi este văzută la fel ca interacţiunile în sistemele multi-agent. Platforma inteligentă colaborativă INVITE trebuie să fie o arhitectură hibridă între cele două tipuri de arhitecturi. Mai mult, pentru ca întreprinderea virtuală să se formeze şi să funcţioneze, va avea nevoie de un bazin de potenţiali candidaţi, care să îşi asume roluri în organizaţia virtuală nou creată. Astfel a apărut conceptul de virtual enterprise breeding environment (VBE), adică o comunitate (reţea) de întreprinderi care sunt motivate să se asocieze în cadrul unei IV. Pentru fiecare oportunitate de afaceri, legată de unul din membrii comunităţii care acţionează ca un broker, se va alege un subset de întreprinderi din interiorul VBE care vor forma IV. Întreprinderile din cadrul unui VBE ar trebui înregistrate într-un registru, parte a unui portal, în care-şi pot declara pag. 74 / 109

75 competenţele. Pe baza acestor informaţii, iniţiatorul IV poate să-şi selecteze partenerii pe măsură ce se detectează noi oportunităţi de afaceri. Bineînţeles, VBE nu este un mediu închis noi membri pot adera la această comunitate, cu condiţia ca ei să fie compatibili cu principiile de operare generale ale acestei comunităţi. Aşadar, în proiectul INVITE adresează şi problema stabilirii şi managementului unei reţele de întreprinderi (VBE), fapt care presupune noi cerinţe tehnice, referitoare la managementul unui VBE. Acestea sunt legate de implementarea următoarelor componente: - registrul, unde întreprinderile se înregistrează pentru a-şi declara competenţele - catalogul de servicii: ţinând cont de faptul că întreprinderile îşi declară competenţele sub forma unor servicii, registrul va conţine un catalog al serviciilor disponibile; - interfaţa serviciilor: datorită autonomiei şi particularităţilor întreprinderilor, şi a modului în care fiecare întreprindere îşi oferă serviciul, va fi nevoie de o componentă care să faciliteze selecţia şi utilizarea serviciilor. Această componentă poate avea două sub-componente: o un descriptor al serviciului (descrie caracteristicile funcţionale ale serviciului oferit) şi o un proxy (descrie interfaţa de programare: metodele, parametrii şi valorile returnate) Cerinţe generale ale platformei INVITE din punct de vedere al funcţionalităţilor oferite utilizatorilor Adoptând metodologia VEM, se pot desprinde cerinţele funcţionale şi cele din punct de vedere al utilizatorului, pentru platforma integrată INVITE. Metodologia VEM consideră faptul că o reţea de întreprinderi (Virtual Breeding Environment VBE amintit anterior) este baza pe care se formează viitoarele IV. În partea de formare a reţelei de întreprinderi, fiecare entitate va trebui să execute nişte paşi pregătitori, în vederea formării unor IV particulare. IV sunt apoi formate din interiorul clusterului pe baza competenţelor existente şi a cererilor clienţilor. Competenţe ale subfurnizorilor, sau ale contractorilor locali pot fi deasemenea incluse în IV, după cum se poate observa şi în Figura Figura Conceptul întreprinderii virtuale Un aspect central al formării IV într-un mod dinamic şi rapid, este conceptul pregătirii reţelei (VBE). Potenţialul avantaj competitiv al unei IV faptul că este capabilă să configureze pag. 75 / 109

76 înalte competenţe într-un sistem de livrare a serviciilor şi produselor este de multe ori ameninţat de timpul necesar formării IV, mai ales atunci când IV este alcătuită din parteneri necunoscuţi unul altuia înaintea formării întreprinderii virtuale. Atunci când se formează o reţea de întreprinderi, unul dintre aspectele cheie care trebuie luat în seamă este gradul şi tipul de pregătire în reţea şi între parteneri. În Figura se observă faptul că reţeaua de întreprinderi, în faza sa operaţională, crează IV, iar IV duce la îndeplinire activităţile ce ţin de ciclul de viaţă al produselor. Mai există şi aspecte particulare, care sunt legate de specificitatea reţelei, a întreprinderii virtuale, respectiv a produsului. În ceea ce priveşte formarea şi managementul unei reţele de întreprinderi (VBE), care să susţină formarea viitoarelor IV, trebuie să susţină desfăşurarea următoarele activităţi: - Identificarea reţelei: se va identifica scopul reţelei, tipul acesteia, şi graniţele sale, în raport cu mediul interior şi exterior. Principala realizare va fi identificarea clară a pieţei şi produselor vizate. Aşadar, din punct de vedere al unui potenţial utilizator, va trebui afişat foarte clar scopul reţelei şi domeniul său de activitate, astfel încât întreprinderea candidată să-şi găsească locul în cadrul comunităţii; - Selecţia întreprinderilor membre: un element central în pregătirea şi formarea reţelei este identificare şi selecţia partenerilor care pot participa la îndeplinirea scopului acesteia. Selecţia nu trebuie să prevadă doar extinderile viitoare, ci trebuie să ia în considerare şi relaţiile deja existente, adică partenerii care deja beneficiază de un anumit grad de încredere. Pentru a participa într-o IV, companiile trebuie să prezinte două tipuri de competenţe: funcţionale şi de colaborare. - Determinarea scopului şi ierarhiei: pentru a evita potenţialele conflicte între partenerii reţelei, ar trebui făcute eforturi înspre stabilirea şi asigurarea faptului că partenerii au o anumite scopuri comune, şi pe cât posibil, împărtăşesc aceleaşi viziuni, strategii şi obiective. - Formarea reţelei: Principala provocare atunci cănd se formează o reţea de întreprinderi este de a forma o IV competitivă într-o perioadă de timp relativ scurtă. Un mijloc pentru a îndeplini acest deziderat este de a pregăti partenerii, dând astfel posibilitatea configurării rapide şi eficiente a unei IV focusate pe client. - Obţinerea gradului de pregătire: După ce reţeaua a determinat tipul şi gradul de pregătire dorit, şi după ce au fost determinate şi pregătite modelele, acestea vor trebui implementate atât în cadrul reţelei cât şi în cadrul fiecărui partener. Aceasta include, de exemplu, lansarea în execuţie a sistemului, într-o manieră integrată cu sistemele IT existente la locaţiile partenerilor. - Formarea IV: Aceasta este cea mai importantă sarcină, si este detaliată în Figura Managementul reţelei: Această activitate include toate tipurile de sarcini de management la toate nivelele cunoscute din managementul tradiţional: monitorizarea directă şi indirectă, decizii la nivel tactic, strategic şi operaţional. Monitorizarea directă include monitorizarea deciziilor la nivel operaţional, şi luarea de măsuri adecvate pentru atingerea scopurilor, cum sunt: formarea unei IV capabilă să răspundă eficient nevoilor clienţilor, sau rezolvarea disputelor dintre parteneri. Monitorizarea indirectă caută eventuale scăpări în pregătirea reţelei şi ia eventualele măsuri de corecţie, cum este reconfigurarea reţelei sau a întreprinderilor virtuale. În ceea ce priveşte întreprinderile virtuale, în Figura sunt ilustrate activităţile cheie ce privesc: formarea (definirea conceptului şi cerinţelor respectiv configurarea IV), operarea, şi disoluţia IV. În continuare vor fi descrise cerinţele specifice ale fiecarei din aceste activităţi cheie. pag. 76 / 109

77 Figura Activităţi cheie legate de formarea şi managementul IV - Analiza cerinţelor clientului: Atunci când un partener al reţelei este confruntat cu o nevoie a clientului, prima activitate este de a estima dacă reţeaua trebuie să îndeplinească acea cerinţă, adică să clarifice daca aceasta se încadrează în scopul reţelei. - Selecţia partenerilor: Selecţia partenerilor care participă în IV include estimarea capabilităţilor partenerilor. Cele mai multe consideraţii în ceea ce priveşte selecţia partenerilor sunt descrise în paragraful precedent, la managementul VBE. Bineînţeles, cu cât s-a făcut o selecţie mai riguroasă în partea de formare a reţelei, cu atât se va uşura sarcina în această fază, de asamblare a întreprinderii virtuale. - Structura de împărţire a muncii: O structură de împărţire a muncii (WBS Work Breakdown Structure) trebuie creată în paralel cu selecţia partenerilor. WBS captează descompunerea produsului VE (procesul global) în subprocese pe care partenerii selectaţi trebuie să le execute - Formarea IV: Formarea IV depinde în mare măsură de nivelul de pregătire la care s-a ajuns în formarea reţelei, conform tabelului precedent. Procesul de formare a IV include: definirea infrastructurii IV, definirea regulilor IV, a şabloanelor ce vor fi folosite, a modelelor de referinţă care vor fi instanţiate, rezolvarea aspectelor contractuale, organizare IV în funcţie de specificul proiectului - Obţinerea gradului de pregătire: Aceasta este deasemenea o activitate similară cu cea din tabelul precedent; cu cât s-a mers mai adânc la pasul de formare a reţelei, cu atât se simplifică sarcina similară în formarea IV pag. 77 / 109

78 - Planificarea: Odată ce IV începe să funcţioneze, este nevoie de planificare mai detaliată. Fiecare partener va trebui să-şi facă propriul program de lucru, şi să decidă dacă la rândul său va subcontracta unele din sarcinile care-i revin. - Managementul IV: În mod similar cu managementul reţelei, managementul IV include metode de monitorizare directă şi indirectă - Monitorizare şi estimare: Monitorizarea proiectului, împreună cu raportarea progresului acestuia, este o activitate importantă de management al proiectului, care asigură faptul că proiectul se încadrează în bugetul şi în limita de timp alocate. Deasemenea, în timpul dezvoltării proiectului, partenerii ar trebui să estimeze dacă unele din procesele desfăşurate pot fi reutilizate în proiectul de faţă sau în alte proiecte, completându-se astfel modelele de referinţă - Colectarea experienţei: Odată ce proiectul a fost finalizat, înainte de distrugerea IV, partenerii pot să aloce puţin timp pentru captarea noilor experienţe acumulate în timpul desfăşurării proiectului. - Închiderea: Proiectul este închis, iar partenerii îşi recapătă locul în reţeaua de întreprinderi, aşteptând alte oportunităţi 2.2. Cerinţe specifice privind sistemele multiagent în cadrul platformei INVITE Rolul agenţilor şi a sistemelor multiagent în fazele de operare şi restructurare ale IV. În continuare se vor descrie câteva scenarii şi cazuri de utilizare care să reflecte procesele de negociere, ofertare, etc. care au loc între agenţi, ca şi reprezentanţi ai întreprinderilor candidate pentru formarea unei IV în vederea răspunsului rapid la apariţia unei oportunităţi de business. În cele ce urmează se va prezenta modul de abordare în ceea ce proveşte utilizarea agenţilor software, ca o metodologie de inginerie software pentru formarea întreprinderilor virtuale. Agenţii pot îndeplini sarcini variate în procesele cooperative derulate în timpul formării intreprinderile virtuale prin Internet, realizând sarcini cum sunt prezentarea, regăsirea şi extragerea de informaţii, participarea la licitaţii pe pieţele electronice. Mulţimea de întreprinderi virtuale din reţea (VBE) este modelată ca un sistem multiagent, în care agenţi autonomi, independenţi, reprezintă fiecare întreprindere. În plus, la un moment dat, una dintre întreprinderi (de regulă, iniţiatorul IV) îşi va asuma rolul de broker, care va avea grijă de formarea IV. Managerul reţelei de întreprinderi, din cadrul proiectului INVITE, are de îndeplinit următoarele cerinţe: - să păstreze registrul unde sunt înregistrate întreprinderile cu profilurile corespunzătoare. Agentul permite unei întreprinderi externe să se înregistreze ca membru al VBE şi elimină acele întreprinderi (împreună cu produsele şi serviciile oferite de acestea) care doresc părăsirea VBE. - să ţină evidenţa profilurilor întreprinderilor individuale. Profilul va conţine o listă cu produse/ servicii oferite, capacităţi puse la dispoziţia potenţialilor clienţi. - să stabilească comunicarea cu acele întreprinderi care sunt din exteriorul VBE, dar care doresc să se asocieze la reţea. Agentul va trebui să informeze candidaţii cu privire la natura reţelei şi domeniul de activitate a acesteia, precum şi la condiţiile de aderare; - să ajute iniţiatorul IV oferindu-i toate informaţiile necesare despre întreprinderile candidate la statutul de membru al IV pe care iniţiatorul doreşte s-o creeze. În ceea ce priveşte problema formării IV cu ajutorul agenţilor, abordările sunt dintre cele mai variate (Boukhelfa şi Boufaida, 2006, Guizzardi şi alţii, 2007, LupuA, 2003, Lupu V şi Lupu C., 2008, Petersen şi alţii, 2003, etc.). Deoarece într-o întreprindere virtuală, întreprinderile individuale îndeplinesc doar o parte din lanţul de valori pentru a dezvolta un produs, problema majoră în ceea ce priveşte asamblarea (formarea) IV este aceea de a mapa procesele parţiale la pag. 78 / 109

79 întreprinderile individuale. Această problemă se poate rezolva în mai multe etape, pornind de la partajarea proceselor economice şi oprindu-ne la asamblarea şi instanţierea lanţului de proces al întreprinderii virtuale. Ideea de bază a abordării problemei de formare a IV este aceea de a ne uita la acest proces ca fiind o problema de decizie în sisteme multiagent. Soluţia acestei probleme constă în rezolvarea mai multor aspecte: - specificarea scopului IV: presupune descrierea procesului global, adică produsul sau serviciul care trebuie asigurat de către întreprinderea virtuală; - descompunerea: maparea specificaţiei globale a scopului IV în procese parţiale; - alocarea: selecţia potenţialilor parteneri şi maparea partenerilor la procesele parţiale identificate în pasul anterior; - sinteza: definirea procesului global prin compunerea proceselor parţiale instanţiate în pasul de alocare. În cele ce urmează se vor descrie fiecare dintre aceste aspecte în mod individual. Specificarea scopului (obiectivului IV). Descrierea IV este dată de specificarea atributelor produsului sau serviciului oferit. Atribute relevante sunt: costul, calitatea, preţul, piaţele de desfacere, timpul de livrare, cât şi constrângeri impuse potenţialilor participanţi în cadrul IV. Specificarea scopului IV este o sarcină ce trebuie îndeplinită de un expert, de aceea formalizarea acestui proces este dificilă, şi de aceea greu de automatizat. Cu toate acestea, agenţii software pot ajuta managerul de produs în proiectarea specificaţiei scopului IV, îndeplinind funcţii de asistare: specificaţiile se fac pe baza unui proces de cooperare şi implică interacţiunea cu alte intreprinderi. Această cooperare poate fi asistată de instrumente CSCW sau Groupware. Descompunerea. Pornind de la specificaţiile produsului / serviciului IV, procesele parţiale relevante sunt identificate şi formalizate utilizând o tehnică de modelare adecvată. Soluţia este facilitată prin aplicarea metodologiei ARIS, care este un cadrul de lucru uniform pentru descrierea proceselor economice. Majoriatea acestor sarcini vor fi îndeplinite de către experţi umani, asistaţi de agenţi inteligenţi. Alocarea. După pasul de descompunere, procesele parţiale trebuie distribuite agenţilor care ar putea contribui la implementarea acestora. În acest sens, trebuie să se realizeze alocarea proceselor parţiale către partenerii potenţiali. Aceasta implică următoarele activităţi: selecţia poteţialilor parteneri; distribuirea (anunţarea) proceselor parţiale către potenţialii parteneri; selecţia partenerilor care să se ocupe de fiecare proces individual. Prima activitate poate fi susţinută de către agenţi brokeri care interacţionează cu agenţii care reprezintă fiecare întreprindere. Celelalte două activităţi definesc problema alocării într-un mod strict. O soluţie centralizată la problemele de alocare descrise în literatura de specialitate este reprezentată de mecanismele de licitaţie. În activităţile de distribuire şi de alocare a subproceselor, iniţiatorul IV poate fi asistat de către un agent, ale cărui funcţii pot fi: i) regăsirea informaţiilor relevante, însemnând anunţurile IV existente care se potrivesc cu posibilităţile (competenţele) întreprinderilor din reţea, ii) formularea de noi oferte, iii) suport pentru procesele de licitaţie: oferte şi evaluare a ofertelor, şi iv) efectuarea în mod autonom a unor sarcini specifice, legate de negociere. Alocarea poate să se desfăşoare în două moduri: în alocarea orizontală, întreprinderile individuale sunt complementare în ceea ce priveşte serviciile oferite, adică diferite întreprinderi acoperă diferite părţi ale procesului. În modul de alocare verticală, un singur proces parţial este acoperit de un grup de întreprinderi. Sinteza. Ultimul aspect presupune compunerea proceselor parţiale - care au fost mapate la partenerii potriviţi - într-un proces care reflectă valoarea adăugată toatală a întreprinderii virtuale. O problemă practică majoră în acest context este aceea că procesele parţiale care trebuie conectate se derulează în diferite medii geografice şi instituţionale, în cadrul diferitelor întreprinderi din cadrul întreprinderii virtuale. Aşadar, conectarea a două procese parţiale nu poate fi realizată doar pag. 79 / 109

80 prin simpla lor compunere, ci este, mai degrabă, un proces de re-inginerie economică, având în vedere faptul că cele două procese trebuie modificate pentru a putea fi îmbinate într-o manieră căt mai eficientă. Această sarcină poate fi mult simplificată prin utilizarea unui formalism de descriere uniformă, sau prin modele de referinţă predefinite. În cele ce urmează se va insista pe selecţia partenerilor şi alocarea sarcinilor, unde agenţii software se preconizează ca vor juca un rol important în cadrul proiectului INVITE. Partenerii care vor forma IV vor fi selectaţi din bazinul de întreprinderi (VBE amintit anterior). Pentru ca partenerii să îndeplinească cerinţele impuse de obiectivul IV va trebui analizat atât modul în care întreprinderile individuale se potrivesc sarcinilor alocate cât şi modul în care echipa IV, în ansamblul ei, este eficientă. Unele dintre cunoştinţele necesare în timpul selecţiei partenerilor nu pot fi cunoscute a-priori, sau se pot modifica în timpul procesului de selecţie, datorită faptului că nu toate capabilităţile şi / sau atributele întreprinderilor pot fi exprimate în mod cantitativ. Deasemenea, trebuie avut în vedere faptul că formarea este doar o parte a ciclului de viaţă al IV, de aceea această etapă trebuie privită într-un anumit context: acela că, înainte de a se forma, vor trebui definite conceptele şi obiectivele acesteia. Setul de cerinţe al clientului (de fapt al iniţiatorului IV) definit în prelabil va fi punctul de plecare pentru stabilirea cerinţelor în ceea ce priveşte echipa IV, iar pentru ca IV să-şi ducă la îndeplinire obiectivul, echipa ideală va trebui formată. Figura Formarea IV din perspectiva ciclului de viaţă Figura prezintă faza de formare a IV în contextul ciclului de viaţă. În timpul procesului de formare a IV, potenţialii parteneri vor fi în competiţie şi vor negocia între ei pentru a fi membri ai IV. Partenerii selectaţi în procesul de formare vor duce la bun sfârşit obiectivele impuse de client, respectiv de oportunitatea de afaceri. Pentru a susţine formarea rapidă a unei IV, este nevoie de un model care să descrie IV în funcţie de entităţile şi relaţiile existente între acestea. Un astfel de model este prezentat în (Petersen şi Divitini, 2002, Petersen şi Gruniger, 2000) şi va fi adoptat în cadrul proiectului INVITE, cu unele modificări. Figura ilustrează acest model. Astfel, IV este caracterizată de un obiectiv (sau un set de obiective) care este atins prin intermediul unei serii de activităţi, îndeplinite prin roluri asumate de agenţi. Fiecare rol cere anumite competenţe, sau abilităţi. Agenţii care-şi asumă rolurile îndeplinesc codiţiile de competenţă cerute. pag. 80 / 109

81 Figura Modelul agentului pentru formarea IV şi scenariile de utilizare Agenţii implicaţi în formarea întreprinderii sunt clasificaţi în două categorii: iniţiatorul IV (care poate fi în acelaşi timp şi clientul, sau beneficiarul produsului / serviciului oferit de IV) şi partenerul (care poate fi în acelaşi timp şi iniţiatorul IV). Partenerul evoluează de la cineva care doreşte să fie parte a întreprinderii virtuale la cineva care a ajuns să fie într-adevăr parte a IV. Procesul prin care candidatul ajunge să fie partener în IV este ilustrat în Figura Figura Formarea întreprinderii virtuale selecţia partenerilor Stadiile prin care candidatul trece până să devină partener al IV sunt următoarele: - partener interesat: este interesat să devină parte a IV şi pentru aceasta face o ofertă de licitaţie; - partener potenţial: este luat în considerare pentru a face parte din IV şi se negociază contractul; - partener al IV: este selectat ca şi membru al echipei IV în urma procesului de negociere. pag. 81 / 109

82 Agenţii trebuie descrişi printr-un set de atribute, iar aceste atribute formează baza evaluării agentului ca partener la IV şi în timpul procesului de selecţie a echipei IV. În cele ce urmează se prezintă cerinţele de proiectare pe care trebuie să le îndeplinească agentul iniţiator (brokerul), prin prisma atributelor care îl caracterizează: Atribut Descriere Scop descrie scopul IV Disponibilitate perioada de timp pentru care este nevoie de asocierea în cadrul IV, adică timpul de viaţă al IV cerinţele IV abilităţile necesare pentru atingerea scopului IV şi constrângerile asociate Deadline data la care se va închide licitaţia Agenţii care reprezintă partenerii IV sunt descrişi prin intermediul mai multor atribute, care, la rândul lor, pot fi descrise prin alte seturi de atribute, reflectând astfel capabilităţile particulare ale agentului. O posibilă descriere este cea de mai jos: Atribut Descriere Scop Scopul partenerului Disponibilitate Perioada de timp în care partenerul este disponibil pentru a-şi duce la îndeplinire munca Abilităţi Descrie abilităţile partenerului Numărul de abilităţi Costul pe oră Cât este costul pentru fiecare oră de muncă solicitat de către partener Număr total de ore Numarul de ore necesar pentru executarea sarcinii pentru care licitează Ratingul de performanţă Nivelul de angajament Risc Indicator al eficienţei E măsurat în termeni de cost al neîndeplinirii angajamentului, care este costul pe care partenerul trebuie să-l plăteasca IV dacă acesta îşi încalcă angajamentul înainte ca obiectivul IV să fie atins. Descrie riscul ce rezultă aducerii partenerului în IV Abilităţile unui agent care reprezintă o întreprindere sunt descrise de un set de atribute multiple care au la rândul lor anumite constrângeri. Fiecare agent poate avea una sau mai multe abilităţi, fiecare dintre acestea fiind descrisă prin atributele: abilităţi, număr de ani de experienţă, rating de performanţă, etc. Asupra acestor atribute se pot formula unele constrângeri, pentru preselecţia candidaţilor (de exemplu, se poate impune un număr minim de ani de experienţă, un cost maxim pe oră, sau un rating de performanţă peste o anumită limită). Cerinţe de comunicare inter-agenţi Figura ilustrează comunicaţia care are loc între iniţiatorul IV şi parteneri. IV este anunţată şi partenerii interesaţi sunt invitaţi să depună ofertele de participare. Aici, la faza de selecţie a partenerilor interesaţi, este necesară în plus comunicarea între agentul iniţiator şi VBE manager, care va avea grijă de preselecţia partenerilor. Printre informaţiile necesare care însoţesc anunţul de licitaţie sunt: - scopul IV; - abilităţile necesare pentru îndeplinirea obiectivului IV; - durata de viaţă a IV; - deadline-ul pentru anunţarea ofertelor pag. 82 / 109

83 Partenerii interesaţi răspund anunţului prin trimiterea unei oferte de licitaţie, care va conţine următoarele informaţii: - obiectivul partenerului; - lista de atribute şi valorile acestora (atributele trebuie să includă abilităţile partenerului). Ofertele sunt luate în considerare dacăobiectivele partenerului sunt aliniate cu cle ale IV, şi dacă partenerul prezintă un set minim de abilităţi cerute. Ofertele descalificate sunt anunţate partenerilor generatori. După aceasta, iniţiatorul IV poate să înceapă negocierea cu partenerii potenţiali. Figura Comunicarea între actori în timpul formării IV Pe lângă informaţiile prezentate mai sus, ofertele de licitaţie trebuie să conţină şi informaţii de contact a partenerului ofertant. Evaluarea ofertelor Ofertele pot fi evaluate utilizând o funcţie utilitate multi-atribut. Pentru fiecare ofertă calificată, atributele sunt verificate pentru a vedea dacă acestea se încadrează în constrângerile impuse. Valorile atributelor se pot pondera, după cum urmează: Valoarea_utila = Σ (valoarea_atributului * pondere). Întrucât atributele pot avea o plajă largă de valori, acestea din urmă vor trebui normalizate. Valorile utile sunt apoi calculate şi se vor ordona, urmând ca lista să se prezinte agentului iniţiator. Acesta va alege partenerii care au cele mai bune valori, sau poate negocia cu ceilalţi pentru a cere oferte mai bune. Selecţia echipei IV Selecţia echipei poate fi considerată un subproces separat, iar în acest subproces se va ţine cont mai degrabă de atributele echipei, decât de atributele funcţiilor utilitate individuale ale partenerilor. Selecţia celei mai bune echipe se poate face în funcţie de mai multe criterii şi nu trebuie neapărat ca echipa ideală a IV să fie compusă din partenerii care au cele mai bune valori de utilitate individuale. De exemplu, se pot impune constrângeri în ceea ce priveşte bugetul alocat pentru îndeplinirea obiectivului IV. Deasemenea, în funcţie de ofertele partenerilor, atributele care definesc IV nu pot fi cunoscute apriori, fiind deseori necesară redefinirea sau schimbarea funcţiei utilitate a consorţiului. Aşadar, în definirea acestei funcţii este nevoie de flexibilitate, atât la nivelul partenerilor, cât şi la nivelul consorţiului Definirea cerinţelor şi proiectarea componentelor Web interactive Modelul Rich Internet Application (RIA) Conceptele Web 2.0 şi Rich Internet Application au o ţintă comună - implementarea unor aplicaţii care răspund nevoilor utilizatorilor şi optimizarea modului de interfaţare utilizator-sistem pag. 83 / 109

84 în activităţile curente. Din acest punct de vedere, o parte din conceptele de programare utilizate pentru dezvoltarea aplicaţiilor tradiţionale suferă modificări substanţiale atât pe parte de server cât şi pe parte de client odată cu introducerea noilor concepte Web 2.0. Formurile HTML şi clasicul WWW au fost concepute pentru prezentarea informaţiei la utilizator şi pentru stocarea reprezentărilor acestor informaţii pe server. Configuraţia web tradiţională a fost utilizată la maximum prin crearea de aplicaţii intra şi internet. Procesul de dezvoltare web este, în majoritatea cazurilor, orientat pe transportul datelor, alocarea resurselor, logica de business şi alte probleme de infrastructură. Tehnologiile utilizate în special pentru rezolvarea acestor probleme au ajuns deja la nivelul de standarde. Modelul RIA propune o nouă metodă de implementare a mecanismelor de optimizare a componentelor de interfaţare (interfeţe cu utilizatorul mult mai sugestive). Conceptul RIA înglobează două aspecte fundamentale: complexitatea la nivelul modelului de date şi la nivelul componentelor de interfaţare cu utilizatorul. Complexitatea la nivelul modelului de date va permite componentelor de interfaţare reprezentarea şi manipularea unui model de date sofisticate înglobate în cadrul blocului client capabil să proceseze date dar şi să comunice într-o manieră asincronă cu componentele blocului server. Modelul RIA vizează înglobarea informaţiei la client, îmbunătăţind interacţiunea cu utilizatorul şi reducând încărcarea blocului server. Complexitate la nivelul interfeţelor înseamnă în primul rând metode mult îmbunătăţite de interfaţare utilizator-sistem. RIA scoate în evidenţă controale care pot interacţiona independent cu modelul de date (RUI rich user interface). Acestea permit atât extinderea aplicaţiilor clasice prin implementarea mecanismului cerere/răspuns care ilustrează că interfaţa grafică se modifică în funcţie de răspunsul recepţionat de la server cât şi prin intermediul unui model în cadrul căruia schimbările sunt specifice domeniului aplicaţiei. Interfeţele sunt divizate în componente individuale capabile să identifice schimbările, să comunice independent cu componentele blocului server sau cu celelalte componente din cadrul blocului client. RIA permite divizarea funcţionalităţilor pe module blocul server având rolul de a implementa logica aplicaţiei iar clientul fiind responsabil de prezentarea informaţiei şi interacţiunea cu utilizatorul. Aplicaţiile enterprise sunt proiectate în baza arhitecturii stratificate (n-tier). Se au în vedere trei nivele: client, middleware şi sistemul informaţional. Fiecare dintre nivele conţine componente ce implementează funcţionalităţi specifice. Nivelul client conţine mecanismul de interfaţare cu utilizatorul, cel de prezentare conţine logica de furnizare a informaţiei la utilizator şi managementul stărilor sistemului, nivelul de business conţine logica de business a sistemului, iar nivelul de integrare conţine conectorii şi adaptorii care accesează procesele distante şi sursele de date. Nivelul de resurse conţine date din baze de date federative, surse de informaţii (sisteme ERP) şi fişiere XML. În mod normal o aplicaţie enterprise este structurată conform figurii Figura Arhitectura three-tier pag. 84 / 109

85 În cadrul sistemelor web, componentele middleware încapsulează logica aplicaţiei: fluxul operaţional, crearea conţinutului informaţional, furnizarea informaţiei la client, respectând mecanismul de cerere/răspuns care guvernează orice aplicaţiei web tradiţională. Pentru a furniza interfaţa solicitată, sistemul va împacheta conţinutul informaţional în format HTML înainte de a-l furniza ca şi răspuns la cererea de la client. Modificarea oricărei părţi din componenta de prezentare necesită transmisia unei cereri la server. Răspunsul la respectiva cerere include o întreagă pagină web nu doar componenta care trebuie modificată. Componentele de tip Applet şi JavaScript/AJAX/DHTML oferă o alternativă blocului client în modelul tradiţional dar n-au constituit niciodată o soluţie fiabilă datorită unor limitări din punct de vedere tehnologic. Conceptul rich client permite reorganizarea modului în care este reflectată structura unei aplicaţii distribuite. Interfaţa cu utilizatorul este divizată în puncte de interacţiune cu utilizatorii care comunica independent cu componentele blocului server. Această trecere de la o pagină la o simplă componentă aduce îmbunătăţiri la nivelul blocului client şi permite implementarea unor rutine inteligente în cadrul componentelor de interfaţare cu utilizatorul. Componentele inteligente nu reprezintă doar reducerea numărului de interogări client/server ci şi îmbunătăţirea substanţială a caracteristicilor aplicaţiei. Modelarea fluxului de evenimente reprezintă o altă caracteristică de bază a componentelor de tip rich client. Conceptul rich client nu necesită predicţia secvenţei de evenimente ce vor fi tratate. Atâta timp cât există independenţă la nivelul componentelor nu va fi nevoie de încapsularea răspunsului în cadrul unei pagini întregi pentru prezentarea informaţiei la utilizator. Fiecare componentă poate interoga blocul server şi poate interpreta răspunsul de la server. Schimbul asincron de mesaje client-server permite dezvoltatorului să controleze modul de creare a mesajelor şi fluxul acestora între cele două entităţi (server şi client). Tipare de proiectare utilizate în cadrul modelelor RIA Procesul de dezvoltare software a sistemelor distribuite ridică două probleme majore: invocarea serviciilor (componentele logicii de business) modul de comunicare client/server. Invocarea serviciilor (componentele logicii de business) se realizează independent, astfel că, modificările din cadrul unei componente a unui anumit nivel nu va afecta componentele altor nivele. Comunicaţia client/server este securizată şi respectă specificaţiile privind managementul stărilor. Fiecare mesaj spre server va reprezenta o cerere validă conţinând pachete de identificare utilizate în întreaga aplicaţie. Există o multitudine de limbaje de programare folosite pentru implementarea modelului tradiţional, Java fiind unul dintre cele mai proeminente. În mediul de programare Java, dezvoltatorul foloseşte tiparul de proiectare business delegate pentru a structura comunicaţia cu componentele logicii de business. Java propune rezolvarea problemelor de comunicaţii client/ server prin intermediul tiparului de proiectare front controller. Această componentă are rolul de a direcţiona cererile de la clienţi spre o componentă tip controller care verifică validitatea cererii şi stabileşte fluxul de control, funizând astfel răspunsul corect la cererea clientului sub forma unei pagini HTML. Cele două tipare de proiectare funcţionează împreună într-o structură complexă. Implementarea unei aplicaţii RIA respectă un scenariu apropiat de cel clasic, dar necesită câteva modificări prin transferarea unor funcţionalităţi spre componentele blocului client. Din punct de vedere arhitectural, apar două concepte de proiectare: brokerul de servicii abstractizarea comunicaţiei client/server. Brokerul de servicii furnizează metodele de invocare a serviciilor, prin intermediul unor componente de tip connector, permiţând astfel componentelor individuale accesul la servicii în baza abstractizărilor cu privire la locaţia acestora sau modul de prelucrare a cererilor. Comunicaţia client-server constă în realizarea unei conexiuni de la componenta din blocul client la server şi schimbul asincron de mesaje în locul implementării mecanismului cerere/răspuns şi înglobarea pag. 85 / 109

86 răspunsului sub forma unei pagini HTML. Fiecărei componente îi corespunde propria logică de interfaţare şi mecanismul de tratare asincronă a fluxului de evenimente. În concordanţă cu cerinţele aplicaţiei, funcţionalităţile de comunicaţii client/server se pot îngloba în cadrul unor componente sub forma unei structuri centralizate. Brokerul de servicii Obiectivul principal urmărit în procesul de dezvoltare al aplicaţiilor RIA constă în asigurarea independenţei între nivelul logicii de business şi componentele de prezentare a informaţiei la utilizator. Conceptul rich client prevede furnizarea unei interfeţe standard pentru invocarea serviciului (triggers, callbacks, etc.), abstractizarea serviciilor, abstractizarea invocării serviciului (indiferent de protocolul utilizat SOAP, RMI, etc), securizarea apelurilor, mecanismul de tratare a cererilor, abstractizarea locaţiei unui serviciu, abstractizarea entităţii apelante, sau furnizarea metodelor standard pentru tratarea evenimentelor prin două tipuri de clase: ServiceBroker şi Bridge. Componenta de tip Bridge reprezintă o conexiune între componenta de interfaţare cu utilizatorul şi serviciul distant. Aceasta se iniţializează în baza abstractizărilor şi implementează funcţionalităţi de comunicare cu componentele locale şi serviciile distante. Comunicaţia între componentele locale şi serviciile distante se realizează într-o manieră securizată, independent de stiva de protocolale sau topologiile reţelelor de acces. Componenta de tip Bridge implementează metodele de gestionare a componentelor de interfaţare cu utilizatorul furnizând mecanismele de reapelare a serviciilor în funcţie de rezultatul furnizat sau chiar cererea unor informaţii suplimentare necesare derulării fluxului operaţional. Figura ilustrează relaţiile între componentele de interfaţare, brokerul de servicii şi componentele de tip Bridge cu rolul de a stabili conexiunea cu serviciile locale sau distante. Figura Relaţiile între clase În cazul unei platforme integrate care oferă funcţionalităţi colaborative interpersonale şi interprocese, se urmăreşte implementarea conceptului rich client în vederea autentificării utilizatorilor sau furnizării accesului la serviciile colaborative şi asincrone. Componentele middleware implementează managementul cererilor de la clienţi şi serviciile distante: managementul utilizatorilor, al serviciilor sincrone (managementul componetelor de tip videoconferinţă, online focus group, spaţiu virtual partajat, online project demo, live customer support) şi asincrone (managementul resurselor multimedia, managementul proiectelor, managementul relaţiei cu furnizorii şi beneficiarii, mesagerie multimedia, etc.). Abstractizarea comunicaţiei client/server Componentele ce formează interfaţa cu utilizatorul şi sub-componentele acestora sunt, la rândul lor luate în considerare, în etapa de proiectare a modulului de comunicaţie cu serverul. Aceste componente de interfaţare implementează funcţionalităţi de management User Interface, mecanismul de control al mesajelor de la server şi invocării serviciilor, management al fluxului de pag. 86 / 109

87 evenimente şi control al logicii de prezentare a informaţiei. Proiectarea modulului client porneşte de la următoarele funcţionalităţi: interfaţarea cu utilizatorul realizată cu ajutorul controalelor de tip calendar, data grid, text, grafică, etc.; manipularea componentelor de interfaţare, maparea datelor, prezentarea informaţiei la utilizator în format compact, orchestrate în cadrul logicii de prezentare; modelarea datelor pe parte de client, implementată de către componenta de tip model; tratarea fluxului de evenimente generate de către elementele de interfaţare (controlul proceselor în cadrul interfeţei cu utilizatorul) şi a celor generate prin recepţia mesajelor de la sever, implementată de către componenta de tip controller; invocarea serviciilor distante într-o manieră transparent, realizată de către componenta de tip mediator. Respectarea acestor specificaţii de proiectare garantează independenţa la nivelul componentelor de interfaţare cu utilizatorul. Instanţa de tip mediator permite componentelor de interfaţare să activeze independent ca părţi ale unei singure componente, interfaţa cu utilizatorul. Componenta de interfaţare cu utilizatorul este compusă dintr-o serie de controale şi butoane care generează diferite evenimente. Elementele care implementează logica de prezentare a informaţiei la utilizator deţin şi sarcina de a trata aceste evenimente şi de a elaborara un model de date local necesar tranzacţiei. Odată generat acest model de date, componenta de tip controller solicită instanţei de tip mediator tipul de serviciu distant şi trimite acestuia colecţia de date ce va compune cererea. Instanţa de tip mediator interoghează brokerul de servicii în vederea obţinerii descriptorilor de servicii apoi invocă serviciul distant. După prelucrarea cererii de serviciu, serverul returnează un mesaj de răspuns pe care componenta de tip bridge îl va ruta spre instanţa de tip mediator. Aceasta va stabili ce metode vor fi apelate de către componenta de tip controller şi ordinea pentru de afişare a informaţiei solicitate de utilizator. Implementarea conceptului rich client în cadrul mediilor colaborative Conceptul rich client prevede divizarea interfeţei cu utilizatorul în puncte de interacţiune care comunică independent de componentele serverului. Răspunsul serverului va fi sub forma unui mesaj şi nu ca şi pagină web, ca şi în cazul aplicaţiilor web tradiţionale, reducând traficul pe reţea. Independenţa la nivelul componentelor de interfaţare cu utilizatorul permite orchestrarea comunicaţiei client/server sub forma unui flux de mesaje asincrone controlat dinamic cu ajutorul unor rutine software. Atâta timp cât există independenţă la nivelul componentelor nu va fi nevoie de încapsularea răspunsului în cadrul unei pagini întregi pentru prezentarea informaţiei la utilizator. Fiecare componentă poate interoga blocul server având resurse pentru a interpreta răspunsul recepţionat. Schimbul asincron de mesaje client-server permite dezvoltatorului să controleze modul de creare a mesajelor şi fluxul acestora între cele două entităţi (server şi client). Aplicaţiile RIA sunt considerate aplicaţii web sincrone. Acest aspect vizează gestionarea optimă a comunicaţiei la nivelul blocului client în vederea preluării datelor de la server şi afişarea lor la utilizator într-o manieră transparentă - orice modificare pe parte de server generează actualizarea datelor din model şi afişarea automată a acestora în interfaţa grafică. Conceptul symbiotic computing prevede divizarea spaţiului virtual, în cazul de faţă mediul colaborativ, în zone de aplicaţii cu scopul de a atenua costurile mari de utilizare, întreţinere şi accesare a serviciilor informaţionale furnizate de mediul virtual sau alte probleme de ordin funcţional. Dintre acestea se amintesc: lipsa de flexibilitate privind managementul conţinutului informaţional şi incompatibilitatea informaţională la nivelul aplicaţiilor care compun mediul virtual, insuficienţa serviciilor informaţionale furnizate şi impactul social al instrumentelor colaborative. Integrarea aplicaţiilor individuale prin intermediul instrumentelor colaborative are pag. 87 / 109

88 menirea de a reduce considerabil costurile, a simplifica accesul la conţinutul informaţional şi a creşte încrederea utilizatorului diminuând problemele de tip E-Gap. Figura Relaţia dintre mediul real şi cel virtual Figura ilustrează creşterea numărului de utilizatori care beneficiază de avantajele unui mediu virtual compact care implementează funcţionalităţile colaborative. Chiar dacă diferenţele dintre mediul fizic şi cel virtual sunt evidente, trebuie să existe o relaţie între cele două iar aceasta poate fi realizată prin intermediul unei componente cu rolul de a modela spaţiul fizic şi problemele lui prin intermediul mediului virtual şi, de asemenea, de a integra tehnologiile digitale în cadrul mediului fizic. Concret, conceptul rich client permite dezvoltarea unui model al spaţiului fizic prin intermediul componentelor virtuale pornind de la detaliile privind mediul real, utilizatori, reguli şi date, etc. Figura ilustrează modelul de transpunere a mediului fizic în cel virtual având la bază conceptul E-Bridge. Figura Modelul de transpunere a spaţiului fizic în mediul virtual Sugawara (2007) ilustrează aplicaţiile de tip E-Bridge ce implementează o serie de funcţionalităţi inteligente şi oferă proprietăţi adaptive, respectiv un grad sporit de flexibilitate. Proprietăţile componentelor de interfaţare inteligente (intelligent rich client) permit definirea unui model colaborativ care garantează autonomie funcţională şi acces selectiv la servicii în funcţie de diferiţi factori precum condiţii de reţea sau terminal de access. pag. 88 / 109

89 Modelul experimental pentru colaborare interpersonală şi interprocese Activităţile în cadrul organizaţiilor virtuale pot fi reorganizate prin prisma a două aspecte fundamentale (Ader 2001): managementul conţinutului informaţional şi managementul fluxului operaţional. Componentele de management al conţinutului informaţional conţin o serie de instrumente pentru gestionarea acestuia (stocarea, modificarea sau accesarea conţinutului informaţional în diferite formate) cum ar fi: instrumente de managementul documentelor, instrumente pentru gestionarea băncilor de date, instrumente lingvistice care oferă suport pentru interogara băncilor de date în limbaje naturale, etc. Componentele de management al fluxului operaţional au la bază o serie de instrumente dedicate fluxului de producţie cum ar fi: instrumente de comunicare interpersonale, instrumente de planificare a activităţilor colective (inclusiv partajarea resurselor comune), forum de discuţii pentru abordarea anumitor teme, instrumente colaborative sincrone pentru accesul simultan la diferite resurse cu scopul de a îmbunătăţi procesul de producţie, instrumente de management al fluxului operaţional care gestionează întreg ciclul de operaţiuni, instrumente colaborative asincrone, etc. Se propune dezvoltarea unui model framework generic care prezintă funcţionalităţi colaborative interpersonale şi interprocese, sincrone şi asincrone şi conţine o serie de module dedicate activităţilor colaborative. Figura ilustrează schema funcţională a framework-ului generic şi modulele colaborative: blocul de management al băncii de date, modulul de management al utilizatorilor, biblioteca virtuală, motorul de căutare, modulul de statistică, modulul pentru chestionare şi evaluare, agenda electronică, blocul de management al proiectelor, spaţiul virtual partajat, mesageria multimedia, forumul de discuţii, videoconferinţa controlată şi modulul de tip online focus group. Figura Schema funcţională framework generic. Pentru simplificarea procesului de dezvoltare, componentele framework-ului se vor diviza în patru clase: componente generice: blocul de management al băncii de date, modulul de management al utilizatorilor, modulul de statistică şi agenda electronic, componente colaborative interpersonale: mesageria multimedia, forumul de discuţii, spaţiul virtual partajat, videoconferinţa, modulul de tip online focus group; componentele interactive: motorul de căutare, biblioteca virtuală, modulul pentru chestionare şi evaluare şi blocul de management al activităţilor în cadrul proiectelor componentele pentru colaborare interprocese: componentele de tip business intelligence şi virtual assistant. pag. 89 / 109

90 Componente generice Funcţionalităţile de bază ale framework-ului fac referire la managementul băncii de date, managementul utilizatorilor, elaborarea de statistici complexe şi rapoarte de analiză menite să ilustreze buna funcţionare a mediului colaborativ şi managementul sarcinilor individuale şi activităţilor colaborative realizat prin intermediul agendei electronice. Modulul de management al utilizatorilor va conţine nivelele de acces conform profilelor de administrator, respectiv utilizator. Indiferent de rolul său în sistem, utilizatorul va accesa sistemul prin intermediului propriului cont de acces. Fiecare cont va avea un anumit nivel de acces conform rolului/rolurilor avute în cadrul organizaţiei. Componenta reprezentativă a modulului de management al utilizatorilor este componenta de autentificare. Aceasta implementează funcţionalităţile de autentificare a utilizatorilor în sistem, verificarea accesului la instrumentele colaborative şi managementul stărilor utilizatorilor pe parcursul funcţionării aplicaţiei. Un utilizator poate trece prin următoarele stări: active, inactive, busy, idle, logged out. Aceste stări sunt interpretate la nivelul blocului rich client şi transmise componentelor serverului în vederea actualizării informaţiilor partajate între participanţii la o sesiune colaborativă. Statisticile şi rapoartele de analiză ilustrează eficienţa sistemelor colaborative aplicate unor domenii de interes precum educaţie şi cercetare (învăţământ colaborativ şi blended learning), management şi producţie (relaţii inter-departamentale şi outsourcing), marketing (în special vânzări), etc. Elaborarea de statistici şi rapoarte de analiză prevede păstrarea în baza de date a unor informaţii caracteristice sesiunilor colaborative, activităţilor fiecărui utilizator într-o perioadă de timp precum şi a rezultatelor în urma chestionarelor cu privire la rolul instrumentelor colaborative în activităţile de zi cu zi ale utilizatorilor provenind din diferite domenii de interes. Managementul sarcinilor individuale şi a activităţilor colaborative este realizat prin intermediul agendei electronice care are rolul de a permite planificarea activităţilor colaborative în timp, consultarea orarului şi notificarea utilizatorilor cu privire la diferite evenimente din agendă. În funcţie de rolul pe care-l are în cadrul organizaţiei, un utilizator are posibilitatea de a introduce noi sarcini individuale pe agenda de lucru şi în acelaşi timp verifică programul impus în cadrul proiectului în derulare de către responsabilul de proiect. De asemenea, responsabilul de proiect are o situaţie clară asupra a ceea ce se întâmplă în proiectul pe care-l gestionează, asignează noi sarcini şi verifică activităţile realizate de către ceilalţi membri ai echipei. În baza rapoartelor individuale completate de fiecare utilizator, se elaborează rapoartele periodice şi cele finale pe care responsabilul de proiect le verifică şi le validează înainte de finalizarea fiecărei faze. Componente colaborative interpersonale Aplicaţiile colaborative interpersonale sunt aplicaţii multimedia profesionale care permit unui număr de doi sau mai mulţi utilizatori finalizarea unor sarcini comune. În funcţie de timp, acestea se pot clasifica în două mari categorii: sincrone prezentarea informaţiei la utilizator se realizează simultan cu transmisia. asincrone momentul prezentării datelor la utilizator este ulterior transmisiei şi selectat în mod arbitrar de către utilizator. Framework-ul include un modul pentru colaborare sincronă ce conţine: videoconferinţă controlată, online focus group, spaţiu virtual partajat. De asemenea, framework-ul cuprinde un modul pentru colaborare asincronă ce include: mesagerie multimedia, forum de discuţii (general, pe departament şi pe proiecte în derulare). Componentele pentru colaborare sincronă permit conlucrarea la distanţă, prin intermediul browserului web. Colaborare la nivelul componentelor generice pentru cooperare sincronă se realizează prin instrumentul SCWInstrument, care reprezintă clasa de bază a pachetului pentru colaborare interpersonală sincronă şi implementează principalele funcţionalităţi colaborative sincrone: comunicare audio/video în timp real, acces la biblioteca virtuală şi partajarea resurselor pag. 90 / 109

91 stocate, partajare de aplicaţii, adnotări la nivelul aplicaţiilor şi resurselor, interacţiune utilizatorutilizator, interacţiune cu resurse, aplicaţii şi echipamente speciale integrate în sistem. Există o componenta subclasa SCWInstrument care asigură comunicarea audio/video şi partajarea de resurse şi aplicaţii în timp real între doi sau mai mulţi utilizatori. În acest caz, sesiunea colaborativă este controlată de un moderator iar, la un moment dat, un singur participant are permisiunea de a interacţiona cu moderatorul, resursele, aplicaţiile şi echipamentele speciale. O altă subclasă a SCWInstrument, permite unui număr de cinci utilizatori să colaboreze simultan pentru finalizarea unor sarcini comune. Cei cinci utilizatori au acces simultan la resursele stocate în biblioteca virtuală, pot introduce adnotări pe margina documentelor partajate şi pot prezenta aplicaţii şi rezultate de proiect în timp real. Modulul pentru colaborare asincronă cuprinde componentele de tip forum de discuţii şi mesagerie multimedia care sunt integrate cu componentele generice, cele pentru colaborare sincronă şi cele interactive în vederea eficientizării proceselor interpersonale. Schimbul de mesaje multimedia la nivelul echipelor de lucru, forumul de discuţii pe echipe, pe proiect, sau la nivel departamental sunt considerate necesare pentru eficientizarea proceselor în cadrul unei organizaţii. Componente interactive Acest tip de componente permit interacţiunea utilizatorilor cu resursele digitale stocate în biblioteca virtuală, interogarea băncii de date în funcţie de câteva criterii bine stabilite, elaborarea de chestionare şi rapoarte privind reacţiile utilizatorilor înainte şi după utilizarea instrumentelor colaborative şi managementul activităţilor în cadrul proiectelor şi elaborarea rapoartelor periodice sau a celor finale în cadrul proiectelor. Componentele interactive cuprinse în cadrul frameworkului sunt: motorul de căutare, biblioteca virtuală, componenta de management a activităţilor proiectelor. Motorul de căutare permite utilizatorilor accesul la diferite informaţii şi resurse în funcţie de rolul avut în sistem şi criteriile de căutare care definesc logica de funcţionare a acestuia. Motorul de căutare are la bază structuri AIML (Artificial Intelligence Markup Language), o derivaţie a limbajului XML care permite interogări în limbaj natural.. Biblioteca virtuală este considerată o componentă interactivă fundamental şi se compune din blocul de management al resurselor digitale, blocul de conversie a fişierelor în simbol intern (format specific al bibliotecii virtuale) şi componenta de acces la resurse. Blocul de conversie are rolul de a converti materialele postate (documente, prezentări, rapoarte, statistici, pagini web, etc) de un utilizator în sistem în format slideshow (tablou de imagini în format JPG) în vederea stocării lor în biblioteca virtuală. De asemenea, se impune conversia secvenţelor audio/video la formatul FLV cunoscut ca fiind unul dintre puţinele utilizate pentru streaming media partajat pe web. Biblioteca virtuală conţine resursele postate pe portal de către utilizatori: documente, formulare, prezentări, situaţii, rapoarte, statistici, filme demonstrative, etc. Fiecare utilizator este responsabil de propria secţiune şi are posibilitatea de a actualiza periodic resursele stocate în sistem, în funcţie de rolul pe care-l deţine. Aplicaţia suportă diferite formate.doc,.pdf,.ppt,.rtf, video, audio, imagini,.swf, şi permite codarea acestora în vederea securizării informaţiilor. Instrumentele pentru managementul activităţilor în cadrul proiectelor permit crearea unui cadru de lucru comun la nivelul unei organizaţii. În plus, prezintă o serie de avantaje pentru dezvoltarea în parteneriat a unor proiecte complexe dintre care se disting monitorizarea şi controlul fluxului operaţional, managementul activităţilor, generarea rapoartelor de activitate şi accesul concurent la aceste rapoarte. Instrumentele pentru managementul proiectelor sunt integrate cu instrumentele colaborative sincrone şi asincrone. În aceste condiţii, membri unei echipe pot colabora direct pe problemele din cadrul proiectului, îşi alocă atribuţiile individuale, îşi definesc sarcinile comune şi elaborează rapoartele de fază pornind de la rapoartele periodice individuale. Există două tipuri de actori care accesează modulul pentru managementul activităţilor în cadrul proiectelor: responsabilul de proiect şi membrul echipei. pag. 91 / 109

92 Un responsabil de proiect are posibilitatea de a adăuga un nou proiect în sistem utilizând un editor HTML pentru introducerea specificaţiilor de proiect, adaugă membri echipei de proiect, alocă sarcini fiecărui membru, verifică activităţile membrilor, elaborează rapoartele de fază, organizează demonstraţiile la finalul fiecărei faze, etc. Un membru al echipei primeşte sarcinile alocate de către responsabilul de proiect, colaborează cu ceilalţi membri în vederea finalizării sarcinilor alocate şi elaborează rapoartele periodice. Componente pentru colaborare interprocese Necesitatea furnizării caracteristicilor colaborative la nivelul componentelor unui sistem este evidentă, fapt pentru care frameworkul generic va include un modul care implementează aceste funcţionalităţi colaborative nu doar între entităţi software de pe acelaşi nivel arhitectural ci şi de pe nivele diferite. Componentele blocului client funcţionează independent unele de altele, fiecare având propriile sarcini: tip Model încapsulează datele recepţionate de la server în vederea prezentării lor la utilizator; tip View implementează logica de prezentare a informaţiilor la utilizator într-un format compact; tip Controller au rolul de a interpreta comenzile utilizatorilor; Brokerul de servicii conţine referinţele la serviciile distante Mediatorul de servicii realizează invocarea serviciilor distante într-o manieră transparent. Pe lângă aceste funcţionalităţi de bază se remarcă interfaţarea utilizator-sistem în limbaj natural, interpretarea gesturilor utilizatorilor şi optimizarea comunicaţiei client/server. Componentele de tip IIU (Interfaţa Inteligentă cu Utilizatorul) urmăresc, pe lângă prezentarea informaţiei la utilizator în format compact, interpretarea gesturilor acestuia fac posibilă interacţiunea cu sistemul în limbaj natural. Elementele de inteligenţă artificială, prin propria autonomie decizională şi maniera de comunicare asincronă, aduc îmbunătăţiri substanţiale în luarea deciziilor şi înlesnesc automatizarea proceselor de business. Componentele de tip Asistent Virtual extind caracteristicile interfeţelor inteligente cu utilizatorul pentru a-i oferi acestuia confortul necesar pe durata utilizării sistemului colaborativ. Acestea sunt implementate independent de serviciile furnizate şi vizează integrarea utilizatorului în cadrul organizaţiei. Caracteristicile de interacţiune cu sistemul în limbaj natural sunt realizate prin intermediul structurilor AIML. Acestea se crează dinamic pe toată durata de funcţionare a mediului colaborativ. Interpretarea gesturilor este o caracteristică necesară în cadrul mediilor virtuale: starea unui utilizator şi gesturile lui, de multe ori nevăzute de către colaboratori, au diferite semnificaţii în domeniile de interes abordate. Prezentarea informaţiilor la utilizator în format compact, completarea lor cu cunoştinţele acumulate pe perioada de funcţionare şi interpretarea rezultatelor în timp util, după o logică specifică structurilor inteligente reprezintă un real câştig pentru utilizator. Comunităţile virtuale au la bază structuri informaţionale de capacităţi foarte vaste iar accesul la informaţii trebuie să se realizeaze în timp util. Transparenţa informaţională garantată de aceste componente de tip Asistent Virtual este posibilă datorită, în primul rând, componentelor inteligente ale serverului capabile să gestioneze optim cererile de la client, să interogheze rapid şi eficient structuri mari de date, să elaboreze un răspuns la solicitările clientului şi să furnizeze răspunsul la client prin intermediul sistemului de mesagerie asincronă. pag. 92 / 109

93 2.4. Cerinţe specifice privind componentele de suport colaborativ Caracterul colaborativ impune o serie de caracteristici pe care sistemul trebuie să le suporte: Principiul AAA (Anyone can say Anything about Anything). Aceasta este consecinţa directă a caracterului deschis dat de WWW începând cu versiunea 2.0, care plasează răspunderea generării de conţinut în sarcina utilizatorului. Infrastructura semantică trebuie concepută de aşa natură încât să permită conectarea şi interoperarea între multiple semnificaţii stabilite de multiple surse, pentru o aceeaşi structură informaţională; Efectul de reţea este denumirea formală a fenomenului Întregul este mai valoros decât suma părţilor. Prin aceasta se sugerează că fiecare nod al unei reţele câştigă valoare din simpla conectare cu celelalte noduri într-un ritm proporţional cu pătratul numărului nodurilor. Conform acestui principiu a avut loc explozia WWW, a reţelelor sociale şi a enciclopediei wikipedia, datorită numărului mare de participanţi dispuşi să contribuie gratuit la dezvoltarea reţelei, fie prin creare de conţinut, fie prin corectare/comentare de conţinut existent. Efectul de reţea se manifestă şi în cooperarea din cadrul întreprinderii virtuale fie prin creare explicită de informaţie, fie prin conversia de resurse informaţionale existente puternic granularizate în resurse colaborative ce aduc beneficii tuturor participanţilor în baza unei coloane vertebrale de reprezentare interoperabilă (XML, CORBA, JSON-JavaScript Object Notation, etc.); Eterogenitatea este o consecinţă imediată a principiului AAA şi a efectului de reţea. Infrastructura IV trebuie să suporte contradicţii şi chiar puncte de vedere conflictuale arbitrabile cu ajutorul agenţilor şi tehnologiilor paradigmei Pragmatic Web (negociere, identitate federativă, reputaţie, demonstraţie). Eterogenitatea se poate manifesta în planul semanticii şi structurii datelor pe multiple căi: o dezacorduri în ce priveşte semnificaţia şi structura datelor; o alterarea intenţionată a semnificaţiei şi structurii datelor; o erori de înţelegere a semnificaţiei şi structurii datelor; o lipsa de actualitate a unor semnificaţii şi structuri care evoluează în timp. Structural, problema e facil de rezolvat prin încorporarea soluţiilor XML şi JSON. Vocabularele XML şi tehnologiile de mapare a arborilor XML asigură un mecanism de negociere şi mapare între organizaţii ce implementează structuri diferite. Notaţia JSON simplifică problema chiar mai departe, degrevând generatorul informaţiei de alinierea la un vocabular comun şi plasând sarcina decodării pe partea receptorului, decodare ce se dovedeşte mult mai facilă şi performantă decât în cazul parsingului XML. În planul interoperabilităţii semantice, platforma unei întreprinderi virtuale trebuie să suporte reprezentarea de concepte contradictorii sau conflictuale şi, implicit, de mecanisme Pragmatic Web de arbitrare. Eterogenitatea identităţilor este un caz particular de eterogenitate care se manifestă în identificarea (prin nume sau alte metode) a entităţilor informaţionale. Aşa cum pot apare contradicţii sau variaţii în semnificaţia şi modul de utilizare a unor date, acestea pot să se manifeste şi în denumiri (semnificaţiile, metadatele, descrierile semantice pot fi considerate proprietăţi ale unor concepte/entităţi, iar identitatea este proprietatea fundamentală a oricărui concept/entitate). Aceasta implică definirea unui arbitru universal al identităţii care să fixeze identitatea de bază a oricărei entităţi despre care există informaţii în întreprinderea virtuală. Apoi, acea identitate (nume public) poate fi dublată de nume secundare (nume de prezentare, nume private) care pot suferi variaţii. Aceasta atrage după sine provocarea de a stabili care organizaţie să fie arbitrul ce fixează identitatea de bază. Dacă acest lucru nu se poate stabili, modelele semantice trebuie să indice sinonimii sau asocieri între denumiri ce se referă la acelaşi lucru; Perspectivele de evoluţie a semnificaţiilor şi a îmbogăţirii cunoaşterii cu noi informaţii trebuie să fie suportată de platforma IV. Aceasta trebuie să modeleze o lume deschisă, având deci o pag. 93 / 109

94 structură extensibilă. În acest scop, vor fi implicate tehnologiile bazate pe XML şi Semantic Web, independente de platformă. Componentele colaborative trebuie să suporte următoarele categorii de interacţiuni între nodurile colaboratoare: Interacţiuni conversaţionale: schimb de informaţii slab structurate/formalizate prin componente de mesagerie instantă/non-instantă în scopul definirii sau descoperirii de relaţii internoduri; Interacţiuni tranzacţionale: schimbul de entităţi tranzacţionale care afectează relaţiile între participanţi, fie impunând constrângeri, fie relaxând constrângeri existente; componentele responsabile cu aceste interacţiuni trebuie să dispună de depozite de stări şi de tranzacţii, cu posibilitatea de derulare înainte sau înapoi a acestora; Interacţiuni colaborative: afectează nodurile, fără a afecta direct relaţiile dintre acestea, producând beneficii distribuite şi permiţând augmentare de entităţi informaţionale de către toţi participanţii; componentele responsabile cu aceste interacţiuni trebuie să permită generare de conţinut, corectare de conţinut, clasificare de conţinut după taxonomii subiective nodurilor (numite în continuare folksonomii) precum şi componente de data mining care să asigure filtrare şi optimizare colaborativă. Figura Cazuri de utilizare pentru sisteme de tip colaborativ pag. 94 / 109

95 Din perspectiva granularităţii colaborării, se impun următoarele tipuri de componente: De comunicare one-to-one (mesagerie); De comunicare many-to-many (forum, sistem de reputaţie bazat pe votare); acestea stau la baza conceptului de inteligenţă colectivă, votarea colaborativă fiind un mecanism esenţial în sisteme de recomandări, optimizări şi clasificări folksonomice iar reputaţia generată de votarea colaborativă poate fi transferată ca bază de calcul pentru componente de suport decizional; De management colaborativ (one-to-many), teren pe care are loc fuziunea cu sistemele decizionale, cu orientare pe conducerea activităţilor de grup: calendare, diagrame de urmărire a activităţilor, bookmarking, sistem workflow, gestiune de reţea socială, calcul tabelar distribuit şi consolidat. Cerinţele sistemelor colaborative sunt inspirate de cele ale sistemelor de tip reţea socială. Agenţii sociali se specializează pe două roluri (ce pot fi jucate de un acelaşi utilizator), acelea de generator de conţinut şi de consumator de conţinut. Un caz de utilizare esenţial în acest context este alimentarea sistemului cu informaţie (deopotrivă date şi metadate). Acestea pot fi alimentate prin generare conştientă (completare de formulare) sau incoştientă (captură de comportament cuantificat prin selecţiile făcute sau legăturile urmate prin sistem). În context colaborativ, folksonomia devine preferabilă taxonomiei deoarece modelele devin subiective şi personalizabile, de regulă pe baza asocierii de metadate şi descrieri semantice de către utilizatorii sistemului. Pe colecţia de informaţii acumulate şi organizate folksonomic, se aplică corelaţii (măsurarea similitudinii unor entităţi), filtrări, clasificări şi optimizări. Fiecare din aceste cazuri de utilizare va permite selectarea unui algoritm de către utilizatorii avansaţi (cu cunoştinţe statistice) şi va fi extins cu un caz de efectuare a recomandărilor, ce asigură liantul între sistemele colaborative şi cele decizionale. Exemple de scenarii de utilizare: Corelare: Utilizatorul selectează două entităţi (produse, parteneri, locaţii sau orice entităţi ce pot fi calificate prin votare de către participanţii la întreprinderea virtuală) pentru corelare; Utilizatorul selectează algoritmul de corelare (ex: Corelaţie Pearson, Manhattan, Distanţă Euclideană etc.); Utilizatorului i se returnează gradul de corelare între entităţi; Opţional, cazul de utilizare poate fi extins la executarea motorului de recomandare, care poate indica entităţi puternic corelate cu entităţile selectate. Comunicare: Utilizatorul se autentifică; Utilizatorul accesează lista nodurilor cu care se află în relaţie; Utilizatorul selectează unul din noduri; Utilizatorul selectează opţiunea de mesagerie; Utilizatorul editează un mesaj şi îl trimite nodului vizat. Alimentare informaţie: Utilizatorul autentificat (generator) elaborează conţinut (text, upload de fişier etc.) cu ajutorul unui formular Web; Utilizatorul asociază relaţii semantice conţinutului generat; Utilizatorul încarcă pe platformă conţinutul şi semantica sa (generând informaţie voluntar); Utilizatorul accesează un element de conţinut generat de alt utilizator (generând astfel un vot în calitate de consumator, deci o informaţie creată involuntar ce poate fi procesată ulterior pentru clasificări şi recomandări). pag. 95 / 109

96 2.5. Cerinţe specifice privind sistemele de asistare a deciziilor În mod uzual, sistemele decizionale trebuie să ofere capabilităţile: Definire de structuri (atribute) şi indicatori (agregare de atribute); Prezentare de entităţi (raportare, grafice); Comparare de entităţi (alternative, simulări, scenarii); Proiectare/predicţie de tendinţe pe bază de serii de timp; Recomandări (bazate pe inferenţe, cunoştinţe, optimi Cerinţele specifice suportului decizional implică doi actori: Agentul operativ responsabil cu alimentarea sistemului cu date; fiecare departament organizaţional sau membru al IV poate dispune de propriul agent operativ; Decidentul, consumator al serviciilor decizionale oferite de sistem. Figura Cazuri de utilizare pentru sisteme de suport decizional pag. 96 / 109

97 Cazurile de utilizare prevăzute sunt extensibile: Instrumentele de navigare si de căutare se completează reciproc, iar informaţia este prezentată într-o structură taxonomică, pe baza unor atribute prefixate entităţilor din arhitectura sistemului; Estimarea de tendinţe pentru indicatorii selectaţi se poate completa cu previzionare; Scenarizarea şi analiza what-if pot fi completate cu recomandări automate; Generarea de grafice şi raportarea sunt uzual extinse cu posibilitatea de imprimare a acestora. Exemplu de scenariu de utilizare pentru: Cazul Reprezentare trend: Utilizatorul selectează entitatea (indicatorul) de reprezentat în serie de timp; Utilizatorul selectează perioada pe care o consideră relevantă în analiză (sau pentru care există date suficiente); Utilizatorul indică tipul de sezonalitate, dacă e cazul; Utilizatorul selectează una sau mai multe funcţii de regresie, obţinând diverse trenduri; Utilizatorul consultă indicatorii de calitate ai trendurilor obţinute şi selectează unul dintre acestea; Opţional, prin extinderea cazului, utilizatorul indică un moment din viitor şi obţine nivelul entităţii prevăzut pentru momentul respectiv. Cazul Reprezentare grafic: Utilizatorul selectează seria de date a indicatorului/atributului de reprezentat; Utilizatorul selectează tipul de grafic; Utilizatorul editează adnotările graficului; Utilizatorul formatează graficul; Opţional, utilizatorul trimite la imprimantă graficul. Cazul Definire indicator: Utilizatorul accesează lista atributelor existente în sistem; Utilizatorul construieşte cu ajutorul atributelor şi operatorilor o expresie; Utilizatorul salvează indicatorul. Îmbinând cerinţele tipice paradigmelor vizate de proiectul de faţă (web, suport decizional, suport colaborativ şi suport inteligent multiagent) cu premisa de virtualizare, fundament al întreprinderii virtuale, s-a stabilit următoarea diagramă sintetică, ce defineşte o veritabilă piaţă software a viitorului, bazată pe cuplarea de paradigme convergente în vederea creşterii valorii deciziilor şi a eficienţei proceselor decizionale. Implicarea subsistemelor în diagrama sistemului colaborativ-decizional este după cum urmează: Subsistemul web interactiv asigură capacităţile comunicaţionale ale sistemului şi interfaţa cu utilizatorul, satisfăcând cerinţele de utilizabilitate şi mentenanţă implicate de generaţia Web 2.0 şi metodologiile agile orientate pe refactorizare, şabloane de proiectare din familia Model- View-Controller şi modularitate; Subsistemul social-colaborativ asigură căile de captură a informaţiei pe nivelele sintacticsemantic, suportând deopotrivă taxonomizarea (clasificarea informaţiei după atribute prefixate de sistem) cât şi folksonomizarea (clasificarea informaţiei după atribute personalizate de utilizatorii sistemului) şi, prin motoare de negociere, asigură liantul spre subsistemul inteligentpragmatic; Subsistemul inteligent, inclusiv paradigma orientată pe servicii şi agenţi de servicii, asigură nivelul pragmatic al platformei, ce ridică informaţia la valoarea de cunoştinţă şi imprimă modele de procesare inteligentă, bazate pe învăţare, inferenţiere şi negociere. pag. 97 / 109

98 Figura Cazuri de utilizare pentru componente colaborative-decizionale Agenţii din diagramă pot fi, conform premiselor stabilite în raportul de faţă, agenţi umani sau agenţi automaţi ce interacţionează direct cu sistemul şi sunt purtători de sarcini, în virtutea arhitecturii orientate pe servicii (SOA) Cerinţe specifice privind managementul workflow-ului şi al proceselor de afaceri Având ca şi scop creşterea eficienţei în procesele derulate şi câştigarea de avantaje strategice, companiile au nevoie de automatizarea fluxurilor de lucru (workflow). Prin acesta se urmăreşte îmbunătăţirea proceselor, eliminarea întârzierilor şi maximizarea productivităţii şi în acelaşi timp dezvoltarea unui sistem de management care să asigure accesul rapid la informaţie, în condiţii de maximă securitate cu costuri minimale şi să permită interacţiunea cu alte companii prin diferite mecanisme care să asigure o cooperare durabilă şi eficientă. Software-ul workflow permite afacerilor moderne să automatiezeze munca de zi cu zi. Este o tehnologie IT care utilizează sisteme electronice pentru a monitoriza procesele. Permite depistarea fluxului ce se desfaşoară între angajaţi, departamente şi alte firme colaboratoare. Un pag. 98 / 109

99 sistem eficient de Workflow introduce avantaje atât din punct de vedere al managerului cât şi din punct de vedere al angajatului. Aplicaţiile de workflow determină ca procesele desfăşurate în cadrul unei întreprinderi să fie mai eficiente prin automatizarea transferului fluxurilor de informaţii pe traseele optime, salvând timp şi bani pentru oricine le utilizează. Utilizând modele colaborative pentru orice stadiu al proceselor vehiculate, aplicaţiile de workflow pot să sporească semnificativ eficienţa proceselor pe ansamblul întregii companii sau a întregului grup de companii care formează o întreprindere virtuală. Pentru realizarea acestor diziderate, la ora actuală tot mai multe firme aderă la o organizare bazată pe sisteme de management al workflow-ului (WFMSs - workflow management systems). Utilizarea WFMSs asigură o structurare optimă şi standardizare a managementului de process între ogranizaţiile implicate într-o întreprindere virtuală (D. Georgakopoulos, M. Hornick, A. Sheth, An Overview of Workflow Management ). Tradiţionalul management de workflow se realiza la nivulul unei singure organizaţii fiind dificil de intracţionat din exterior neexistând mecanismele necesare. În acest context, companiile şi-au focalizat eforturile pentru a devenii întreprinderi virtuale, prin care să se realizeze mecanismele organizaţionale necesare pentru a realiza o cooperare care să aducă beneficii maximale firmelor implicate fără a aloca un număr mare de resurse financiare şi umane (H. Ludwig şi alţii, 1999). Pentru a permite integrarea procesului întrun WFMS trebuie extinse funcţionalităţile standard ale workflow-ului existent. Workflow-ul trebuie să fie capabil să gestioneze conexiunea cu sisteme workflow heterogene fiecare având anumite nivele de autonomie bine specificate în întreprinderea vituală şi o dinamică de formare a mecanismelor colaborative avansată. Cooperarea între parteneri este bazată pe dinamica serviciilor de outsourcing care realizează interacţiunea dintre distribuitorii de servicii şi consumatori, compatibilitatea partenerilor de afaceri fiind una din priorităţile şi calităţile acestui sistem. În figura este prezentată o abordare a intreracţiunii dintre distribuitorii şi consumatorii de servicii. Contractul de interacţiune, care este baza cooperării dintre consumator şi distribuitor, include de asemenea detalii despre modul în care se realizează monitorizarea şi controlul activităţiilor care vor duce la finalizarea eficientă a colaborării. Figura Intreracţiunii dintre distribuitorii şi consumatorii de servicii Mediile orientate pe serviciu asigură interacţiunea entităţi de tip serviciu Web. Definiţiile date acestei entităţi diferă de la furnizor la funizor. Asfel definiţiile unui Serviciu Web sunt: Un serviciu Web este o interfaţă care descrie o colecţie de operaţii care sunt accesibile pe o reţea, prin intermediul transferului de mesaje XML (extensible Markup Language) standard. pag. 99 / 109

100 Serviciile Web îndeplinesc o anumită sarcină, sau un anumit set de sarcini. Un serviciu Web este descris folosind o noţiune XML standardizată, formală, denumită descriere serviciu, care furnizează toate detaliile necesare pentru interacţiunea cu serviciul, inclusiv formatele de mesaj, protocoalele de transport şi locaţia. Natura interfeţei ascunde detalii de implementare ale serviciului, astfel încât acesta poate fi folosit independent de platforma hardware sau software pe care este implementat şi independent de limbajul de programare în care este scris.acesta le permite aplicaţiilor Web să fie slab cuplate orientate pe componente şi implementări ce implică mai multe tipuri de tehnologii. Serviciile Web pot fi utilizate de sine stătătoar sau în conjuncţie cu alte servicii Web pentru a efectua o operaţie complexă sau o tranzacţie (Microsoft) sau Serviciile Web sunt componente software care pot fi în mod spontan descoperite, combinate şi recombinate pentru a oferii o soluţiei problemei/cererii utilizatorului. Limbajul Java şi XML sunt principalele pentru servicii Web (Sun). Toate operaţiile de calitate înaltă trebuie să manifeste cuplarea slabă. Întradevăr cuplarea slabă apare atunci când apelul pentru o operaţie poate fi făcut fără nici o ipoteză relativ la contextul mutual între apelant şi operaţia care este apelată. Cu alte cuvinte, operaţia invocată trebuie sa fie în totalitate condusă de datele de intrare care sunt date de apelant. Orice soluţie bine construită trebuie să manifeste cuplarea slabă. Cu toate acestea există anumite diferenţe importante între clase interne sau funcţii care există în cadrul unei soluţii şi serviciile pe care soluţia, ca un întreg le furnizează interfeţelor sale externe. Cel mai important punct este legat de faptul ca funcţiile şi clasele interne, de cele mai multe ori manifestă un grad relativ de cuplare: - Supoziţia poate fi facută cu privire la tehnologiile care sunt utilizate: Funcţiile tranzacţionale şi de securitate sunt manevrate de containerele aplicaţiilor server ale serviciilor. Caracteristicile limbajelor pot fi utilizate din plin, ceea ce este bine pentru limitarea la soluţia globală, dar, pe de altă parte o clasă Java sau EJB sunt de neutilizat pentru un client non-java, - În multe cazuri controlul intern şi structurile de control a contextului sunt plasate printre serviciile interne, care pot să nu aibă semnificaţie pentru serviciile externe care fac invocarea. În afara acestor probleme de cuplare, multe dintre componentele interne vor furniza, de asemenea, operaţii de granularitate fină, de nivel scăzut care nu trebuie să prezinte, neapărat semnificaţie pentru clienţii externi, sau să fie uzuale pentru aceştia. Serviciile date de sietemele SOE (Service Oriented Enterprise) sunt acele servicii pe care o soluţie le face disponibile pe cea mai exterioară interfaţă. Clienţii acestor servicii sunt alte soluţii din cadrul sistemului şi acestea pot fi în egală măsură extinse pentru anumite servicii către clienţii din afara sistemului, chiar dacă acestea sunt aplicaţii externe, procese sau consumatori/utilizatori. Aceste servicii: Trebuie să fie neutre tehnologic: acestea trebuie sa fie invocabile prin tehnologii care respectă nucleul cel mai mic comun de standarde, care sunt disponibile, în general în toate mediile. Aceasta implică, de asemenea ca mecanismele de invocare (protocol, transport, mecanisme de descoperire şi descrierea serviciilor) trebuie sa fie conforme cu standardele acceptate de industrie, în general. Trebuie să fie cuplate slab: nu trebuie să necesite cunoştinţe relative la orice structură internă sau convenţii (contextuale) fie pe parte de client, fie pe partea de serviciu. Trebuie să furnizeze servicii semnificative. Trebuie să dea un set complet de stiluri de invocări; stilul operaţiilor 'one-way' şi 'publicare', precum şi operatii cerere/răspuns. Multe servicii de integrare vor implica publicarea evenimentelor care provin de la un sistem sursă, pentru sisteme 'interesate', ceea ce nu necesită răspuns. De exemplu adăugarea unui nou contact la un sistem CRM (Customer relationship pag. 100 / 109

101 management) poate necesita publicarea unui eveniment de notificare pentru un alt sistem, care va păstra informaţia despre client local. Trebuie să dispună de definiţii şi locaţii care sa fie stocate într-un depozit, care la rândul sau să poată fi accesat de servicii. Acest depozit permite utilizatorilor potenţiali a serviciului să localizeze şi să invoce serviciul, ceea ce, prin indirectare duce la transparenţa locaţiei. Toate aceste caracteristici sunt esenţiale din punct de vedere al integrării aplicaţiilor disparate şi a serviciilor într-un mediu eterogen. Cerinţele sistemului de servicii de management al workflow-ului Ţinând cont de starea curentă a implementărilor comerciale, următorii paşi trebuie luaţi în considerare pentru a pune bazele unor standarde bazate pe SOE care să fie orientate pe provizioane de servicii de interfeţe pentru soluţii semnificative peste domenii şi organizatii. Ipotezele luate aici în considerare sunt legate de faptul că dezvoltările noi vor fi bazate pe J2EE si.net. 1. Utilizare tehnologilor componentelor pentru Serverul de Aplicaţii pentru a furniza implementarea serviciilor SOE Serviciile cerere/răspuns pot fi create utilizând EJB-uri, cu atât mai mult cu cât acestea sunt fără stare, jetoane sesiune ne-tranzacţionale (sau obiecte.net echivalente). Acestea pot fi enunţate simplu ca interfeţe la nivelul soluţie, utilizând tehnologia serviciilor Web (SOAP, WSDL şi UDDI). Acestea pot fi astfel invocate ca servicii SOE de către clienţi externi, sau invocate direct de către clienţi în cadrul aceleiasi soluţii, în special acolo unde performanţele sunt critice. Un jeton sesiune ne-tranzacţională (sau obiect.net) este utilizată numai pentru interfaţarea scopurilor. Este foarte probabil ca aceasta să invoce componentele din fundal care sunt tranzacţionale (pretind tranzacţii). Jetonul ne-tranzacţional de pe nivelul celei mai din exterior interfeţe de pe frontiera soluţiei asigură faptul că, în context, clienţii nu pot compune mega tranzacţii care să includă servicii enunţate de alte soluţii. 2. Se va continua utilizarea SOE-urilor bazate pe ProprietaryQ pentru serviciile one-way Acestea sunt prea proprietare pentru a fi viabile ca implementări pe termen lung a SOE. Acestea pot continua sa fie utilizate pentru servicii one-way acolo unde performanţa de penetraţie nu este critică. Astfel de servicii trebuie să fie descrise în WSDL şi stocate într-un depozit UDDI. Accesul la astfel de servicii trebuie să fie generate 'de mână', generate de proxy-urile de nivel înalt care vor putea fi înlocuite în viitor. Acestea pot fi complet încapsulate, API-urile pentru proprietaryq expunând serviciul ca o clasa proxy directă Java sau.net, care au ca şi clase de intrare clase sau literali XML. 3. Să nu se expună brokerele de mesaj clienţilor SOE Brokerele de mesaj nu vor fi expuse niciodată, direct clienţilor SOE (pot fi însă expuse altor clienţi, de exemplu, în cadrul aceleiaşi soluţii). Acestea vor fi utilizate numai acolo unde este necesar, dacă funcţia deja existentă poate fi accesată direct prin Java Connector, nu mai este necesar un broker de mesaje. Daca clienţii SOE au nevoie de a invoca un serviciu furnizat e un broker de mesaj, acesta trebuie să fie totdeauna realizat front-end de către serviciul SOE, care la rândul sau poate fi încapsulat de un jeton sesiune fără stare sau de un obiect.net. 4. Clienţii serviciilor externe trebuie să utilizeze totdeauna proxy-uri de nivel înalt Pentru reiterare: serviciile externe sunt servicii care nu sunt furnizate de soluţia în care rezidă clientul. Atunci când un client trebuie să invoce un astfel de serviciu extern, acesta trebuie să utilizeze un nivel înalt proxy. Aceste proxy-uri pot fi generate de instrumentele serviciilor Web, sau pot fi simplu generate de mâna. Acest simplu principiu de indirectare va permite implementărilor de fundament să evolueze fără a afecta clienţii. pag. 101 / 109

102 Figura Arhitectură de integrare Workflow bazat pe SOE Paşii de mai sus sunt succint prezentaţi în figura În interiorul soluţiilor J2EE se poate observa un lanţ de Web-uri care gestionează prezentarea şi fluxul aplicaţiilor economice, precum şi lanţul EJB care furnizează serviciile economice implementate ca EJB-uri. O parte dintre acestea vor fi fără stare, jetoane sesiune ne-tranzacţionale care devin interfaţa la nivel soluţie a aplicaţiei, exportate ca Servicii SOE cu definirea lor WSDL şi stocarea acestora în depozitul UDDI. O arhitectură de integrare bazată pe SOE, va fi capabilă să absoarba creşterile de fluxuri, care pot fi asteptate ca urmare a îmbogăţirii statutului producţiei în urmatorul interval de timp. Această perspectivă este dată în figura de mai jos. MDB (Message-Driven Bean), în mediul J2EE, vor furniza un mediu care controlează complet depozitul pentru servicii one-way şi care este bazat pe transport fiabil, asincron şi un mediu de rulare fiabil pentru procesarea mesajelor prin MDB. Aceasta furnizează performanţe înalte, procesarea concurentă a pool-ului de mesaje, precum şi o structură simplă, bazată pe standarde, care permite mesajelor a fi procesate ca text (XML), obiecte sau reprezentări autodescrise. Aceasta poate, în continuare reduce, dacă nu chiar elimina complet, necesitatea de a susţine SOE-uri bazate pe proprietaryq. Mai mult, se asteaptă ca MDB să dea un mecanism de implementare naturală pentru serviciile Web asincrone. Este de asteptat, de asemenea ca, un cadru de invocare a serviciilor, comercial, să fie capabil de a expune direct funcţiile existente şi functiile brokerului de mesaj ca servicii de anvelopă complete, completate cu descrierea WSDL, legarea informaţiei şi publicarea acestora în depozitul UDDI. Acest cadru devine capabil pentru gestiunea tuturor problemelor care apar la formarea/izolarea cererilor în cozi cerute de protocoalele existente Definirea funcţiilor de anvelopă. Condiţii tehnice Definirea principalelor funcţii îndeplinite de platforma INVITE s-a făcut pe baza analizei cerinţelor diferitelor metode, tehnologii şi sisteme de susţinere a mecanismelor IV, identificate în paragrafele ale capitolul 2. Funcţiile de anvelopă pentru susţinerea mecanismelor întreprinderilor virtuale, intrările acestora, rezultatele şi componentele platformei INVITE care vor implementa aceste funcţii sunt detaliate în cele ce urmează. 1. Crearea, menţinerea şi actualizarea reţelei de întreprinderi suport pentru viitoarele IV pag. 102 / 109