Studiu de caz in domeniul Servicii administratia publica

- versiunea 2 -

CUPRINS 1 Tipuri de servicii in administratia publica date generale ..................................... 4 1.1. 1.2 1.3. Introducere ........................................................................................................... 4 Tipuri de servicii in administratia publica ......................................................... 5 e-Guvernare ....................................................................................................... 10 Descrierea domeniului de servicii e-Guvernare ............................................ 10 e-Participare si e-Incluziune ......................................................................... 15 e-Guvernare in Romania .............................................................................. 16 Metrici de performanta in e-Guvernare ......................................................... 19

1.3.1. 1.3.2. 1.3.3. 1.3.4. 1.4.

Servicii publice de consultanta si asistenta pentru mediul de afaceri ......... 21

1.5. Servicii publice de consultanta si asistenta pentru accesarea de fonduri nerambursabile............................................................................................................. 24 1.6. Servicii publice de consultanta si asistenta la implementarea proiectelor finantate din fonduri nerambursabile ......................................................................... 25 2. 2.1. Tehnologii software pentru serviciile din administratia publica ....................... 25 Servicii Web ....................................................................................................... 26 Tipuri de arhitecturi ....................................................................................... 26 Arhitectura de tip RPC .................................................................................. 27 Arhitectura de tip REST ................................................................................ 29 Principiile SOA ............................................................................................. 37 Rolurile serviciilor Web intr-o SOA ............................................................... 37 Interactiunea si compunerea serviciilor ........................................................ 38 Limbajul XML ................................................................................................ 38 SOAP ........................................................................................................... 39 WSDL ........................................................................................................... 40 UDDI............................................................................................................. 41 WSRF ........................................................................................................... 41 Arhitectura orientata pe servicii in sistemele Grid......................................... 43 Sintaxa OWL ................................................................................................ 45 Cazuri de utilizare......................................................................................... 51 Concluzii Web semantic ............................................................................... 55 2.1.1. 2.1.2. 2.1.3. 2.2. 2.2.1. 2.2.2. 2.2.3. 2.2.4. 2.2.5. 2.2.6. 2.2.7. 2.2.8. 2.2.9. 2.3. 2.3.1. 2.3.2. 2.3.3.

Arhitectura orientata spre servicii ................................................................... 35

Web-ul semantic ................................................................................................ 44

2.4.

Potential de inovare .......................................................................................... 56 Noi capabilitati ale serviciilor publice electronice .......................................... 56 Dezvoltarea interactiunii cu utilizatorii........................................................... 56 Managementul identitatii electronice ............................................................ 57 Interoperabilitatea serviciilor publice electronice .......................................... 58 Managementul cunostintelor ........................................................................ 58

2.4.1. 2.4.2. 2.4.3. 2.4.4. 2.4.5.

2.5. Descrierea serviciului Servicii publice de rezolvare a cererilor clientilor in varianta actuala ............................................................................................................ 59 2.5.1. Procesul actual ............................................................................................. 59 2.5.2. Prezentarea potentialului de inovare a serviciului Servicii publice de rezolvare a cererilor clientilor..................................................................................... 62 2.6 Descrierea serviciului public de consultan i asisten pentru afaceri ......... 64 2.6.1 Procesul actual .................................................................................................. 64 2.6.2 Prezentarea potentialului de inovare a serviciului publice de consultan i asisten pentru afaceri .............................................................................................. 66 3. 3.1. 3.2. Concluzii ................................................................................................................ 69 Tendinte si inovare in serviciile software pentru administratia publica ....... 69 Rezumat servicii ................................................................................................ 70

3.3. Implicatii asupra necesitatii calificarii si pregatirii de personal implicat in servicii ........................................................................................................................... 70 4. Bibliografie ............................................................................................................ 72

1 Tipuri de servicii in administratia publica date generale

1.1. Introducere Administratia publica reprezinta domeniul care se ocupa de implementarea politicilor guvernamentale, avand drept principal scop realizarea unui avans in managementul si politicile guvernamentale pentru ca acesta sa functioneze cat mai bine. In contextul prezentului studiu, cea mai relevanta definitie a administratiei publice o reprezinta procesul de transpunere a politicilor guvernamentale in realitatea pe care cetatenii o vad in fiecare zi. In acest context, se poate vedea clar legatura intre administratia publica si organizarea politicilor si programelor guvernamentale in folosul tuturor cetatenilor, dar si a companiilor. Datorita cresterii birocratiei din administratia publica, cauzata atat de cresterea politicilor guvernamentale, cit si de cresterea populatiei, a aparut o noua teorie numita Noul Management Public (NMP) la sfarsitul anilor 1980. Acest nou model propune o orientare spre servicii a sectorului public, porning de la ideea folosirii modelelor existente pentru sectorul privat, inclusiv a valorilor organizationale, pentru a creste eficienta sectorului public. La inceputul anilor 1990, administratia publica a tarilor dezvoltate s-a reformat adoptand principiile acestei noi teorii, care s-a extins apoi in toata lumea. NMP se bazeaza pe impartirea birocratiilor mari in agentii mai mici si mai fragmentate, incurajand astfel competitia intre diferitele agentii publice. O observatie importanta este ca NMP trateaza indivizii ca pe clienti (termen specific sectorului privat), mai degraba decat ca cetateni. Aceasta reprezinta si principala critica adusa acestui model intrucat cetatenii nu mai sunt proprietarii (patronii) sistemului de guvernamant, ci doar ca un mijloc de a face profit. La inceputul secolului 21, guvernarea digitala (e-Guvernare) a fost propusa ca nou model pentru serviciile publice, venind si ca un raspuns pentru NMP. Principiile e-Guvernarii se axeaza pe reintegrarea responsabilitatilor procesului de guvernare, profitand de epoca digitala pentru a oferi un holism in serviciile publice, mergand pe ideea ca cetatenii trebuie sa aiba posibilitatea sa isi indeplineasca obligatiile fasa de stat intr-un mod cat mai usor si mai cursiv. Guvernarea orientata pe servicii reprezinta insa o tehnica de guvernare moderna ce poate fi folosita chiar impreuna cu e-Guvernarea, daca o privim doar ca o modalitate de a indeplini nevoile cetatenilor, oferind bunuri si servicii publice de inalta calitate. Cele mai importante doua trasaturi ale guvernarii bazate pe servicii ar trebui sa fie: oferirea de bunuri si servicii publice fara a se implica in producerea de bunuri si servicii private si incurajarea dezvoltarii serviciilor publice orientate spre piata. Astfel, Guvernul nu trebuie sa aiba monopolul in oferirea de bunuri si servicii publice, permitand astfel funizarea de servicii publice si sectorului privat pentru a creste competitia in toate domeniile administratiei publice. Rezultatul final va fi minimizarea defectelor din serviciile publice oferite cetatenilor si cresterea productivitatii in administratia publica. Guvernarea bazata pe servicii scoate in evidenta faptul ca principalul rol al Guvernului este acela de a oferi functiile baza necesare serviciilor publice si ca valorile cele mai importante sunt orientarea spre oameni si centrele de servicii. Astfel, rolul Guvernului nu mai este de a regulariza piata serviciilor si bunurilor publice, ci de a se concentra pe imbunatatirea reglementarilor si controlului macroeconomic, de a standardiza piata, de a creea un mediu de piata corect si de a imbunatati calitatea si abilitatea serviciilor publice.

Indiferent de modelul de organizare al administratiei publice (orientat pe servicii sau clasic), dezvoltarea serviciilor software si a tehnologiilor Web a oferit o modalitate de imbunatatire a eficientei si eficacitatii organizatiilor birocratice de dimensiuni mari. Astfel, termeni precum e-Comert, e-Guvernare, e-Organizare, e-Participare, etc. au devenit din ce in ce mai utlizati in ultimii 10-15 ani. Conceptele de e-Guvernare si e-Guvernamant au cunoscut o evolutie vasta in aceasta perioada, pornind de la folosirea site-urile Web pentru informarea cetatenilor, a comunicarii prin posta electronica si mergand pana la sisteme IT, atat hardware, cat si software, foarte avansate pentru a oferi e-cetatenilor acess la informatiile si serviciile publice. E-Guvernarea, prescurtare de la guvernare electronica, cunoscuta si ca e-gov, guvernare digitala, guvernare online sau guvernare conectata, reprezinta orice forma de interactiune digitala intre Guvern si cetatenii sai (G2C), Guvern si companii, organizatii comerciale sau eCommerce (G2B), intre diversele agentii guvernamentale, eventual din state diferite (G2G). Acestea sunt doar principalele ramuri ale e-gov, intrucat exista si interactiunea intre Guvern si organizatiile religioase (G2R), etc. Astfel, e-Guvernarea se afla la confluenta dintre administratie publica, tehnologia informatiei si comunicatii, ingineria proceselor de afaceri, precum si e-cetatenii care trebuie sa foloseasca servicii publice oferite de orice forma de administratie publica (la nivel de oras, provincie, national sau international). In continuarea acestui capitol vor fi prezentate principalele tipuri de servicii necesare in administratia publica pentru cetateni si companii. Apoi, se va face o scurta trecere in revista a principalelor aspecte ale e-Guvernarii, scotandu-se in evidenta ultimele evolutii si servicii folosite. Astfel, se ajunge la definirea notiunilor de e-Participare si e-Incluziune ale cetatenilor la e-Guvernare. Vom discuta apoi serviciile de e-Guvernare oferite in Romania, precum li principalele directii de evolutie din perioada imediat urmatoare. Tot in cadrul acestui capitol va fi prezentata o scurta comparatie cu serviciile de aministratie publica oferite prin e-Guvernare de catre alte tari europene. Capitolul curent se termina cu prezentarea principalelor metrici de performanta in e-gov si prezentarea statisticilor ce reflecta pozitia Romaniei la nivel mondial si european. 1.2 Tipuri de servicii in administratia publica

Exista o gama larga de servicii oferite in administratia publica, atat la nivel local, cat si national. Scopul acestei sectiuni nu este de a furniza informatii despre toate aceste servicii, ci de a delimita clar serviciile care sunt o prioritate in acest moment pentru eGuvernare. Astfel, exista un set de 20 de servicii monitorizate la nivel european (12 pentru cetateni si 8 pentru operatorii economici), si pentru care se urmareste cresterea calitatii furnizarii acestora, cresterea numarului de utilizatori, cresterea gradului de acoperire pentru diferite categorii si a nivelului de dezvoltare. Serviciile adresate cetatenilor din lista aceasta sunt urmatoarele: 1. Serviciile pentru colectarea impozitului pe venit al cetatenilor; 2. Cautarea unui loc de munca; 3. Serviciu pentru urmarirea beneficiilor asistentei sociale; 4. Eliberarea documentelor personale; 5. Serviciu pentru inmatricularea autovehiculelor; 6. Eliberarea autorizatiilor de constructie;

7. Serviciu pentru monitorizarea declaratiilor la politie; 8. Serviciu pentru librariile publice; 9. Eliberarea certificatele personale; 10. Inscrierea in universitati; 11. Serviciu pentru anuntarea schimbarii de domiciliu; 12. Servicii de sanatate pentru cetateni; Serviciile adresate companiilor sunt cele de mai jos: 13. Plata si monitorizarea contributiile sociale; 14. Serviciu pentru plata impozitului pe profit; 15. Serviciu pentru plata TVA; 16. Inregistrarea operatorilor economici noi si modificarea datelor operatorilor economici existenti; 17. Date statistice ale operatorilor economici; 18. Serviciu pentru gestiunea declaratiilor vamale; 19. Eliberarea autorizatiilor de mediu; 20. Serviciu pentru achizitiile publice. Dupa cum se poate observa, aceste servicii sunt esentiale in administratia publica, fiind folosite de catre aproape toti cetatenii si toate companiile. Acestea au fost si motivele pentru care au fost incluse de catre Comisia Europeana in lista serviciilor fundamentale pentru procesul de guvernanta, fiind monitorizata oferirea acestor servicii online, in cadrul programelor de e-Guvernare. Dupa cum se poate observa si din figura 1, toate tarile membre ale Uniunii Europene au cunoscut o crestere accelerata a disponibilitatii in varianta online acestor servicii in ultimii 10 ani [4]. Mai mult, se constata ca exista o disponibilitate online mai mare a serviciilor publice adresate companiilor, decat cele adresate cetatenilor.

Figura 1. Evolutia serviciilor publice fundamentale complet disponibile online in tarile EU27+

Din punct de vedere al evaluarii prezentei online a acestor servicii publice, Comisia Europeana a stabilit sa foloseasca un model al maturitatii serviciului impartit in 5 etape [4], care sunt prezentate in tabelul 1. In figura 2 (preluta tot din [4]), sunt prezentate aceste etape ca etape in maturizarea serviciului public online, in acest context etapele mai fiind numite si stagii de sofisticare. In cadrul acestui model, este esential sa se atinga cel putin nivelul 3, care de altfel este un standard in majoritatea tarilor europene in acest moment. Formularele electronice sunt disponibile pentru cele mai multe servicii din lista celor 20 de servicii publice esentiale monitorizate. De asemenea, nivelul tranzactional, numit si manipularea integral electronica a cazului, in care utilizatorul aplica pentru folosirea serviciului online si il poate folosi fara a fi nevoie de birocratie suplimentara devine in ultima perioada un standard pentru oferirea serviciilor publice online. Ultimul nivel din modelul maturitatii serviciului, targetizarea, este folosit pentru a identifica gradul de integrare a datelor din front- si back-office, daca aceste date sunt reutilizate, iar serviciile oferite sa fie proactive. Doar serviciile care sunt in nivelul 4 sau 5 sunt considerate a fi complet disponibile online.
Tabelul 1. Stagiile de sofisticare folosite pentru masurarea maturitatii serviciilor publice online Etapa 1 2 3 4 5 Descriere etapa Sa existe materiale de informare online pentru serviciul public. Existenta interactiunii cu cetateanul intr-un singur sens (de exemplu: download de formulare) Existenta interactiunii cu cetateanul ambele sensuri (de exemplu: completarea formularelor online) Existenta tranzactiilor pentru folosirea serviciului public online. Trebuie sa fie incluse modalitati de decizie, notificare, livrare si plata a serviciilor publice Automatizare, personalizare target-izare (targetization)

Figura 2. Masurarea maturitatii serviciilor publice online, model definit de C.E.

1

EU27+ include toate rile membre ale Uniunii Europene, precum i Croaia, Elveia, Islanda i Norvegia.

Folosind acest model, se poate masura maturitatea sau sofisticarea serviciilor publice online oferite de fiecare tara. In figura 3 este prezentat nivelul mediu de sofisticare al serviciilor publice fundamentale din tarile EU27+, inclusive evolutia acestui indicator intre 2007 si 2009 cand au fost facute ultimele 2 evaluari. Din aceste date, se observa ca Romania ocupa ultimul loc intre tarile membre ale Uniunii Europene cu un nivel mediu al sofisticarii doar un pic peste 60%. Aceasta inseamna ca in Romania sunt foarte putine servicii care sa poata fi considerate complet disponibile online. Din figura se poate observa ca tarile care alcatuiesc top 10 au un nivel de sofisticare de peste 90%, printre acestea existand si tari din EU12 (Slovenia si Estonia). Totusi, singurele tari care au un nivel de maturitate de 100% sunt Malta si Portugalia.

Figura 3. Nivelul mediu al sofisticarii serviciilor publice online in tarile EU27+

La nivel european, serviciile publice adresate companiilor sunt mai mature decat cele adresate cetatenilor. Acest lucru confirma un trend global: Guvernele continua prioritizarea dezvoltarii serviciilor pentru companii intrucat acestea au o rata de adoptare mai mare (unele fiind obligatorii de folosit in anumite tari) si un impact mai important asupra performantelor economice ale tarii. Nivelul mediu de sofisticare al serviciilor publice online oferite companiilor era in 2009 de 90% la nivelul EU27+, in timp ce serviciile adresate cetatenilor se situa doar la 78%. Cele 20 de servicii publice fundamentale pot fi grupate in 4 categorii: servicii generatoare de venituri pentru administratia publica (taxe, contributii sociale, TVA, taxe vamale); servicii de registratura (pentru masini, companii, nasteri si casatorii, domiciliere, date statistice despre companii si cetateni); servicii utile publicului (sanatate, biblioteci publice, licitatii publice, stabilirea politicilor, cautarea de slujbe); servicii pentru permise si licente (pentru autovehicule, cladiri, carti de identitate, pasapoarte, eliberarea diplomelor de studii, avize de mediu).

Desigur ca nivelul de sofisticare este diferit pentru fiecare grup de servicii, dupa cum este evidentiat in figura urmatoare (preluata din [4]). Serviciile publice online cele mai mature in Uniunea Europeana sunt cele din prima categorie, care genereaza venituri directe administratiei publice, iar cele mai putin mature servicii sunt cele pentru eliberarea de permise si licente, care nu aduc nici un beneficiu direct statelor.

Figura 4. Gradul de sofisticare al serviciilor publice online in EU27+, in functie de categoria serviciului

Intrucat pentru o e-Guvernare eficienta este absolut necesar ca aceste 20 de servicii fundamentale sa fie complet disponibile online (deci sa se afle pe nivelul 4 sau 5 de maturitate), are sens o analiza mai atenta a datelor din EU27+ asupra progresului facut de fiecare stat in parte si a procentului de servicii care sunt complet disponibile online. Aceste date sunt prezentate in figura 5 [4]. Tot in [4] a fost facuta o analiza suplimentara asupra ratei de atingere a tuturor cerintelor necesare pentru indeplinirea perfecta a nivelul de sofisticare 5. Dupa cum se poate observa, din acest punct de vedere rezultatele sunt mediocre, media la nivel EU27+ fiind de doar 50%, cu toate avantajele oferite de potentialul utilizarii tehnologiei pentru restructurarea proceselor administrative. Astfel doar jumatate din serviciile care ar putea fi livrate complet automatizat (de exemplu, serviciile de plata a taxelor) sau personalizat (de exemplu, serviciile pentru documente personale sau biblioteci publice) au atins acest nivel de maturitate.

Figura 5. Rata de disponibilitate online completa a serviciilor publice din fiecare stat

Figura 6. Rata de sofisticare de nivel 5 (targetizare sau serviciu proactiv)

1.3.

e-Guvernare

1.3.1. Descrierea domeniului de servicii e-Guvernare Dupa cum a fost mentionat si in introducere, termenul de e-Guvernare, provenind de la guvernare digitala, se refera la toate modalitatile folosite de Guvernare (administratia publica locala sau nationala) de a utiliza tehnologiile oferite de tehnologia informatiei si telecomunicatii, pentru a imbunatati eficienta si eficacitatea sectorului public. In afara celor 20 de servicii publice fundamentale identificate de catre Comisia Europeana, conceptul de e-Guvernare merge mult mai departe. De exemplu, folosind e-gov este posibil ca vizitand site-ul web al unui oras sa fie permisa comunicarea cu angajatii administratiei locale prin interfete grafice incorporate in site, prin mesagerie instanta, conversatii audio-video si orice alte tehnologii mai avansate. Mai mult decat atat, pot fi introduse noi metode

10

colaborative de propunere de legi si alte initiative legislative locale venite din partea cetatenilor, daca acestia reusesc sa acumuleze un numar suficient de mare de semnaturi digitale de la alti concetateni, folosind site-uri web specializate pentru aceste activitati administrate de administratiile publice. Aceleasi metode colaborative pot fi folosite pentru discutarea propunerilor legislative cu societatea civila, asigurand accesul fiecarui cetatean la a fi de acord sau in dezacord cu anumite prevederi ale acestor propuneri. Sumarizand, e-Guvernarea implica folosirea tehnologiilor IT&C pentru a imbunatati accesul la serviciile publice, modalitatea de livrare a acestora catre contribuabili, pentru a aduce beneficii cetatenilor, companiilor si angajatilor. Principalele obiective ale eGuvernarii sunt: Folosirea tehnologiilor IT&C, in special a Internetului, pentru a oferi servicii publice mai calitative si a atinge o guvernanta mai buna; Folosirea tehnologiilor IT&C in toate aspectele operationale ale organismelor administratiei publice locale si centrale; Optimizarea continua a livrarii serviciilor publice si a procesului de guvernanta prin transformarea relatiilor interne si externe prin intermediul tehnologiei, a Internetului si a conceptului de new-media (sau media online).

Doua directii de evolutie sunt foarte importante pentru conceptul de e-Guvernare. In primul rand, desi e-Guvernarea este inteleasa, in mod traditional, ca fiind axata in jurul operatiunilor administratiilor publice locale si centrale, e-Guvernanta are are o definitie extinsa, incercand sa includa si implicarea si participarea cetatenilor la actul de guvernare, an scopul de a ambunatati deciziile luate de guvernare in folosul majoritatii cetatenilor. Exact in acest context, au sens notiunile de e-Participare si e-Incluziune a cetatenilor la procesul de e-Guvernanta, notiuni ce sunt prezentate in detaliu in sectiunea urmatoare. A doua directie, o reprezinta faptul ca desi e-Guvernarea este definita de multe ori ca Guvernare online sau Guvernare folosind Internetul, exista multe tehnologii de Guvernare electronica care nu folosesc Internetul ca mediu de comunicatie cu cetatenii si companiilor. Printre acestea se numara: folosirea SMS-urilor si a MMS-urilor, folosirea retelelor si a serviciilor mobile, Bluetooth, CCTV, RFID, identificarea biometrica a persoanelor, sisteme de management a traficului rutier, cardurile destepte, metode de livrare a serviciilor publice prin TV si radio, folosirea comunitatilor online (inclusiv a retelelor sociale), mesagerie instanta si chat, etc. Strategia nationala de creare a platformei e-Romania, reprezinta ultimul si cel mai complex proiect pentru e-Guvernare in Romania. Din [3], reiese ca semnificatia si importanta eGuvernarii este datorata faptului ca guvernarea electronica reprezinta simplificarea modurilor de lucru prin aplicarea unor tehnologii ale informatiei si ale comunicatiilor in zonele de administrare a informatiilor, de comunicare si de tranzactii in cadrul si intre institutiile de stat, precum si intre stat si cetateni sau operatorii economici. Tot in aceasta strategie se observa ca nu sunt definite decat primele patru nivele de sofisticare ape serviciilor publice, rezultand faptul ca nivelul al 5-lea, cel al serviciilor publice online proactive, complet mature, nu a fost luat in considerare. Astfel, scopurile e-Guvernarii sunt definite doar de (date preluate tot din [3]): Informare: informatiile vor fi disponibile on-line, prin publicarea lor pe site-ul web al unei autoritati publice (nivelurile 1 si 2 de sofisticare);

11

Comunicare: capacitatea de a avea acces interactiv si de a face schimb de informatii (nivelul 3 de sofisticare); Tranzactie: realizarea efectiva de servicii, inclusiv semnarea de formulare de cerere si livrari electronice ale documentelor oficiale si notificarilor (nivelul 4 de sofisticare).

Printre beneficiile aduse de e-Guvernare, cele mai importante se refera la: Usurinta de acces si accesul non-stop la serviciile publice: mediile de comunicatie electronice sunt disponibile oricand, nu implica costuri suplimentare (timp, energie si bani) din partea contribuabililor. Eliminarea necesitatii deplasarii contribuabililor la oficiile administratiei publice, rezultand in economia de timp pentru cetateni si companii, ceea ce se traduce in cresterea productivitatii economice. Cresterea participarii si implicarii cetatenilor in procesul de guvernare. Folosind servicile de e-Guvernare, orice cetatean poate sa isi comunice punctul de vedere atat catre autoritatile publice, dar si catre concetateni. Astfel, votantii pot avea un impact direct si pot influenta procesul de guvernare. Pastrarea datelor in format digital permite autoritatilor sa reevalueze si sa simplifice procedurile si formularele care sunt considerate prea complicate de catre public. E-Guvernarea ofera doar o alternativa pentru interactiunea clasica (la ghiseu) cu autoritatile publice, dar acest lucru nu inseamna ca acestea sunt eliminate, ci ele functioneaza in paralel, astfel incat fiecare cetatean poate alege modalitatea de interactiune cu serviciile publice (online sau la ghiseu). E-Guvernarea asigura o transparenta suplimentara procesului de guvernare, datorita faptului ca datele de interes public pot fi accesate online, rapid si fara efort, de oricine. Se pot verifica astfel discrepante in declaratiile de avere, voturile alesilor, etc. Exista si un avantaj ecologic pentru folosirea e-Guvernarii, prin renuntarea la folosirea hartiei pentru actele publice. Viteza, eficacitatea si comoditatea folosirii serviciilor publice online de catre cetateni si companii. Avantaje pentru salvarea si indexarea datelor in baze de date electronice spre deosebire de folosirea fisetelor pentru hartii. Aprobarea publicului: peste tot unde au fost introduce, opinia publica a avut o reactie pozitiva fata de serviciile publice electronice. De exemplu, in statul Alabama s-au vandut peste 140.000 de autorizatiile electronice de vanatoare si pescuit doar in primul sezon cand s-a introdus aceasta modalitate de eliberare a autorizatiilor. Exista totusi si o serie de dezavantaje in utilizarea e-Guvernarii, care sunt insa sensibil mai putine decat avantajele: Principalul dezavantaj si risc il reprezinta hiper-supravegherea contribuabililor. Daca se doreste, prin folosirea diverselor tehnologii pentru e-Guvernare (online, dar si offline de exemplu retelele mobile, camere de luat vederi, etc.) autoritatile publice pot avea o evidenta foarte buna asupra activitatilor contribuabililor. Daca acest lucru prezinta un avantaj in anumite situatii (de exemplu, supravegherea activitatilor teroriste sau criminale), poate fi si o incalcare a libertatilor cetatenilor. Exista costuri financiare din ce in ce mai ridicate pentru implementarea si mentenanta serviciilor de guvernare electronica.

12

Inaccesibilitatea serviciilor de guvernare electronica pentru anumite categorii de cetateni: aflati in locatii fara conexiune la Internet, cetatenii cu deficiente de vedere sau cei care nu isi pot permite utilizarea calculatoarelor din diverse motive. Sentimentul fals de transparenta: intrucat autoritatile au acces la date, acestea pot sa fie alterate sau eliminate, fara ca publicul sa constientizeze acest lucru. Serviciile de guvernare electronica pot fi tintele unor atacuri electronice si acesta reprezinta un risc constant.

Pentru ca serviciile de guvernare electronica sa fie folosite cu succes si adoptate de catre utilizatori, acestea trebuie sa satisfaca niste cerinte [3]: Sa ofere incredere si securitate: Cetatenii trebuie sa aiba incredere in autoritatea publica electronica la fel de mult cum au in cea traditionala. Cetateanul trebuie sa poata verifica faptul ca versiunile electronice ale documentelor oficiale pe care le primesc nu au fost modificate si au fost trimise de catre autoritati. Posibilitatea de autentificare si semnatura electronica: Autoritatile publice trebuie sa poata verifica daca documentele primite de la cetateni ajung in starea lor originala si daca acestea sunt cu adevarat trimise de catre o anumita persoana. Transparenta: Schimbarile tehnice vor fi acceptate doar daca ele vor fi acceptate de toti cei vizati si daca aceste schimbari vor fi facute intr-un mod transparent. Accesibilitatea: Serviciile publice electronice trebuie sa fie accesibile tuturor, fara discriminare. Solutiile oferite, precum si site-urile web trebuie sa fie fara bariere si accesibile tuturor. Usurinta de folosire: Gama de servicii electronice oferite trebuie sa fie structurata intr-un mod usor de inteles, simplu si clar. In plus, formularele si portalurile vor trebui sa aiba un design consistent. Navigarea si meniurile trebuie sa fie intuitive si logice, cu o structura familiara, astfel incat utilizatorii sa poata gasi rapid ceea ce cauta. Securizarea datelor: Cetatenii acorda un grad ridicat de incredere administratiei in ceea ce priveste protectia datelor. Sectoarele specifice de identificare personala vor fi special concepute pentru a fi in conformitate cu standardele de protectie a datelor. Cooperarea intre autoritati: e-Guvernarea functioneaza cel mai bine atunci cand toate nivelurile de guvernare lucreaza impreuna, de la autoritatile locale pana la ministere. Aplicatiile si infrastructurile existente vor trebui sa lucreze impreuna pentru a se putea ajunge la nivelul dorit de eficienta. Modularitate: e-Guvernarea are o structura modulara, care permite integrarea imediata a noilor componente in sistem pentru a tine pasul cu cele mai recente tehnologii. Interoperabilitatea: Tipuri diferite de sisteme vor trebui sa fie capabile sa comunice unul cu celalalt. Totusi, in special in contextul proiectului INSEED este important de remarcat ca eGuvernarea nu inseamna doar tehnologii IT&C, ci include de asemenea cunostinte si educatie2. Astfel, guvernarea electronica este strans legata de:

Mai multe detalii despre legtura ntre e-Guvernare si educatie la adresa (wiki al Unviersitii din Haga): http://wiki.triastelematica.org/index.php/Education:EGovernment_-_a_holistic_approach_%28II%29

13

Capitalul uman: e-gov imbuatateste experienta tuturor participantilor la acest proces, crescand astfel valoarea sistemelor informatice; Sistemele de management a cunostintelor; Incurajarea si sprijinirea impartasirii de experiente: informatie + experienta + rezultate = cunostinte; Sprijinirea si diseminarea normelor celor mai bune practici pentru folosirea cat mai eficienta si dezvoltarea serviciilor publice electronice; Inovarea in e-gov aduce beneficii atat cetatenilor, cat si angajatilor din administratia publica; Aplicatiile pentru managementul relatiilor cu cetatenii sunt niste unelte software utile pentru a imbunatati comunicarea intre administratia publica si utilizatori; Sprijinirea invatarii pe tot parcursul vietii: regulamentele, legile si organizatiile se schimba, iar oamenii trebuie sa fie sprijiniti sa se adapteze la ele; Servicii de e-learning pentru a oferi training pentru folosirea tehnologiilor relevante pentru e-Guvernare.

In plus, o analiza atenta asupra e-Guvernarii si potentialului de inovare in acest domeniu trebuie sa tina cont ca e-gov nu inseamna numai tehnologie, ci trebuie sa includa si elemente de strategie politica. Astfel, de multe ori exista tendinta de a uita ca modelele din e-Comert nu se transfera pur si simplu catre e-Guvernare intrucat guvernanta in administratia publica nu este acelasi lucru cu guvernanta din corporatii. Astfel, suplimentar fata de elementele strategice, tactice si operationale care se gasesc in companii, eGuvernarea trebuie sa includa si procesele politice. Nivelul politic influenteaza toate politicile si actiunile guvernamentale aflate pe un nivel inferior in figura 7. Totusi, dupa cum se poate observa din aceeasi figura, satisfactia cetatenilor poate influenta aceasta strategie politica prin bucla de feedback (sageata cu numarul 9). Astfel, inovarea in serviciile din administratia publica trebuie sa tina cont de o multitudine de factori diferiti: Legislatie, reguli si practici; Detalii despre organizatiile si procesele guvernamentale; Tehnologie si continutul serviciilor; Cunostinte si capital uman; Comunicare si accesabilitate.

Numai lucrand cu toti acesti factori intr-o maniera holista, poate fi posibil sa fie evitate erorile facute de e-Comert. E-Guvernarea efectiva necesita integrarea informatiilor de pe toate aceste nivele, ceea ce inseamna inclusiv integrarea proceselor si modelelor organizationale.

14

Figura 7 . Complexitatea procesului de e-Guvernanta in care aplicatiile inglobeaza foarte multe cunostinte de pe niveluri diferite: politic, administrativ, strategic, birocratic (figura preluata din [6]).

1.3.2. e-Participare si e-Incluziune Dupa cum s-a mentionat si in sectiunea anterioara, unul dintre rolurile principale ale eGuvernarii este de a oferi putere si de a include cetatenii in procesul de luare a deciziilor. Atat cetatenii, cat si sistemele democratice de guvernare pot beneficia din imbunatatirea accesului la informatiile si serviciile publice. Studiul Organizatiei Natiunilor Unite despre eGuvernare [10] masoara canalele oferite de administratiile publice pentru participarea online a cetatenilor si modul in care le sunt ascultate opiniile, masurand astfel puterea oferita cetatenilor si includerea lor in luarea deciziilor. Astfel este definit un index pentru eparticipare ce tine cont de mecanismele pentru consultarea si luarea deciziilor folosind opinia cetatenilor. Exista trei teste pentru evaluarea acestui index: Daca Guvernul publica online informatiile necesare pentru luarea deciziilor guvernamentale. Daca sunt oferite publicului oportunitati de a participa la consultari cu oficialii guvernamentali si institutiile care sunt responsabile de politicile guvernamentale. Daca cetatenii pot influenta direct deciziile, de exemplu prin vot online sau prin vot folosind telefoanele mobile.

Modalitatile prin care publicul poate fi implicat in luarea deciziilor si care sunt utile pentru stimularea e-participarii sunt foarte diverse, folosind principalul avantaj al Internertului: chiar si vocile marginalizate pot fi auzite online, mai ales cu aparitia si dezvoltarea Webului social. Cele mai frecvente modalitati de stimulare a e-participarii sunt: Folosirea chestionarelor de feedback si consultarea acestor rezultate;

15

Folosirea sondajelor si votarii online si publicarea rezultatelor pe site-urile institutiilor publice si utilizarea acestor date in elaborarea politicilor publice; Folosirea Web2.0 si a retelelor sociale pentru comunicarea mesajelor importante; Integrarea uneltelor colaborative in site-urile ministeriale (de exemplu, wiki-uri si blog-uri); Utilizarea camerelor de chat; Utilizarea consultarii populatiei prin SMS; Monitorizare blog-urilor si grupurilor de pe retele sociale relevante pentru actul de guvernare; Creearea de catre administratia publica de pagini si grupuri in site-urile celor mai importante retele sociale; Oferirea cetatenilor a posibilitatii de a face propriile propuneri, care apoi sunt edeliberate si folosite de administratiile centrale si locale in luarea deciziilor; Folosirea forumurilor de discutii, la care sa participe nu doar cetatenii, dar si oficiali guvernamentali seniori, cu putere de decizie; Oferirea de date suplimentare despre evenimentele de e-participare si e-incluziune viitoare (de exemplu, calendare, etc.).

E-participarea este la randul sau divizata in trei criterii diferite: e-infomare, e-consulare si e-luarea deciziilor. E-informarea masoara daca administratia publica ofera acele informatii care incurajeaza si stimuleaza e-participarea. Aceasta include publicarea online a politicilor despre e-participare, a calendarului discutiilor si consultarilor, precum si utilizarea de unelte electronice pentru notificarea automata a cetatenilor care si-au manifestat interesul de a participa la aceste consultari. Principalele metode de e-consulare includ: sondaje online, voturi online, formulare de feedback, camere de chat, blog-uri, liste de stiri. Utilizarea uneltelor specifice Web2.0 este inca in faza incipienta. Indicatorul de e-luare a deciziilor masoara nivelul la care tarile sunt dedicate includerii opiniilor cetatenilor in elaborarea politicilor guvernamentale. Cele mai populare tehnologii sunt: utilizarea forumurilor de discutii, folosirea arhivelor discutiilor anterioare, oficialii guvernamentali raspund intrebarilor cetatenilor, oficialii modereaza e-consultari, folosirea petitiilor online si a voturilor online. Doar 9% dintre tarile monitorizate permit creearea, semnarea electronica de catre mai multi cetateni si trimiterea de petitii online catre autoritati in 2010. 1.3.3. e-Guvernare in Romania In raportul e-Government in Romania al Comisiei Europene [5] este prezentata starea actuala a serviciilor publice electronice din Romania. Desi este evidenta inapoierea acestor servicii fata de media europeana, este important de observat ca atat proiectul anterior, e-guvernare.ro, cat si noul proiect propus in 2010, e-Romania, sunt inca intr-o faza incerta de realizare, in special datorita lipsei finantarii si a problemelor cauzate de licitatiile publice. Totusi, acest raport prezinta starea de fapt a disponibilitatii serviciilor de e-Guvernare in Romania anului 2010, pe care le-am sintetizat in acest subcapitol. Fiind un raport al Comisiei Europene, accentul s-a pus pe gradul de maturitate al celor 20 de servicii publice fundamentale prezentate in sectiunea 1.2.

16

Serviciile publice electronice pentru cetateni care au fost analizate sunt urmatoarele. 1. Serviciile pentru colectarea impozitului pe venit al cetatenilor - Adresa web: http://formulare.e-guvernare.ro/Forms/default.aspx - Nivel de sofisticare: 2, 3 sau 4 (depinzand de orasul de resedinta) - Formularele pot fi semnate electronic, iar in 50% din municipalitati impozitele pe venit pot fi platite online 2. Cautarea unui loc de munca - http://www.anofm.ro; http://www.semm.ro - Nivel de sofisticare: 3 - Locurile de munca pot fi cautate inca din 2002 3. Serviciu pentru urmarirea beneficiilor asistentei sociale - Ajutorul pentru somaj: http://www.mmssf.ro; http://www.anofm.ro , nivel de sofisticare: 2 (informatii online si formulare pentru download) - Alocatiile pentru copii: http://www.mmuncii.ro/ro/; http://sas.mmssf.ro , nivel de sofisticare: 1 (infomare) - Asigurari medicale: http://formulare.e-guvernare.ro/Forms/default.aspx , nivel de sofisticare: 2 (informatii online si formulare pentru download) - Burse scolare: http://www.edu.ro , nivel de sofisticare: 1 (infomare) 4. Eliberarea documentelor personale - Pasaport: http://www.pasapoarte.mai.gov.ro/; http://www.mai.gov.ro/ , nivel de sofisticare: 2 (informatii online si formulare pentru download) - Carnet de conducere: http://www.mira.gov.ro/Home/index.htm , nivel de sofisticare: 2 (informatii online si formulare pentru download) 5. Serviciu pentru inmatricularea autovehiculelor - http://www.mira.gov.ro/Home/index.htm - Nivel de sofisticare: 2 6. Eliberarea autorizatiilor de constructie - Nu exista 7. Serviciu pentru monitorizarea declaratiilor la politie

17

- http://www.politiaromana.ro - Nivel de sofiticare: 1 8. Serviciu pentru librariile publice - http://www.cultura.ro - Nivel de sofisticare: 2 9. Eliberarea certificatele personale - Nu exista 10. Inscrierea in universitati - http://www.edu.ro - Nu exista serviciu centralizat, posibilitatea de inscriere online depinde in functie de unviersitate 11. Serviciu pentru anuntarea schimbarii de domiciliu - http://www.mai.gov.ro - Nivel de sofisticare: 1 12. Servicii de sanatate pentru cetateni - www.ms.ro - Nivel de sofisticare: 1 Serviciile adresate au un grad de sofisticare un pic mai bun decat cele adresate cetatenilor: 13. Plata si monitorizarea contributiile sociale - https://formularunic.e-guvernare.ro/ , http://www.anaf.ro/public/wps/portal/ANAF - Nivel de sofisticare: 4 14. Serviciu pentru plata impozitului pe profit - https://formularunic.e-guvernare.ro/ , http://www.anaf.ro/public/wps/portal/ANAF - Nivel de sofisticare: 4 15. Serviciu pentru plata TVA

18

- https://formularunic.e-guvernare.ro/ , http://www.anaf.ro/public/wps/portal/ANAF - Nivel de sofisticare: 4 16. Inregistrarea operatorilor economici noi si modificarea datelor operatorilor economici existenti - http://www.onrc.ro/; http://recom.onrc.ro/index.htm - Nivel de sofisticare: 2 17. Date statistice ale operatorilor economici - http://www.insse.ro/cms/rw/pages/index.ro.do - Nivel de sofisticare: 3 sau 4 18. Serviciu pentru gestiunea declaratiilor vamale - Nu exista 19. Eliberarea autorizatiilor de mediu - http://www.mmediu.ro - Nivel de sofisticare: 2 20. Serviciu pentru achizitiile publice. - www.e-licitatie.ro - Nivel de sofisticare: 4 sau 5 Concluzia este ca in Romania exista un nivel mare de fragmentare al serviciilor de eGovernment si nu exista un one-stop shop (punct de contact unic, punct unic de asistenta). De asemenea, serviciile sunt deconectate, majoritatea sunt in stagii de dezvoltare incipienta, oferind doar informatii si comunicare intr-un singur sens, prin oferirea formularelor utile spre download. Se observa insa un inceput de punct unic de asistenta pentru companii, ceea ce este un lucru de laudat. In plus, serviciul de licitatii publice din Romania este considerat unul dintre serviciile cu cel mai mare succes si grad de sofisticare, fiind printre putinele servicii oferite la un nivel european. 1.3.4. Metrici de performanta in e-Guvernare In prezent, exista mai multe metrici de evaluare a performantei in e-Guvernare, dar cele mai importante sunt cele definite de catre Organizatia Natiunilor Unite [10] si de catre Comisia Europeana [3]. Cei mai importanti indicatori din cele doua metodologii sunt:

19

Modelul sofisticarii serviciului, in 5 etape, definit de catre CE si discutat in sectiunea 1.2. Romania ocupa ultimul loc in UE conform acestui indicator si penultimul loc in EU27+. Modelul de dezvoltare al serviciului public electronic, definit de catre raportul ONU, foloseste numai 4 etape, dar care sunt foarte similare cu cele ale modelului anterior: etapa 1 servicii de informare emergente, etapa 2 servicii de informare avansate, etapa 3 servicii transactionale si etapa 4 servicii conectate, proactive. Practic, in acest model, etapa a doua de dezvoltare include nivelurile 2 si 3 din modelul propus de CE. Indicatorul pentru eProcurement ce masoara nivelul de dezvoltare al serviciilor pentru licitatie publica, considerat foarte important de catre CE. Romania are un scor de 36% pentru acest indicator, maximul fiind de 100%. Si acest indicator este format din 2 scoruri diferite: pre-contract-award si post-award-transaction, care masoara evolutia licitatiilor publice inainte de castigarea licitatiilor, respectiv modul in care se desfasoara tranzactia dupa ce licitatia publica a fost adjudecata. Metrica pe 5 axe pentru evaluarea experientei cu utilizatorul definita tot de CE. Cele 5 criterii de evaluare sunt: utilizabilitatea, accesibilitatea pentru crawlere web, monitorizarea gradului de satisfacere a utilizatorilor, utilizarea unei abordari de tipul one-stop-shop si design al unui portal axat pe utilizator. Din acest punct de vedere, Romania sta foarte rau intrucat pe 3 axe scorul sau este zero dupa cum se poate observa din figura 8.

Figura 8 . Indicatorul Romaniei pentru experienta utilizatorului in relatia cu serviciile publice electronice.

Indicatorul pentru e-participare definit de catre ONU, care este format din 3 componente discutate in sectiunea 1.4. Indicatorul general pentru e-Guvernare utilizat de catre ONU, care combina scorul pentru nivelul de dezvoltare al serviciilor cu scorul indicatorului pentru e-participare.

20

Romania ocupa locul 47 in clasamentul oferit de ONU pentru acest indicator in 2010, cu un scor de 0.55/1.00. 1.4. Servicii publice de consultanta si asistenta pentru mediul de afaceri

Serviciul public de consultanta este un serviciu profesional de consiliere si, la cerere, de implicare, realizat de catre specialisti din institutiile publice si avand ca scop sprijinirea managerilor din mediul privat in realizarea obiectivelor de afaceri. Actiunile consultantilor pot fi corective, progresive sau creative. Serviciile publice de consultanta si asistenta in managementul financiar fac parte din interventia publica pentru crearea unui mediu de afaceri favorabil dezvoltarii unei piete libere, globalizate si competitive. In Romania, in decursul timpului, serviciile de consultanta oferite de catre institutiile publice s-au diversificat, acoperind o arie larga de activitati de consultanta la nivel national, regional, judetean si local. Regula generala ar fi ca aceste servicii sa fie oferite in mod gratuit, insa exista si exceptii in care institutiile publice regionale sau judetene pot oferi si servicii pe baze contractuale, contra cost. Spre deosebire de sectorul privat, institutiile publice ofera consultanta financiara, si de alta natura, alaturi de alte servicii publice specifice, pentru care au fost create. Serviciile publice de consultanta si asistenta financiara pentru mediul de afaceri sunt oferite/ furnizate de urmatoarele categorii de institutii: Institutii si organizatii internationale Aceste servicii publice sunt adresate cu precadere sectorului IMM-urilor, dar nu numai. Dintre principalele servicii amintim: Enterprise Europe Network: o retea de peste 500 de organizatii din Europa ce furnizeaza servicii de informare despre politicile, programele si legislatia comunitara, cautare de parteneri de afaceri, brokeraj pentru transferul de tehnologii, evaluarea nevoilor materiale, financiare, de know-how etc.; Euro Info Centrale: acorda IMM-urilor servicii-suport in urmatoarele domenii tematice: programe si surse de finantare, cooperare in afaceri si cautare de parteneri, evaluarea calitatii si marcarea produselor, accesul pe noi piete, protectia mediului si dezvoltarea durabila, achizitii publice, dezvoltare tehnologica, societate informationala si e-business; SOLVIT: este o retea on-line disponibila statelor membre UE unde se cauta solutionarea problemelor transfrontaliere legate de: aplicarea impozitelor, libera circulatie a capitalurilor si a platilor, accesul pe piata al produselor si serviciilor, achizitiile publice etc.; Portalul Europa voastra Intreprinderi: ofera informatii pentru societatile ce desfasoara activitati economice in alt stat din UE. Portalul este oferit in comun de catre Comisia Europeana si autoritatile nationale; Programul de asistenta privind implementarea si respectarea legislatiei mediului de catre IMM-uri: domeniile vizate in acest program sunt: reducerea poverii administrative, integrarea in activitate a normelor de mediu, imbunatatirea nivelului de know-how, cresterea gradului de comunicare intre organizatii etc.;

21

TechWeb destinat IMM-urilor: ofera servicii de informare si resurse IMM-urilor ce doresc sa solicite finantare pentru cercetare in tehnologie; InnovAccess: ofera servicii de informare in domeniul proprietatii intelectuale; Altele: Reteaua Europeana a Centrelor de Afaceri si Inovare (C.A.I.); eMarket Services; Lexelerator; Centrul de documentare privind responsabilitatea sociala corporatista; Comert electronic (site); Grupul de consultare a intreprinderilor europene (European Business Test Panel); Oficiul european pentru standardizare in domeniul comertului, artizanatului si al IMM-urilor (N.O.R.M.A.P.M.E.). Agentia pentru Implementarea Proiectelor si Programelor pentru Intreprinderi Mici si Mijlocii (A.I.P.P.I.M.M.) asigura implementarea tehnica si financiara a proiectelor si programelor de sprijinire a infiintarii de noi intreprinderi si de sustinere a dezvoltarii sectorului IMM. Agentia are 13 oficii teritoriale cu 195 de posturi. Agentia Nationala pentru Ocuparea Fortei de Munca (A.N.O.F.M.), impreuna cu cele 42 de agentii judetene si peste 180 de agentii locale, ofera servicii somerilor si agentilor economici. Principalul sau obiectiv este cresterea gradului de ocupare a fortei de munca si implicit scaderea ratei somajului. Pentru indeplinirea acestui obiectiv organizeaza servicii de ocupare a fortei de munca, organizeaza, presteaza si finanteaza servicii de formare profesionala, realizeaza propuneri privind elaborarea proiectului de buget al asigurarilor pentru somaj, administreaza bugetul asigurarilor pentru somaj si prezinta Ministerului Muncii, Familiei si Protectiei Sociale rapoarte trimestriale si anuale privind executia bugetara, implementeaza programe finantate din Fondul Social European. Consultanta si asistenta pentru initierea unei activitati de intreprinzator se acorda, la cerere, persoanelor neincadrate in munca, sub forma de servicii juridice, de marketing, financiare, metode si tehnici eficiente de management etc.. Pentru someri si studenti, consultanta si asistenta pentru inceperea unei activitati independente sau initierea unei afaceri sunt gratuite. Agentia Nationala de Consultanta Agricola (A.N.C.A.), aflata in subordinea Ministerului Agriculturii si Dezvoltarii Rurale, are la nivel judetean 41 de Oficii Judetene de Consultanta Agricola si, la nivel comunal, 546 de Centre Locale de Consultanta Agricola si Casele Agronomului. A.N.C.A. ofera servicii de adaptare a fortei de munca din mediul rural la economia de piata, de asistenta tehnica de specialitate, de elaborare de proiecte de ferme-model, de modele tehnicoeconomice cadru pentru culturi de plante si specii de animale, de proiecte de accesare a fondurilor europene etc.. Oficiul de Stat pentru Inventii si Marci (O.S.I.M.) ofera servicii in domeniul proprietatii industriale. La cerere, ofera si consultanta de specialitate si cursuri de pregatire a specialistilor in domeniul proprietatii industriale. Centrele regionale O.S.I.M. se gasesc in Galati, Constanta, Bacau, Suceava, Harghita, Brasov, Mures, Maramures, Bistrita-Nasaud, Bihor, Timis, Dolj si Bucuresti. Institutii regionale, agentii de dezvoltare regionala. A.D.R.-urile furnizeaza o serie de servicii publice grupate in 4 categorii principale: Managementul

Agentii publice romanesti

Institutii publice descentralizate

22

Programului Operational Regional 2007-2013; Programare regionala; Cooperare externa; si Promovare regionala. Institutii publice judetene. Aceste institutii au fost create pentru a furniza servicii de planificare strategica si operativa pentru autoritatile publice locale, insa, in subsidiar, ofera si consultanta mediului de afaceri. Dintre cele mai importante enumeram: Agentia de Dezvoltare economico-sociala Timis (ADETIM) ce ofera servicii de consultanta si management de proiect, cat si sprijin in accesarea programelor de finantare, in vederea realizarii de obiective de investitii din sectorul public si privat; Agentia de Dezvoltare Durabila a Judetului Brasov (ADDJB) ce ofera servicii de consultanta pentru initiative de dezvoltare economica a judetului, de dezvoltare a patrimoniului istoric, arheologic si cultural, de dezvoltare a turismului zonal etc.; Agentia de Dezvoltare Judeteana Harghita ofera servicii de consultanta financiara pentru dezvoltarea capitalului autohton si atragerea capitalului strain, promovarea oportunitatilor de afaceri si cooperare la nivel judetean, atragerea de fonduri europene s.a.; Agentia de Dezvoltare economicosociala Caras-Severin ofera servicii de asistenta tehnica si consultanta intreprinderilor mici si mijlocii si investitorilor care prin activitatea lor imbunatatesc mediul economic din judet; Agentia de Implementare a proiectelor de dezvoltare a judetului Arges elaboreaza cereri de finantare si management de proiect, pregateste documentatie pentru proiectele de accesare a fondurilor europene nerambursabile; Agentia de dezvoltare economico-sociala a judetului Hunedoara (ADEH) acorda consultanta in domeniul promovarii si sprijinirii initiativei private si a ONG-urilor in vederea accesarii fondurilor structurale. Serviciile de consultanta furnizate de structurile asociative sunt concentrate in centre de asistenta antreprenoriala (CAA), se adreseaza de obicei IMM-urilor si presupun informare, cercetare, organizare de evenimente, incubare, consultanta financiara. Exista astazi mai multe categorii de CAA si anume: centre UNDP (United Nations Development Programme) cu asistenta ONU, centre infiintate prin fundatia CRIMM (Centrul Roman pentru IMM-uri) si centre PAEM (Programme of Active Employment Measures) cu fonduri PHARE, centre finantate de British KnowHow Fund, centre romano-americane finantate initial de USAID (United States Agency for International Development), centre finantate de guvernele Germaniei, Olandei si altele. Camerele de Comert sunt in tara noastra in numar de 42, cea mai mare fiind Camera de Comert si Industrie a Romaniei si a Municipiului Bucuresti. Acestea sprijina si promoveaza operatorii economici din industrie, agricultura, comert, turism si servicii si acorda consultanta de afaceri, asistenta pentru constituirea si functionarea societatilor comerciale, facilitare de contracte de afaceri de tip bi si multiparteneriat, organizeaza misiuni de afaceri in strainatate etc.. De asemenea, se organizeaza aici cursuri intensive pe probleme de organizare, conducere si programare in afaceri. Dintre organizatiile neguvernamentale care acorda consultanta mediului de afaceri sunt de mentionat:

Structuri asociative, fundatii, ONG-uri

23

o Consiliul National al Intreprinderilor Private Mici si Mijlocii din Romania (CNIPMMR) ofera servicii cu tarif preferential pentru membri, constand in consultanta juridica, manageriala si de marketing, consultanta pentru intocmirea planurilor de afaceri, intocmirea dosarelor pentru accesarea diverselor surse de finantare, intocmirea formalitatilor pentru cumpararea activelor disponibile ale statului etc.. o Reteaua CDIMM finantata din fonduri PHARE (Programul PHARE R9207) din care au supravietuit si s-au dezvoltat CDIMM Braila, CDIMM Maramures si CDIMM Arges. Centrele ofera consultanta pentru evaluarea ideilor de afaceri, intocmirea planurilor de afaceri, finantarea afacerilor si management, intocmirea studiilor de fezabilitate pentru investitori, analize si proiectii financiare etc.. o Fundatia CRIMM, dependenta aproape integral de fondurile PHARE, a fost nevoita sa isi restranga considerabil activitatea odata cu terminarea finantarii europene. o Fundatia Post-Privatizare (FPP) gestioneaza din februarie 2008 portalul pentru IMM-uri www.esimplu.ro, cu cea mai vasta colectie de resurse on-line pentru acestea. Portalul a facut parte din programul PHARE CES 2006 ce sa incheiat in februarie 2010. Din 2010 FPP se adreseaza antreprenorilor care au deja o afacere si celor care sunt gata sa accepte provocarile unui demers de infiintare a unei intreprinderi, atat in mod direct prin consultanta in materie de fonduri structurale si surse de finantare, cat si indirect prin intermediul Fondului Roman de Contragarantare, ce preia o parte din riscul asumat de catre fondurile de garantare, la acordarea garantiilor pentru creditele obtinute de IMM-uri. 1.5. Servicii publice de consultanta si asistenta pentru accesarea de fonduri nerambursabile Acestea constau in pregatirea accesarii fondurilor nerambursabile prin: analiza eligibilitatii aplicantului si respectiv a proiectului acestuia; asistenta in stabilirea grupului tinta in conformitate cu prevederile programului de finantare; stabilirea de solutii pentru incadrarea proiectului in conditiile programului de finantare nerambursabila; asistenta la identificarea de parteneri eligibili pentru proiect; asistenta la stabilirea rolurilor si responsabilitatilor in cadrul parteneriatului incheiat pentru implementarea proiectului; consultanta la alocarea resurselor (materiale si umane) necesare si intocmirea bugetului alocat pentru implementarea proiectului; realizarea documentatiei de accesare a programului de finantare; asistenta la pregatirea documentelor insotitoare cererii de finantare; asistarea clientului in relatia cu Autoritatea Contractanta;

24

 1.6.

consultanta pentru pregatirea documentelor in vederea pre-contractarii finantarii nerambursabile. Servicii publice de consultanta si asistenta la implementarea proiectelor finantate din fonduri nerambursabile

Se menioneaz aici trei categorii de servicii: Servicii referitoare la managementul procedural al finantarii: consultanta pentru insusirea de catre client a procedurilor (tehnice si financiare) de lucru in cadrul programului/programelor de finantare nerambursabile; asistarea clientului in relatia acestuia cu autoritatea contractanta in procesul de implementare a proiectului; asistarea clientului la gestionarea documentelor justificative aferente implementarii activitatilor prevazute in proiect; consultanta la intocmirea raportarilor periodice catre autoritatea contractanta in vederea realizarii decontarilor cheltuielilor realizate pentru proiect.

Servicii referitoare la managementul de proiect: consultanta la implementarea activitatilor proiectului printr-un management eficient al timpului (grafic realizare activitati) si al resurselor (buget); asistarea clientului la organizarea, gestionarea si monitorizarea activitatilor in vederea atingerii obiectivelor asumate prin proiect.

Servicii referitoare la consultanta achizitii publice de servicii si bunuri: pregatirea documentatiilor/dosarelor pentru atribuirea contractelor de achizitie publica prin procedurile specifice legislatiei achizitiilor publice; consultanta pentru pregatirea si desfasurarea procedurilor de achizitie; asistarea clientului in vederea obtinerii avizelor Autoritatii Contractante pentru procedurile de atribuire derulate; asistarea clientului la desfasurarea contractelor de achizitie si la eligibilitatea cheltuielilor efectuate.

2.

Tehnologii software pentru serviciile din administratia publica

In cadrul acestui capitol sunt prezentate principalele tehnologii folosite pentru dezvoltarea serviciilor electronice folosite in e-Guvernare, punandu-se accentul pe servicii Web, arhitecturi orientate spre servicii si Web semantic. In ultima parte a capitolului este prezentat potentialul de inovare in domeniul serviciilor software folosite in administratia publica.

25

2.1.

Servicii Web

Un serviciu web reprezinta orice serviciu disponibil pe Internet, care foloseste un sistem de mesaje standardizat XML si care nu este legat de nici un sistem de operare sau de un calculator. Acum cativa ani serviciile web nu erau suficient de rapide pentru a fi considerate interesante. Dar, datorita dezvoltarii majore a tehnologiilor din ultimii ani, cei mai multi oameni si cele mai multe companii au conexiune broadband (in banda larga) si au folosit web-ul din ce in ce mai mult. Cand platformele majore au putut accesa Web-ul folosind browserele Web, diferite platforme au putut sa interactioneze. Pentru ca aceste platforme sa interactioneze, au fost dezvolatate aplicatiile Web. Serviciile web au dus aplicatiile Web la urmatorul nivel de dezvoltare. Folosind serviciile web, aplicatia ta isi poate publica functiile sau mesajele catre toata lumea ce foloseste Web-ul. Folsind serviciile web, departamentul economic bazat pe un server Windows se poate conecta la un alt server ce ruleaza Unix. Serviciile web au doua tipuri de utilizare. In primul rand componentele unui serviciu web sunt reutilizabile. Sunt lucruri de care aplicatiile au nevoie foarte des. Deci de ce sa construim aceste lucruri mereu cand putem sa le reutilizam? De aceea au fost create serviciile web. Serviciile web pot oferi aplicatiilor componente precum conversia valutara, rapoarte de vreme si chiar traducerea unui limbaj ca serviciu. In al doilea rand, serviciile web conecteaza aplicatii existente deja. Ele ajuta sa rezolvi problema interoperabilitatii, permitand schimbul datelor intre diferite aplicatii si diferite platforme. Aceste reprezinta 2 avantaje majore ale seviciilor web. Avantajele serviciilor web sunt: interoperabilitatea intre aplicatii reutilizarea serviciilor existente distribuire usoara a informatiei intre consumatori dezvoltare rapida

2.1.1. Tipuri de arhitecturi Exista numeroase standarde si protocoale, cel mai folosit fiind HTTP, destinate construirii serviciilor web. Aceste standarde poarta numele de stiva WS-*. Printre acestea se numara WS-Notification, WS-Security, WSDL, si SOAP. Insa acestea adauga o mare complexitate serviciilor web . De aceea simplitatea tehnologiilor folosite pentru web (protocolul HTTP, standardul de nume URI si protocolul XML) a dus la contruirea unor altfel de servicii, arhitecturile serviciilor web impartindu-se in doua mari categorii: arhitectura de tip RPC ( Big Web Services-orientate pe servicii) arhitectura de tip REST ( orientate pe resurse)

Bazate pe un limbaj comun XML (eXtensible Markup Language) si un protocol comun de transport HTTP (HyperText Transfer Protocol) in general, serviciile Web actioneaza ca un intermediar intre cele dou entitati ce doresc sa comunice intre ele. XML constituie motorul care face posibil transferul datelor prin intermediul Internetului, constituind totodata fundamentul serviciilor Web.

26

Arhitectura de tip RPC permite trimiterea si primirea mesajului intr-un invelis. Acest invelis poate fi de mai multe tipuri : SOAP, XML-RPC si chiar HTTP. Din cauza acestui invelis, acest stil de serviciu web este unul complex. De ce sa folosim un tip complex cand putem sa folosim o arhitectura la fel de usoara ca si ce a WEB-ului: arhitectura de tip REST. 2.1.2. Arhitectura de tip RPC Arhitectura de tip RPC este cea mai complexa si cuprinde practic toate tehnologiile necesare unei arhitecturi de tip REST. Asa cum am mai spus o arhitectura de tip REST foloseste doar tehnologiile utilizate in web: HTTP, URI si XML . Remote Procedure Call (Apelul Procedurilor la Distanta) este o tehnologie de comunicatie inter-procese care permite unui program de pe un computer sa genereze o subrutina sau unei proceduri sa se execute intr-un alt spatiu de adresa (de regula pe un alt computer sau pe o retea partajata) fara ca programatorul sa codeze explicit detaliile aceste interactiuni la distanta. Practic, programatorul scrie, in principiu, acelasi cod indiferent ca subrutina este locala sau la distanta fata de programul executant. Cand soft-ul in cauza este scris folosind principii orientate-obiect, se poate vorbi despre apelare la distanta sau apelarea metodelor la distanta. In general o arhitectura de tip RPC si in general protocolul SOAP este confundat cu notiunea de serviciu web, desi exista si alte stiluri de construire a unui serviciu web precum REST. Diagrama ce descrie functionarea unei serviciu web de tip RPC este prezentata in figura de mai jos:

Figura 9. Functionarea unei serviciu web de tip RPC

O arhitectura a serviciului web poate fi analizata din doua puncte de vedere: din punctul de vedere al rolurilor in cadrul serviciului web si din punctul de vedere al stivei de protocoale folosite. Acest tip de serviciu web necesita mai multe componente de baza pentru a putea fi realizat:
furnizorul de servicii: reprezinta un nod in Internet care asigura printr-o interfata accesul la un serviciu software care executa un anumit set de operatii; consumatorul de Servicii:reprezinta un nod in retea care se leaga la furnizorul de servicii, si foloseste functionalitatea oferita de acesta, construind solutia de afacere ;

registru de servicii reprezinta un software care gazduieste servicii publicate, acestea putand fi furnizate la cererea solicitantului. Registrul implementeaza descoperirea de servicii si functii prin care solicitantul poate cere un anumit serviciu;

27

Figura 10. Rolurile din cadrul unui serviciu de tip RPC si interactiunea dintre acestea

Arhitectura orientata spre servicii Web de tip RPC trebuie sa implementeze trei operatii care definesc contractele dintre rolurile principale (furnizor, solicitant, registru): (1) publicare: inregistrarea (sau promovarea) serviciului de catre furnizorul serviciului in registrul de servicii; (2) descoperire: operatie complementara operatiei de conectare (binding), deoarece serviciile publicate trebuie regasite. Solicitantul descopera serviciul in registrul servicii conform unor criterii de cautare specificate de solicitant. Criteriile de cautare pot fi, de exemplu, tipul serviciului, caracteristicile furnizorului, caracteristicile de calitate a serviciului etc.; (3) conectare: conecteaza furnizorul de servicii cu solicitantul de servicii intr-o relatie de tip clientserver. Aceasta relatie poate fi dinamica (de exemplu, generarea dinamica a proxy-ului solicitantului) sau statica (cand dezvoltatorul poate predefini si codifica modul de asociere a serviciului cu orice solicitant). O alta modalitate de a examina arhitectura serviciilor web se realizeaza prin studierea stivei de protocoale a serviciului. Stiva este in continua dezvoltare dar in prezent contine patru niveluri: nivelul transport al serviciului : nivelul este responsabil de transportul mesajului dintre consumator si furnizor. In prezent acest nivel contine protocoale precum HTTP (hypertext transfer protocol), Simple Mail Transfer Protocol (SMTP), file transfer protocol (FTP), si protocoale mai noi precumprecum Blocks Extensible Exchange Protocol (BEEP). nivelul de mesaje XML: acest nivel este responsabil de codarea mesajelor intr-un format XML astfel incat mesajele sa poata fi intelese la celalalt capat. In prezent acest nivel este descris de protocoalele XML-RPC si SOAP. nivelul de descriere a serviciului : este responsabil cu descrierea interfetei publice a serviciului. Descrierea serviciului este realizata prin Web Service Description Language (WSDL), acesta urmand a fi prezentat mai tarziu nivelul de descoperire a serviciului : acest nivel este responsabil de centralizarea serviciilor intr-un registru comun si furnizeaza functionalitati de publicare a serviciului. Descoperirea serviciului se realizeaza in prezent prin : Universal Description, Discovery, and Integration (UDDI).

28

Serviciile web evolueaza permanent, de aceea pot aparea noi niveluri in cadrul stivei. Figura de mai jos sintetizeaza nivelurile actuale din cadrul stivei serviciului web.

Figura 11. Stiva serviciului web de tip RPC

In figura urmatoare este prezentata modalitatea de interactiune a serviciilor web folosind protocoale de tip RPC.

Figura 12. Interactiunea serviciilor web folosind protocoalele de tip RPC

2.1.3. Arhitectura de tip REST REST este acronimul de la Representational State Transfer si reprezinta un model architectural pentru crearea serviciilor web. REST descrie o arhitectura orientata pe resurse, aceasta fiind prezentata in detaliu prima data in teza de doctorat a lui Roy Fieldings. Motivul realizarii unei astfel de arhitecturi a pornit de la faptul ca serviciile de tip RPC si cele care in general folosesc SOAP aduc o oarecare complexitate. Simplitatea WEB a reprezentat sursa de inspiratie a serviciilor web de tip REST. Serviciile WEB de tip REST folosesc toate componentele ce au facut web-ul un mare success. REST aplica arhitectura web-ului asupra serviciilor web. Desi REST nu este un standard, el se foloseste de standarde: HTTP ( Hypertext Transfer Protocol) URI ( Uniform Resource Identifier)

29

XML/HTML/GIF/JPEG

Practic REST presupunea construirea unui serviciu web folosind HTTP, XML si URI asa cum a fost construit si web-ul. Pentru a putea intelege mai bine modul in care se realizeaza un serviciu de tip REST mai intai va fi prezentata o abordare simpla, pe intelesul tuturor iar apoi o descriere tehnica a acestuia. De unde a pornit construirea unui serviciu de tip REST? O multime de teorii complexe plutesc in jurul conceptului REST, dar ce este practic REST? In lumea software vorbim de design si vorbim despre arhitectura. Uneori, incercam sa facem o distinctie formala intre aceste doua concepte, alteori, ne rezumam la a face o distincitie instinctuala. Instinctual ar trebui sa observam ca arhitectura REST este la fel cu interactiunile de tip web-style intre clienti si servere - care sunt arhitectura. Comportamentul intern al software-ului clientului si serverului se poate numi design. REST nu este despre design. Este despre arhitectura. REST este un set de reguli la care o arhitectura ar trebui sa se conformeze. Pentru ca nu este suficient de detaliat pentru a defini o arhitectura reala vom spune despre REST ca este un stil arhitectural. Web-ul este un exemplu real de arhitectura care urmeaza in linii mari regulile REST. Pentru a intelege aceste reguli trebuie sa avem o imagine a unei arhitecturi fara constrangeri. Arhitectura fara constrangeri: o arhitectura este construita din diferite componente proiectate (design pieces). Aceste componente interactioneaza unele cu altele, in diverse moduri. Imaginati-va o arhitectura fara constrangeri care permite trimiterea de mesaje intre oricare componente. Orice componenta poate trimite un mesaj la orice alta componenta iar regulile referitoare la semnificatia mesajului sau felul in care mesajul este tratat sa ramana la latitudinea emitatorului si receptorului. Intr-o arhitectura REST se deosebesc doua trasaturi importante : datele asupra careia clientul ii spune serverului sa opereze se afla in URI operatia pe care serverul o face asupra datelor este descrisa direct de metoda HTTP

REST este o alta abordare a serviciilor web. Din punct de vedere tehnic, arhitectura de tip REST se descrie prin cateva notiuni de baza : resursa, URI, reprezentare, interfata uniforma. Legarea acestor componente intr-un mod cat mai eficient duce la crearea unei arhitecturi REST. O imagine de ansamblu asupra serviciilor de tip REST este prezentata in diagrama de mai jos: In REST totul este o resursa Intr-o arhitectura de tip REST totul este o resursa. Orice poate fi referit ca un obiect este o resursa. In general tot ce poate fi stocat in calculator si reprezentat ca un flux de octeti este o resursa. O resursa poate fi un obiect concret precum un mar sau un obiect abstract precum notiunea de curaj. Posibile resurse pot fi : Versiunea 1.0.3 a unui soft O harta a unei tari Urmatorul numar prim dupa 1024

30

URI

Numarul de cumparatori pentru un anumit produs O lista de bug-uri dintr-o baza de date

Ce anume defineste o resursa ? Fiecare resursa are asociat cate un URI. URI reprezinta numele si adresa unei resurse. URI este prescurtarea termenului englez Uniform Resource Identifier, un identificator alfanumeric univoc si unic pe lume al unei resurse din Internet, cum ar fi un document sau un site web. Deseori URI-ul unei resurse este identic cu URL-ul ei, URL fiind prescurtarea de la Uniform Resource Locator, o forma timpurie a identificatorului. Daca o anumita informatie nu are un URI atunci nu este o resursa si nu este practic pe Web. Un URI al unei resurse trebuie sa fie descriptive. Exemple de URI sunt prezentate mai jos: http://www.example.com/software/releases/1.0.3.tar.gz http://www.example.com/software/releases/latest.tar.gz http://www.example.com/weblog/2006/10/24/0 http://www.example.com/map/roads/USA/AR/Little_Rock http://www.example.com/wiki/Jellyfish http://www.example.com/search/Jellyfish http://www.example.com/nextprime/1024 http://www.example.com/next-5-primes/1024 http://www.example.com/sales/2004/Q4 http://www.example.com/relationships/Alice;Bob http://www.example.com/bugs/by-state/open O resursa poate avea mai multe URI . Numarul de vanzari ale unui produs se poate gasi si la URI http://www.example.com/sales/2004/Q4 dar in acelasi timp se poate gasi si la http://www.example.com/sales/Q42004. Interfata uniforma "Interfata uniforma" este principiul de baza al REST. In tot web-ul exista doar cateva operatii care se pot face asupra unei resurse. HTTP furnizeaza patru metode de baza ce descriu operatiile cele mai comune : Primirea unei reprezentatii a unei resurse : HTTP GET Crearea unei noi resurse HTTP PUT pentru un URI nou sau HTTP POST pentru un URI deja existent Modificarea unei resurse existente: HTTP PUT Stregerea unei resurse existente : HTTP DELETE

Toate aceste operatii sunt suficiente in realizarea unei arhitecturi de tip REST.

31

Asa cum am mai spus arhitectura REST este una fara constrangeri. Arhitectura fara constrangeri permite apeluri la functii, invocari de metode, apelul procedurilor la distanta, precum si alte mesaje care sunt intelese de catre un anumit server sau de catre un mic subset de componente din arhitectura. REST elimina ad-hoc mesaje si schimba radical axa de dezvoltare API spre definirea componentelor informationale care pot fi regasite si manipulate. In loc de a adauga in arhitectura apeluri speciale la functii sau interfete, servicii noi, adauga noi informatii care pot fi manipulate utilizand cereri standard. Un exemplu: in loc de o cerere de tipul "aprindeBec" la un obiect-server, putem folosi PUT "true" la obiectul http://exemplu.com/Bec/aprinde furnizat de catre server. Obiectul http://exemplu.com/Bec/aprinde poate raspunde, de asemenea, la o cerere de tip GET care va returna adevarat sau fals. POST este o cerere de tipul "adaugati informatii" care nu are sens pentru bec, de fapt nu are sens nici sa stergi un bec. Deci, aceste solicitari ar esua cu un raspuns care indica acest fapt. Reprezentari Asa cum rezulta si din titlu, intr-o arhitectura REST exista si notiunea de reprezentare. Resursele nu reprezinta date, ci reprezinta doar ideea creatorului de serviciu web despre cum sa structureze datele. Un server de web nu poate trimite o ide. Poate trimite un flux de octeti, intr-un format specific si intr-un limbaj specific. Astfel putem descrie o reprezentare a unei resurse. Legatura dintre o resursa, URI si reprezentarea resursei este prezentata in figura de mai jos:

Figura 13. Resursa, URI, Reprezentare -> REST

Am descris pana acum toate componentele unui stil arhitectural REST. Dar care este legatura intre acestea si de unde numele de REST? Diagrama de mai jos descrie modul in care se realizeaza un serviciu web de tip REST :

32

Figura 14. Interactiunea pentru un serviciu de tip REST

In imaginea de mai sus clientul refera o resursa web. Reprezentarea resursei este returnata (documentul .html). Reprezentarea plaseza clientul intr-o anumita stare. Apoi clientul acceseaza o alta resursa prin apasarea unui link din documentul Boein747.html. Reprezentarea acestei resurse plaseaza clientul intr-o alta stare. Ca urmare aplicatia client realizeaza un transfer de stari -> REST!. Comparatie REST vs SOAP Pentru a intelege si mai bine conceptul de REST vom face o comparatie intre arhitectura REST si arhitectura de tip RPC si in special protocolul SOAP. Asa cum am mai spus, un serviciu de tip REST foloseste 4 verbe HTTP: PUT, POST, GET, DELETE. Exemplu de utilizare a acestora pentru un serviciu web REST: GET /weatherforecast/02110 HTTP/1.1 Se obtine vremea dintr-o localitate

POST /weatherforecast HTTP/1.1 Se trimite catre server prognoza meteo sub format XML Un nou URI este creat

PUT /weatherforecast/95101 HTTP/1.1 Se actualizeaza o reprezentare a resursei deja existenta Se sterge reprezentarea resursei

- DELETE /weatherforecast/02110 HTTP/1.1 In contrast, un serviciu web ce foloseste SOAP are urmatorul exemplu de utilizare: - POST /weatherforecast.asmx HTTP/1.1 Se trimite un mesaj SOAP pentru a obtine vremea dintrun oras Se trimite un mesaj SOAP pentru a crea prognoza meteo pentru un oras

- POST /weatherforecast.asmx HTTP/1.1

33

Raspunsul este un mesaj SOAP

- POST /weatherforecast.asmx HTTP/1.1 Se trimite un alt mesaj SOAP pentru a actualiza prognoza meteo

- POST /weatherforecast.asmx HTTP/1.1 o Se trimite un alt tip de mesaj pentru a sterge prognoza meteo Se observa ca toate metodele HTTP folosite sunt POST. Operatia ce se executa asupra resursei se trimite in cadrul mesajului. In REST nu s-a dorit implementarea de alte protocoale, nu s-a dorit reinventarea rotii de aceea s-a folosit un protocol deja existent :HTTP si metodele sale in timp ce in arhitectura de tip RPC s-au creat protocoale precum XML-RPC sau SOAP. In SOAP informatia este in mesajul SOAP: POST /weatherforecast.asmx HTTP/1.1 <?xml version="1.0" encoding="UTF-8" standalone="no"?> <SOAP-ENV:Envelope xmlns:SOAPENV=" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> <SOAP-ENV:Body> <wns:getWeather xmlns:wns="urn:weather" SOAPENV: encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <zipCode xsi:type="xsd:string">02110</zipCode> </wns:getWeather> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Diferenta dintre REST si SOAP (reprezentantul arhitecturii RPC) este prezentata mai jos:

34

Figura 15 Servicii Web REST

Figura 16 Servicii Web RPC folosind SOAP

2.2.

Arhitectura orientata spre servicii

Conceptul de arhitectura orientata pe servicii a inceput sa se contureze recent si a avut o evolutie rapida, fiind adoptat in tot multe sisteme informatice in ultimii ani. Totusi, majoritatea ideilor care stau la baza arhitecturilor orientate pe servicii nu sunt neaparat noi: structurarea aplicatiilor in componente independente, care sa functioneze ca servicii, oferind anumite functionalitati, a fost introdusa cu peste 20 de ani in urma prin programarea orientata pe obiecte. De asemenea, comunicarea intre aplicatii/servicii, pe baza unui anumit protocol, a fost implementata prin mecanisme ca DCOM si CORBA inca de cand a inceput evolutia sistemelor distribuite. Arhitecturile orientate pe servicii au introdus insa si o serie de caracteristici noi, rezultate din experienta obtinuta cu aplicatiile traditionale pana la inceputul anilor 2000. O astfel de caracteristica este autonomia completa a unui serviciu fata de celelalte. In acest mod unitatile functionale create sunt responsabile doar pentru domeniul propriu, executand un set specific de functii in cadrul unei anumite entitati (care de obicei reprezinta unul dintre participantii la un proces comercial). Aceasta abordare are avantajul realizarii unei cuplari slabe intre componente, ceea ce permite o dezvoltare complet independenta a acestora. O alta caracteristica noua introdusa de arhitecturile orientate pe servicii este interoperabilitatea. Aceasta a fost de fapt principala motivatie care a dus la aparitia ideii de orientare pe servicii: la inceputul anilor 2000, companii ca Microsoft si IBM au sustinut adoptarea unui standard de comunicatie intre aplicatii/servicii (SOAP Simple Object Access Protocol), care sa fie independent de platforma pe care acestea au fost dezvoltate. Initiativa a fost cauzata de dezvoltarea rapida a aplicatiilor distribuite, atat in mediul comercial cat si in cel academic, ceea ce a dus la nevoia de standardiza modul de comunicare in medii eterogene. Astfel au aparut o serie de tehnologii noi, dintre care impactul cel mai important l-au avut serviciile web, dar s-a dezvoltat si conceptul abstract de arhitectura orientata pe servicii. Prezentam in continuare o definitie si un set de principii generale pentru arhitecturi orientate pe servicii. O SOA (Arhitectura Orientata pe Servicii) este o schema, un model de design unde un rol important il joaca incapsularea ideii de aplicatie in servicii care interactioneaza printr-un

35

protocol de comunicatie comun. Cand pentru stabilirea cadrului de comunicatie se folosesc servicii Web, acestea reprezinta implementarea bazata pe Web (Web-based) a unei arhitecturi orientate pe servicii. Arhitectura rezultata stabileste in esenta o paradigma de modelare in care fiecare serviciu Web este un bloc functional. Aceasta inseamna ca pentra a migra o arhitectura de aplicatii catre o SOA, principiile de design pentru servicii Web si tehnologiile aferente vr fi o componente importante din noul model. Un serviciu web este o interfata de comunicare oferita de un server, prin care clientii (programe aflate pe alte sisteme) pot solicita diverse informatii. Este o metoda prin care aplicatiile pot comunica intre ele prin mesaje asincrone sau prin apeluri de procedura la distanta (RPC: Remote Procedure Call). Dar acesta este doar un concept. Si pentru a nu sfarsi ca alte tehnologii care au pornit de la o idee buna dar s-au extins in tot mai multe directii fara a se focaliza catre anumite probleme centrale, a fost nevoie de un standard pe baza cariua sa se construiasca serviciile Web. Altfel zis un set de reguli care sa fie strict respectate de produsele dedicate acestei arii. Serviciile Web folosite in arhitecturi bazate pe servicii, trebuie sa se supuna principiilor SOA descrise in sectiunea urmatoare. Pentru a stabili clar ce inseamna o arhitectura bazata pe servicii, sa incepem prin a face distinctia dintre aceasta notiune si o aplicatie care foloseste servicii Web. Este destul de simpla adaugarea catorva servicii Web unei aplicatii. Aceasta integrarea limitata e folositoare ca exemplu didactic, sau pentru a completa o aplicatie existenta cu o functionalitate bazata pe servicii, care se preteaza scopului unui anumit proiect. Insa nu avem de-a face cu o arhitectura orientata pe servicii. Arhitectura SOA presupune asadar: un standard pentru expunerea si accesarea aplicatiilor sub forma de servicii ; infrastructura pentru comunicare si gestiunea serviciilor; un limbaj specializat pentru compunerea functionalitatilor simple in unele complexe care sa modeleze procese economice.

O SOA bazata pe servicii Web XML are la baza tehnologiile XML, axandu-se pe expunerea logicii de aplicatie existente ca servicii slab cuplate. In sprijinul acestui model, principiile SOA (principiile de orientare pe servicii) au in vedere reutilizarea, independenta de stare, autonomia, gradul sporit de abstractie, "descoperirea" serviciilor, cuplarea slaba a serviciilor si gradul in care se pot combina/compune. Folosirea principiilor SOA altereaza arhitectura multistrat existenta, adaugand un strat logic, prin folosirea unor interfete de de implementare(oferite de serviciile Web), stabilind astfel un punct comun de integrare a serviciilor. Acest nivel de integrare a serviciilor sta la baza noului model care poate fi extins dincolo de scopul unei singure aplicatii, pentru a unifica platforme diferite intr-un cadru interoperabil. Cand serviciile Web sunt si ele parte a infrastructurii, ele sunt folosite pentru integrarea aplicatiilor. Este important sa se inteleaga complexitatile de modelare pe care le introduce SOA. In platformele multistrat, cei care se ocupa de design trebuie sa constientizeze pe deplin faptul ca introducerea serviciilor va afecta datele si modelul economic existent.

36

In masura in care serviciile se diversifica, creste importanta securitatii si a scalabilitatii. Platformele orientate pe servicii vor trebui sa satisfaca aceste nevoi folosind o infrastructura adecvata, specifica fiecarei aplicatii. 2.2.1. Principiile SOA Ceea ce face ca serviciile Web pentru SOA sa difere de serviciile Web create pentru alte platforme de aplicatii distribuite, este faptul ca in primul caz, ele trebuie sa se supuna unor conventii. Mai jos sunt prezentate cateva principii ale orientarii pe servicii, care stabilesc un cadru distinct pentru dezvoltarea serviciilor Web intr-o SOA. Aplicarea acestor principii duce la standardizarea serviciilor Web, pastrandu-le slab cuplate: - Componentele reutilizabile sunt grupate in servicii distincte. Nu exista o limita teoretica intre logica componentei reprezentata de un serviciu. - Intre servicii exista un contract formal. Pentru ca serviciile sa interactioneze, ele trebuie sa fie conectate doar de un contract formal, care defineste termenii schimbului de informatii si orice descriere suplimentara a serviciilor. - Serviciile sunt slab cuplate. Serviciile trebuie sa interactioneze slab cuplat, si trebuie sa pastreze aceasta stare de cuplare slaba. Acest principiu e strans legat de abstractizarea si autonomia serviciilor. - Serviciile abstractizeaza logica de implementare. Singura parte a serviciului care este vizibila in exterior este ceea ce se expune prin descrierea serviciului. In afara acestei descrieri, natura si forma logicii interioare serviciului sunt invizibile si irelevante pentru celelalte servicii. - Serviciile se pot compune/integra. Acest lucru presupune ca logica de implementare a unui serviciu are mai multe nivele de granularitate si promoveaza reutilizarea si crearea straturilor de abstractizare. - Serviciile sunt autonome. Logica unui serviciu nu trebuie sa contina informatie de stare, deoarece poate micsora capacitatea serviciilor de a ramane slab cuplate. Serviciile trebuie sa maximizeze independenta de stare, chiar daca asta inseamna ca managementul starii sa fie rezolvat in alta parte. - Serviciile se pot descoperi. Serviciile trebuie sa permita descrierilor sa fie descoperite si intelese atat de oameni cat si de clienti softaware(service requestors). 2.2.2. Rolurile serviciilor Web intr-o SOA Serviciile Web pot avea diferite roluri, depinzand de scenariul de utilizare, contextul in care sunt vazute si starea curenta a programului pe care-l ruleaza. Un acelasi serviciu Web poate schimba rolurile, dar poate sa aiba si roluri multiple in acelasi timp. 1.Furnizorul de serviciu(service provider) - expune o interfata publica prin care se poate invoca acel serviciu de catre utilizatorii de serviciu. Furnizorul de serviciu promoveaza aceasta interfata publicand o descrierea a serviciului. Intr-un model clientserver, furnizorul de serviciu are rolul serverului. 2.Utilizatorul/consumatorul de serviciu(service requester) este cel care trimite un mesaj printr-un serviciu Web, sau un program care cere un anumit serviciu. Utilizatorul de serviciu joaca rolul de client in modelui client-server.

37

Serverele ofera o metoda prin care clientii pot solicita utilizarea unora dintre serviciile oferite de server. La baza, aceasta metoda poate corespunde unui apel de procedura la distanta, unui apel al unei metode a unui obiect sau transmiterii unor mesaje, insa, din punct de vedere al aplicatiei, ea reprezinta o modalitate de a accesa serviciul pus la dispozitie. Rolurile de server si client se pot interschimba pe parcursul executiei aplicatiilor. 3.Intermediarul(brokerul) este un serviciu Web care primeste un mesaj de la utilizatorul de serviciu si trimite mesajul catre furnizor, apoi poate intermedia si raspunsul de la furnizor catre utilizator. Intermediarii pot fi pasivi(ei doar ruteaza mesajele in sistem) sau activi(modifica headere de mesaje, dar nu si continutul util). 2.2.3. Interactiunea si compunerea serviciilor Componentele unei arhitecturi orientate pe servicii pot fi organizate dupa mai multe modele: Orchestrare: exista un proces central cu rol de coordonare explicita a serviciilor; acestea nu sunt consiente ca sunt implicate intr-un serviciu compus. Coregrafie: nu exista un coordonator central; fiecare serviciu web stie cand sa se execute si cu cine interactioneaza - efort colaborativ bazat pe sincronizare si schimbarea de mesaje. Acest concept e strans legat de acela de activitate(task). Activitate: modelele bazate pe schimb de mesaje stau la baza activitatilor serviciilor. O activitate presupune un grup de servicii Web care interactioneaza si colaboreaza pentru a realiza o functie sau un grup logic de functii. Diferenta dintre coregrafie si activitate consta in faptul ca, in general, o activitate este asociata unei anumite functii a aplicatiei. 2.2.4. Limbajul XML Popularitatea sistemului Internet a inceput sa creasca exploziv odata cu aparitia si dezvoltarea World Wide Web. Brusc o mare de informatie era disponibila folosind un browser web si o legatura la Internet. Fara continutul foarte variat insa interesul pentru World Wide Web ar fi fost mult mai redus; acest continut variat a si scos la iveala limitarile HTML. Numarul mare de editoare HTML(Hypertext Markup Language) si usurinta in folosire a permis multor oameni cu putine cunostinte tehnice sa publice continut pe web. Proliferarea site-urilor web personale cu continut variat este o dovada in plus ca HTML este un limbaj excelent pentru definirea prezentarii datelor. Totusi HTML nu este prea folositor atunci cand vine vorba de descrierea datelor. Odata cu maturizarea webului a devenit evident faptul ca este de dorit separarea prezentarii de continut. Acest lucru a permis unor specialisti cum ar fi artistii grafici sa se concentreze pe prezentare, iar alti specialisti cum sunt programatorii sa se concentreze pe crearea si manipularea datelor de continut. XML(Extensible Markup Language) a aparut ca un standard web pentru reprezentarea si transmiterea datelor pe Internet. XML este un metalimbaj generic, independent de platforma, de descriere a datelor. World Wide Web Consortium(W3C) a produs standarde pentru mai multe tehnologii legate de XML. XML este text structurat. Simplitatea XML este ceea ce il face atat de bun pentru multe scopuri. Textul este suportat de toate platformele de calcul. Deci daca se pot reprezenta

38

datele ca text utilizatorii oricarei alte platforme de calcul pot accesa datele fara conversii specializate dintr-un format in altul. 2.2.5. SOAP Simple Object Access Protocol (SOAP) este un protocol bazat pe XML, folosit pentru transmiterea informatiei in sisteme distribuite. Cuvantul simplu explica intentia creatorilor SOAP. Un mesaj SOAP s-a dorit a fi un document XML bine format, cu alte cuvinte text pur. SOAP a depasit proiectul initial si este considerat mai mult decat un protocol si anume un framework pentru schimbul mesajelor intre clienti si servicii web. Diferenta dintre un protocol si un framework poate fi observata daca ne gandim la protocolul HTTP care a revolutionat schimbul de date intre browsere si serverele web. HTTP este folosit la conectarea a milioane de oameni la web dar nu ofera o platforma pentru schimbul liber de date. SOAP rezolva acesta problema prin folosirea protocoalelor existente(ca HTTP, sau SMTP) pentru a permite mesajelor SOAP sa fie trimise ca parte a mesajelor acestor protocoale. Majoritatea retelelor au instalate o multitudine de firewall-uri, proxy-uri, si alte elemente de securitate pentru a bloca orice comunicatie inafara de datele HTTP. Din acest motiv, mesajele SOAP sunt trimise ca parte a mesajelor HTTP, intr-un proces numit transmiterea SOAP peste HTTP. Se presupune ca aplicatiile care comunica folosind SOAP trebuie sa verifice validitatea textului XML care contine mesajele SOAP. Deoarece pe drumul dintre client si serviciul web pot interveni si alte aplicatii numite intermediari, acestea pot lua decizii de prelucrare folosind informatia continuta in headerul mesajului SOAP. Folosind acest header optional, SOAP este un protocol extensibil. Un mesaj SOAP este alcatuit din 2 sectiuni obligatorii <Envelope> si <Body>, la care se poate adauga o sectiune optionala <Header>. Fiecare element din mesaj este prefixat de spatiul de nume soap: . Acest spatiu de nume este definit in elementul <Envelope> (plic) si se aplica tuturor elementelor continute in spatiul de nume SOAP. Spatiile de nume au un rol important in SOAP. Acestea sunt folosite pemtru a combate problemele de ambiguitate intre 2 sau mai multe documente XML impiedicand aparitia de elemente si atribute cu nume identice dar cu semnificatii diferite. Acest lucru este realizat prin prefixarea fiecarui element si atribut cu un sir de caractere asa cum este prefixul soap: folosit anterior(de exemplu <soap:Body>). Spatiile de nume ele insele sunt URI-uri arbitrare(pot fi si stringuri oarecare) care trebuie specificate cand se defineste o mapare(un alt nume mai scurt) pentru un spatiu de nume; exemplu: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope . Elementul <Envelope> este nodul radacina al documentului XML care reprezinta mesajul SOAP. Contine elementele <Header> si <Body> si este obligatoriu. Elementul <Header> este primul element fiu al elementului <Envelope> si este facultativ. Toti fii imediati ai elementului header se numesc inregistrari header sau headere. Elementul Header asigura o metoda generala de a adauga caracteristici noi unui mesaj SOAP intr-o maniera descentralizata fara o intelegere anterioara intre cei care comunica. Headerele permit extinderea informatiei despre un mesaj. Utilizarile tipice ale inregistrarilor header sunt: autentificare, managementul tranzactiilor etc.

39

Daca elementul <Envelope> nu contine elementul <Header> atunci elementul <Body> trebuie sa fie primul fiu imediat al elementului <Envelope>. Daca elementul <Header> este prezent atunci elementul <Body> trebuie sa urmeze imediat dupa acesta. Toti fii imediati ai elementului Body se numesc inregistrari body , si fiecare inregistrare este un element separat in cadrul lui Body. In contextul serviciilor web elementul body contine date specifice unui anumit apel de metoda, cum ar fi numele metodei, parametrii ei si valorile de return de dupa apel. 2.2.6. WSDL WSDL este un limbaj bazat pe XML care ofera un model pentru descrierea si definirea serviciilor web. WSDL defineste serviciile ca fiind o colectie de noduri in retea, sau porturi, care comunica intre ele prin mesaje. WSDL specifica un format XML pentru documentele ce contin definitia unui serviciu web. Definitia abstracta a porturilor si mesajelor este separata de utilizarea lor concreta, permitand reutilizarea acestor definitii. Un port este definit prin asocierea unei adrese de retea cu o legatura reutilizabila, iar o colectie de porturi definesc un serviciu. Mesajele sunt descrieri abstracte ale datelor care se transmit, iar tipurile porturilor sunt colectii abstracte de operatii suportate. Protocolul concret si specificatia formatului datelor pentru un anumit tip de port constituie o legatura reutilizabila, unde mesajele si operatiile sunt legate la un protocol de retea si la un format de mesaj concret. WSDL este folosit adesea in combinatie cu SOAP si cu XML Schema pentru a oferi servicii web in Internet. Un program client care se conecteaza la un serviciu web poate citi descrierea WSDL pentru a determina ce fel de functii sunt disponibile pe server. Orice tipuri speciale de date sunt incluse in WSDL folosind XML Schema. Un document WSDL este o lista de definitii. Intr-un document WSDL elementul radacina se numeste definitions. Acest element contine 5 fii imediati folositi pentru a defini un serviciu web. Urmatoarele 5 elemente apar in cadrul elementului definitions, intr-un fisier WSDL in ordinea specificata: - elementul <types> defineste tipurile de date folosite pentru schimbul de mesaje; - elementul <message> descrie mesajele folosite in comunicatie; - elementul <portType> identifica un set de operatii si mesajele atasate fiecareia dintre acestea; este de fapt o interfata a serviciului. - elementul <binding> specifica detaliile de protocol folosite de operatiile serviciului si descrie cum se traduce continutul abstract al acestor mesaje intr-un format concret; - elementul <service> grupeaza un set de port-uri corelate. Daca un serviciu web poate fi accesat folosind mai multe protocoale, atunci documentul WSDL pentru acel serviciu web va contine mai multe elemente port(in elementul service) fiecare referindu-se la un binding specific pentru un anumit protocol. De asemenea fiecare dintre elementele binding specifice unui protocol se va referi la randul lui la un anumit portType. Elementul portType respectiv se va referi la randul lui la un anumit set de elemente message input si output, care la randul lor se vor referi la tipuri definite de elementul types.

40

2.2.7. UDDI Initiativa UDDI (Universal Description, Discovery and Integration) este sustinuta de catre OASIS. UDDI este numele dat unui grup de registre din internet ce expun informatii legate de companii, organizatii sau alte entitati si de interfetele (API-urile) pe care acestea le pun la dispozitie. Registrele ruleaza pe asa numite Situri Operatoare si pot fi folosite de catre oricine pentru a publica sau gasi informatii legate de aceste entitati. Serviciile UDDI sunt independente de platforma bazandu-se pe standarde XML. Prin accesarea Siturilor Operatoare se pot cauta serviciile web puse la dispozitie de catre o anumita organizatie. Se doreste astfel creearea unui mecanism de descoperire a APIurilor existente pentru a interactiona cu serviciile de comert electronic ale organizatiei. Aceasta, la randul ei, are avantajul unei expunerii crescute in lumea comertului electronic. O inregistrare UDDI a unei organizatii contine urmatoarele 3 componente: - Pagini albe: adresa, informatii de contact, identificatori - Pagini aurii: categorizari industriale bazate taxonomii standard - Pagini verzi: informatii tehnice referitoare la serviciile expuse de catre organizatie UDDI a fost proiectat pentru a fi interogat prin intermediul mesajelor SOAP si pentru a asigura accesul la documente WSDL care sa descrie protocoalele si formatele de mesaje necesare pentru a interactiona cu serviciul web expus. 2.2.8. WSRF WSRF (Web Services Resource Framework) reprezinta o serie de specificatii pentru servicii web publicate de OASIS (Organization for the Advancement of Structured Information Standards este un consortiu global ce se ocupa cu dezvoltarea si adoptarea pe scara larga a standardelor pentru e-business si servicii web). La dezvoltarea acestor specificatii au mai contribuit Globus Alliance si IBM. O limitare serioasa a serviciilor web o constituie faptul ca acestea nu stocheaza in mod normal informatii legate de stare. Desigur, exista diferite modalitati de a depasi acest neajuns, cum ar fi salvarea explicita a acestor informatii si folosirea unor metode de identificare a sesiunii (in mod asemanator cu aplicatiile web). WSRF pune la dispozitie diferite specificatii pe care un serviciu web le poate implementa pentru a pastra informatiile de stare. In acest sens, clientii trebuie sa includa in cererea lor un identificator care sa descrie in mod unic o anumita resursa. Acest identificator poate varia de la un simplu sir de caractere URI pana la elemente XML complexe. Pe langa posibilitatea de a specifica o anumita resursa standardul permite si operatii de tipul get/set asupra proprietatiilor resursei. Asadar acestea pot fi folosite pentru a citi si respective scrie starea resursei. Acest model este in principal folosit de unelte de management pentru ca acestea sa poata vedea si lista resursele fara a avea alte informatii despre acestea. Un exemplu in acest sens este folosirea unui serviciu web pentru monitorizarea statusului altor serviciilor (WSDM - Web Services Distributed Management). Principalele componente ale acestei specificatii sunt:

41

- WS-Resource: defineste o resursa de serviciu web ca fiind perechea formata din resursa propriu-zisa si serviciul web prin care aceasta poate fi accesata. - WS-ResourceProperties: descrie o interfata folosita pentru asocierea unui set de valori avand tipurile specificate cu o resursa de serviciu web (WS-Resource). - WS-ResourceLifetime: reprezinta o interfata pentru managementul duratei de viata a unei resurse. - WS-BaseFaults. - WS-ServiceGroup: este o interfata pentru lucrul cu colectii de resurse WS-ResourceProperties O resursa este compusa din punctul de vedere al utilizatorului din mai multe proprietati (resource properties). De exemplu in figura anterioara fiecare WS-Resource are 3 proprietati (resource property): Fisier, Dimensiune si Descriptori. Ws-ResourceProperties specifica cum sunt definite si accesate resource property. Acestea sunt definite in fisierul WSDL. WS-ResourceLifecycle O resursa are ceea ce se numeste ciclu de viata. Cu alte cuvinte o resursa nu este o entitate statica care este creata atunci cand se porneste serverul si distrusa atunci cand acesta este oprit. Resursele pot fi create si distruse la orice moment de timp. Specificatia WS-ResourceLifecycle asigura niste mecanisme de baza pentru managementul ciclului de viata al resurselor. WS-RenewableReferences Odata ce un client dispune de referinta endpoint a unei WS-Resource, pot exista cazuri cand apare nevoia de a reinoi acea referinta daca devine invalida. Specifiatia WSRenewableReferences defineste mecanismele pentru a face acest lucru. WS-ServiceGroup Deseori este nevoie de managementul unor grupuri de servicii web sau grupuri de resurse WS-Resource si de a realiza operatii ca adaugarea unui serviciu la un grup, eliminarea unui serviciu dintr-un grup si, mai important, gasirea unui serviciu intr-un grup care indeplineste o anumita conditie. Specificatia WS-ServiceGroup defineste modalitatile prin care se poate realiza aceasta grupare. WS-BaseFaults Aceasta specificatie are rolul de a asigura o metoda standard de a returna erorile care pot apare in timpul invocarii unui serviciu web. Prezentam mai jos alte specificatii strans legate de WSRF. WS-Notification WS-Notification este o colectie de specificatii, care desi nu fac parte din WSRF, sunt in stransa legatura cu acesta. Aceasta specificatie permite serviciilor web sa fie configurate ca producator de notificari, si unor clienti sa fie consumatori de notificari(inscrisi). Aceasta inseamna ca daca apare o schimbare intr-un serviciu web (adica intr-una dintre WS-

42

Resources) se transmite o notificare tuturor consumatorilor inscrisi(nu toate schimbarile produc notificari ci doar cele dorite de producatorul serviciului web). WS-Addressing Aceasta specificatie ofera un mecanism de a adresa serviciile web mult mai flexibil decat simple URI-uri. Cel mai important este faptul ca se poate folosi WS-Addressing pentru a adresa un serviciu web + o resursa pereche( care formeaza o WS-Resource). 2.2.9. Arhitectura orientata pe servicii in sistemele Grid Avantajele arhitecturii orientate pe servicii au determinat adoptarea acesteia si in sistemele Grid, intr-un moment in care acest concept era inca nou. Orientarea pe servicii a fost o evolutie fata de primul model arhitectural al Grid-ului, propus de Ian Foster, Carl Kesselman si Steven Tuecke in [11]. Acest model implica existenta mai multor niveluri, aranjate in mod asemanator unei clepsidre: partea ingusta a clepsidrei corespunde unui set mic de protocoale si abstractii de baza; deasupra acesteia pot fi mapate o multime larga de comportamente, iar dedesubt pot exista tehnologii de nivel jos foarte diverse. De la acest model bazat pe protocoale s-a fact trecere la unul orientat pe servicii. Astfel, [12] descrie Grid-ul ca fiind un set extensibil de servicii care raspund la mesaje specifice protocoalelor. Serviciile Grid pot fi agregate pentru a indeplini cerintele organizatiilor virtuale. Acest model nou, denumit Arhitectura Deschisa pentru Servicii Grid (Open Grid Services Architecture OGSA), si-a propus sa alinieze tehnologiile Grid cu standardele serviciilor web. Astfel, se pot valorifica avantajele care rezulta din utilizarea limbajului WSDL (Web Services Description Language) si din separarea descrierii abstracte a interfetei pe care serviciul o ofera utilizatorilor, de specificarea concreta a adresei unde serviciul este disponibil si a modului in care acesta va comunica cu clientii. Printre aceste avantaje mentionam generarea automata a codului pentru client si pentru server pornind de la descrierea WSDL, posibilitatea de a descoperi servicii prin intermediul cataloagelor publice, asocierea descrierii serviciilor cu protocoale de retea interoperabile, compatibilitatea cu servicii de nivel mai inalt [12]. Modelul OGSA a a fost implementat in Globus Toolkit versiunea 3. OGSA descrie mecanisme standard pentru crearea, denumirea si descoperirea instantelor de servicii Grid. In acest model, resursele computationale, legaturile de retea, resursele de stocare, bazele de date etc. sunt reprezentate de servicii; un serviciu poate fi definit ca o entitate care ofera anumite capabilitati, comunicand cu clientii prin intermedil retelei. Perspectiva orientata pe servicii simplifica virtualizarea (incapsularea diverselor implementari in spatele unei interfete comune) si raspunde la nevoia de a avea mecanisme standard de definire a interfetelor. In 2003, [13] introduce un prim set de specificatii pentru conceptele OGSA, denumit Infrastructura Deschisa pentru Servicii Grid (Open Grid Service Infrastructure OGSI). Autorii au definit modalitati pentru crearea, denumirea si gestionarea instantelor de servicii, pentru declararea si inspectarea datelor de stare ale serviciilor, pentru notificarea in cazul schimbarii starii etc. Definitiile sunt date ca tipuri WSDL, si pot fi combinate pentru a crea servicii Grid complexe. Versiunea urmatoare a Globus Toolkit (GT4) are in continuare la baza arhitectura orientata pe servicii, dar a adoptat o paradigma noua pentru dezvoltarea serviciilor Grid: Web

43

Services Resource Framework (WSRF). Noua abordare ofera o compatibilitate mai buna cu instrumentele existente pentru dezvoltarea serviciilor web, inclusiv cele comerciale. Globus Toolkit nu este singurul middleware pentru Grid in care s-a adoptat arhitectura orientata pe servicii. Un alt exemplu este Condor, un instrument pentru planificare de aplicatii si pentru gestiunea resurselor utilizat pe scara larga de mai mult de 20 de ani. La Condor a fost adaugata recent un modul numit BirdBath, care expune o parte din functionalitatile instrumentului ca servicii web. Arhitectura orientata pe servicii a fost introdusa si in instrumentele de planificare comerciale, cum ar fi Tivoli Dynamic Workload Broker de la IBM. 2.3. Web-ul semantic

OWL Web Ontology Language a fost creat pentru a fi folosit atunci cand informatiile continute in diverse documente trebuie sa fie procesate de aplicatii software, si nu doar prezentata in diverse forme utilizatorului. OWL poate fi folosit pentru a reprezenta intelesul termenilor dintr-un vocabular, percum si relatiile intre acesti termeni. Reprezentarea termenilor si a relatiilor dintre ei se numeste o ontologie. OWL ofera mai multe facilitati pentru exprimarea sensurilor si a semanticii decat XML, RDF si RDF-S, rezultand inalta abilitate a acestui limbaj de a reprezenta pe Web continut interpretabil de o aplicatie. OWL este o revizuire a primului limbaj semantic numit DAML+OIL, lansat in 2000, si incorporeaza invatamintele trase din designul si aplicarea acestuia. De ce a aparut OWL ? Din cauza abundentei informatiilor de pe Web, viitorul acestuia este strans legat de asocierea informatiilor cu un sens explicit, facand astfel mai usor procesul de precesare si integrare automata a informatiilor disponibile pe Web. Acest Web al viitorului se numeste Semantic Web si este bazat pe abilitatea de a defini scheme de marcare customizate folosind XML si pe modalitatea flexibila reprezentare a datelor oferita de RDF. Primul lucru care este necesar pentru Semantic Web este un limbaj al ontologiilor (de definire a ontologiilor) care sa poata descrie formal sensul terminilogiei (informatiilor) folosite in cadrul documentelor Web. Pentru ca o aplicatie sa poata intelege aceste documente este necesar un limbaj mai puternic decat RDF Schema. Un exemplu demonstreaza clar utilitatea unui astfel de limbaj. Pe Web exista o gramada de site-uri ce prezinta spre comercializare diverse sortimente de vin. Sa presupunem ca dorim sa realizam o aplicatie care sa ne furnizeze o lista de vinuri sau o cautare a unui sortiment de vin. In acest moment, o astfel de aplicatie este foarte greu de realizat. Pentru a facilita realizarea unei astfel de aplicatii, nu este suficienta efectuarea unei cautari folosind niste cuvinte cheie, ci este necesara specificarea sensurilor (intelesurilor) resurselor descrise de un document (pagina) Web. Acest strat suplimentar capteaza semantica informatiilor prezente intr-un document. OWL este un limbaj pesntru definirea si instantierea ontologiilor Web. Termenul ontologie a fost preluat din filosofie si se refera la stiinta descrierii entitatilor ce alcatuiesc lumea si a legaturilor dintre ele. O ontologie OWL poate include descriptori de clase, proprietati si instante ale acestora. Fiind data o astfel de ontologie, semantica formala a OWL specifica cum se deriva consecintele logice, de exemplu fapte care nu sunt specificate literal in ontologie, dar sunt determinate de semantica.

44

Oare pentru a rezolva problemele evidentiante anterior era neaparat necesar un alt standard XML/Web ? Nu erau suficiente XML si XML Schema ? Exista doua raspunsuri la aceste intrebari: - O ontologie difera de o schema XML prin faptul ca este o reprezentare a cunostintelor, nu un format de mesaj. Majoritatea standardelor Web sunt compuse dintr-o combinatie de formate de mesaje si specificatii ale protocoalelor. Aceste formate au o semantica operationala; dar specificatia nu a fost gandita pentru a suporta gandire in afara contextului tranzactie. De exemplu, cand se primeste un mesaj de efectuare a unei tranzactii, se transfera o suma de bani din contul cumparatorului in cel al vanzatorului si se livreaza produsul cumparat, dar nu exista nici un mecanism prin care sa concluzionam ca daca produsul este un Chardonnaz, atunci el este, de asemenea, un vin alb. - Un avantaj al ontologiilor OWL va fi existenta unor unelte ce vor putea sa gandeasca pe baza ontologiilor. Aceste unelte vor oferi suport generic, ce nu este specific nici unui domeniu particular, ceea ce nu s-ar putea putea face daca s-ar defini pentru fiecare domeniu, scheme XML specifice acestuia. 2.3.1. Sintaxa OWL Inainte de a trece la discutia propriu-zisa despre sintaxa OWL, trebuie mentionat ca limbajul OWL ofera trei sublimbaje, ce ofera diferite facilitati conforme cu nevoile comunitatilor specifice de implementatori si utilizatori: - OWL Lite este cel mai simplu dintre cele trei sublimbaje, si a fost creat pentru a fi folosit de catre acei utilizatori ce au nevoie, in principal, de o ierarhie de clasificare si constrangeri simple. De exemplu, desi suporta constrangeri de cardinalitate, OWL Lite permite pentru cardinalitate numai valorile de 0 si 1. De asemenea, uneltele folosite sunt mai simplu de dezvoltat si mai ieftine si se ofera o modalitate usoara de migrare catre OWL Lite a diverselor taxonomii existente. - OWL DL destinat utilizatorilor care vor expresivitate maxima fara pierderea completitudinii (toate determinarile sunt calculate garantat) si decidabilitatii (toate calculele dureaza un timp finit) computationale ale sistemelor de inferente. Acest sublimbaj include toate elementele de limbaj OWL cu restrictii precum separarea tipurilor (o clasa nu poate fi in acelasi timp si o instanta sau o proprietate, o proprietate nu poate fi si instanta sau clasa). Numele acestui sublimbaj provine de la descriptive logics (DL), domeniu in care se studiaza logica cu predicate de ordinul I, ce sunt decidabile. De asemenea, OWL DL suporta limbajele comerciale ce folosesc logica descriptiva. - OWL Full este indicat utilizatorilor ce cauta exprisivitate maxima si libertatea sintactica a RDF, dar fara garantii computationale. De exemplu, o clasa poate fi tratata ca o colectie de instante sau ca o instanta in sine. Este improbabil sa existe un software de inferente care sa suporte toate facilitatile lui OWL Full. OWL DL este o extensie a OWL Lite, iar OWL Full este o extensie a OWL DL. Alegerea intre cele trei sublimbaje depinde de necesitatile utilizatorului, fiind vorba de o alegere intre performante mai bune sau un limbaj mai puternic (mai dezvoltat). Desi e decidabil, OWL DL ofera rezultate proaste in cazul cel mai defavorabil, dar ofera restrictii expresive mai puternice. OWL Full este ales in loc de OWL DL cand se doreste ca OWL sa suporte facilitatile de meta-modelare oferite de RDF Schema (de exemplu, definirea claselor de clase).

45

OWL fiind o extensie a vocabularului RDF, sintaxa OWL este compatibila cu sintaxa RDF/XML. Astfel, o ontologie OWL este un graf RDF [9], care la randul sau este un set de tripleti RDF. Ca orice graf RDF, si o ontologie OWL poate fi scrisa in diverse forme sintactice [10]. Orice forma sintactica aleasa pentru reprezentarea unei ontologii este valida, atata timp cat rezulta acelasi set de tripleti. De exemplu, urmatoarele reprezentari au acelasi inteles, deoarece codifica acelasi set de tripleti RDF:
<owl:Class rdf:ID="Continent"/>

si
<rdf:Description rdf:about="#Continent"> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#Class"/> </rdf:Description>

In continuare, este prezentat un scurt exemplu de definire a unei ontologii folosind OWL, folosit ulterior pentru a explica elementele de sintaxa de baza:
<?xml version="1.0" encoding="UTF-8" ?> <rdf:RDF xmlns=http://www.example.com/owl# xmlns:othex="http://www.otherexample.com/owl#" xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns# xmlns:rdfs=http://www.w3.org/2000/01/rdf-schema# xmlns:owl=http://www.w3.org/2002/07/owl#>

<owl:Ontology rdf:about=""> <rdfs:comment> Exemplu de ontologie definita folosind OWL. Aici se poate definitia DAML de la care s-a pornit, daca exista asa ceva. </rdfs:comment> <rdfs:label>Bird Ontology</rdfs:label> <owl:imports rdf:resource=" http://www.otherexample.com/owl"/> </owl:Ontology> specifica

<owl:Class rdf:ID="OrganicThing" />

<owl:Class rdf:ID="AnorganicThing"> <owl:complementOf rdf:resource="#OrganicThing " /> </owl:Class> <owl:Class rdf:ID="Animal"> <rdfs:subClassOf rdf:resource="#OrganicThing" /> </owl:Class>

46

<owl:Class rdf:ID="Plant"> <rdfs:subClassOf rdf:resource="#OrganicThing" /> <owl:disjointWith rdf:resource="#Animal" /> </owl:Class>

<owl:ObjectProperty rdf:ID="hasMaker"> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#FunctionalProperty" /> </owl:ObjectProperty> <owl:Class rdf:ID="Continent" />

<owl:ObjectProperty rdf:ID="livesInContinent"> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl/#TransitiveProperty" /> <rdfs:domain rdf:resource="#Bird" /> <rdfs:range rdf:resource="#Continent" /> </owl:ObjectProperty>

<owl:Class rdf:ID="Bird"> <rdfs:subClassOf rdf:resource="#Animal" /> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#canFly" /> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger"> 1 </owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#livesInContinent"/> <owl:someValuesFrom rdf:resource="#Continent"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:label xml:lang="en">bird</rdfs:label> <rdfs:label xml:lang="fr">oiseau</rdfs:label> </owl:Class>

47

<owl:Class rdf:ID="Fish"> <rdfs:subClassOf rdf:resource="#Animal" /> </owl:Class>

<owl:Class rdf:ID="Mamel"> <rdfs:subClassOf rdf:resource="#Animal" /> </owl:Class> <Continent rdf:ID="Europe" /> <Continent rdf:ID="Africa" /> <Continent rdf:ID="Asia" /> <Continent rdf:ID="NorthAmerica" /> <Continent rdf:ID="SouthAmerica" /> <Continent rdf:ID="Australia" /> <Continent rdf:ID="Antarctica" />

<Bird rdf:ID="ImperialPenguin"> <livesInContinent rdf:resource="#Antarctica" /> <canFly rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">0</canFly> </Bird>

<Bird rdf:ID="Vulture"> <owl:differentFrom rdf:resource="#ImperialPenguin"/> <livesInContinent rdf:resource="#NorthAmerica" /> <canFly rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</canFly> </Bird>

</rdf:RDF>

Cum OWL face parte din eforturile pentru dezvoltarea Web-ului Semantic, iar acesta este inerent distribuit, OWL trebuie sa permita ca informatia sa poate fi adunata de la diverse surse. Astfel, ontologiile pot fi legate intre ele, inclusiv prin importarea informatiilor din alte ontologii. a. Spatiile de nume Primul spatiu de nume este cel asociat ontologiei declarate in acest exemplu. Apoi este un spatiu de nume, al unei alte ontologii, care este folosita (poate fi folosita) in definirea ontologiei exemplu. Al treilea spatiu de nume specifica calea catre vocabularul definit de

48

OWL, aflat la http://www.w3.org/2002/07/owl#. Aceasta declaratie trebuie inclusa in toate definitiile de ontologii. Ultimele spatii de nume sunt cele catre vocabularele RDF si RDFS, deoarece OWL depinde de aceastea. Alt spatiu de nume folosit foarte des in definirea ontologiilor este cel catre XML-Schema, dar, in exemplul de sus, desi este folosit nu este declarat un prefix pentru el. b. Header-ul ontologiei Dupa stabilirea spatiilor de nume, de obicei, se include un tag owl:Ontology ce contine informatii despre ontologia definita, putandu-se specifica comentarii, numarul de versiune, precum si includerea altor ontologii in definirea celei curente. In cadrul acestui tag se afla alte tag-uri ce colecteaza metadate despre document. Printre aceste tag-uri se afla: rdf:about unde se specifica numele sau referinta ontologiei, rdfs:comment, owl:priorVersion, owl:imports ce specifica alte ontologii de care este dependenta ontologia definita, si rdfs:label unde se poate da un nume in limbaj natural ontologiei. c. Definirea claselor simple cu nume OWL are o clasa de baza, numita owl:Thing, si orice superclasa definita de utilizator este o subclasa a acesteia. De asemenea, exista si clasa vida owl:Nothing. Definirea unei superclase cu nume se face asignand atributului rdf:ID numele clasei, conform exemplului urmator:
<owl:Class rdf:ID="OrganicThing" />

Definirea unei clase poate fi facuta incremental, precum si distribuita. Odata definita o clasa cu nume, alte definitii de ontologii pot referi aceasta clasa prin URI#className. Pentru a crea o subclasa, se foloseste constructorul rdfs:subClassOf, dupa cum se poate vedea mai jos:
<owl:Class rdf:ID="Animal"> <rdfs:subClassOf rdf:resource="#OrganicThing" /> </owl:Class>

Tag-ul rdfs:label poate fi folosit pentru a atribui un nume in limbaj natural clasei definite. Numele poate diferi in functie de limba folosind atributul lang. d. Definirea indivizilor (instantelor) Un individ este introdus declarandu-l ca fiind membrul unei clase (apartinand unei clase) astfel (aceasta este varianta minimala, pentru o clasa fara atribute):
<Continent rdf:ID="Europe" />

Aceasta constructie este echivalenta cu urmatoarele:

<owl:Thing rdf:ID="Europe" />

<owl:Thing rdf:about="#Europe"> <rdf:type rdf:resource="#Continent"/>

49

</owl:Thing>

In exemplul de mai sus, intai se defineste o clasa cu nume, iar apoi se modifica tipul acesteia folosind rdf:about si tag-ul rdf:type. e. Definirea proprietatilor simple Clasele si indivizii permit numai definirea taxonomiilor. Proprietatile sunt cele ce ne permit sa inferam fapte generice despre toti membrii unei clase si faate dpecifice despre fiecare individ in parte. O proprietate este o relatie binara si se disting doua tipuri de proprietati: - proprietati tip de date care sunt relatii intre instantele unei clase si literali RDF sau tipuri de date definite in XML Schema. - proprietati obiectuale care sunt relatii intre instantele a doua clase. O proprietate poate fi restrictionata specificand domeniul de definire si cel de valori pentru care este valida. Acest lucru se face precum in exemplul urmator:
<owl:ObjectProperty rdf:ID="livesInContinent"> <rdfs:domain rdf:resource="#Bird" /> <rdfs:range rdf:resource="#Continent" /> </owl:ObjectProperty>

Precum clasele, si proprietatile pot fi ierarhizate, modificand domeniul de definire sau cel de valori, folosind tag-ul rdfs:subPropertyOf in definitia subproprietatii. f. Clase anonime OWL permite definirea claselor anonime (fara nume). De exemplu, mai jos se defineste o clasa anonima, ce restrictioneaza definirea clasei Bird:
<owl:Class rdf:ID="Bird"> <rdfs:subClassOf rdf:resource="#Animal" /> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#canFly" /> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger"> 1 </owl:cardinality> </owl:Restriction> </rdfs:subClassOf>

g. Mai multe despre proprietati La definirea indivizilor proprietatile clasei trebuie instantiate (exemple in cod). In plus, proprietatile pot avea urmatoarele tipuri: - proprietati tranzitive: P(x,y) and P(y,z) implies P(x,z)

50

- proprietati simetrice: P(x,y) daca P(y,x) - proprietati functionale: P(x,y) si P(x,z) implica y = z - proprietati inversOf: P1(x,y) daca P2(y,x) Proprietatile pot fi restrictionate si mai mult folosind cardinalitatea, precum si tag-urile allValuesFrom, someValuesFrom. Tag-ul hasValue poate obliga toate instantele unei clase sa aiba aceasi valoare pentru o proprietate. h. Mai multe despre clase OWL DL este foarte puternic in definirea claselor, putandu-se defini clase complexe ca reunini, intersectii sau complemente ale altor clase. g.Tipurile de date OWL foloseste tipurile de date definite in XML Schema, precum si rdfs:Literal. 2.3.2. Cazuri de utilizare Folosirea ontologiilor va imbunatati aplicatiile web existente si va largi gama activitatilor desfasurate pe Web. OWL a fost creat special pentru indeplinirea acestor obiective. In continuare, sunt prezentate cinci exemple de utilizare. a. Portal web Un portal web este un site web ce prezinta diverse informatii despre un domeniu de interes specific, permitand utilizatorilor interesati primirea de stiri, schimbarea de opinii, construirea unei comunitati si legarea de alte resurse web de interes comun. Pentru ca un portal sa aiba succes, cel mai important lucru este gasirea unui continut interesant. Aceste informatii sunt, de obicei, postate, de utilizatori. Pentru ca aceste informatii sa fie bine structurate si usor de minat, este foarte utila definirea unei ontologii pentru acea comunitate. Inferentele oferite de ontologie permit o cautare mult mai exacta decat minarea textelor bazata numai pe cuvinte cheie. Un exemplu de astfel de portal este OntoWeb, ce serveste comunitatii interesate de cercetarea in domeniul ontologiilor. Alte exemple de portale dezvoltate folosind OWL: AIFB SEmantic PortAL al Universitatii din Karlsruhe si AKT Portal al Universitatii din Southampton. b. Colectii multimedia Ontologiile se pot dovedi foarte folositoare in a pastra continut semantic despre imagini, audio sau alte obiecte netextuale, intrucat aceste obiecte sunt de obicei indexate dupa metataguri spre a oferi un inteles despre continutul lor. Aceste ontologii se pot imparti in doua categorii: specifice formatului media sau specifice continutului. A doua categorie este mult mai interesanta, pentru ca este independenta de format. c. Managementul site-urilor web ale corporatiilor Corporatiile au adesea site-uri web cu o multitudine de pagini, majoritatea pentru utilizare interna de catre angajatii acestora. Pentru o mai buna utilizare a informatiei de pe aceste pagini nu este suficienta o taxonomie, ci ar fi mult mai utila folosirea unei suite de ontologii specifice fiecarui tip de utilizator (fiecarui rol), ontologii ce pot fi dependente intre ele.

51

Managementul si cautarea informatiilor folosind ontologii ar deveni mult mai usoare si mai flexibile. d. Crearea documentatiilor Ontologiile pot fi folosite cu succes si pentru descrierea documentatiilor create pentru un anumit domeniu, in special in inginerie. Documentele pot fi de mai multe tipuri, fiecare tip fiind destinat unei anumite categorii de utilizatori. Ontologiile pot fi folosite pentru a construi un model informational care sa permite o cautare in spatiul informatiilor reprezentate dupa articole, legaturi intre articole, alte documente care sunt necesare sau utile. Folosind inferentele si constrangerile de care dispune OWL, se pot cauta articole care indeplinesc anumite conditii (de exemplu daca folosesc o piesa de anumite dimensiuni, atunci am constrangeri ale celorlalte piese folosite). e. Agenti si servicii web Web-ul semantic poate oferi agenti web cu capabilitatea de a intelege si de a integra informatii preluate din diverse surse. Un exemplu poate fi un agent ce planifica activitatile din timpul liber. Aceasta planificare depinde de sursele informationale si de preferintele utilizatorului. Pentru aceasta trebuie sa existe ontologii care sa descrie termeni precum hoteluri, restaurante, cinematografe, etc. Astfel de informatii pot fi preluate din diverse surse, precum portaluri, site-uri de rezervare, etc. Un astfel de exemplu este AgentCities, care ofera o serie de servicii business to customer precum hoteluri, restaurante, cinematografe, clasificate in functieorasul in care sunt disponibile. Ontologiile pot fi folosite in orice domeniu unde este necesara adaugarea de sensuri informatiilor pastrate. De aceea, OWL va fi folosit in special pentru prezentarea si cautarea informatiilor. Permitand distribuirea surselor de informatii, OWL este cu atat mai puternic cu cat permite si definirea constrangerilor de integritate a informatiilor. Un alt exemplu de utilizare a OWL este Swoogle, un motor de cautare pentru documente apartinand web-ului semantic, inclusiv ontologii, construit de Universitatea din Maryland. In continuare voi prezenta doua exemple didactice de ontologii, plus niste link-uri catre niste exemple de ontologii folosite in viata reala, dar care sunt mult prea stufoase pentru a fi folosite in aceasta prezentare. Exemplul 1 este foarte simplu si defineste clasa Airport acesteia.
<rdf:RDF xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:owl="http://www.w3.org/2002/07/owl#" xml:base="http://www.daml.org/2001/10/html/airport-ont">

si niste proprietati asociate

<owl:Ontology rdf:about=""> <owl:versionInfo>$Id: $</owl:versionInfo> airport-ont.daml,v 1.1 2002/03/14 06:24:16 mdean Exp

<rdfs:comment>Airport</rdfs:comment>

52

</owl:Ontology>

<rdfs:Class rdf:ID="Airport"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#name"/> <owl:allValuesFrom rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#iataCode"/> <owl:allValuesFrom rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#icaoCode"/> <owl:allValuesFrom rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#location"/> <owl:allValuesFrom rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#latitude"/> <owl:allValuesFrom rdf:resource="http://www.w3.org/2001/XMLSchema#double"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction>

53

<owl:onProperty rdf:resource="#longitude"/> <owl:allValuesFrom rdf:resource="http://www.w3.org/2001/XMLSchema#double"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#elevation"/> <owl:allValuesFrom rdf:resource="http://www.w3.org/2001/XMLSchema#double"/> </owl:Restriction> </rdfs:subClassOf> </rdfs:Class>

<owl:DatatypeProperty rdf:ID="elevation"/> <owl:DatatypeProperty rdf:ID="iataCode"/> <owl:DatatypeProperty rdf:ID="icaoCode"/> <owl:DatatypeProperty rdf:ID="latitude"/> <owl:DatatypeProperty rdf:ID="location"/> <owl:DatatypeProperty rdf:ID="longitude"/> <owl:DatatypeProperty rdf:ID="name"/>

</rdf:RDF>

Exemplul 2 defineste clasa Person, cu subclasele Man si Woman, pecum si proprietatile isWifeOf, isHusbandOf. Intrucat foloseste elementul disjointWith acest exemplu este scris in OWL DL.
<rdf:RDF xmlns=http://owl.protege.stanford.edu# xmlns:protege=http://protege.stanford.edu/plugins/owl/protege# xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns# xmlns:rdfs=http://www.w3.org/2000/01/rdf-schema# xmlns:owl=http://www.w3.org/2002/07/owl#>

<owl:Ontology rdf:about=""> <owl:imports rdf:resource="http://protege.stanford.edu/plugins/owl/protege"/> </owl:Ontology>

<owl:Class rdf:ID="Person"/> <owl:Class rdf:ID="Man">

54

<rdfs:subClassOf

rdf:resource="#Person"/>

<owl:disjointWith> <owl:Class rdf:about="#Woman"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:ID="Woman"> <owl:disjointWith rdf:resource="#Man"/> <rdfs:subClassOf rdf:resource="#Person"/> </owl:Class>

<owl:ObjectProperty rdf:ID="isHusbandOf" rdf:type="http://www.w3.org/2002/07/owl#FunctionalProperty"> <rdfs:domain rdf:resource="#Man"/> <rdfs:range rdf:resource="#Woman"/> <owl:inverseOf <owl:minCardinality>0</owl:minCardinality> <owl:maxCardinality>1</owl:maxCardinality> </owl:ObjectProperty> rdf:resource="#isWifeOf"/>

<owl:ObjectProperty rdf:ID="isWifeOf" rdf:type="http://www.w3.org/2002/07/owl#FunctionalProperty"> <rdfs:domain rdf:resource="#Woman"/> <rdfs:range rdf:resource="#Man"/> <owl:inverseOf rdf:resource="#isHusbandOf"/>

<owl:minCardinality>0</owl:minCardinality> <owl:maxCardinality>1</owl:maxCardinality> </owl:ObjectProperty>

</rdf:RDF>

2.3.3. Concluzii Web semantic Web-ul semantic devine tot mai necesar din cauza abundentei de informatii aflate pe Web, informatii din domenii diverse. Daca se doreste ordine in informatie, atunci definirea unei ontologii este neaparat necesara. In acest fel, se poate asocia sens unei bucati de text sau de media. Fiind gandit ca un limbaj distribuit, in care definirea ontologiilor poate fi facuta in diverse locuri, OWL este va sta la baza Web-ului semantic. Permitand definirea de constrangeri informationale si modelarea informatiilor pe baza de clase si proprietati, OWL este un standard Web care are sanse mari de reusita.

55

Fiind inca la inceput, OWL este folosit, in mare parte parte, de mediul academic si de cercetare. Succesul sau va depinde insa si de parerea marilor concerne din domeniul IT. Daca va fi sustinut de un astfel de concern are sanse mari de reusita, altfel va ramane doar un standard reusit. Pentru a dezvolta ontologii folosind OWL exista o gama larga de instrumente, atat comerciale, cat si gratis, care ofera facilitati diverse, de la editare vizuala pana la verificare automata a corectitudinii sintactice si semantice a otologiilor generate. Desi pare greoi de inteles, OWL este logic, iar pentru un programator obisnuit sa lucreze orientat pe obiecte este chiar usor de utilizat. Posibilitatea de includere ale altor definitii, clasele si instantele sunt toate cunoscute acestuia. 2.4. Potential de inovare

Datorita faptului ca definitia e-Guvernarii este foarte vasta si implica folosirea oricaror tehnologii informatice si de telecomunicatii pentru imbunatatirea serviciilor administratiei publice, inclusiv a implicarii si participarii active a cetatenilor la procesul de guvernare, exista un potential imens de inovare din foarte multe de vedere. Cum tehnologiile IT&C sunt in permanenta dezvoltare, si guvernarea electronica trebuie sa tina pasul cu acestea si sa le foloseasca eficient, atat in folosul cetatenilor, cit si in folosul functionarilor publici. De aceea, in cadrul acestei sectiuni sunt prezentate doar directiile principale de evolutie ale e-Guvernarii in urmatoarea perioada, pentru a tine pasul cu ultimele avansuri tehnologice si cu asteptarile utilizatorilor. 2.4.1. Noi capabilitati ale serviciilor publice electronice Probabil cel mai important avantaj adus de catre serviciile de e-Guvernare, il reprezinta deschiderea si transparenta in serviciile de administratie publica oferite cetateanului. Din acest punct de vedere, toate tehnologiile care sprijina e-participarea si e-implicarea cetatenilor in guvernare vor fi din ce in ce mai utilizate in viitorul apropiat: retele sociale, forumuri de discutii moderate de oficiali, wiki-uri colaborative, propunerea de e-petitii de catre e-cetateni si posibilitatea votarii/semnarii acestor e-petitii de catre alte persoane pentru a ajunge sa fie discutate de administratia publica. In general, toate tehnoogiile Web2.0 si cele ce vor permite si implica cetatenii in diverse forme de dezbatere cu exprimarea acordurilor si dezacordurilor, vor fi folosite pentru a ajunge la ceea ce se numeste e-democratie. Un alt aspect important pe care serviciile publice electronice il vor aduce este reprezentat de posibilitatea de definire si monitorizare stricta a fluxurilor de activitati. Astfel, se pot aduce imbunatatiri chiar in productivitatea procesului legislativ prin urmaririrea si modificarea acelor activitati care sunt deficiente sau introduc latente. 2.4.2. Dezvoltarea interactiunii cu utilizatorii Interactiunea cu utilizatorii a serviciilor publice electronice reprezinta un capitol important pentru a asigura usurinta navigarii, posibilitatea de acces la servicii in conditii cat mai variate si a creste satisfactia clientilor. Din acest punct de vedere, un prim aspect care trebuie luat in considerare datorita avansului tehnologic este acela al accesibilitatii serviciilor publice in retelele si pe echipamentele mobile (precum telefoane mobile, tablete mobile, PDA, etc.) Odata cu transformarea Web-ului spre acceptarea acestor noi modalitati de interactiune, si serviciile publice trebuie sa urmeze aceeasi evolutie pentru a

56

fi cat mai utile clientilor sai. Legat de acest aspect, trebuie avute in vedere si noile forme de interactiune ce sunt datorate atat tehnologiilor mobile, dar si avansului din alte domenii: tehnologii colaborative, prelucrarea limbajului natural. Astfel, serviciile de e-Guvernare trebuie sa se orienteze spre a folosi noile dezvoltari cauzate de Web-ul social si de avansul din regasirea informatiei si mineritul textelor (cautari inteligente, etc.) Un alt aspect important din aceasta categorie il reprezinta standardizarea serviciilor publice electronice, a accesului la aceste servicii, a modului de interactiune cu serviciile, precum si a datelor interschimbate intre servicii si utilizatori. Relevant din acest punct de vedere este ideea aparitiei punctelor unice de acces (one-stop shop), care sa permita accesul la toate serviciile publice din acelasi loc, folosind aceleasi date de autentificare si urmarind aceleasi produri si aceiasi pasi. Toate serviciile publice, trebuie sa beneficieze de modularitate si adaptabilitate pentru a putea atinge al cincilea nivel de sofisticare definit de CE si sa devina servicii proactive, complet automatizabile, care sa permita si personalizarea serviciilor pentru fiecare tip de utilizator. Un aspect oarecum legat de personalizare, dar mai avansat, il reprezinta accesibilitatea serviciilor publice electronice, in special pentru persoanele cu dizabilitati de vedere. In interactiunea cu utilizatorii nu trebuie neglijat nici aspectul important al securitatii datelor si autentificarii. Utilizatorii trebuie sa aiba incredere ca datele comunicate de catre ei in mod electronic vor fi disponibile numai autoritatilor statului si ca hiper-supravegherea de catre anumiti angajati nu este posibila. Din acest punct de vedere, toate datele trebuie sa fie comunicate incriptat si sa fie semnate electronic de catre utilizatori pentru a nu permite repudierea acestora. Numai astfel se poate ajunge la o e-Guvernare sigura, care trebuie sa fie dublata cu politici clare de acces la informatiile publice atat de catre cetateni, dar si de catre functionarii publici. De asemenea sunt foarte multe aspecte de interactiune om-calculator si design al aplicatiilor care trebuie avute in vedere, precum ergonomie, utilizabilitate, navigabilitate, etc. 2.4.3. Managementul identitatii electronice Un element crucial al serviciilor publice electronice il reprezinta securitatea si confidentialitatea datelor trimise de contribuabili catre autoritatile publice. Acestea sunt asigurate cu ajutorul semnaturilor digitale, dar si a sistemelor de chei publice (PKI) cu care se face incriptarea datelor comunicate. Insa utilizarea sistemelor de autentificare si identificare digitala, aduc probleme la nivelul confidentialitatii datelor de identificare digitala. In acest context, apar sisteme complexe de gestiune a identitatilor electronice, multe dintre ele bazate pe ontologii si taxonomii care sa permita existenta diferitelor nivele de identitate, roluri si acces la date. Aceste sisteme de management a semnaturilor digitale si a eIdentitatii (eID) sunt esentiale nu doar pentru functionarea serviciilor publice la nivel national, ci chiar european si transfrontalier, in general. Din acest punct de vedere, Comisia Europeana finanteaza un proiect european complex numit STORK (Secure idenTity acrOss boRders linKed) pentru a permite recunoasterea transfrontaliera a sistemelor pentru eID si pentru a permite accesul oricarui cetatean european ce are un eID la serviciile publice din 18 tari europene (pentru detalii, se poate consulta site-ul proiectului https://www.eid-stork.eu/). Scopul proiectului este de a permite tuturor cetatenilor din UE sa isi poata dovedi identitatea si sa foloseasca sistemele nationale de

57

identificare electronica (parole, carduri de identitate, chei publice, telefoane mobile, etc.) in orice alta tara din UE. Un rol important in asigurarea identificarii electronice il au si tehnologiile noi, precum cele de identificare biometrica a cetatenilor. Acestea combina tehnologia cardurilor destepte folosite pentru identificare si autentificare cu utilizarea datelor biometrice, precum: recunoasterea amprentelor, recunoasterea irisului sau recunoastere faciala. Deja aceste tehnologii sunt folosite pentru pasapoartele biometrice sau ePasapoarte in mai multe tari. Chiar acolo unde nu sunt folosite date biometrice, cardurile destepte sunt folosite uzual pentru identificarea si autentificarea persoanelor in realizarea tranzactiilor online cu serviciile publice, dar cu servicii comerciale private. Totusi, desi toate aceste tehnologii sunt folosite pentru a asigura securitatea datelor si a evita fraudele, trebuie avuta in vedere si increderea publicului si acceptabilitatea lor de catre cetateni si companii. In acest context, utilizarea datelor biometrice sunt privite cu lipsa de incredere, atat de catre cetateni, care considera aceste dispozitive ca pe o tentativa de invadare a dreptului lor la libertate, datorita posibilitatii urmaririi activitatilor lor de catre stat, dar si de catre experti, care considera ca aceste tehnologii nu sunt sigure la atacurile electronice, replicare si falsificare. Rezulta ca ultimul aspect care trebuie avut in vedere la acest capitol este cel al prevenirii atacurilor asupra identitatii electronice, inclusiv falsificarea dispozitivelor pentru identificare, dar si a datelor care sunt transmise. 2.4.4. Interoperabilitatea serviciilor publice electronice Pentru ca serviciile publice electronice sa aiba o rata mare de adoptie si sa corespunda necesitatilor, este necesar sa se asigure cooperarea si interoperabilitatea intre diversele servicii publice si independenta de furnizori. Interoperabilitatea serviciilor publice este pe cel putin trei nivele: tehnologica furnizarea serviciului sa nu depinda de folosirea unei anumite tehnologii si schimbarea tehnologiei sa fie usor de realizat, organizationala serviciile sa fie usor de adaptat in functie de schimbarile suferite de procesele si organizarea administratiei publice, si semantica datele salvate trebuie sa fie usor de interpretat si folosit in alte contexte. Pentru realizarea interoperabilitatii la nivel tehnologic se pot folosi serviciile Web, arhitectura orientata pe servicii sau diverse software-uri si tehnologii open-source, componente ce pot fi usor schimbate fara a afecta intregul sistem. Pentru a asigura interoperabilitatea la nivel organizational, un rol foarte important at au definirea politicilor si standardizarea serviciilor publice electronice, utlizarea de arhitecturi de tip enterprise ce pot fi usor adaptate la modificarile organizationale (la nivel de resurse, procese sau date). Ultimul aspect, cel al interoperabilitatii semantice a datelor se poate atinge prin folosirea tehnologiilor si serviciilor specifice Web-ului semantic, utilizarea de ontologii specifice proceselor, cu mapari intre diferitele ontologii folosite de organizatii diferite. O alternativa la Web-ul semantic o reprezinta salvarea de metadate si folosirea taxonomiilor. In orice caz, managementul cunostintelor folosite de serviciile publice electronice devine o problema din ce in ce mai dificila. 2.4.5. Managementul cunostintelor Odata cu evolutia si diversificarea serviciilor publice electronice, managementul cunostintelor devine o problema din ce in ce mai dificil de rezolvat. Astfel, sursele de cunostinte sunt fragmentate si eterogene, provenind de la diverse servicii, iar integrarea

58

lor este necesara pentru a folosi la maxim aceste date, atat de catre functionarii publici, dar si de catre cetateni si companii. Problema devine si mai dificila odata cu dezvoltarea mecanismelor de e-participare si eincluziune, prin care sunt introduse medii complexe, care de multe ori pot fi colaborative si dinamice in timp. Oferirea de informatii in mod interactiv utilizatorilor va trebui si ea rezolvata, putand aparea situatii in care acestia fac cereri ne-predictibile, care pot da nastere chiar la situatii conflictuale din cauza cererilor mai multor utilizatori. Pentru a rezolva cu succes astfel de probleme, serviciile trebuie sa fie gandite astfel incat sa fie adaptabile la necesitatile fiecarui utilizator, mergand pana la servicii avansate, evolutive si auto-extensibile. Odata cu evolutia in timp, se va pune problema ca serviciile publice sa ofere asistenti personali inteligenti pentru fiecare utilizator care sa foloseasca tehnici de regasirea informatiilor, prelucrarea limbajului natural si invatare automata, mergand chiar la dezvoltarea de agenti inteligenti care sa asiste utilizatorul in functie de profilul si de istoricul acestora. Mai mult, se poate dovedi necesar ca in timp sa apara sisteme de recomandare specifice pentru rezolvarea anumitor probleme ale utilizatorilor, in special folosind tehnicile de filtrare si recomandare colaborativa, profitand astfel de volumul mare de date si de utilizatori din sistem. 2.5. Descrierea serviciului Servicii publice de rezolvare a cererilor clientilor in varianta actuala

2.5.1. Procesul actual Persoanele fizice sau juridice se adreseaza unei persoane aflata la un ghiseu pentru a inregistra o cerere adresata primarului. O alta persoana din cadrul primariei foloseste o aplicatie pentru a introduce toate informatiile necesare atat pentru persoanele vechi cat si pentru cele noi. Cererea este transmisa unei alte persoane desemnata de catre primar, care va fi numita in continuare director, pentru a fi analizata. In functie de continutul cererii si de propriile consideratii, directorul triaza cererile pe care le trimite mai departe, catre primar, spre aprobare si introduce in aplicatie toate elementele solicitate in cerere. Apoi, le marcheaza in aplicatie pe cele respinse, si adauga o justificare. Cererile aprobate sunt transmise catre primar care da o rezolutie, dupa care se trimit unui functionar pentru a da un raspuns cu motivatie. Cererile refuzate fac obiectul unei notificari transmise persoanelor prin e-mail. Acest proces este lent, iar cei care depun cereri se plang de lipsa de promptitudine si de accea trebuie elaborat un proces nou.

59

Figura 17. Procesul actual de rezolvare a cererilor clientilor

Date de intrare :

Asa cum se observa din figura 17, datele folosite la intrare, respectiv iesire, sunt manipulate cu ajutorul unor obiecte numite itemi. Itemii sunt alcatuiti din combinatii de tipuri simple de date si tipuri de date complexe sau definite de utilizator. Fiecare metoda primeste un obiect ca element de intrare trebuind sa intoarca un obiect ca element de iesire. In cazul de fata se creeaza un obiect numit Cerere care are urmatoarea structura folosita la modelarea procesului: 1. Cetatean care are tipul de data Record si este alcatuit din urmatoarele tipuri de date simple: a. IdentificatorC de tip Integer b. NumeC de tip String c. PrenumeC de tip String d. Adresa de tip String e. Oras de tip String f. CodPostal de tip String 2. TemeCerere care are tipul de data Solicitare si este alcatuit din urmatoarele tipuri de date simple: a. NumeTema de tip String b. NumarTema de tip Integer c. Descriere 3. Tipurile de date simple: a. NumarInregistrareCerere de tip Integer b. SituatieCerere de tip Boolean

60

Date de iesire :

Obiectul de iesire se prezinta sub forma unei copii a obiectului de intrare care are cateva valori modificate. La iesire se vor obtine, in functie de rezolutie, doua obiecte, unul numit Solutie, iar celalalt numit Notificare care au urmatoarea structura : 1. Solutie a. NumarInregistrareCerere de tip Integer b. Cetatean de tip Informatie, care are structura : IdentificatorC de tip Integer NumeC de tip String PrenumeC de tip String Adresa de tip String Oras de tip String CodPostal de tip String

c. TemeCerere care are tipul de data Solicitare si este alcatuit din urmatoarele tipuri de date simple: 2. Notificare a. email de tip String 3. text de tip String Functionalitati oferite: - Organizare superioara a modului de solutionare a cererilor cetatenilor - Colectarea, analizarea si compararea performantelor operationale pe baza simularii. Cu ajutorul simularii se pot identifica (inainte de punerea in functiune a aplicatiei in mediul real de executie) activitatile care au cea mai mare durata de executie sau resursele care produc probleme de trafic. Tot cu ajutorul simularii se poate determina timpul mediu de procesare a unei cereri - Regulile utilizate in aplicatie se pot modifica dinamic, la executie. In momentul executiei, managerul regulilor de domeniu afiseaza o lista de reguli. Fiecare regula din lista poate fi modificata (inclusiv valorile parametrilor). Dupa salvarea regulii modificate, regula poate fi publicata pentru a deveni activa. - Pe baza analizei statice se pot efectua aprecieri ale eficientei procesului de solutionare a cererilor inainte ca acesta sa fie pus in executie, pe baza simularii. - Folosind rezultatele simularii se pot face aprecieri ale eficientei comparand rezultatele mai multor simulari. NumeTema de tip String NumarTema de tip Integer Descriere

61

Furnizori existenti ai serviciului Procese aferente:

Primaria Cererile respinse de catre primar trebuie motivate de catre un functionar al primariei, prin adaugarea unui text descriptiv, cu invocarea unor articole de lege, acolo unde este cazul. Indicatori ai calitatii serviciului - Cost si eficienta - Durata, timp maxim de asteptare - Timpul mediu de solutionare a cererii - Elemente de intrare: item introdus (minimum, maximum) - Elemente de iesire: item obtinut (minimum, maximum) - Intrare logica: conditii ce trebuie indeplinite inainte de inceperea activitatii - Iesire logica: conditii ce trebuie indeplinite dupa ce datele de iesire sunt trimise mai departe. Gradul actual de informatizare In cadrul acestui proces exista prea multi operatori umani care fac ca procesul sa fie lent. Procesul poate fi imbunatatit prin introducerea unei interfete grafice utilizator care sa permita fiecarei persoane sa-si inregistreze singura cererea online. Clientii vor folosi o aplicatie Web pentru a introduce si inregistra cereri. Clientii noi trebuie sa-si introduca toate informatiile de identificare. Aplicatia Web declanseaza executia procesului. Gradul actual de automatizare Procesul actual nu dispune de automatizare, ceea ce conduce la cresterea timpului de operare. Se poate elabora un serviciu Web care sa preia datele despre client din cadrul altor aplicatii ale primariei, cum ar fi de exemplu, sistemul de evidenta al populatiei. Serviciul Web se modeleaza sub forma unui subproces separat. Parametrii pot fi obtinuti din cadrul itemilor existenti si transferati in cadrul unei activitati reprezentata de serviciul Web. Rezultatul obtinut de la serviciul Web poate fi folosit la actualizarea itemului din cadrul procesului. 2.5.2. Prezentarea potentialului de inovare a serviciului Servicii publice de rezolvare a cererilor clientilor Calitatea serviciilor publice pentru cetateni poate creste substantial prin implementarea in administratia publica a strategiei managementului relatiilor cu clientii/ cetatenii (Customer Relationship Management CRM, respectiv Citizen Relationship Management CiRM), recunoscuta ca un set de practici manageriale eficace. Managementul relatiilor cu clientii (Customer Relationship Management CRM) reprezinta o stategie care are la baza o serie de instrumente pentru dezvoltarea parteneriatelor pe termen lung cu clientii, bazate pe cunoasterea cerintelor acestora (nevoi si asteptari) in diferite etape ale relatiei cu clientii, livrand produse si furnizand servicii care sa corespunda asteptarilor clientului.

62

Managementul relatiilor cu cetatenii (Citizen Relationship Management CiRM) reprezinta o strategie si un set de practici de management, bazate pe tehnologie si focalizate asupra cetateanului, pentru mentinerea si optimizarea relatiilor cu cetatenii si incurajarea de noi forme de participare a acestora. Obiectivul principal al CRM este de a ajuta organizatiile (inclusiv din administratia publica) sa foloseasca resursele TIC si competentele angajatilor organizatiei pentru a intelege si a capata noi perspective asupra comportamentului clientilor/ cetatenilor si a perceptiei acestora privind conceptul de valoare (pentru un produs sau un serviciu). CRM permite organizatiilor sa automatizeze, sa integreze si sa foloseasca inteligent instrumentele de care dispun in relatiile cu clientii/ cetatenii, oferind posibilitatea realizarii unei legaturi aproape personale intre acestia si organizatie. Pentru scopul acestui studiu de caz ne referim la managementul relatiilor cu cetatenii in administratia publica numai din perspectiva urmatoarelor procese: comunicare cu clientul/ cetateanul, crearea de valoare pentru client/ cetatean si rezolvarea cererilor depuse de catre acestia. 2.5.2.1. Inovari tehnologice

Instrumentele folosite pentru lucrul cu procese permit: Descrierea procesului urmata de modelarea grafica a acestuia, simularea timp de o luna a operatiilor necesare, efectuarea de modificari. Avantajul folosirii unei arhitecturi de tipul celei descrise este imens din acest punct de vedere, deoarece, pe de o parte, prin modelare, se pot incerca mai multe variante ale aplicatiei realizate cu costuri minime (instrumentele ajutatoare fac ca acest lucru sa fie foarte simplu si rapid), iar pe de alta parte procesele care in realitate dureaza foarte mult (zile, saptamani, sau chiar luni), in IT nu dureaza mai mult de cateva minute (simulare). In acest fel se poate ajunge, prin incercari (mai putin costisitoare), la setul de reguli cel mai avantajos, fiind posibila totodata adaptarea cu rapiditate la cererile de modificare dictate de piata sau de cadrul legislativ. Introducerea grafica a relatiilor dintre date, cetateni, sisteme si servicii Identificarea si marcarea punctelor de masurare a indicatorilor de calitate Personalizarea solutiei in functie de optiunile de punere in mediul real de executie Testarea procesului si obtinerea asigurarii de functionare corecta Inovari de management/organizationale

2.5.2.2.

Pentru fiecare activitate se pot asocia resurse, cum ar fi, de exemplu, rolul necesar pentru a efectua activitatea respectiva, resursele individuale sau de grup, durata necesara. Rol: Specifica costul, disponibilitatea si scopul Resursa: resursa individuala sau de grup, cost, disponibilitate, rol Calendar: Specificarea duratei, perioadei de repetitie, datei de inceput, datei posibile de incheiere.

Prin folosirea instrumentelor ajutatoare la elaborarea de aplicatii cu arhitectura orientata pe servicii se pot face o serie de analize asupra datelor existente in sistem. Astfel, se poate face o analiza dimensionala, prin care se analizeaza datele numerice agregate pe

63

baza unei dimensiuni. Pentru agreagre se folosesc functii totalizatoare (sum, count, avg etc.). Folosind analiza dimensionala se pot face o serie de interpretari ale datelor cum ar fi: provenienta cererilor: se determina cererile totale pe locatie (oras, cartier etc.) media timpului de procesare a comenzilor pe locatie (oras, cartier etc.) categoria de cetateni care depune cele mai multe cereri

Pe baza rezultatelor obtinute in urma analizelor si a simularilor se pot face aprecieri referitoare la eficienta activitatilor din cadrul procesului, putandu-se lua masuri de optimizare. 2.6 Descrierea serviciului public de consultan i asisten pentru afaceri 2.6.1 Procesul actual Prin afaceri nelegem toi agenii economici care funcioneaz la un moment dat pe pia, organizaii existente i nou nfiinate, indiferent de mrime, form de proprietate, profil i domeniu de activitate, precum i persoane fizice autorizate. Toate aceste categorii de organizaii sunt denumite generic n coninutul prezentului studiu de caz clieni. O categorie aparte de clieni ai serviciilor publice de consultan i asisten, luat n considerare n prezentul studiu de caz, o formeaz omerii. Furnizorul de servicii publice pentru afaceri analizat n prezentul studiu de caz este Agenia Naional de Ocupare a Forei de Munc. Ca servicii avem in vedere, printre altele, urmtoarele: formare profesional, reorientare profesional i recalificare, elaborarea proiectului de buget al asigurrilor pentru omaj i administrarea acestuia, asisten managerial i financiar pentru afaceri etc. Date de intrare : Nu exist o perspectiv clar asupra clienilor ageni economici i omeri care au nevoie i solicit consultan i asisten n afaceri: cine sunt clienii? Exist o nelegere limitat a cerinelor clienilor (n ceea ce privete nevoile i ateptrile acestora): ce categorii de nevoi exist? Companiile pierd clieni n favoarea competiiei; companiile mici sunt absorbite de cele mari sau nu supravieuiesc. Tot mai muli clieni sunt nemulumii. Nr. omerilor i al persoanelor care necesit reorientare i recalificare profesional este n cretere. Potenialii clieni nu cunosc natura serviciilor publice de consultan i asisten n afaceri puse la dispoziia lor i nici tipurile de organisme care ofer astfel de servicii. Competenele angajailor organizaiei furnizoare de servicii nu rspund cerinelor clienilor. Baze de date privind clienii i categoriile de nevoi ale acestora referitoare la consultan i asisten n afaceri, ntlnite n mod frecvent.

Date de ieire :

64

Procese operaionale i de comunicare defectuoase pentru client. Preuri neatractive ale serviciilor, innd cont de calitatea acestora. Clieni nemulumii sau nemotivai.

Funcionaliti oferite: Identificarea clienilor/ agenilor economici care au nevoie de suport, consultan i asisten n afaceri. Utilizarea TIC pentru organizarea, automatizarea i sincronizarea proceselor organizaiei furnizoare de servicii. Identificarea, atragerea i ctigarea de noi clieni. mbuntirea/ creterea valorii furnizate clienilor existeni. Reducerea costurilor cu activitile de marketing i serviciile oferite clienilor. Reducerea nr. reclamaiilor.

Furnizori existenti ai serviciului Sunt prezentai la pct.1, subpct. 1.1.

Procese aferente: Orientarea clienilor: segmentarea clienilor, comunicarea cu clienii, retenia clienilor. Satisfacerea clienilor: crearea de valoare pentru client, rezolvarea reclamaiilor. Loializarea clienilor: loializare tranzacional i loializare perceptual.

Indicatori ai calitii serviciului Nr. de clieni beneficiari ai serviciului de consultan i asisten oferit, precum i rezultatele n afaceri ale acestora ca urmare a valorificrii serviciului oferit. Soluii de afaceri oferite concretizate n nr. de contracte finanate, volumul finanrii, crearea de noi companii etc. Studii de fezabilitate realizate. Nr. de reclamaii soluionate/ Nr. total de reclamaii nregistrate (frecvena de monitorizare: lunar).

Gradul actual de informatizare Exist o serie de puncte de contact cu clienii pentru oferirea de consultan i asisten financiar pentru mediul de afaceri.

65

Exist baze de date referitoare la clieni. Modalitile de comunicare sunt cele clasice (comunicare direct, online) i de multe ori defectuoase.

Gradul actual de automatizare Sporadic, companiile din mediul privat au implementat un program informatizat pentru managementul relaiilor cu clienii. n instituiile publice acest obiectiv reprezint n continuare o int greu de atins.

2.6.2 Prezentarea potentialului de inovare a serviciului publice de consultan i asisten pentru afaceri Calitatea serviciilor publice de consultan i asisten pentru mediul de afaceri, precum i a serviciilor publice pentru ceteni poate crete substanial prin implementarea n administraia public a strategiei managementului relaiilor cu clienii/ cetenii (Customer Relationship Management CRM, respectiv Citizen Relationship Management CiRM), recunoscut ca un set de practici manageriale eficace pentru mediul privat. Managementul relaiilor cu clienii (Customer Relationship Management CRM) reprezint o stategie care are la baz o serie de instrumente pentru dezvoltarea parteneriatelor pe termen lung cu clienii, bazate pe cunoaterea cerinelor acestora (nevoi i ateptri) n diferite etape ale relaiei cu clienii, livrnd produse i furniznd servicii care s corespund ateptrilor clientului. Managementul relaiilor cu cetenii (Citizen Relationship Management CiRM) reprezint o strategie i un set de practici de management, bazate pe tehnologie i focalizate asupra ceteanului, pentru meninerea i optimizarea relaiilor cu cetenii i ncurajarea de noi forme de participare a acestora. Obiectivul principal al CRM este de a ajuta organizaiile (inclusiv din administraia public) s foloseasc resursele TIC i competenele angajailor organizaiei pentru a nelege i a cpta noi perspective asupra comportamentului clienilor/ cetenilor i a percepiei acestora privind conceptul de valoare (pentru un produs sau un serviciu). CRM permite organizaiilor s automatizeze, s integreze i s foloseasc inteligent instrumentele de care dispun n relaiile cu clienii/ cetenii, oferind posibilitatea realizrii unei legturi aproape personale ntre acetia i organizaie. Pentru scopul acestui studiu de caz concretizat n creterea gradului de inovare al serviciilor publice pentru afaceri atenia ne este focalizat asupra implementrii n administraia public a unui sistem de management al relaiilor cu cetenii i agenii economici din perspectiva urmtoarelor procese: comunicare cu clientul (cetean sau agent economic), crearea de valoare pentru client (cetean sau agent economic) i rezolvarea reclamaiilor cu scopul evalurii satisfaciei clienilor (ceteni sau ageni economici). 2.6.2.1 Comunicarea cu clientul Comunicarea cu clientul se refer la procesul de transmitere de informaii, idei, dar i decizii, instruciuni de lucru etc., n mod transparent i echitabil, clienilor organizaiei. Pentru optimizarea relatiilor cu clientii, respectiv cresterea satisfactiei acestora, personalul

66

organizatiei cu responsabilitate, comunica permanent cu clientii referitor la: informatii despre serviciile solicitate; formularea ofertelor tinand seama de cerintele si conditiile specifice de afaceri ale fiecarui client; tratarea reclamatiilor primite de la clienti; informatii referitoare la gradul de satisfactie al clientilor. n vederea creterii eficacitii procesului de comunicare cu clientul, din perspectiva celor dou pri implicate organizaia furnizoare de servicii-emitorul i beneficiarul serviciului-receptorul acesta trebuie s conin urmtoarele etape: Codificarea nelesului: selectarea limbajului care s exprime semnificaia unui mesaj; Transmiterea mesajului: de la emitor la receptor prin diverse ci de comunicare (vizual, auditiv, electronic etc.); Decodificarea i interpretarea: descrifrarea limbajului i explicarea sensului mesajului de ctre receptor; Filtrarea: deformarea sensului unui mesaj ca urmare a unor limite fiziologice sau psihologice ale receptorului; Feedback: verificarea de ctre emitent n ce msur mesajul transmis a fost neles corect sau a suferit filtrri. Comunicarea verbal; Comunicarea nonverbal; Comunicarea online; Comunicarea telefonic; Alte mijloace de comunicare: radio, Tv, fax etc.

Principalele mijloace de comunicare vizeaz:

2.6.2.2. Crearea de valoare pentru client Valoarea adugat clientului se concretizeaz n beneficii obinute direct de ctre client ca urmare a interaciunii cu furnizorul de servicii, precum i beneficii indirecte determinate de mbuntirea calitii serviciului oferit. Beneficiile directe obinute ctre client sunt direct determinate de competenele personalului organizaiei furnizoare de servicii cu responsabilitate n domeniu. Beneficiile indirecte sunt influenate de gradul de informatizare i automatizare a serviciului solicitat. 2.6.2.3 Rezolvarea reclamaiilor Reclamaia este o expresie a unei insatisfacii sau nemulumiri a clientului fa de calitatea produselor i a serviciilor furnizate, procedurile, tarifele i taxele aplicate, comportamentul i competenele angajailor, la care este ateptat n mod explicit sau implicit un rspuns sau o rezoluie. Sistemul de tratare a reclamaiilor trebuie s se caracterizeze prin: accesibilitate uoar prin asigurarea canalelor multiple pentru exprimarea opiniilor; investigarea profund i corect a reclamaiilor; rezolvarea prompt i corect a reclamaiilor;

67

despgubirea pentru pagubele produse; respectarea termenelor stabilite; inerea la curent a clienilor privind stadiul de rezolvare; pstrarea confidenialitii; asigurarea tuturor resurselor umane i materiale adecvate; furnizarea informaiilor ctre management n vederea mbuntirii serviciilor; informarea clienilor despre mbuntirile adoptate n urma reclamaiilor.

ncurajarea reclamaiilor nseamn asigurarea unei accesibiliti uoare i bine mediatizate, tratarea cu respect i seriozitate a fiecrui client, indiferent de obiectul reclamaiei sau modalitatea de adresare a acestuia, optimizarea proceselor prin care sunt tratate reclamaiile. Astfel, pe de o parte se obin informaii preioase pentru management, iar pe de alt parte, clienii crora li s-au rezolvat prompt problemele, devin clieni cel puin att de loiali ca i cei care nu au experimentat o problem. O reclamaie va trebui s furnizeze urmtoarele informaii: obiectul reclamaiei, datele de identificare a persoanei, care depune reclamaia, un numr de telefon pentru contactare ulterioar pe ct este posibil i modul de soluionare, dac reclamantul are opiune n acest sens. n ceea ce privete tratarea reclamaiilor, toate reclamaiile vor beneficia de aceeai prioritate, indiferent de obiect, forma sau limba de prezentare. Reclamaiile clienilor vor fi tratate pe trei nivele: nivelul 1: operatorii de la Centrul de Relaii cu Clienii, pe ct posibil, rezolv reclamaiile la primul contact cu clientul; nivelul 2: reclamaiile care necesit luarea unor decizii, vor fi rezolvate de ctre personalul de conducere desemnat n acest scop din cadrul organizaiei; nivelul 3: reclamaiile ale cror rezolvare nu corespunde cu ateptrile clientului, dup epuizarea tuturor posibilitilor interne, vor fi soluionate prin conciliere extern.

O reclamaie se va considera rezolvat atunci cnd s-a reuit eliminarea obiectului reclamaiei, adic restabilirea situaiei optime care ar fi existat dac defeciunea/ greeala nu ar fi aprut i cnd reclamantul se declar mulumit de soluia adoptat. La orice tip de reclamaie a clientului se va emite rspuns n scris, care se va expedia prin pot, la adresa menionat de ctre client. n cazul n care o reclamaie nu poate fi rezolvat n termenul prestabilit, clientul va fi informat n scris asupra decalrii termenului i a stadiului n care se afl soluionarea reclamaiei. Acest proces de informare se va repeta din 15 n 15 zile calendaristice, pn la rezolvarea final. 2.6.2.4 Inovri tehnologice i organizaionale Pornind de la cele trei procese descrise mai sus, prezentm n continuare cteva aciuni concrete care conduc la mbuntirea eficacitii i eficienei acestor procese i sporesc gradul de inovare al acestora.

68

Inovri tehnologice: crearea unor baze de date privind clienii i categoriile de nevoi ale acestora referitoare la consultan i asisten n afaceri i actualizarea permanent a acesteia; extinderea modalitilor de comunicare cu clientul inclusiv prin posibilitatea adresrii solicitrii online i soluionrii acesteia n aceeai modalitate; oferirea de informaii ct mai cuprinztoare (privind natura serviciilor, soluii de afaceri oferite etc.) pe pagina web a furnizorului de servicii i asigurarea transparenei acestora pentru toate prile interesate; implementarea unui program informatizat de managementul relaiilor cu clienii i monitorizarea celor trei componente ale acestuia: orientarea clienilor, satisfacerea clienilor i loializarea clienilor (dup modelul companiilor private). Inovri organizaionale: creterea calitii serviciilor publice de consultan i asisten pentru afaceri, evaluat n termeni de ndeplinire a nevoilor i ateptrilor (competen, promptitudine, responsabilitate); creterea eficacitii proceselor de marketing prin realizarea unei comunicri relevante pentru client/ cetean; creterea randamentului proceselor operaionale prin informatizarea acestora; oferirea de preuri sczute ale serviciilor, competitive; simplificarea fluxurilor de lucru i a procedurilor ncepnd cu adresarea solicitrii din partea clientului i pn la rezolvarea reclamaiilor acestora, dup caz; eliminarea aprobrilor i avizrilor inutile de ctre efii ierarhici superiori.

3. Concluzii
3.1. Tendinte si inovare in serviciile software pentru administratia publica Serviciile software pentru administratia publica schimba deja modul de interactiune intre cetateni si companii, pe de o parte, si organismele guvernamentale, de cealalta parte. Nivelul mare de acceptare al acestor servicii de catre utilizatori dovedeste utilitatea acestor servicii petnru cetateni si companii: economia de timp, energie si bani reprezinta principalul avantaj, dar nu trebuie pierdute din vedere si celelalte castiguri: istoricul tranzactiilor este mai usor de consultat, documentele nu se mai pierd fiind salvate digital, etc. In plus, administratia publica are, de asemenea, o serie de avantaje: toate datele sunt disponibile electronic, putandu-se explora foarte usor evolutiile si tendintele viitoare, se pot face prognoze, se pot identifica serviciile mai putin folosite, etc. Nu in ultimul rand, folosirea serviciilor de e-Guvernare reperzinta o solutie eficienta pentru combaterea evaziunii si determinarea trisorilor sistemului public. Tocmai datorita acestor avantaje multiple, serviciile publice electronice vor cunoaste o dezvoltare puternica si in perioada urmatoare, preconizandu-se a reprezenta modalitatea cea mai importanta de interactiune intre stat, cetateni, companii si alte organizatii in viitorul cel mai apropiat pentru majoritatea problemelor. Totusi, aceasta evolutie a sistemelor publice electronice nu poate fi facuta eficient fara specialisti pe diferite niveluri: tehnologic, organizational, administrativ, legal si politic. Tocmai din aceasta cauza este impresios necesara pregatirea specialistilor in sistemele electronice pentru administratia publica si dezvoltarea de programe de formare profesionala inca din ciclul universitar. Din punct de vedere tehnologic, evolutia si inovarea in acest domeniu vor urma tendintele generale din tehnologia informatiei si comunicatii, avand insa unele aspecte particulare. In primul rand, e-Guvernarea va fi influentata de catre noile oportunitati pe care le deschide cetatenilor: e-participarea si e-implicarea in procesele de decizie ale administratiei publice.

69

Apoi, va trebuie sa se concentreze pe dezvoltarea interactiunii cu utilizatorii, astfel incat serviciile publice sa fie usor de folosit, accesibile tuturor persoanelor, ergonomice, intuitive, etc. Un aspect important in perioada urmatoare il va consitui crearea unei modalitati de eidentificare a cetatenilor si companiilor la nivel global astfel incat sa poata folosi orice serviciu public din lume. Insa atingerea acetui obiectiv va ridica noi probleme de scalabilitate, securitate si tehnologice. Interoperabilitatea si cooperarea sistemelor electronice publice va fi un alt factor important in dezvoltarea imediat urmatoare a acestui domeniu. Acest aspect va fi cu atat mai dificil de realizat cu cat interoperabilitatea trebuie realizata atat la nivel tehnologic, dar si organizational si de semantica a datelor. Mai mult, serviciile din tari diferite vor trebui sa poata comunica eficient intre ele, de multe ori avand aspecte organizationale, legale si de semantica a datelor diferite. Nu in ultimul rand, odata cu evolutia si cresterea numarului de utilizatori si de servicii publice disponibile electronic, managementul eficient al cunostintelor o sa aiba un rol important, putand aduce diferite aspecte noi, precum sisteme publice de recomandare (de companii sau de actiuni de intreprins) sau chiar asistenti personali care sa ghideze utilizatorii in functie de serviciile pe care trebuie sa le foloseasca. 3.2. Rezumat servicii

In momentul de fata, exista o serie de servicii publice considerate fundamentale de catre Comisia Europeana si care trebuie sa fie disponibile ca servicii electronice in perioada imediat urmatoare. Primul pas important pentru aceste servicii este sa fie complet disponibile online, tranzactionale, insa exista dezvoltari ulterioare pentru a face serviciile proactive, adica complet automatizabile sau personalizabile in functie de necesitatile utilizatorilor. In plus, exista o serie de alti indicatori care sunt relevanti pentru serviciile de e-Guvernare: e-Procurement, care masoara avansul serviciilor electronice pentru achizitiile publice, sau e-Participare, care maasoara nivelul in care cetatenii au posibilitatea sa isi spuna opinia si sa se implice in actul de guvernare. 3.3. Implicatii asupra necesitatii calificarii si pregatirii de personal implicat in servicii

Pentru a rezolva complexitatea serviciilor din administratia publica se impune formarea de competente interdisciplinare care sa aiba in vedere domeniile: tehnologiile informatiei si comunicatiilor, management, organizare si operare pe Internet, precum si legislatie, psihologie si sociologie. In domeniul tehnologiilor informatiei si comunicatiilor se urmareste formarea de competente in proiectarea, implementarea, evaluarea si exploatarea tehnologiilor inovative pentru administratie publica. In domeniul managementului, organizarii si operarii pe Internet se urmareste formarea de competente in ceea ce priveste capacitatea de gestiune eficienta, organizare flexibila si usurinta de utilizare. In domeniul legislatiei, psihologiei si sociologiei se urmareste formarea de competente in ceea ce priveste intelegerea nevoilor cetateanului / firmelor, a abilitatii de a raspune asteptarilor lor cu respectarea legalitatii.

70

In ceea ce priveste cunostintele, acestea trebuie sa aiba in vedere metode stiintifice de analiza, proiectare si dezvoltare a serviciilor din administratia publica, eficientizarea managementului, maximizarea productivitatii serviciilor Programele de studiu pot fi adaptate diverselor profiluri de specialisti (administratie publica, inginerie, management etc). Din informaiile relevate mai sus reiese clar necesitatea pregtirii de personal calificat n domeniul serviciilor pentru afaceri, att n ciclul de formare iniial (licent i masterat), ct i n cadrul programelor de formare continu. La nivelul programelor de masterat, un domeniu potenial de calificare ar fi Managementul serviciilor pentru afaceri. Principalele competene dezvoltate de un astfel de program includ: Dintre competenele profesionale amintim: C1 - Operarea cu concepte i metode tiintifice n domenii interdisciplinare C2 - Integrarea conceptelor avansate i metodelor specifice tiinelor economice n dezvoltarea serviciilor pentru afaceri C3 - Integrarea principiilor managementului schimbrii, managementului relaiei cu clienii i responsabilitii sociale n dezvoltarea serviciilor pentru organizaii C4 - Modelarea i implementarea proceselor de afaceri n domeniul serviciilor destinate organizaiilor C5 - Proiectarea, dezvoltarea i managementul serviciilor pentru afaceri C6 - Inovarea serviciilor pentru afaceri utiliznd tehnologii moderne Ca i competene transversale precizm: CT1 - Aplicarea normelor i valorilor de etic profesional pentru luarea deciziilor i realizarea independent sau n grup a unor sarcini/ obiective complexe la locul de munc CT2 - Planificarea i organizarea resurselor umane n cadrul unui grup sau al unei organizaii, n condiii de contientizare a responsabilitii pentru rezultatele profesionale CT3 - Asumarea nevoii de formare continu pentru a crea premisele de progres n carier i adaptare a propriilor competene profesionale i manageriale la dinamica mediului economic Profilul ocupaional al absolvenilor programului de masterat mai sus menionat vizeaz (este precizat i codul COR): 241227 Specialist n dezvoltare organizaional 241919 Manager proiect 241922 Analist servicii client 241928 Specialist mbuntire procese 241931 Responsabil proces 241939 Administrator societate comercial 241946 Manager mbuntire procese 242307 Analist calitate

71

244101 Consilier/ Expert/ Inspector/ Referent/ Economist n Management 244107 Consultant n management 247007 Agent de dezvoltare Un program de formare continu pentru pregtirea de personal calificat n domeniul serviciilor pentru afaceri, program de tip modul compact ar trebui s aib un buget de ore de cel putin 28 ore de curs i 28 ore de seminar. Un astfel de modul compact are la baz o abordare interdisciplinar care permite acumularea de cunotine complexe de management, marketing, finane, contabilitate, antreprenoriat, dar i formarea unor abiliti de comunicare i prezentare, ntr-un mod care s permit cursanilor s neleag sistemele de servicii pentru afaceri i s-i dezvolte abilitatea de a lucra n echipe, de a lucra cu clienii i furnizorii i de a lucra eficient n sectorul serviciilor pentru a crea valoare pentru clieni. Cursul exploreaz tipurile de servicii pentru afaceri, evideniind nevoia pentru o abordare interdisciplinar care s permit inovarea n servicii i studierea tehnologiilor i a instrumentelor necesare pentru a genera inovaie n industria serviciilor. Aplicaiile sunt concepute astfel nct s implice studenii n discuii i dezbateri, s faciliteze analiza i dezbaterea de articole i lucrri tiinifice, analizarea i rezolvarea de studii de caz, rezolvarea de teme n clas i acas, susinerea unei prezentri i realizarea unui proiect final. Formulm, astfel, dou recomandri de inovare n servicii necesare unei mai bune nelegeri a sistemelor de servicii n procesele de afaceri: implementarea unui program informatizat de managementul relaiilor cu clienii i monitorizarea celor trei componente ale acestuia: orientarea clienilor, satisfacerea clienilor i loializarea clienilor (dup modelul companiilor private); asigurarea competenelor profesionale necesare i monitorizarea continu a performanelor angajailor care contribuie n mod direct la crearea de valoare pentru client, dar i indirect la adugarea de valoare proceselor operaionale ale organizaiei,

4. Bibliografie
[1] - Yhang Shu, Study of e-Government The effective way of building service oriented government, Journal of International Relations, 2010 [2] - Dave Mayo, Service Oriented Government: 7th SOA For E-Gov, 2009 [3] - Guvernul Romaniei, HG nr. 195/2010 privind aprobarea Strategiei nationale "e-Romania", 2010 [4] - European Commission, Smarter, Faster, Better eGovernment, 8th Benchmark Measurement, 2009 [5] - European Commission, eGovernment in Romania, 2010 [6] - Monica Palmirani, The role of legal knowledge from e-government to e-governance, Proceedings of ICAIL2003, 2003 [7] - The Economist Intelligence Unit, E-government in Central Europe - Rethinking public administration, 2004 [8] - Panos Hahamis, Jennifer Iles and Mike Healy, e-Government in Greece: Bridging the gap Between Need and Reality, Electronic Journal of e-Government, Volume 3, Issue 4, 2005

72

[9] - Demetrios Sarantis, Dimitris Askounis, Electronic government interoperability framework in Greece: Project management approach and lessons learned in public administration, Journal of US-China Public Administration, Volume 7, No.3, 2010 [10] - United Nations eGovernment Survey 2010, 2010 [11] - I. Foster, C. Kesselman, S. Tuecke, The Anatomy of the Grid: Enabling Scalable Virtual Organizations. International Journal of High Performance Computing Applications, 15 (3) pp 200-222, 2001 [12] - I. Foster, C. Kesselman, J. Nick, S. Tuecke, The Physiology of the Grid - An Open Grid Services Architecture for Distributed Systems Integration (extended version of Grid Services Architecture for Distributed Systems Integration. IEEE Computer 35(6), pp 37-46). Open Grid Service Infrastructure WG, Global Grid Forum, 2002 [13] - S. Tuecke, K. Czajkowski, I. Foster, J. Frey, S. Graham, C. Kesselman, T. Maquire, T. Sandholm, D. Snelling, P. Vanderbilt, Open Grid services infrastructure (ogsi) version 1.0, 2003 [14] - Russell Kay, QuickStudy: Representational State Transfer (REST), ComputerWorld, 2007 [15] - Leonard Richardson, Sam Ruby - RESTful Web Services, OReilly Media, 2007 [16] - Ethan Cerami, Web Services Essentials. Distributed Applications with XML-RPC, SOAP, UDDI & WSDL, OReilly Media, 2002 [17] - Antonescu, D., Rolul i importana activitii de consultan n atragerea i obinerea finanrilor pentru mediul de afaceri din Romnia, Institutul de Prognoz Economic, Academia Romn, 2008. [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] Ciumara, T.M., Piaa serviciilor de consultan n management din Romnia, Tez de doctorat, INCE, 2010. Masi L, Fodell D., Murphy W., Wright K., 2009, Service Science, Management and Engineering (SSME), IBM. Ministerul Economiei, Comerului i Mediului de Afaceri, Analiza serviciilor publice i private de consultan destinate mediului de afaceri din Romnia Studiu calitativ i cantitativ, 2010. Ministerul Economiei, Comerului i Mediului de Afaceri, Strategia Guvernamental pentru mbuntirea i Dezvoltarea Mediului de Afaceri, 2010. Ministerul Finanelor Publice, Cadrul Strategic Naional de Referin 2007-2013, www.mfinante.ro . Ministerul Finanelor Publice, Documentul Cadru de Implementare a Programului Operaional Asisten Tehnic, , octombrie 2009, www.mfinante.ro . Piaa de consultan n management din Romnia n perioada 2009-2010, Asociaia Consultanilor de Management din Romnia AMCOR., 2009. Pinhanez C., Kontogiorgis P., 2008, A Proposal for a Service Science Discipline Classification System, IBM Research, T.J. Watson. Raport privind piaa de consultan din Romnia, 2008-2009, AMCOR. Raport privind piaa european de consultan n management, FEACO, 2007-2008. Serviciile pentru ntreprinderi un sector n expansiune, Comisia Naional de Prognoz, 2007. SR ISO 10002 : 2005 privind Managementul calitii; Satisfacia clientului precum i Liniile directoare pentru tratarea reclamaiilor n cadrul organizaiilor. Survey of the European management consultancy market 2009, FEACO. www.feaco.org . www.ec.europa.eu . http://www.europeanprojects.ro/poscce322.html . www.fseromania.ro . www.fonduriadministratie.ro .

73

[36] [37]

www.inforegio.ro . www.oecd.ro .

74