Analiza Proceselor de Afaceri Pentru Firma de Publicitate

CUPRINS

Introducere

CAPITOLUL I. STUDIU ASUPRA TEHNOLOGIILOR ACTUALE

1.1. Business Process Modeling

1.1.1. Aspecte generale

1.1.1.1. Procesul de afaceri

1.1.1.1.1. Conceptul de proces de afacere în organizație

1.1.1.1.2. Managementul proceselor de afaceri

1.1.1.1.3. Procese de afaceri și BPD

1.1.2. BMPN la prima vedere

1.1.2.1. Istoricul BMPN

1.1.2.2. Utilizarea BPMN

1.1.2.2.1. BPMN 2.0

1.1.2.3. Statistici

1.1.2.4. Avantajele și dezvantajele BPMN

1.1.3. Standardele BPMI.ORG

1.1.3.1. Bune practici în modelarea BPMN

1.1.3.2. Modalitatea generală de lucru în vederea proiectării modelului de business

1.1.3.3. Simularea proceselor

1.1.3.4. Maparea modelului de business peste modelul lingvistic implementat cu ajutorul ontologiilor și semanticii web

1.1.3.5. Dificultățile managerilor de proiecte BPM

1.1.3.6. Utilizarea metodologiei lanțului critic

1.1.4. Fazele tipice ale unui proiect de tip BPM

1.1.4.1. Asumarea strategică a deciziei de utilizare a abordării

1.1.4.2. Examinarea situației actuale

1.1.4.3. Analiza

1.1.4.4. Concepția

1.1.4.5. Implementarea

1.1.4.6. Suportul funcțional tehnic

1.1.5. Modelarea proceselor de afaceri folosind BPMN

1.1.5.1. Analiza procesului de afaceri pentru construirea ontologiilor

1.1.5.1.1. Metodologie de analiză de tip proces-activitate

1.1.5.1.2. Colectarea de informații

1.1.5.1.3. Gestiunea lanțului de activități

1.1.5.2. Diagrama proceselor de afaceri

1.1.5.2.1. Obiectele de flux

1.1.5.2.2. Obiectele conectoare

1.1.5.2.3. Centre de responsabilități

1.1.5.2.4. Artefacte

1.1.5.3. Submodele BPMN

1.1.6. Modelarea evenimentelor în afaceri

1.1.6.1. Evenimente complexe

1.1.7. Procese, subprocese și sarcini de afaceri

1.1.8. Modelarea punctelor de decizie prin gateway-uri

1.1.9. Impunerea normelor B2B

1.1.9.1. Modelarea fluxurilor de mesaj B2B

1.1.10. Procesul de transformare a datelor

1.1.11. Orchestrarea serviciilor web ale BPMN

1.1.12. BPMN și UML

1.1.12.1. Legătura dintre BPMN și UML

1.1.13. Prezențe pe piața Business Process Integration

1.1.13.1. Sybase

1.1.13.2. SeeBeyond

1.1.13.3. IBM Business Process Manager

1.1.14. Tendințe BPMN

1.2. Process Mining

1.2.1. Necesitatea apariției unei noi tehnici de manipulare a datelor

1.2.2. Posibilități oferite de tehnicile de data mining

1.2.3. Tehnicile de data mining și depozitarea datelor

1.2.4. Descrierea datelor pentru data mining

1.2.4.1. Sumarizare și vizualizare

1.2.4.2. Clustering

1.2.4.2.1. Definiție și exemple de clustering

1.2.4.2.2. Măsurarea distanțelor

1.2.4.2.3. Clasificarea algoritmilor de clustering

1.2.4.2.4. Algoritmul K-means

1.2.4.2.5. Algoritmul BFR

1.2.4.2.6. Fastmap

1.2.4.2.7. Clustering ierarhic

1.2.4.2.8. Algoritmul GRGPF

1.2.4.2.9. Algoritmul CURE

1.2.4.3. Analiza legăturilor

1.2.5. Data mining și OLAP

1.2.6. Data mining, învățarea automatelor și statistica

1.2.7. Data mining și tendințele hardware și software

1.2.8. Modele și algoritmi data mining

1.2.8.1. Data mining predictiv

1.2.8.1.1. Ierarhia alegerilor

1.2.8.1.2. Terminologie

1.2.8.1.3. Tipologie

1.2.8.1.4. Regresie

1.2.8.1.5. Șiruri temporale

1.2.8.2. Modele data mining

1.2.8.2.1. Rețele neuronale

1.2.8.2.2. Arbore de decizie

1.2.8.2.3. Modelul MARS

1.2.8.2.4. Reguli de inducție

1.2.8.2.5. Metoda celor mai apropiați vecini

1.2.8.2.6. Regresii logistice

1.2.8.2.7. Analiza discriminantă

1.2.8.2.8. Modelul aditiv generalizat

1.2.8.2.9. Boosting

1.2.8.2.10. Algoritmi genetici

1.2.8.3. Modelul episoadelor

1.2.8.3.1. Monotonia episoadelor și algoritmul Al-Priori

1.2.8.3.2. Verificarea episoadelor

1.2.8.3.2.1. Episoadele parale

1.2.8.3.2.2. Episoadele seriale

1.2.8.3.2.3. Episoadele compuse

1.2.9. Modelarea procesului de data mining

1.2.9.1. Definirea problemei

1.2.9.2. Crearea bazei de date

1.2.9.3. Explorarea datelor

1.2.9.4. Prepararea datelor pentru modelare

1.2.9.5. Construirea modelului pentru data mining

1.2.9.6. Evaluare și interpretare

1.2.9.7. Aplicarea modelului și analiza rezultatelor

1.2.10. Aplicații ale tehnicilor de data mining

1.2.10.1. Categorii de produse data mining

1.2.10.2. Capabilități fundamentale

1.2.10.3. Forarea în WWW

1.2.10.3.1. Ierarhizarea paginilor

1.2.10.3.2. Probleme cu grafurile rețelei reale

1.2.10.3.3. Soluții Google pentru problemele rețelei

1.2.10.3.4. Dispozitive antispam

1.2.10.3.5. Centri și autorități

1.2.10.3.6. Găsirea seturilor neobișnuite de obiecte

1.2.10.3.7. Motorul DICE

1.2.10.3.8. Construirea tiparelor din apariții ale datelor

1.2.10.4. Învățarea automatelor

1.2.10.4.1. Aspecte generale

1.2.10.4.2. Contribuții la învățarea automatelor

1.2.10.4.3. Învățarea probabilă aproximativă corectă

1.2.10.4.4. Aplicații în lumea reală

1.2.11. Succesul în data mining

1.3. Process Execution

1.3.1. Aspecte generale

1.3.2. Proceduri de monitorizare a proceselor

1.3.3. Măsuri de monitorizare a proceselor

1.3.4. Metode de monitorizare a proceselor

1.3.5. Metodele analitice

1.3.6. Descrierea erorilor

1.3.7. Estimarea parametrilor

1.4. Enterprise Architecture

1.4.1. Arhitectura sistemului

1.4.1.1. Celulele

1.4.1.2. Serverele

1.4.1.3. Profilurile

1.4.1.4. Managerii de implementare

1.4.1.5. Nodurile

1.4.1.6. Agenții de nod

1.4.2. Instalarea aplicației Oracle SQL Developer Data Modeler

1.4.3. Proiecte Data Modeler

1.4.4. Crearea diagramelor fluxurilor de date

1.4.4.1. Crearea unui proces

1.4.4.2. Crearea unei entități externe

1.4.4.3. Crearea unui flux de date

1.4.4.4. Crearea unui loc de stocare

1.4.5. Analiza corectitudinii diagramelor

CAPITOLUL AL II-LEA. DEZVOLTAREA APLICAȚIEI

2.1. Business Use Case

2.1.1. Motivație

2.1.2. Principalele activități ale unei agenții de publicitate

2.1.2.1. Activitatea de urmărire a agenției

2.1.2.2. Activitatea de gestiune a utilizatorilor

2.1.2.3. Activitatea de gestionare a cererilor

2.1.2.4. Activitatea de gestiune a contractelor

2.1.3. Definirea obiectivelor sistemului informatic al unei agenții de publicitate

2.1.4. Modelarea sistemului informatic al unei agenții de publicitate

2.1.5. Nivelul cazurilor de utilizare

2.1.5.1. Diagrama principală a cazurilor de utilizare

2.1.5.2. Diagrame detaliate ale cazurilor de utilizare

2.2. Specificații, arhitectură și funcționalități

2.2.1. Modelarea procesului de afaceri

2.2.2. Simularea procesului

2.2.2.1. Descrierea succintă a activităților întreprinse

2.2.2.2. Realizarea diagramei procesului actual

2.2.2.3. Simularea costului și a beneficiilor reproiectării

2.2.3. Proiectarea

2.2.3.1. Diagrame de activități

2.2.3.2. Diagrama claselor

2.2.3.3. Rafinarea diagramei de clase

2.2.4. Implementarea

2.2.5. Desfășurarea

2.2.6. Realizarea diagramei procesului reproiectat

2.3. Raportul de test

2.3.1. Diagrama de clase fără atribute și operații

2.3.2. Diagrama de stare

2.3.3. Diagrama de secvență

2.3.4. Diagrame de colaborare

2.3.5. Diagrama BPMN a procesului de solicitare

2.4. Concluzii

Concluzii și contribuții personale

Bibliografie

Glosar

Anexe

INTRODUCERE

Lucrarea de față intitulată Analiza proceselor de afaceri pentru firma de publicitate, tratează problemele legate de analiza proceselor de afaceri, acest studiu bazându-se pe o bibliografie solidă a unor autori cunoscuți în materie, printre care amintesc: I. Andone, R. C. Appleby, V. Ariton, Patrice Briol, V. Cărciunoiu, D. Curiac, Lin Fu-Ren, M. Havey, T. Ionescu, L. P. Leach, Andrew W. Moore, C. Murray, Jan Recker, Lucia Rusu, B. Silver, M. Umble, C. Voloșencu, S. A. White, D. Zaharie și alții.

Lucrarea de față se dorește a fi o prezentare analitică a proceselor de afaceri. Se subliniază importanța acesora, precum și rolul lor în acțiunile desfășurate. De asemenea, în lucrare, se fac referiri la data mining.

Lucrarea este structurată în două capitole.

Capitolul întâi, intitulat Studiu asupra tehnologiilor actuale, are menirea de a prezenta succint aspectele teorice ale proceselor de afaceri

Organizarea anchetei din capitolul al doilea, intitulat Dezvoltarea aplicației, are rolul de a verifica analiza proceselor de afaceri la o agenție de publicitate

Metoda de cercetare pe care o voi folosi este una calitativă, preponderent explicativă, care are ca obiectiv prezentarea principalelor concepte și explicații teoretice, dar și a analizei acestora în situații concrete. Am ales cercetarea calitativă pentru că presupune un ansamblu de metode, subiectul fiind cercetat dintr-o perspectivă naturalistă și interpretativă.

Pe baza informațiilor prezentate pe parcursul lucrării în cele două capitole amintite, sunt formulate, în final, unele concluzii și recomandări referitoare la tematica lucrării abordate.

Prin prezenta lucrare, am dorit să demonstrez importanța deosebită a cunoașterii aspectelor definitorii privind analiza proceselor de afaceri, întru realizarea scopului propus stabilindu-mi următoarele: analiza aspectelor teoretice și metodologice privind procesele de afaceri; identificarea și analiza lacunelor, confuziilor și contradicțiilor în ceea ce privește tema abordată.

Obiectivele urmărite în această cercetare sunt următoarele:

Stabilirea temei de cercetare: analiza proceselor de afaceri pentru firma de publicitate;

Selectarea bibliografiei în vederea documentării, selecționând atât materiale informative pur teoretice, cât și rapoartele unor studii de caz pe aceeași temă, elaborate în prealabil de către specialiști;

Documentarea propriu-zisă atât din materialele selectate, cât și urmărirea unui curs de specializare în materie;

Interpretarea și prelucrarea datelor obținute.

Modelele și ariile abordate în această lucrare sunt:

Documentarea teoretică din cărțile de specialitate indicate selectiv în bibliografie;

Documentarea practică prin culegerea de date din studiile de specialitate;

Culegerea și sistematizarea datelor;

Analiza comparativă a datelor, interpretarea rezultatelor și formularea de concluzii și propuneri.

CAPITOLUL I

STUDIU ASUPRA TEHNOLOGIILOR ACTUALE

1.1. Business Process Modelling

Profundele schimbări globale ating și domeniul afacerilor. În contextul rapidelor dezvoltări tehnologice și a globalizării piețelor și competiției, companiile folosesc noile tehnologii informaționale pentru reorganizarea radicală a modelelor de conducere a companiilor. Noile cerințe competiționale ale organizațiilor presupun o mai mare atenție dată clienților, costurilor scăzute, calității și adaptabilității continue.

1.1.1. Aspecte generale

O dată cu recunoașterea nevoii de schimbare, organizațiile vor da mai mare importanță proceselor cheie ale afacerilor cu impact direct asupra profitabilității și creșterii importanței clientului. Pentru a fi eficiente, organizațiile trebuie să fie capabile să își definească, analizeze, implementeze, măsoare și controleze procesele. Iar această schimbare nu ar putea fi posibilă fără educarea personalului și implemetarea tehnologiilor corespunzătoare. Fuziunile și achizițiile, schimbarea modelelor de afaceri, noile cerințe ale întreprinderii și schimbarea așteptărilor clienților, toate pun multiple probleme în legătură cu procesele din organizație.

1.1.1.1. Procesul de afaceri

Pentru a înțelege mai bine această tehnologie trebuie înțelese câteva noțiuni, precum ar fi managementul proceselor.

Un proces de afaceri este orice colecție de activități în cadrul companiei care are drept scop dezvoltarea produselor și serviciilor pentru clienți (Chang, 2006). Gestionarea în mod eficient a proceselor este – activitate critică pentru succesul companiei, iar acest lucru este mai greu de realizat decât pare la prima vedere – în mare parte datorită faptului că procesele nu sunt independente, ci interacționează reciproc (Fu-Ren, Yang și Pai, 2002).

Există mai multe tipuri de procese de afaceri, precum: procese cheie, procese suport și sub-procese.

Un proces tipic de afg

1.2.10.1. Categorii de produse data mining

1.2.10.2. Capabilități fundamentale

1.2.10.3. Forarea în WWW

1.2.10.3.1. Ierarhizarea paginilor

1.2.10.3.2. Probleme cu grafurile rețelei reale

1.2.10.3.3. Soluții Google pentru problemele rețelei

1.2.10.3.4. Dispozitive antispam

1.2.10.3.5. Centri și autorități

1.2.10.3.6. Găsirea seturilor neobișnuite de obiecte

1.2.10.3.7. Motorul DICE

1.2.10.3.8. Construirea tiparelor din apariții ale datelor

1.2.10.4. Învățarea automatelor

1.2.10.4.1. Aspecte generale

1.2.10.4.2. Contribuții la învățarea automatelor

1.2.10.4.3. Învățarea probabilă aproximativă corectă

1.2.10.4.4. Aplicații în lumea reală

1.2.11. Succesul în data mining

1.3. Process Execution

1.3.1. Aspecte generale

1.3.2. Proceduri de monitorizare a proceselor

1.3.3. Măsuri de monitorizare a proceselor

1.3.4. Metode de monitorizare a proceselor

1.3.5. Metodele analitice

1.3.6. Descrierea erorilor

1.3.7. Estimarea parametrilor

1.4. Enterprise Architecture

1.4.1. Arhitectura sistemului

1.4.1.1. Celulele

1.4.1.2. Serverele

1.4.1.3. Profilurile

1.4.1.4. Managerii de implementare

1.4.1.5. Nodurile

1.4.1.6. Agenții de nod

1.4.2. Instalarea aplicației Oracle SQL Developer Data Modeler

1.4.3. Proiecte Data Modeler

1.4.4. Crearea diagramelor fluxurilor de date

1.4.4.1. Crearea unui proces

1.4.4.2. Crearea unei entități externe

1.4.4.3. Crearea unui flux de date

1.4.4.4. Crearea unui loc de stocare

1.4.5. Analiza corectitudinii diagramelor

CAPITOLUL AL II-LEA. DEZVOLTAREA APLICAȚIEI

2.1. Business Use Case

2.1.1. Motivație

2.1.2. Principalele activități ale unei agenții de publicitate

2.1.2.1. Activitatea de urmărire a agenției

2.1.2.2. Activitatea de gestiune a utilizatorilor

2.1.2.3. Activitatea de gestionare a cererilor

2.1.2.4. Activitatea de gestiune a contractelor

2.1.3. Definirea obiectivelor sistemului informatic al unei agenții de publicitate

2.1.4. Modelarea sistemului informatic al unei agenții de publicitate

2.1.5. Nivelul cazurilor de utilizare

2.1.5.1. Diagrama principală a cazurilor de utilizare

2.1.5.2. Diagrame detaliate ale cazurilor de utilizare

2.2. Specificații, arhitectură și funcționalități

2.2.1. Modelarea procesului de afaceri

2.2.2. Simularea procesului

2.2.2.1. Descrierea succintă a activităților întreprinse

2.2.2.2. Realizarea diagramei procesului actual

2.2.2.3. Simularea costului și a beneficiilor reproiectării

2.2.3. Proiectarea

2.2.3.1. Diagrame de activități

2.2.3.2. Diagrama claselor

2.2.3.3. Rafinarea diagramei de clase

2.2.4. Implementarea

2.2.5. Desfășurarea

2.2.6. Realizarea diagramei procesului reproiectat

2.3. Raportul de test

2.3.1. Diagrama de clase fără atribute și operații

2.3.2. Diagrama de stare

2.3.3. Diagrama de secvență

2.3.4. Diagrame de colaborare

2.3.5. Diagrama BPMN a procesului de solicitare

2.4. Concluzii

Concluzii și contribuții personale

Bibliografie

Glosar

Anexe

INTRODUCERE

Lucrarea de față intitulată Analiza proceselor de afaceri pentru firma de publicitate, tratează problemele legate de analiza proceselor de afaceri, acest studiu bazându-se pe o bibliografie solidă a unor autori cunoscuți în materie, printre care amintesc: I. Andone, R. C. Appleby, V. Ariton, Patrice Briol, V. Cărciunoiu, D. Curiac, Lin Fu-Ren, M. Havey, T. Ionescu, L. P. Leach, Andrew W. Moore, C. Murray, Jan Recker, Lucia Rusu, B. Silver, M. Umble, C. Voloșencu, S. A. White, D. Zaharie și alții.

Lucrarea de față se dorește a fi o prezentare analitică a proceselor de afaceri. Se subliniază importanța acesora, precum și rolul lor în acțiunile desfășurate. De asemenea, în lucrare, se fac referiri la data mining.

Lucrarea este structurată în două capitole.

Capitolul întâi, intitulat Studiu asupra tehnologiilor actuale, are menirea de a prezenta succint aspectele teorice ale proceselor de afaceri

Organizarea anchetei din capitolul al doilea, intitulat Dezvoltarea aplicației, are rolul de a verifica analiza proceselor de afaceri la o agenție de publicitate

Metoda de cercetare pe care o voi folosi este una calitativă, preponderent explicativă, care are ca obiectiv prezentarea principalelor concepte și explicații teoretice, dar și a analizei acestora în situații concrete. Am ales cercetarea calitativă pentru că presupune un ansamblu de metode, subiectul fiind cercetat dintr-o perspectivă naturalistă și interpretativă.

Pe baza informațiilor prezentate pe parcursul lucrării în cele două capitole amintite, sunt formulate, în final, unele concluzii și recomandări referitoare la tematica lucrării abordate.

Prin prezenta lucrare, am dorit să demonstrez importanța deosebită a cunoașterii aspectelor definitorii privind analiza proceselor de afaceri, întru realizarea scopului propus stabilindu-mi următoarele: analiza aspectelor teoretice și metodologice privind procesele de afaceri; identificarea și analiza lacunelor, confuziilor și contradicțiilor în ceea ce privește tema abordată.

Obiectivele urmărite în această cercetare sunt următoarele:

Stabilirea temei de cercetare: analiza proceselor de afaceri pentru firma de publicitate;

Selectarea bibliografiei în vederea documentării, selecționând atât materiale informative pur teoretice, cât și rapoartele unor studii de caz pe aceeași temă, elaborate în prealabil de către specialiști;

Documentarea propriu-zisă atât din materialele selectate, cât și urmărirea unui curs de specializare în materie;

Interpretarea și prelucrarea datelor obținute.

Modelele și ariile abordate în această lucrare sunt:

Documentarea teoretică din cărțile de specialitate indicate selectiv în bibliografie;

Documentarea practică prin culegerea de date din studiile de specialitate;

Culegerea și sistematizarea datelor;

Analiza comparativă a datelor, interpretarea rezultatelor și formularea de concluzii și propuneri.

CAPITOLUL I

STUDIU ASUPRA TEHNOLOGIILOR ACTUALE

1.1. Business Process Modelling

Profundele schimbări globale ating și domeniul afacerilor. În contextul rapidelor dezvoltări tehnologice și a globalizării piețelor și competiției, companiile folosesc noile tehnologii informaționale pentru reorganizarea radicală a modelelor de conducere a companiilor. Noile cerințe competiționale ale organizațiilor presupun o mai mare atenție dată clienților, costurilor scăzute, calității și adaptabilității continue.

1.1.1. Aspecte generale

O dată cu recunoașterea nevoii de schimbare, organizațiile vor da mai mare importanță proceselor cheie ale afacerilor cu impact direct asupra profitabilității și creșterii importanței clientului. Pentru a fi eficiente, organizațiile trebuie să fie capabile să își definească, analizeze, implementeze, măsoare și controleze procesele. Iar această schimbare nu ar putea fi posibilă fără educarea personalului și implemetarea tehnologiilor corespunzătoare. Fuziunile și achizițiile, schimbarea modelelor de afaceri, noile cerințe ale întreprinderii și schimbarea așteptărilor clienților, toate pun multiple probleme în legătură cu procesele din organizație.

1.1.1.1. Procesul de afaceri

Pentru a înțelege mai bine această tehnologie trebuie înțelese câteva noțiuni, precum ar fi managementul proceselor.

Un proces de afaceri este orice colecție de activități în cadrul companiei care are drept scop dezvoltarea produselor și serviciilor pentru clienți (Chang, 2006). Gestionarea în mod eficient a proceselor este – activitate critică pentru succesul companiei, iar acest lucru este mai greu de realizat decât pare la prima vedere – în mare parte datorită faptului că procesele nu sunt independente, ci interacționează reciproc (Fu-Ren, Yang și Pai, 2002).

Există mai multe tipuri de procese de afaceri, precum: procese cheie, procese suport și sub-procese.

Un proces tipic de afaceri include (Briol, 2008):

Aprovizionare: asigurând materialele și echipamentul necesar producerii bunurilor și serviciilor.

Dezvoltarea produselor: planificarea noilor produse sau servicii destinate clienților sau perfecționarea produselor existente.

Producție: crearea produselor și serviciilor.

Comenzi-livrare: primirea comenzilor de la clienți și asigurarea onorării acestora.

Distribuție: asigurând distribuția în condiții sigure a bunurilor către clienți.

Suport pentru clienți: oferind asistență clienților după ce aceștia au cumpărat produsele și serviciile.

Cel mai important avantaj al orientării pe procese este acela că ajută la înțelegerea modului cum se desfășoară lucrurile în organizație, scoțând în evidență problemele, ineficiențele, care într-o organizație tipică ar rămâne ascunse dând falsa impresie că totul s-ar desfășura normal.

Sunt multiple motive pentru care organizațiile nu reușesc să-și gestioneze eficient procesele. Când procesele cresc în diferite departamente funcționale, un singur manager de proces poate controla foarte ușor procesele din întreaga organizație. De exemplu, un departament poate să introducă un soft nou pentru a-și moderniza propriul proces, dar acest soft nu se încadrează total cu cerințele tuturor departamentelor. Soluția constă în o mai b#%l!^+a?atentă analiză și a decide ceea ce e mai bine pentru întreaga organizație din punctul de vedere al BPM.

1.1.1.1.1. Conceptul de proces de afacere în organizație

Tehnologia informației este considerată inovatoare în raport cu descrierea și implementarea unei strategii de afaceri, iar procesele de afaceri au rol catalizator în creșterea valorii de afaceri a tehnologiei informației. De aceea, pentru orice întreprindere, procesele de afaceri se concretizează atât în contextul, cât și în fundamentul necesar dezvoltării sistemelor informatice pentru întreprinderi.

Procesele din întreprinderi sunt mijloacele prin care orice organizație își conduce afacerea, încorporând orice activitate sau grup de activități care adaugă o valoare unei resurse interne, pentru a obține un produs sau un serviciu destinat unui beneficiar (intern sau extern organizației). O singură întreprindere execută un număr mare de procese de afaceri pentru realizarea obiectivelor sale strategice, în acest fel furnizând oportunitatea utilizării tehnologiei informatice pentru îmbunătățirea proceselor și a performanțelor organizaționale (Porter și Millar, 1985). Noile tehnologii informatice permit nu doar îmbunătățirea proceselor individuale, dar pot oferi posibilități de integrare a proceselor de afaceri între unități fizice și organizaționale disipate (Basu și Blanning, 2003).

O clasificare simplistă a proceselor de afaceri le împarte pe acestea în elementare și complexe. Deosebirea dintre cele două ar consta în numărul de activități pentru care au fost definite. Astfel, un proces complex implică, de obicei, mai multe funcții esențiale ale întreprinderii, iar operațiile sale au un impact semnificativ asupra funcționalității generale a activității organizaționale. Pentru a surprinde întreaga hartă a activităților depuse și sarcinilor implicate, se procedează, de obicei, la divizarea proceselor complexe în subprocese, până la obținerea de procese elementare care definesc o singură funcție pe care întreprinderea trebuie să o realizeze prin activitățile sale. Activitățile sunt elemente componente ale unui proces sau subproces realizate în mod individual de o singură entitate subdivizionară (de obicei, un departament al întreprinderii). Orice activitate este definită prin ansamblul de sarcini din care este alcătuită și care sunt asignate indivizilor din cadrul departamentului în responsabilitatea căruia intră realizarea respectivei sarcini (Gruden și Strannegard, 2003).

În opinia majorității specialiștilor în managementul organizației, procesele de afaceri pot fi privite atât ca scopuri în realizarea unei strategii de afaceri, cât și ca modele de automatizare a afacerii prin utilizarea tehnologiilor informatice. Totuși, ei atrag atenția cu privire la abordarea proceselor exclusiv prin prisma dezvoltării sistemelor informatice, fără a ține cont de realitatea economică ce definește activitatea unei întreprinderi. Aceasta ar pune accentul pe date și proceduri, având ca principal obiectiv relațiile dintre elementele procedurale și maniera de utilizare a datelor, iar conceptul de proces de afacere poate fi privit ca mijloc de analiză a modului în care aplicațiile unui sistem informatic pot fi integrate în scopul identificării oportunităților oferite de automatizarea proceselor (Havey, 2005).

Figura 1. Structura ierarhică a proceselor de afaceri din întreprinderi

În prezent, în dezvoltarea sistemelor informatice pentru întreprinderi, se constată că paradigma programării încă deține o influență majoră în descrierea proceselor de afaceri, activitatea întreprinderii fiind alcătuită din procese definite în conformitate cu funcțiile sistemului informatic. Acest mod de tratare a proceselor de afaceri limitează funcțiile acestora la ceea ce poate realiza sistemul informatic și nu ține cont, întotdeauna, de întreaga realitate economică. Deși sistemul informatic din cadrul unei organizații joacă, în prezent, un rol crucial de susținere a activității specifice întreprinderii, majoritatea proceselor economice nu pot fi complet automatizate. De fapt, automatizarea completă se poate realiza doar pentru anumite activități de afaceri ce pot fi privite doar ca etape funcționale ale unui ansamblu mai complex de alte procese economice.

1.1.1.1.2. Managementul proceselor de afaceri

În practica de afaceri și a managementului organizațional, s-au conturat două perspective cu privire la organizarea și conducerea afacerii unei întreprinderi: una orientată pe funcții și cealaltă orientată pe procese.

Perspectiva funcțională privește problemele specifice activității de management din punctul de vedere al resurselor organizației puse la dispoziția departamentelor în scopul realizării anumitor funcții particulare afacerii. Perspectiva orientată pe procese este oarecum complementară perspectivei funcționale, căutând să optimizeze performanța întreprinderii pe seama îmbunătățirii proceselor cheie care definesc fundamentul afacerii întreprinderii (Harrington, Esseling și van Nimwegem 1997).

Perspectiva funcțională a managementului este utilă pentru optimizarea resurselor interne, în timp ce perspectiva orientată pe procese privește coordonarea activităților complexe ale întreprinderii, care implică și resurse externe.

Gestionarea acestor procese într-o viziune unitară și în sensul impus de perspectiva orientată pe procese a generat un concept des utilizat, acela de management al proceselor de afaceri (Business Process Management). Deși este un termen îndelung disputat în literatura de specialitate, definițiile pe care diverși autori le-au furnizat sunt conturate pe baza aceleiași idei de optimizare a proceselor întreprinderii prin diverse mijloace specifice. În linii mari, termenul Business Process Management (BPM) desemnează atât o strategie de afaceri, cât și un segment software, destinate să gestioneze eficiența și randamentul proceselor din cadrul întreprinderii, prin practici de modelare, automatizare și monitorizare (Herayizadeh, Mendling și Rosemann, 2009).

Ca disciplină de management, BMP înlocuiește perspectiva funcțională a managementului cu cea orientată pe procese aliniată cu obiective de afaceri de nivel înalt.

Ca tehnologie sau segment software, BMP furnizează un set de instrumente software necesare pentru optimizarea performanței, realizarea obiectivelor concrete de b#%l!^+a?performanță, automatizarea și monitorizarea activităților și sarcinilor aferente proceselor de afaceri și furnizarea unei platforme software pentru îmbunătățirea performanței afacerii (Juric și Sasa).

Adresându-se proceselor complexe dintr-o întreprindere, BPM implică nu doar angajații unei organizații, ci și clienții, furnizorii și ceilalți parteneri ai săi. Implementarea unui sistem de management al proceselor de afaceri furnizează, pe lângă returnarea investiției, și noi nivele de analiză, vizibilitate, responsabilitate și predictibilitate pentru afacere.

Un sistem de management al proceselor din întreprindere privește orice proces prin prisma ciclului de viață al acestuia. Sistemul de gestionare a proceselor face referire la aceste etape ale ciclului de viață, de la apariția procesului în cadrul întreprinderii și până la eventuala eliminare a lui din strategia de afaceri. Astfel, sistemele Business Process Management dețin patru arii principale de activități, corespunzătoare principalelor etape din ciclul de viață al proceselor de afaceri: proiectarea și modelarea, implementarea sau execuția, monitorizarea și optimizarea proceselor. Aceste arii de activități sunt iterative și trebuie gestionate în orice stadiu al proceselor de afaceri (Kabilan, 2005).

Figura 2. Ciclul de viață al proceselor de afaceri (Ward-Dutton și Macehiter, 2005)

Proiectarea și modelarea proceselor de afaceri trebuie să surprindă complexitatea și dinamica fiecărui proces ce va fi inclus în strategia de afaceri și să explice modul în care acesta va afecta activitatea întreprinderii și va contribui la adăugarea unui plus de valoare în cadrul lanțului valoric specific (Silver, 2008).

Implementarea sau execuția privește, pe de o parte, includerea unor noi procese de afaceri în activitatea specifică întreprinderii, iar pe de altă parte, adoptarea noilor modele stabilite în cadrul etapei de modelare a proceselor existente, care necesită îmbunătățiri sau restructurări. Implementarea trebuie să țină cont nu doar de integrarea proceselor noi cu cele existente, dar și de atribuirea responsabilităților pe roluri asociate proceselor și gestionarea acestor roluri (Silver, 2008).

Monitorizarea este o componentă vitală în abordarea managementului proceselor de afaceri, în primul rând datorită faptului că o perspectivă a afacerii orientată pe procese este, de cele mai multe ori, asociată cu nevoia de vizibilitate a performanțelor și a conformității cu strategia de afaceri și în al doilea rând, datorită nevoii de evidențiere a eficienței și randamentului proceselor (Silver, 2008). Monitorizarea se referă la acel set de activități care permit descoperirea anumitor elemente, care confirmă sau infirmă utilitatea unui proces de afaceri, dar și a anumitor anomalii ce nu ar putea fi vizibile în etapele anterioare de proiectare și modelare statică. De aceea, tehnologia de monitorizare oferă un feedback vital atât managerilor afacerii, cât și persoanelor responsabile cu implementarea proceselor, beneficiind de suport tehnic din aria auditului financiar și informatic.

Optimizarea este procesul de analiză a informațiilor colectate prin activitatea de monitorizare și de definire a unor posibile direcții de rafinare a modelelor proceselor de afaceri și a implementării acestora (Silver, 2008). De fapt, optimizarea este responsabilă de caracterul iterativ al proceselor de afaceri, întrucât ea este cea care determină reluarea etapelor de modelare, implementare și optimizare a acestora.

Definirea proceselor de afaceri a devenit nucleul unui limbaj comun între oameni de afaceri și specialiști IT. În acest context, Business Process Management rămâne o disciplină care combină capabilitățile software cu expertiza de afaceri pentru accelerarea optimizării și îmbunătățirii proceselor și pentru a facilita inovarea afacerii unei întreprinderi. Acest aspect a fost înțeles de majoritatea companiilor furnizoare de soluții informatice integrate pentru întreprinderi, pentru care managementul proceselor constituie punctul de plecare în definirea unei arhitecturi informaționale care să deservească afacerea întreprinderii prin utilizarea tehnologiilor existente și nu invers.

1.1.1.1.3. Procese de afaceri și BPD

Putem defini un proces de business ca o succesiune de activități de business realizate de către participanți, cu scopul de a-și atinge obiectivele și de a livra valoare. Aceste procese pot fi modelate pe trei nivele de detail, iar BPMN le suportă pe toate (Pant și Juric, 2008):

Harta procesului (Process map) – este o diagramă simplă de activități.

Descrierea procesului – este o diagramă de activități extinsă cu informații adiționale.

Modelul procesului – este o diagramă de activități extinsă cu suficiente informații, astfel încât procesul să poată fi analizat, simulat sau executat folosind BPEL – Business Process Execution Language.

În analiza de business, procesele – independent de tipul lor (de management, operaționale sau de suport) trebuie modelate pentru a beneficia de următoarele avantaje (Recker, 2006):

Asimilare – procesele, dacă sunt împărțite în activități atomice, pot fi mai bine înțelese de către toți participanții la livrare.

Monitorizare și evaluare – procesele, dacă sunt reprezentate clar și concis pot fi mai bine monitorizate și evaluate și li se pot aplica anumiți indicatori de performanță (KPI – Key Performance Indicators).

Optimizare – procesele, dacă sunt descompuse în activități independente și interconectate, pot pune în evidență blocaje (bottlenecks), căi duplicate, căi alternative și bucle, putând fi astfel candidate la îmbunătățiri.

Creare de procese noi – procesele, dacă sunt corect modelate, reflectând starea actuală a sistemului (as-is system), sunt un punct solid de pornire pentru modificări funcționale (change requests) sau extensii ulterioare (to-be system).

Automatizare – procesele, dacă sunt reprezentate pas cu pas, pot fi ușor automatizate, reducând astfel costurile asociate cu dezvoltarea și testarea, îmbunătățind calitatea produsului și optimizând etapele de mentenanță și suport.

Diagramele oferite de BPMN, numite BPD – Business Process Diagrams sunt similare b#%l!^+a?diagramelor de activitate, fiind însă cu mult mai expresive și ușor de asimilat și putând fi totodată executate de utilitarele BPEL (Recker, 2008).

Pentru a crea BPD-ul, analistul de business identifică și modelează evenimentul de început al procesului, apoi celelalte evenimente, în ordinea în care se petrec până la evenimentul care încheie procesul. Deciziile de business și căile alternative se modelează folosind blocuri de decizie (gateways). Dacă procesul de business este unul complex, el poate fi descompus în sub-procese, fiecare dintre acestea fiind modelat printr-o BPD aferentă, iar rezultatele obținute vor fi interconectate, pentru a obține vederea de ansamblu (Recker, 2008).

1.1.2. BPMN la prima vedere

BPMN (Business Process Modeling Notation) reprezintă un standard important pentru modelarea proceselor, care a ajuns la un nivel de importanță foarte înalt în practicile BPM (Business Process Model), practici ce presupun optimizarea proceselor de afaceri.

Acesta este un limbaj ce permite definirea unei multitudini de scenarii în desfășurarea activității unei organizații, de la nivelul unor procese interne specifice și până la nivelul proceselor inter-organizaționale, cuprinzând interacțiuni între servicii și excepții în fluxurile de lucru.

În timp BPMN a început să fie adoptat la scară largă în practică de diverse organizații,

cum ar fi:

Furnizori de instrumente: Pega, Sparx Systems, Telelogic, Intalio, itp-commerce;

Instituții de învățământ: Widener University, Queensland University of Technology și Howe School of Technology Management;

Experți și consultanți în modelare: Object Training, BPM-Training.com și BPMInstitute.org.

1.1.2.1. Istoricul BPMN

BPMN a fost dezvoltat de un consorțiu format din reprezentanți ai celor mai importante organizații din sfera pieței instrumentelor BPM, sub forma unei înțelegeri de utilizare a unui standard comun.

BPMI (Business Process Management Initiative), care acum face parte din OMG (Object Management Group) a dezvoltat BPML, un limbaj de execuție a proceselor XML.

BPML a fost mai târziu înlocuit de BPEL (Business Process Execution Language), un limbaj de execuție.

În 2004, BPMI a dezvoltat și publicat BPMN versiunea 1.0.

În anul 2006, BPMI a acordat drepturile de gestionare a BPMN grupului OMG, un consorțiu non-profit din industria standardelor IT. Acest consorțiu deține o multitudine de specificații, printre care: UML, CORBA, CWM și multe alte standarde din domeniu.

În anul 2008, OMG a lansat versiunea 1.1 pentru BPMN, iar în ianuarie 2011 a fost lansată ultima versiune 2.0. Versiunea 2.0 și-a propuns să: linieze BPMN cu BPDM (Business Process Definition Meta Model); includă câteva extensii suplimentare, cum ar fi accesorii pentru coregrafia procesului (process choreography); ofere scheme XML pentru transformarea modelului; extindă BPMN prin modelarea afacerii și să ofere suport pentru deciziile executive.

1.1.2.2. Utilizarea BPMN

BPMN consolidează cele mai bune idei din alte specificații, incluzând: diagramele de activitate UML, IDEF, eBXML, BPSSm ADF, Event-Process Chains (EPCs).

Standardul oferă numeroase beneficii în trainingul utilizatorilor finali, prin ușurința înțelegerii de către toți membrii dintr-o organizație (Rusu,Iuga și Marțiș, 2011): analiști care realizează diagramele de procese; specialiștii IT care implementează și integrează activitățile proceselor organizației; restul specialiștilor non-IT din cadrul organizației, ce gestionează și monitorizează procesele afacerii.

BPMN oferă un mecanism pentru generarea proceselor executabile ale organizației BPEL. Astfel, un proces modelat de un analist poate fi aplicat direct instrumentului BPM, interpretarea umană și traducerea în alte limbaje nemaifiind este necesară.

Printre obiectivele secundare urmărite se numără (Tcherevik): nu-și mai are locul existența unui alt pas între modelare și implementare; asigură descrierea cu o notație orientată spre afacere a limbajului XML, utilizat pentru executarea proceselor organizației (BPEL); oferă un standard de notare pentru modelare răspândit; pune la dispoziție un mijloc de comunicare generalizată a informațiilor pentru toate procesele.

Specificațiile BPMN conțin două părți (White, 2005): descrierea elementelor vizuale ale standardului, o dată cu utilizarea acestora și, corelația dintre obiectele vizuale și traducerea lor în limbajul de execuție (BPEL4WS). Această parte este utilizată de către furnizorii de instrumente în dezvoltarea soluțiilor tehnice.

De asemenea, specificațiile descriu două niveluri abstracte în modelarea proceselor, cum ar fi: nivelul rezumat, ce conține numai elementele grafice principale ce vor fi folosite de analist; nivelul detalii, cu elemente complementare vizuale și mecanisme utilizate, în principal, pentru asigurarea corectitudinii procesului de implementare.

1.1.2.2.1. BPMN 2.0

Viziunea BPMN 2.0 este de a avea o singura specificatie pentru un nou BPMN care definește formatul notației, metamodelului și interschimbului, dar cu un nume modificat care păstrează încă brand-ul BPMN. Caracteristicile includ (http://www.omg.org/spec/BPMN/2.0):

Alinierea BPMN cu BPDM pentru a forma o singură limbă coerentă.

Permiterea schimbului modelelor de proces de activități și aspectelor de diagramă între instrumentele de modelare a proceselor pentru a păstra integritatea semantică.

Mărirea BPMN pentru a permite orchestrarea și coregrafierea modelelor ca modele de sine stătătoare sau integrate.

Suportarea afișării și interschimbului de perspective diferite ale unui model care să permită unui utilizator să se concentreze asupra preocupărilor specifice.

Serializeazarea BPMN și furnizarea schemelor XML pentru transformarea modelelor și extinderea BPMN spre modelare de activități și suport pentru deciziile executive.

Versiunea finală a specificației a fost terminată în ianuarie 2011.

1.1.2.3. Statistici

În anul 2008, un grup de cercetători de la Queensland University of Technology a dorit să afle în ce măsură este BPMN utilizat în practică la scară largă, mai exact, la nivel global. Aceștia au proiectat și administrat un chestionar adresat modelatorilor BPMN aflați oriunde în lume. Timp de patru luni, pe parcursul anului 2007, 590 de utilizatori BPMN aflați în toate colțurile lumii au răspuns la acel chestionar. În total, au fost colectate date de la modelatori BPMN din peste 30 de țări. Distribuția geografică globală a respondenților evidențiază distribuția generală a practicienilor BPM.

După cum se poate observa în Figura 3, Europa, America de Nord și Oceania dețin o treime din totalul răspunsurilor. Aproape 60% dintre respondenți lucrează în sectorul privat. Peste 40% dintre aceștia lucrează în organizații mari cu peste 1000 de angajați, în timp ce 22,7% și 26,8% dintre cei care au răspuns, lucrează pentru organizații de mărime medie respectiv, organizații mici.

Figura 3. Țările participante și continentele de origine

Mărimea echipei de modelare, în care aceștia lucrează, variază de la mai puțin de 10 membrii (64,4% dintre respondenți) până la mai mult de 50 de membrii (3,8% dintre respondenți). Se pare că și în cadrul organizațiilor mari, echipa dedicată modelării BPMN este mică.

În ceea ce privește instrumentele folosite în modelarea BPMN, studiul cuprinde o listă cu cele mai populare instrumente folosite și cu ceea ce un utilizator dorește de la un astfel de instrument.

Microsoft Visio cu șabloanele sale BPMN disponibile este cel mai utilizat instrument (18,2%), însă neavând un management al utilizatorilor, rămâne la stadiul unui instrument de familiarizare cu BPMN.7

Clasamentul continuă cu soluția Itp-Commerce (7,8%), ce reprezintă un plug-in ce extinde capacitățile de modelare ale Visio cu un motor de simulare BPMN, cu atribute adiționale și opțiuni diverse de analiză.

Printre celelalte opțiuni disponibile, se numără câteva soluții la scară mică: Sparx Systems (6,9%), Telelogic (5,7%), Intalio (5%), IDS Scheer și Casewise, ultimele două cu o cotă de piață de 3,3% (Herayizadeh, Mendling și Rosemann, 2009).

Din punct de vedere al funcționalităților folosite de către utilizatori, studiul arată că sunt utilizate în principal arhive de modele, browsere de modele și funcționalități similare implementate în instrumentele de modelare pentru suportul navigării în cadrul unui număr mare de modele BPMN – funcționalități pe care Visio nu le poate asigura.

De asemenea, de obicei, modelele BPMN sunt extinse cu simboluri adiționale (riscurile legate de procese, informații organizaționale, indicatori de performanță) sau chiar alte modele (grafice organizaționale, specificații pentru regulile afacerii, descrieri de servicii).

Toate acestea apar, deoarece BPMN este un limbaj de modelare a proceselor, însă o multitudine de sarcini organizaționale necesită informații suplimentare, fie pentru specificațiile de fluxuri de lucru (resurse, date, obiecte), fie pentru managementul de conformitate (riscuri, strategii de aliniere, proprietarii de procese).

Tabelul 1. Suportul oferit de instrumentele BPMN

BPMN dispune de o gamă variată de simboluri, însă cercetătorii au fost interesați în mod deosebit să vadă în ce măsură sunt acestea utilizate (Herayizadeh, Mendling și Rosemann, 2009). Figura 4 evidențiază care sunt simbolurile uzuale în practică. După cum se poate observa, cele mai utilizate simboluri sunt: flux normal (normal flow), eveniment (event) și legătură (link). În categoria celor mai puțin utilizate se află: conector de pagină (off-page connector), instanțe multiple (multiple instances) și grupuri (group).

Figura 4. Utilizarea simbolurilor BPMN

1.1.2.4. Avantajele și dezavantajele BPMN

Pentru a releva avantajele și dezavantajele BPMN, sunt necesare părerile specialiștilor din domeniul modelării, în mod special, a acelora care au lucrat în practică cu acest standard. Având în vedere faptul că numărul cazurilor de utilizare în practică este unul destul de limitat, iar rapoartele de utilizare sunt puține, singurele surse de informare pertinente sunt forumurile din domeniu. Astfel, după o privire de ansamblu asupra câtorva dintre acestea, au fost schițate, mai jos, câteva avantaje și dezavantaje.

BPMN este mult mai expresiv decât alte limbaje similare, UML (diagrama de activități sau diagrama de secvențe) sau Petri nets. Acest limbaj poate exprima aproape orice fel de proces administrativ sau al domeniului afacerii. Utilizează două niveluri de reprezentare a informațiilor: un nivel cu notații grafice foarte ușor de înțeles; un al doilea nivel care, o dată cu definirea unui set de atribute, poate fi utilizat pentru a acoperi o specificație mult mai largă. În cazul CWM atributele pot fi definite de către utilizator, cu scopul de a modela diferite caracteristici specifice unei situații (Rusu,Iuga și Marțiș, 2011).

Fiind în primul rând un limbaj de natură grafică, acesta poate fi înțeles cu ușurință de către o varietate de specialiști, atât analiștii, proiectanți ai proceselor de afaceri, cât și de experții în domeniu: avocați, manageri, manageri de top, dezvoltatori software, utilizatori simpli. În al doilea rând, setul de atribute non-grafice determină ca BPMN să devină un limbaj de notație puternic ce poate fi pliat pe specificul organizației (Pant și Juric, 2008).

Diferitele tipuri de utilizatori pot avea perspective diverse asupra întregii diagrame BPMN. CWM este exprimat potrivit unui nivel înalt de abstractizare, ce creează tipurilor de utilizatori o perspectivă asupra modului în care fiecare rol va acționa asupra procesului.

În același timp, detaliile de pe nivelul cel mai de jos al procesului pot fi încapsulate în același CWM de nivel înalt. Astfel, fiecare rol poate avea o perspectivă diferită asupra întregii CWM. Spre exemplu, un cumpărător nu este interesat de activitățile întreprinse de către producător în realizarea produselor. El poate vizualiza doar produsele ce pot fi comandate, prin efectuarea operațiunilor drill down asupra activităților lui, mai exact, activitatea de achiziționare a produselor (Kabilan, 2005).

BPMN este extensibil, elementele grafice pot fi extinse, astfel încât, limbajul să se poată adapta la specificul domeniului. Deși BPMN restricționează adăugarea de elemente noi în nucleul limbajului, acesta permite analistului să adauge noi atribute definite de utilizator, să schimbe formatul și specificațiile machetei. Spre exemplu, cele trei tipuri de evenimente: start, intermediar și sfârșit, pot fi modificate pentru a avea diferite etichete interne și, de asemenea, pot fi adăugate informații adiționale (Ward-Dutton și Macehiter, 2005).

Câteva tipuri de bază ca: Message, Rule, Link, Compensation, Error, Timer sunt deja predefinite. Se pot adăuga etichete adiționale, cum ar fi, spre exemplu, o notație diferită pentru starea obligatorie (ObligationState).

Modelul BPMN este orientat către modelarea proceselor afacerii, oferind o tehnică de modelare a fluxurilor mult mai precisă și riguroasă.

Un alt avantaj al modelului BPMN este dat de fundația matematică solidă, concepută special pentru a se plia pe limbajul de execuție al afacerii. BPMN se poate mapa pe UML, oferind, astfel, o modelare precisă a afacerii, simplificând activitatea de proiectare a sistemului (Basu și Blanning, 2003).

Unul din cele mai mari dezavantaje al modelului BPMN rezultă din faptul că nu se poate genera cod sursă pe baza diagramelor. Multe companii aleg UML ca standard de modelare, deoarece permite generarea de cod sursă, reducându-se din volumul de muncă al programatorilor. Având în vedere faptul că, pe baza codului generat și modificat de către programatori, se pot genera diagramele și se pot verifica, în ansamblu, modificările programatorilor (Gruden și Strannegard, 2003).

Extensibilitatea, deși un punct forte al modelului BPMN, poate fi și un mare dezavantaj al acestuia dacă nu este folosită corect. Astfel, dacă sunt definite și folosite prea multe elemente grafice, utilizatorii pot fi derutați și confuzi în procesul de înțelegere a diagramei (Recker, 2008).

Specificațiile BPMN acoperă numai descrierea elementelor de notație, nu oferă o definiție specifică pentru proiectarea proceselor din organizație sau o metodologie de implementare.

Notațiile BPMN se concentrează pe procesele organizației fără a acoperi celelalte aspecte ale afacerii: graficele și resursele organizației; modelul informațional al datelor; strategia afacerii; regulile afacerii.

1.1.3. Standardele BPMI.ORG

BPMI a dezvoltat trei standarde pentru a facilita BPM (White, 2005):

BPMN, ca un standard de modelare a proceselor de business-ului.

BPML, limbajul de modelare al procesului de business, ca standard al limbajului de execuție al business-ului.

BPQL, limbajul de interogare al procesului de business, un standard de management al interfetei necesare pentru lansarea și execuția proceselor de e-Business.

O importanță și fundamentală deosebire a standardelor BPMI este aceea că au fost dezvoltate pe baza unui puternic fundament matematic, folosind ramura Pi-Calculus a procesului Calculi. Aceasta este o metodă formală de calcul care pune baza pentru procesele dinamice și mobile. Standardele BPMI sunt analoage cu baza matematică a teoriei relaționale care susține sistemele de management a bazelor de date relationale (RDBMS), ceea ce înseamnă că procesele de business concepute folosind standardul BPMN pot fi manipulate și executate direct, datorită disponibilității imediate a limbajului de execuție. Acest lucru este analog datorită funcționalității modelelor de date relationale și a generației de SQL/DDL. Limbajul de modelare a procesului de business (BPML) este conceput de către BPMI.ORG pentru a fi o baza Pi-Calculus standard de descriere a procesului de business (Recker, 2008).

Spre deosebire de precedentele tipuri de diagrame ale procesului de business, diagrama de proces de business BPMN a fost creată ținând cont de limbajele de execuție a business-ului și serviciile web. Notațiile speciale adăugate la diagrama dau o imagine generală asupra evenimentelor bazate pe mesaje și mesaje transmise între organizații.

BPMN arată specificații pentru a se mapa direct la standardul BPML și la oricare limbaj concurent de execuție a business-ului, nou introdus: BPEL4WS dezvoltat de BEA, IBM, MICROSOFT și alții (Recker, 2008).

OASIS (www.oasis-open.org) este o organizatie non-profit, un consorțiu global care conduce dezvoltarea, convergența și adoptarea standardelor de e-Business. OASIS produce în toată lumea standarde de securitate, servicii web, conformitate XML, tranzacții de business, publicații electronice, hărți tematice și interoperabilitatea între și cu medii de b#%l!^+a?afaceri. Atât BPML (de la BPMI. ORG), și BPEL4WS (de la Microsoft, IBM, și alții) au fost înscrise la OASIS, care a format un comitet tehnic menit să creeze un standard de limbaj de execuție al procesului de business. Rezultatul actual dat de acest comitet se numește Servicii web.

Statusul curent al BPML este acela ca este înregistrat ca fiind o specificatie care a influențat comitetul WS-BPEL.

1.1.3.1. Bune practici în modelarea BPMN

Chiar dacă limbajul BPMN este flexibil și nu ne impune constrângeri în ceea ce privește modelarea, este bine să respectăm câteva bune practici stabilite în prealabil la nivelul echipei de proiect, al departamentului sau al organizației (Basu și Blanning, 2003):

Activitățile procesului de business trebuie modelate în ordine cronologică, pe o cronologie de la stânga la dreapta.

Procesele de business încep de regulă cu un eveniment declanșator și continuă până la obținerea de rezultate.

Task-urile și activitățile din cadrul unui proces trebuie asociate la roluri relevante din punctul de vedere al business-ului.

Un model complet al procesului de business ar trebui să prezinte modul în care obiectele și/sau datele sunt transferate.

Procesele de business trebuie modelate ierarhic, descriindu-se sub-procesele componente, în cazul în care acestea există.

Este recomandată stabilirea și folosirea convențiilor de nume pentru modelarea proceselor de business, ca de exemplu: numele elementelor trebuie să fie scurte și concise; este redundant să repetăm cuvinte precum task sau proces în numele unui task respectiv proces; activitățile trebuie să aibă ca nume un verb; în numele complexe, fiecare cuvânt trebuie scris cu literă mare: de exemplu, vom denumi o activitate SolicitareAbsență nu solicitareabsență sau Solicitareabsență.

Dacă procesul de business evoluează în timp, este recomandat să versionăm BPD-urile create, pentru a putea fi urmărite schimbările.

1.1.3.2. Modelarea generală de lucru în vederea proiectării modelului de business

Se va specifica o singură diagramă de proces. Această diagramă va fi ușor de utilizat și înteles chiar și de către persoanele care nu au experință în domeniul tehnic (de obicei managerii). De asemnea, această diagramă va fi suficient de expresivă pentru a permite modelarea proceselor de business foarte complexe care vor fi ulterior mapate ușor în limbajele de implementare, simulare și execuție.

Pentru a modela un proces, utilizatorul va trebui: să identifice evenimentele importante din cadrul procesului de afaceri; să modeleze evenimentele identificate; să proceseze evenimentele care se execută; să centralizeze rezultatele obținute (Chang, 2006).

La pasul următor, se identifică elementele de tip decizional, precum și elementele de ramificare ale fluxului. Acestea se vor modela cu ajutorul unor elemente speciale denumite gateways. Aceste elemente vor fi similare cu blocurile decizionale din cadrul schemelor logice.

De asemenea, un proces poate conține la rândul lui alte subprocese, care vor fi reprezentate grafic prin intermediul unei alte diagrame conectate prin intermediul unei legături de blocul de tip proces care reprezintă părintele. Procesele care nu se vor descompune în alte subprocese sunt considerate task-uri (cel mai jos nivel de proces). Simbolizarearea grafică se realizează prin semnul „+” lângă numele procesului conform reprezentării specifice BPMN. Procesele care nu au acest semn sunt task-uri (Chang, 2006).

Pentru a scpecifica cine ce face evenimententele și procesele vor fi plasate în așa-zisele piscine care denotă cine execută procesul respectiv. Aceste elemente de grupare pot fi partiționate la rândul lor. Spre exemplu, organizația poate reprezenta piscina, iar o subdiviziue a ei să fie un department sau o divizie (Kabilan, 2005).

Evenimentele care se execută pot fi de mai multe tipuri și complexități. Când se modelează fluxuri de proces mai complexe cum sunt serviciile web B2B se vor folosi evenimente mai complexe precum: mesaje, timere, reguli de business, condiții de eroare, etc.

În centrul modelării procesului de business se află chiar procesele care pot fi de trei tipuri (Recker, 2006): proces, subproces și task. De aceea este foarte important ca utilizatorul să identifice corect procesele și ierarhiile care se stabilesc între acestea încă de la începutul etapei de proiectare.

Blocurile de decizie care modelează logica interacțiunii dintre procese vor avea implementări specifice fiecărui tip de operator logic: sau, și, sau-exclusiv. De asemenea, va exista o modelare specifică și pentru deciziile complexe realizate prin compunerea oparațiilor logice (Briol, 2008).

Pentru modelarea cât mai aproape de realitate a proceselor de afaceri, există posibilitatea de a defini regulile după care se defășoară. Sistemul nu permite crearea de legături între blocuri în situația în care sunt încălcate regulile respective. Astfel se reduce riscul de a introduce erori sau inconsistențe logice în proiectarea modelului.

În cadrul organizației, datele sunt transformate prin intermediul proceselor. Spre exemplu, un proces de tip comandă determină crearea unei comenzi. Atunci când produsul este livrat către consumator comanda a fost realizată. Dacă apar inconsistențe în modul de achitare al comenzii (informații eronate cu privire la datele despre cont, etc.) se poate determina anularea comenzii. Clientul poate să își corecteze informațiile legate de cont.

Pentru modelarea datelor în cadrul unei diagrame de proces, se vor identifica principalele tipuri de date și se vor utiliza obiecte de tip dată. Obiectele de tip dată sunt artefacte care reprezintă tipuri de elemente electronice și fizice. Datele reprezintă în esență entități (corespunzătoare tabelelor din baza de date) sau clase (corespunzatoare modelelor orientate obiect care conțin date).

Modelarea datelor poate fi opțională deoarece nu afectează în mod direct fluxul, ci mai degrabă oferă informații despre anumite procese.

1.1.3.3. Simularea proceselor

Un model descris conform pașilor de mai sus reprezintă o descriere logică a fluxului. Pornind de la modelul realizat, se va putea defini semantica asociată. Totuși, pentru a obține rezultate optime această abordare trebuie sincronizată cu etapa de simulare a procesului.

Simularea pentru un model, se referă la mimarea operațiilor de business care se vor realiza, prin testarea pas cu pas a evenimentelor. Pe parcursul simulării vor fi înregistrate metrici de performanță care vor se vor supune, ulterior, analizei și evaluării. Avantajul acestei etape este acela că reduce considerabil riscul de a comite erori cu consecințe grave în mediul real de lucru.

1.1.3.4. Maparea modelului de business peste modelul lingvistic implementat cu ajutorul ontologiilor și semanticii web

Semantica utilizată în modelul lingvistic se bazează pe ontologii. Structura rețelei va fi similară cu cea din WordNet. Regulile semantice și lexicale vor fi create pe baza unor euristici conform regulilor lingvistice și a logicii economice. Modelul lingvistic va avea la bază limbajul XML pentru modelarea și structurarea informațiilor.

În prezent, majoritatea modelelor lingvistice utilizează XML-ul și sunt construite peste limbajul de descriere al serviciilor web (WSDL) conform standardelor W3C. Fluxul major din cadrul WSDL este acela că limbajul amestecă descrierea interfețelor statice cu legarea informațiilor de anumite protocoale de comunicare.

Prin intermediul modelului lingvistic sunt reprezentate: fluxurile de date; mesajele; evenimentele; regulile de afaceri; excepțiile; tranzacțiile (distribuite, sincrone, asincrone, etc)

În vederea implementării unui model de business, primul lucru care trebuie avut în vedere este modelul serviciilor web care conțin funcționalitățile specifice fiecărui element al modelului. Serviciile web reprezintă baza pentru elementele descrise anterior. Această etapă va avea la rândul ei cinci subetape: proiectarea procesului de afaceri; dezvoltarea serviciilor care să implementeze funcționalitățile pentru componentele modelului; simularea procesului și relizarea anumitor modificări în vederea sporirii eficienței; publicarea serviciilor; modelarea serviciilor în concordanță cu procesele de business prin asamblarea și coordonarea comportamentului lor (Kabilan, 2005).

Modelarea proceselor de business este o etapă esențială în cadrul unei organizații. Cu ajutorul acestor modele se vor putea valorifica mai ușor și mai eficient experiențele anterioare.

Figura 5. Exemple de diagrame realizate pentru modelarea proceselor de afaceri cu BPMN – Procesul de afaceri din cadrul unei licitații

Figura 6. Exemple de diagrame realizate pentru modelarea proceselor de afaceri cu BPMN – Rezervarea biletelor

De asemenea, datorită faptului că se va utiliza un limbaj intuitiv, concis și clar pentru reprezentarea proceselor, evenimentelor, datelor, etc. în cadrul unui flux de afaceri, toate persoanele implicate (de la analiștii de afaceri la persoanele tehinice care vor implementa software-ul necesar) vor putea înțelege logica din spatele procesului modelat (Recker, 2008).

Cu ajutorul modelelor grafic, lingvistic și de simulare a procesului se vor putea crea mai ușor reguli de business care vor reprezenta baza de cunoștiințe a sistemului inteligent, ce va sprijini managementul organizației în procesul decizional.

1.1.3.5. Dificultățile managerilor de proiecte BPM

Dificultățile cu care se confruntă în general managerii de proiect se referă (Leach,2000) în principal la:

Estimarea excesivă a duratelor activităților. Majoritatea managerilor de proiect includ rezerve de timp în estimările activităților de proiect pentru a se putea proteja de variațiile obișnuite. Totuși deoarece activitățile din acest tip de proiecte, în special cele de analiză și modelare se desfășoară la început fără o cunoaștere detaliată a situației concrete, estimările realizate nu se bazează pe metrici cantitative care să permită aprecieri cu o acuratețe suficientă.

Existența unei cantități neglijabile de variație pozitivă în duratele activităților. În majoritatea proiectelor de BPM, persoanele implicate raportează în general finalizarea activităților la momentul planificat și nu mai devreme. Acest lucru se întâmplă de obicei datorită legii lui Parkinson prin care timpul rămas neutilizat se pierde. În plus, există si sindromul studentului (Goldratt, 1997) datorită căruia majoritatea persoanelor tind să realizeze mai puțin de o treime din muncă în primele două treimi ale duratei activităților. Majoritatea descoperă însă existența problemelor în ultima fază, dar timpul rămas nu mai permite finalizarea în timpul anticipat inițial. Astfel câștigul inițial de timp numit variație pozitivă se pierde și nu mai poate fi utilizat.

Dificultatea de a transmite de-a lungul proiectului variația pozitivă. Chiar dacă realizate mai devreme decât era prevăzut o mare parte din activitățile realizate astfel nu permit transferul acestui beneficiu activităților următoare din secvență deoarece persoanele ce ar trebui să preia această activitate sunt de regulă ocupate cu finalizarea altor activități.

Întârzieri datorate îmbinării punctelor de sincronizare ale activităților. Majoritatea proiectelor au drumuri ce cuprind puncte de sincronizare care definesc ori un drum critic ori un punct de reper menit să ofere zone de vizibilitate asupra stării proiectului. Cu cât există mai multe activități paralele înaintea punctului de sincronizare cu atât probabilitatea ca cel puțin o activitate să întârzie, crește și astfel induce această întârziere întregului proiect.

Concurența sarcinilor presupunea executarea în paralel a activităților din mai multe proiecte. Deși realizarea în paralel a activităților apare ca o modalitate de îmbunătățire a eficienței pentru că ar crește gradul de ocupare a resurselor, totuși aceasta favorizează munca în exces fără beneficii pozitive la nivelul sistemului ca întreg.

1.1.3.6. Utilizarea metodologiei lanțului critic

Abordarea lanțului critic este o aplicare directă a teoriei restricțiilor în managementul proiectelor și a primit o atenție deosebită în literatura recentă de management al proiectelor. Ca urmare a publicării de către Goldratt a cărții Lanțul critic în 1997, numeroase cărți (Newbold, 1998; Leach, 2000) și articole (Cabanis-Brewin, 1999; Herroelen, De Reyck și Demeulemeester, 1998; Leach, 1999; Patrick, 1999; Pinto, 1999, Rand, 2000; Umble și Umble, 2000) au fost scrise pentru a clarifica filozofia lanțului critic.

Elementele fundamentale ale metodologiei se bazează pe construirea unui program de referință folosind ca durate ale activităților estimări bazate pe un nivel de încredere de 50%. Datele de finalizare ale activităților individuale ca și punctele de reper (milestones) ale proiectului sunt eliminate iar concurența sarcinilor (multitasking) este evitată. Pentru a minimiza munca neterminată (work-in-progress) o rețea a proiectului este construită iar activitățile se poziționează cu durata de începere cea mai târzie în urma calculării drumului critic. În cazul apariției unor conflicte între resurse, aceste se rezolvă prin mutarea activităților mai devreme.

Lanțul critic este definit ca lanțul de activități dependente pe baza relațiilor de precedență și pe baza dependenței resurselor ce determină durata proiectului. Timpul de siguranță este eliminat din duratele activităților de pe lanțul critic prin stabilirea unor estimări optimiste și mutarea rezervelor la sfârșitul drumului critic sub forma unei rezerve a întregului proiect (project buffer). Această rezervă a proiectului va proteja data de finalizare a proiectului promisă clientului în fața variabilității activităților de pe drumul critic.

Rezervele speciale numite feeding buffers sunt inserate acolo unde o activitate non-critică sau un lanț non-critic întâlnește lanțul critic. Scopul lor este a proteja lanțul critic de probleme datorită activităților non-critice și să permită activităților lanțului critic să înceapă devreme dacă totul funcționează corect. Cu toate că metode detaliate pot fi utilizate pentru stabilirea mărimii rezervelor (Leach, 2000) procedura standard este de a le stabili după regula de 50% adică de a stabili rezerva proiectului la 50% din durata întregului proiect și a rezervelor de tip feeding la jumătate din durată celui mai mare lanț non-critic. Rezervele de resurse, de obicei prezente într-o formă de semnale de avertizare sunt plasate oriunde o resursă trebuie să realizeze o activitate pe lanțul criticm iar activitatea anterioară de pe lanțul critic este realizată de o resursă diferită.

În timpul execuției proiectului, atât lanțul critic cât și programul referință trebuie menținute neschimbate. Activitățile proiectelor sunt executate conform unei mentalități de tipul execuție rapidă – repaus (roadrunner) folosind o programare a proiectelor fără rezerve. Programarea este bazată pe activități cu date de începere cea mai devreme cu excepția acelor activități fără predecesori care pot fi începute la momentul de începere conform programării inițiale.

Realizarea mai rapidă a activităților decât programarea trebuie raportată, iar activitățile trebuie începute imediat ce munca este disponibilă. Execuția proiectului este realizată prin rezerve ca un mecanism pro-activ de semnalizare.

Pe măsură ce activitățile sunt încheiate, managerul de proiect trebuie să urmărească modul de consum al rezervei. Atât timp cât o porțiune predeterminată de rezervă rămâne neatinsă totul este considerat a se desfășura în condiții normale. Dacă rezerva se consumă dincolo de un anumit punct, o semnalizare este realizată, iar dacă se trece dincolo de un punct critic, acțiuni corective trebuie realizate cât mai rapid (Rand, 2000).

Într-un mediu de proiecte multiple această metodologie se bazează pe cinci pași: prioritizarea proiectelor organizației; planificarea proiectelor individuale conform metodologiei lanțului critic; ordonarea proiectelor; introducerea rezervelor la locul îngust; măsurarea și raportarea rezervelor; managementul rezervelor. Pasul 1 are drept obiectiv evitarea multitaking-ului între proiecte. Pasul 2 presupune identificarea resursei cu constrângere de capacitate la nivel de companie (loc îngust). Proiectele sunt ordonate în pasul 3 pe baza programării locului îngust. Acest lucru este realizat prin plasarea unei rezerve de capacitate în fața resursei strategice. În pasul 4, o rezervă la nivelul locului îngust este plasată înaintea activităților ce folosesc resursa strategică pentru a o proteja de problemele existente cu resursele non-strategice. Modul de management al rezervelor este similar cu cel din cazul proiectelor singulare în pașii 5 și 6 (Leach, 2000).

1.1.4. Fazele tipice ale unui proiect de tip BPM

Specificul acestui gen de proiecte a fost semnalat de mai mulți autori, o exprimare apropiată de mediul economic românesc regăsindu-se la Chang James F. (2006).

Din fazele enumerate, vom observa complexitatea acestui gen de proiecte, utilizarea interdisciplinară a numeroase arii din domeniul administrării afacerilor, managementului strategic, managementului calității, managementul schimbărilor, tehnologia informațiilor.

Literatura de specialitate nu a acordat suficientă atenție instrumentelor de management de proiect necesare pentru a desfășura cu succes acest gen de proiecte. Fiind un mix între proiectele de îmbunătățire de procese și proiectele software, dificultățile inerente acestora se regăsesc și aici în aceeași măsură, în plus intervenind o complexitate nouă: aceea a îmbinării metodologiilor a două tipuri de proiecte din arii diferite (îmbunătățirea de procese si tehnologia informațiilor).

1.1.4.1. Asumarea strategică a deciziei de utilizare a abordării

O dată ce organizația a ales să utilizeze aceste metode, trebuie să își asume la nivel organizațional această decizie. Acest lucru presupune în primul rând alinierea la nivelul deciziilor strategice din partea managementului de nivel superior. Implicarea managerilor la acest nivel asigura reducerea rezistenței pe care întâmpină astfel de proiecte la schimbările pe care urmează să le introducă.

1.1.4.2. Examinarea situației actuale

În ce privește examinarea situației actuale aceasta trebuie orientată pe următoarele aspecte (Chang, 2006):

Examinarea proceselor cuprinde catalogarea proceselor existente, identificarea proceselor cheie și prioritizarea acestora pentru implementare. Aici se pot utiliza o multitudine de criterii însă regulile cele mai uzitate sunt de analiză comparativă a costurilor și beneficiilor rezultate din automatizare și gradul de impact asupra altor procese.

Identificarea opțiunilor tehnologice presupune identificarea produselor susceptibile de a fi achiziționate, înțelegerea interfețelor cu aplicațiile deja existente, înțelegerea maturității grupurilor de suport referitoare la aceste soluții.

În final, pregătirea organizației pentru schimbare netezește terenul pentru amplele modificări în ceea ce privește practicile și modul de lucru al celor care vor utiliza această soluție.

1.1.4.3. Analiza

În această fază se includ atât activitățile de realizare a analizei propriu-zise a proceselor, cât și cele de organizare tipică a proiectului, și anume stabilirea misiunii proiectului, stabilirea echipei etc.

1.1.4.4. Concepția

Această fază presupune concepția propriu-zisă a soluției propuse, plecând de la o viziune de înalt nivel până la descrierea detaliată a componentelor soluției respective (logica proceselor, fluxurile detaliate, interfețele, modelele de date etc.)

1.1.4.5. Implementarea

Implementarea presupune activități similare proiectelor de dezvoltare software, parametrizări, teste unitare și de integrare. Testele de calitate și cele de acceptanță din partea utilizatorilor sunt cruciale de a fi derulate înainte de punerea în producție, evitându-se astfel grave probleme ce pot surveni.

1.1.4.6. Suportul funcțional tehnic

Ultima fază presupune atât activitățile de suport funcțional, cât și tehnic necesare utilizatorilor finali pentru a începe să utilizeze eficient și eficace noul sistem.

1.1.5. Modelarea proceselor de afaceri folosind BPMN

După cum știm, procesele economice ale unui întreprinderi sunt supuse modelării, iar această activitate presupune utilizarea, de către analiști a unor tehnologii ultraperformante, precum BPM (Business Process Management). Așadar, BPM reprezintă un set de tehnologii și standarde specializate în proiectarea, execuția, administrarea și monitorizarea proceselor din întreprinderi.

Putem începe prin a spune că, notațiile Business Process Modelling Notation se referă la reprezentarea grafică a proceselor de afaceri într-un flux de lucru (workflow). Modelul BPMN cuprinde trei tipuri de submodele și anume: procesele private (interne), procesele abstracte (publice), respectiv procese de colaborare (globale).

Mai putem aminti și faptul că atributele unei diagrame de proces în notația BPMN se referă la identitatea obiectului, nume, versiune, autor, limba în care sunt redactate textele, limbajul pentru sintaxa interogărilor, data creării, data modificării, numărul de pool-uri și textul care o documentează.

Atributele proceselor din notația BPMN se referă la: nume, tipul procesului, starea, elementele grafice, responsabilii, atribuirile și proprietățile, intrările, ieșirile și valorile logice atașate.

Standardul BPMN recomandă ca în cazul în care se folosesc prea multe tipuri de submodele combinate (trei sau mai multe procese) cu fluxuri de mesaje între ele, atenția acordată trebuie să fie mai mare pentru a nu se complice lucrurile, dacă se ajunge la diagrame mult prea complexe și greu de înțeles. De asemenea, BPMN acordă atenție proceselor private și colaborative.

1.1.5.1. Analiza procesului de afaceri pentru construirea ontologiilor

Toate tehnicile de analiză bazate pe metoda proces-activitate presupun analiza afacerii pentru a obține informații semantice referitoare la activitățile efectuate și modul de transfer al informațiilor între activități. O serie de activități legate între ele formează un process (Basu și Blanning, 2003).

Tehnicile bazate pe metoda process- activitate pot fi grupate în trei mari categorii ((Havey, 2005):

Cost/preț/profit: cost pe activitate; cost pe produs sau serviciu; preț pe produs sau serviciu; profitul pieței, canalului, sectorului sau clientului; prețul de transfer.

Creșterea performanțelor: planificarea proceselor și activităților; reducerea costurilor, analiza valorii; eliminarea constrângerilor; reingineria procesului de afaceri; integrarea fluxului de procese; benchmarking.

Gestiunea performanțelor curente: gestiunea bazată pe valoare; măsurarea și gestiunea performanțelor; evaluarea la nivelul serviciului; bugetare bazată pe activitate; bugetare bazată pe prioritate; bugetarea și contabilizarea resurselor (în sectorul public); benchmarking; cea mai bună valoare; contabilizarea bazată pe process; integrarea fluxului de procese.

Utilizarea acestor tehnici transcede orice sector al industriei. Această metodă poate fi aplicată la orice nivel al unei organizații, la colaborarea între organizații, oricărei activități care consumă resurse.

1.1.5.1.1. Metodologie de analiză de tip proces-activitate

Pentru realizarea analizei de tip activitate-proces se pleacă de la structura organizațională a companiei. Reprezentanții fiecărui centru cu buget propriu din structura organizațională a departamentului sau unității de afaceri analizează activitatea realizată și operațiile din cadrul activității desfășurate (Umble și Umble, 2000).

Operațiile și activitățile sunt grupate în fluxuri de activități formând sub-procese, acestea putând fi legate de procesele de bază ale afacerii. Procesele de bază sunt acele procese care definesc scopul existenței organizației, procesele care au ca efect obținerea serviciilor sau produselor pe care compania le oferă. Toate activitățile și sub-procesele desfășurate în cadrul companiei trebuie să contribuie la aceste procese de bază în diferite moduri. Acest tip de analiză clarifică tipurile de relații și permite înțelegerea modului în care funcționează afacerea (Leach, 2000).

În acest model de analiză numărul nivelurilor ierarhiei variază considerabil în funcție de mărimea organizației și de nivelul de detaliere cerut pentru a atinge obiectivele definite și pentru extragerea semanticilor.

Având ca exemplu activitatea unei agenții de publicitate, structura organizațională a agenției de publicitate este prezentată pe verticală și procesele de bază pe orizontală, în Figura 7. Diagrama din Figura 7 prezintă modul în care departamentele din structura organizațională contribuie la procesul de bază prin intermediul sub-proceselor pe care le realizează. Procesele reprezintă o serie de activități care produc o anumită ieșire și ignoră toate barierele funcționale.

Figura 7. Diagrama contribuției departamentelor la procesul de bază

În Figura 8, este exemplul sistemului și al sub-procesului de distribuție de produse văzut ca un sub-proces care contribuie la dezvoltarea infrastructurii, aceasta contribuind la rândul ei la dezvoltarea proceselor de bază. Figura 8 arată că un sub-proces este format dintr-un flux de activități, fiecare putând fi analizată în fluxul de operații care compun activitatea. Dacă este necesar, fiecare operație poate fi împărțită în sub-operații.

Toate operațiile sunt formate dintr-un număr de subprocese, unele dintre acestea fiind de tip suport și sunt comune majorității organizațiilor precum: aprovizionare, recrutare de personal, gestiunea informațiilor. Alte operații sunt specifice domeniului analizat, și formează o listă de așteptare.

Figura 8. Analiza sistemului și a sub-proceselor în procesul de livrare

1.1.5.1.2. Colectarea de informații

În funcție de activitățile și procesele folosite, datele trebuie colectate de la persoanele care participă la realizarea activităților din fiecare centru de buget sau sub-proces.

Informațile înregistrate sunt folosite pentru construirea semanticilor activităților și proceselor descrise și pot fi referitoare la (Silver, 2008): activitățile și operațiile efectuate; fluxul de relații dintre activități sau procese; intrările și ieșirile activităților sau proceselor și unitățile lor de măsură; resursele consumate, ca de exemplu: timp, spațiul de birouri folosit (depinde de tipul de resurse); alocarea per produs, serviciu sau client (depinde de tipul de activități); factorii care influențează performanța procesului sau activității (depinde de cost); măsurarea performanței (criterii financiare și non-financiare, cantitative și calitative); obiective și responsabilități pe activitate sau process; clasificarea activității (de bază, suport, divers); servicii alternative, idei de îmbunătățire.

Există o serie de metode care pot fi folosite pentru colectarea datelor în vederea construirii semanticilor. Principalele surse pentru date sunt (Recker, 2008): sistemele de pontaj – pentru identificarea resurselor; sistemele informaționale ale organizației – pentru identificarea activităților, ieșirilor și parametrilor non-financiari; sistemele informaționale financiare – pentru costuri, materiale și bugete; sistemul de resurse umane – pentru structuri organizaționale, informații despre persoane și salarii; centrul de cost al departamentului sau procesului analizat (activități, relații, fluxuri, costurile implicate, intrări și ieșiri).

Principalele metode de colectare a datelor sunt (Herayizadeh, Mendling și Rosemann, 2009): metoda observației; grupuri de discuții folosite pentru a obține sugestii pentru analiza activității sau procesului – utile când se încearcă obținerea rapidă de informații inițiale; preluarea informațiilor din alte sisteme informatice; interviuri; aplicarea de chestionare.

1.1.5.1.3. Gestiunea lanțului de activități

Gestiunea lanțului de activități de la aprovizionare până la desfacere presupune controlul și coordonarea tuturor activităților unei organizații de la furnizorii de produse la clienții săi (Silver, 2008).

Lanțul de aprovizionare poate fi împărțit în două componente (Recker, 2008): lanțul superior – componenta de cumpărare a comerțului electronic și lanțul inferior – componenta de vânzare a comerțului electronic.

Figura 9. Rețele de lanțuri de activități de la aprovizionare la desfacere

Figura 9 prezintă cele două părți ale lanțului de activități de la aprovizionare la desfacere împreună cu legăturile cu partenerii și furnizorii precum și cu furnizorii, partenerii și clienții acestora. După fabricare, produsele sunt transmise prin lanțul de distribuție aprovizionare-desfacere. Când se implică clientul se vorbește despre un canal de tip cerere b#%l!^+a?care bazează toate resursele, inclusiv: producția, vânzările, marketing-ul, cercetarea, dezvoltarea și serviciile pe cererile clienților.

Modelul de afaceri axat pe cerere folosește o serie tehnologii, precum previziuni, cercetări de piață și business intelligence pentru îmbunătățirea canalului cererii și pentru a putea răspunde comportamentului actual al consumatorului. Toate aceste tehnici se pot folosi pentru construirea semanticilor asociate acestor activități.

Un sistem de gestiune a lanțului aprovizionare-desfacere este format din următoarele cinci componente (Pant și Juric, 2008):

Planificarea: dezvoltarea unei strategii pentru gestiunea lanțului aprovizionare-desfacere în vederea obținerii eficienței maxime.

Sursa: implică selectarea furnizorilor de bunuri și servicii necesare în lanțul aprovizionare-desfacere; gestiunea relațiilor, stabilirea regulilor de plată, de livrare și de calcul al prețurilor.

Producția: acoperă planificarea cererii, fabricarea, asamblarea, testarea, împachetarea și crearea stocurilor de produse.

Livrarea: se referă la recepționarea cererilor clienților, depozitarea, selectarea și livrarea, facturarea și plata.

Retururi: presupune crearea proceselor pentru gestiunea bunurilor returnate de clienți, inclusiv a celor care necesită reparații.

1.1.5.2. Diagrama proceselor de afaceri

În cadrul diagramei proceselor de afaceri (BPD) sunt utilizate următoarele concepte: obiecte de flux (flow objects); obiecte conectoare (connecting objects); centre de responsabilități (swimlane objects); artefacte (artifact objects).

1.1.5.2.1. Obiectele de flux

Obiectele de flux sunt de trei tipuri.

Evenimentele reprezintă ceva ce se întâmplă pe parcursul unui proces sau a unei coreografii, afectând fluxul modelului (Porter și Millar, 1985). De obicei, evenimentele au o cauză (trigger) și un impact (result) și sunt împărțite în trei sub-categorii: de început (start), intermediare (intermediate) și de final (end).

Evenimentele de start indică unde (sau ce) va începe un proces. Evenimentele de start pot fi de mai multe tipuri, pentru a arăta condițiile în care se inițiază procesul (Basu și Blanning, 2003).

Figura 10. Eveniment start

Evenimentele intermediare sunt acele evenimente care pot apărea după ce un proces a fost inițiat, dar înainte de a se termina (Basu și Blanning, 2003).

Figura 11. Eveniment intermediar

Evenimentele finale indică unde se termină un proces și modul de finalizare al acestuia (Basu și Blanning, 2003).

Figura 12. Eveniment final

Un eveniment poate fi utilizat pentru a prinde (catch) sau a arunca (throw) un trigger eveniment (Cozgarea, 2010).

Există mai multe tipuri de evenimente ce se pot manifesta în cadrul unei diagrame a proceselor de afaceri. Aceste evenimente (Cozgarea, 2010) sunt descrise în tabelul de mai jos.

Tabelul 2. Evenimente ce se pot manifesta în cadrul unei diagrame (Cozgarea, 2010)

Activitatea este un termen generic utilizat pentru a face referire la o etapă din munca efectuată de către un participant la proces. Activitățile pot fi atomice (nu se mai pot diviza în alte sub-activități) sau non-atomice (se pot diviza într-un set de sub-activități). Activitățile descrise în cadrul unei diagrame BPMN pot fi sub-procese (Sub-Processes) sau sarcini (tasks) (Ward-Dutton și Macehiter, 2005).

Un task reprezintă o activitate atomică (Havey, 2005).

Figura 13. Reprezentarea grafică a unei activități

Subprocesul este o activitate compusă care este inclusă într-un proces (Havey, 2005).

Figura 14. Reprezentarea grafică a unui subproces

Un subproces poate conține activități ce se vor executa în mod repetitiv (Cozgarea, 2010).

Figura 15. Subproces repetitiv

Punctele de decizie controlează modul în care fluxurile de secvență interacționează în cadrul unui flux. Pot fi adăugate condiții care să permită efectuarea unor alegeri condiționale, iar un anumit comportament poate fi reprezentat prin marcatori interni (Ward-Dutton și Macehiter, 2005).

Un punct de decizie se reprezintă grafic sub forma unui romb.

Punctele de decizie pot fi de mai multe tipuri.

Punctele de decizie bazate exclusiv pe date sunt bazate pe expresii logice conținând atributul <expresie condiție> specific ieșirii fluxului secvențial din punctul de decizie (Havey, 2005).

Figura 16. Variante de reprezentare grafică a punctului de decizie bazat exclusiv pe date

Punctul de decizie bazat exclusiv pe evenimente reprezintă un punct de ramificație în cadrul procesului, unde alternativele sunt bazate pe evenimente ce apar într-un punct din proces (Basu și Blanning, 2003).

Figura 17. Punctul de decizie bazat exclusiv pe evenimente

Punctul de decizie inclusiv reprezintă un punct de ramificație unde alternativele sunt bazate pe expresii condiționale, conținute în cadrul fluxului secvențial de ieșire. Evaluarea unei expresii condiționale nu exclude evaluarea altei expresii condiționale (Porter și Millar, 1985).

Figura 18. Reprezentarea grafică a punctului de decizie inclusiv

BPMN include punctul de decizie complex, pentru situațiile în care este dificil să se reprezinte în întregime celelalte tipuri de puncte de decizii (Porter și Millar, 1985). Un punct de decizie complex poate fi utilizat pentru fuzionarea sau scindarea fluxurilor secvențiale din cadrul unui proces de afaceri.

Figura 19. Reprezentarea grafică a punctului de decizie complex

Punctul de decizie paralel furnizează un mecanism ce sincronizează fluxuri paralele și creează fluxuri paralele (Cozgarea, 2010).

Figura 20. Reprezentarea grafică a punctului de decizie paralel

1.1.5.2.2. Obiectele conectoare

În BPMN există două tipuri de obiecte conectoare: fluxul (secvențial sau mesaj) și asocierea.

Fluxul secvențial (Sequence Flow) indică ordinea în care sunt executate activitatile în interiorul unui proces sau a unei coreografii (Porter și Millar, 1985).

Figura 21. Fluxul secvențial

Dacă sursa unui flux secvențial este o activitate, în locul punctului de decizie se poate utiliza un mini-romb, care trebuie plasat la începutul fluxului secvențial. Un flux secvențial, care este generat în urma evaluării unei expresii condiționale, poate fi definit ca o alternativă implicită, prin marcarea acestuia cu backslash (Basu și Blanning, 2003).

Figura 22. Fluxul secvențial condițional implicit

Flux Mesaj (Message Flow) arată fluxul de mesaje dintre doi participanți (Havey, 2005).

Figura 23. Flux mesaj

Asocierea (Association) este utilizată pentru a lega informații (sub formă textuală sau grafică) la obiecte flux (Havey, 2005).

Figura 24. Asocierea

O asociere dirijată precizează care dintre obiectele de date sunt de intrare și care sunt de ieșire dintr-o activitate (Havey, 2005).

Figura 25. Asocierea dirijată

1.1.5.2.3. Centre de responsabilități

BPMN utilizează centrele de responsabilități (swimlanes) pentru separarea unor zone din cadrul procesului. Centrele de responsabilități folosite în cadrul diagramelor proceselor de afaceri pot fi: pool sau lane.

Pool reprezintă un participant la o colaborare. Interacțiunea dintre pool-uri se realizează prin intermediul fluxurilor mesaj (Cozgarea, 2010).

Lane subdivizează procesul sau un pool, cu scopul organizării și clasificării activităților (Cozgarea, 2010).

1.1.5.2.4. Artefacte

Artefactele au rolul de a aduce informații suplimentare unei diagrame. BPMN utilizează trei artefacte standard.

Obiectul-data precizează datele necesare unei activități, precum și cele produse de către acestea (Havey, 2005).

Figura 26. Reprezentarea grafică a unui obiect data

Adnotarea adaugă informații adiționale, sub formă de text, diagramei BPMN sau unor părți ale acesteia (Havey, 2005).

Figura 27. Reprezentarea grafică pentru artefactul Adnotare

Grupul furnizează un mecanism vizual de grupare a elementelor din cadrul unei diagrame (Havey, 2005).

Figura 28. Reprezentarea grafică pentru artefactul Grup

1.1.5.3. Submodele BPMN

BPMN este folosit pentru a comunica o varietate largă de informații unei varietăți numeroase de public. BPMN este conceput pentru a acoperi această gamă larga de utilizare și permite modelarea proceselor de activități de tip capăt-la-capăt pentru a permite celui care privește diagrama sa, să poată diferenția cu ușurință secțiunile unei diagrame BPMN. Există trei tipuri de bază de submodele în cadrul unei model BPMN punct-la-punct: procesele de activități private (interne), procese abstracte (publice) și procese de colaborare (globale).

Procesele de activități private sunt cele în interiorul unei organizații specifice și reprezintă tipul de procese care au fost, în general, numite procese de flux de lucru sau BPM. În cazul în care sunt folosite swim lane-uri, atunci un proces de activități privat va fi restrâns într-un singur pool. Fluxul de secvențe al procesului este, prin urmare, restrâns într- b#%l!^+a?un pool și nu poate trece granițele pool-ului. Fluxul de mesaje poate traversa granița pool-ului pentru a arăta interacțiunile care există între procese de activități private separate (http://www.bmpn.org)

Procesele abstracte reprezintă interacțiunile dintre un proces privat de activități și un alt proces sau participant. Numai acele activități care comunică în afara proceselor de activități private sunt incluse în procesul abstract. Toate celelalte activități interne ale procesului privat de activități nu sunt afișate în procesul abstract. Astfel, procesul abstract arată lumii din afară secvența de mesaje, care sunt necesare pentru a interacționa cu acest proces de activități. Procesele abstracte sunt restrânse într-un pool și pot fi modelate separat sau într-o diagramă BPMN mai mare pentru a vedea fluxul de mesaje între activitățile proceselor abstracte și alte entități. Dacă procesul abstract este în aceeași diagramă ca procesul de activități corespunzător privat, atunci activitățile care sunt comune pentru ambele procese pot fi asociate (http://www.bmpn.org).

Procesul de colaborare descrie interacțiunile dintre două sau mai multe entități de activități. Aceste interacțiuni sunt definite ca o secvență de activități care reprezintă modelele schimbului de mesaje între entitățile implicate. Procesele de colaborare pot fi restrânse într-un pool și diferitele interacțiuni de activități participante sunt prezentate ca lane-uri în acel pool. În această situație, fiecare lane ar reprezenta doi participanți și o direcție de deplasare între ei (http://www.bmpn.org).

Mai pot fi, de asemenea, indicate ca două sau mai multe procese abstracte interacționând prin flux de mesaje. Aceste procese pot fi modelate separat sau într-o diagramă BPMN mai mare pentru a arăta asociațiile între activitățile procesului de colaborare și alte entități. Dacă procesul de colaborare este în aceeași diagramă cu unul dintre procesele de activități private corespunzătoare lui, atunci activitățile care sunt comune pentru ambele procese pot fi asociate.

Următoarele procese sunt tipuri de procese de activități care pot fi modelate cu BPMN (Recker, 2006): activități private de proces de nivel înalt (fără defectare funcțională); proces privat detaliat de activități; proces de activități vechi; proces nou de activități; proces privat de activități detaliat, cu interacțiuni cu una sau mai multe entități externe (sau procese de tip cutie neagră); două sau mai multe procese de activități private detaliate care interacționează; relație detaliată a proceselor de activități private cu procese abstracte; relație detaliată a proceselor de activități private cu procese de colaborare; două sau mai multe procese abstracte; relația proceselor abstracte cu procesele de colaborare; doar procesul de colaborare (de exemplu, ebXML BPSS sau RosettaNet); două sau mai multe procese private de activități detaliate care interacționează prin procesele lor abstracte și/sau printr-un proces de colaborare.

BPMN este conceput pentru a permite toate tipurile de diagrame de mai sus. Cu toate acestea, dacă sunt combinate prea multe tipuri de submodele, cum ar fi trei sau mai multe procese private cu flux de mesaje între fiecare dintre ele, atunci diagrama poate deveni prea greu de înțeles. Astfel, este recomandat ca modelatorul să aleagă un scop anume pentru BPD, cum ar fi un proces privat, sau un proces de colaborare (http://www.bmpn.org).

1.1.6. Modelarea evenimentelor în afaceri

În timplul modelarii proceselor de afaceri, se modelează evenimentele care se întâmplă în afacere, și se arată cum acestea influențează fluxul de procese. Un eveniment fie pornește un flux de procese, fie are loc în timpul unui flux de procese sau încheie un flux de procese. BPMN furnizează un mod de notare distinct pentru fiecare tip de eveniment.

1.1.6.1. Evenimente complexe

Când sunt modelate fluxuri de proces mai complexe, cum ar fi servicii web B2B, trebuie modelate evenimente de afaceri mai complexe, cum ar fi: mesaje, cronometre (timers), reguli de afaceri și tratarea erorilor. BPMN permite specificarea tipului de cronometru atașat evenimentului și reprezentarea lui cu o iconiță reprezentativă.

Atașarea unui tip de cronometru la un eveniment creează anumite constrângeri asupra fluxului de procese care sunt modelate (Recker, 2008). De exemplu un cronometru nu poate încheia un flux de procese. Se pot doar primi sau trimite fluxuri de mesaje de la sau către evenimentele de tip mesaj. Aceste tipuri de reguli pentru modelare, care sunt de fapt diferite reguli în afaceri ar trebui executate automat de către unealta de modelare furnizând suport pentru BPMN.

Deseori un eveniment are loc în timp ce un proces rulează, realizând astfel o întrerupere a procesului, și declanșarea unui nou proces care să ruleze. Sau, un proces va fi complet, cauzând pornirea unui eveniment și rularea unui nou proces. Aceste evenimente intermediare pot fi modelate prin plasarea unui simbol de eveniment direct pe procesul căruia îi este asociat (White, 2005). În Figura 30, se poate vedea un mesaj de tip eveniment care este declanșat atunci când procesul Check Inbox se sfârșește, cauzând un mesaj Password Request să fie trimis către procesul Send Passwor”. Acest tip de notare BPMN clarifică pentru faptul că procesul Check Inbox generează un eveniment de tip mesaj, care trimite un mesaj către alt proces.

Figura 29. Evenimente complexe

Figura 30. Un eveniment de tip mesaj este declanșat la sfârșitul procesului „Check Inbox”, trimițând mesajul „Password Request” către procesul „Send Password”

1.1.7. Procese, subprocese și sarcini de afaceri

La baza procesului de modelare al afacerilor se află însăși procesele. Există trei tipuri de procese (Fu-Ren, Yang și Pai 2002): procesele, subprocesele și sarcinile. Fiecare este reprezentată grafic de același simbol dreptunghiular, utilizarea diferitelor denumiri reflectând doar relațiile ierarhice dintre ele.

Un proces este o rețea de lucruri ce lucrează. Se desenează ca un dreptunghi pe nivelul superior al diagramei de Procese de Afaceri BPMN. Pot fi specificate detalii proprii ale unui proces prin crearea sau atașarea unui alt proces de afaceri la cel inițial. Subdiagrama este considerată o diagramă copil. Un proces care are o diagramă copil primește un semn „+” în corpul său (Chang, 2006).

Reprezentarea grafică a detaliilor unui proces printr-o altă diagramă de proces de afaceri se consideră descompunerea procesului. Se poate continua descompunerea unui proces fără nicio restricție – crearea unei diagrame copil pentru un proces, și diagrame copil pentru procesele primei diagrame copil (Havey, 2005).

Procesele desenate pe diagrame copil sunt considerate subprocese. Procesele de pe nivelul inferior, care nu se descompun mai departe sunt considerate sarcini.

Figura 31. Parte a unei diagrame de Proces de Afaceri BPMN pentru un sistem de licitație online

Figura 31 arată o diagramă a unui proces de afaceri BPMN în care procesul Register Item For Auction a fost modelat. Semnul „+” în corpul procesului arată că există cel puțin o diagramă de proces de afaceri copil legată la acest proces și că pe acea diagramă se găsește o reprezentare grafică a detaliilor acestui proces.

Figura 32 arată o parte a diagramei de proces de afaceri copil BPMN la procesul Register Item For Auction. Deoarece se află pe o diagramă copil, procesele sunt considerate subprocese. Procesele de pe această diagramă care nu sunt descompuse mai departe (nu au semnul „+” în centrul lor) sunt considerate sarcini. După cum se poate vedea, este ușor de identificat o sarcină într-o diagramă – sunt acele dreptunghiuri rotunjite care nu au un semn „+” în centru.

Figura 32. Subprocese și sarcini

Din nou, diagrama BPMN este reprezentată pentru a fi ușor de înțeles de către privitori. Pentru a ajuta la înțelegerea complexităților proceselor, se poate afișa în mod grafic o pictogramă a unui flux de procese copil pe însuși simbolul de proces. În editorul de modelare, acesta se face prin apăsarea pe semnul „+” în centrul simbolului de proces, ce va schimba semnul în „-“, și prezentarea schiței pictogramei. În acest fel. la vederea unei diagrame a unui Proces de Afaceri BPMN, se pot observa cu ușurință procesele complexe, care se descompun pe nivele.

Figura 33. Vizualizarea schiței pictogramei diagramei fiice a unui proces

Pentru a arăta ordinea de execuție a proceselor, acestea trebuie conectate printr-o săgeată. Tranziția este reprezentată grafic cu o săgeată cu vârful plin (Havey, 2005).

Tranziția este folosită pentru a arăta secvențele proceselor în interiorul unei organizații sau a unui departament. Deci, în cazul în care au fost adăugate noduri și subnoduri în diagramă, se vor folosi săgeți pentru a conecta evenimentele, procesele și gateway-urile plasate între noduri și subnoduri.

BMPN trasează o a doua linie de flux – Săgeata de Mesaj – disponibilă pentru a modela comenzile de procese dintre organizații și departamente (cu alte cuvinte, între noduri).

1.1.8. Modelarea punctelor de decizie prin gateway-uri

Deciziile, îmbinările și bifurcațiile în fluxul de proces sunt modelate printr-un simbol; în fluxul de proces sunt modelate printr-un simbol gateway. Un gateway poate fi gândit ca o întrebare pusă într-un anumit punct în fluxl de proces. Întrebarea are definite o mulțime de răspunsuri alternative, care sunt de fapt porți (Havey, 2005).

Tabelul 3. Tipuri de Gateway-uri și simboluri asociate

Se poate seta un stereotip pentru un gateway, schimbând astfel logica specificată de el și simbolul care-l reprezintă.

Pe măsură ce progresăm în modelarea fluxurilor de afaceri, procesele, evenimentele și gateway-urile diagramei procesului de afaceri sunt luate și așezate în noduri sau subnoduri. Un nod este reprezentat ca o regiune dreptunghiulară desanată orizontal sau vertical în interiorul diagramei. Un subnod este o subpartiție în interiorul unui nod și extinde întreaga lungime a nodului. Tipic, un nod reprezintă o organizație și un subnod reprezintă un departament al acelei organizații. Prin luarea proceselor și așezarea lor în noduri și subnoduri, se specifica cine ce face, pentru evenimente se specifică unde au ele loc și pentru gateway-uri se specifică unde sunt luate deciziile și cine le ia (Harrington, Esseling și van Nimwegem 1997).

Un nod poate reprezenta și alte lucruri în afară organizațiilor, cum ar fi o funcție (ceva ce organizația execută, cum ar fi Marketingul, Vânzările sau Formarea), o aplicație (sau un software), o locație (o locație fizică în interiorul companiei), o clasă (un modul software într-un program software dintr-un computer orientat obiect), sau o entitate (reprezentând un tabel logic într-o bază de date). Poate reprezenta un singur lucru, dar acel lucru provine dintr-o listă eterogenă de diferite tipuri de lucruri (Chang, 2006).

Figura 34. Noduri și subnoduri

1.1.9. Impunerea normelor B2B

BPMN specifică anumite norme pentru modelarea mesajelor și fluxurilor. Săgețile de flux pot fi desenate între evenimente, procese și gateway-uri în interiorul aceluiași nod. Săgețile de mesaj pot fi desenate numai între evenimente, procese sau gateway-uri care se găsesc în noduri diferite – deoarece mesajele sunt schimbate doar între diferite organizații sau aplicații (Cozgarea, 2010).

BPMN sugerează ca aceste norme să fie impuse prin editorul de modelare BPMN. System Architect impune aceste reguli de desenare prin apariția unui simbol că un vânător de fantome (ghostbuster), interzicând conexiunea între elementele greșite; permite numai conexiuni între elementele corespunzătoare ale modelului. Aceasta ajuta prin prevenirea introducerii de erori sau inconsistente logice în sistemele B2B în timpul modelarii (Cozgarea, 2010).

1.1.9.1. Modelarea fluxurilor de mesaj B2B

Cum am menționat anterior, unul dintre scopurile diagramei de proces de afaceri BPMN este de a permite modelarea mesajelor B2B. În acest scop, diagrama de proces de afaceri BPMN oferă posibilitatea modelarii săgeților de mesaj.

Figura 35. Săgețile de mesaj

Diagramele de procese de afaceri tradiționale permit modelarea fluxurilor de proces secvențiale – de la evenimentele de început la cele de sfârșit. Diagrama de proces de afaceri BPMN mărește linia de flux de secvență cu un rând de mesaje, astfel încât poate modela oameni sau mașini care să își trimită mesaje unul altuia – un aspect important în înțelegerea și descrierea proceselor B2B și B2C (Cozgarea, 2010).

1.1.10. Procesul de transformare a datelor

Un order request (crearea unei cereri) cauzează generarea unui order (comandă). Când produsul este livrat clientului, comandă este îndeplinită. O carte de credit nefuncțională poate cauza anularea comenzii. Un client își poate actualiza informațiile din cadrul contului cu o carte de credit nouă, sau o adresă nouă (Chang, 2006).

Se poate controla felul în care datele sunt modificate în timpul unui flux de procese prin reprezentarea obiectelor de tip date în diagrama de procese BPMN.

Modelarea datelor de tip obiect este opțională – ele nu au niciun efect direct asupra fluxului de procese, ci doar furnizează informații despre cum funcționează fluxul de procese. Se poate atașa un obiect de tip de date unui flux de mesaje sau secvențe printr-o linie punctată (Figura 36), sau prin desenarea unor linii de asociere de la și către obiectele de tip de date și procese (Figura 37), creând astfel un flux de date în fluxul de procese.

Figura 36. Atașarea unui obiect de tip dată la un flux de ordine

Starea obiectului poate fi specificată între paranteze pătrate sub obiect. Acest lucru arată cum obiectul este transformat în timpul procesului. În Figura 36, se poate vedea că factura este aprobată atunci când este trimisă de la procesul Send Invoice către procesul Make payment. În Figura 37, se poate vedea că procesul Approve Purchase Order modifică starea unui obiect Purchase Order din starea Complete în starea Approved.

Figura 37. Desenarea liniilor de asociere între obiecte de tip dată și un proces

Uneori o fotografie nu este de ajuns, este nevoie de cuvinte pentru a descrie un lucru pe care o fotografie nu îl poate reprezenta. Astfel BPMN furnizează o adnotare textuală care poate fi aplicată oricărui model de elemente, astfel încât să poată fi descrise detalii suplimentare despre elementul în sine cu ajutorul cuvintelor (Basu și Blanning, 2003).

Pot fi folosite adnotări textuale pe toate elementele unei diagrame de procese BPMN (Silver, 2008). Adnotările textuale sunt afișate într-un dreptunghi atașat unui simbol printr-o linie dreaptă, după cum se poate vedea în Figura 38.

Figura 38. Adnotarea textuală

1.1.11. Orchestrarea serviciilor web ale BPMN

Internet-ul este un mediu eterogen dintre platforme multe și aplicatii diferite. Într-un lanț al valorilor definit și limitat, organizatiile și indivizii vor să aiba parte de cele mai bune componente care sunt oferite în acest lanț ca și valoare. Aplicatiile și serviciile trebuie să lucreze împreună într-un mod armonios. Aceasta este una dintre forțele care conduce la standardizarea serviciilor web.

Pentru a face serviciile web să lucreze este nevoie de un proces în patru etape -conceperea proceselor cu ajutorul BPMN, verificarea lor pentru eficiență prin simulare, disponibilitatea lor prin publicarea unui limbaj de execuție a procesului business și orchestrarea și coordonarea lor folosind Sistemul de Management al Procesului de Business (BPMS).

BPMS oferă abilitatea de transformare a unor discipline distincte de fluxuri de producție, EAI și B2B dintr-o soluție practică complexă oferită de consultanții cu calități într-o soluție deschisă, accesibilă maselor de dezvoltatori, producând noi tipuri de aplicații strâns legate și agile. BPMS orchestrează participanții (aplicații, oameni, parteneri) în execuție, procese finite și micșorează diferența dintre strategie și execuția business (Kabilan, 2005).

Prin companiile importante, care dezvoltă BPMS se numără: IBM, BEA Systems, Vitria, Imtalio, FileNet, Fuego și Collaxa.

1.1.12. BPMN și UML

Apariția a BPMN, BPML și BPMS nu face învechită nevoia pentru dezvoltarea de noi sisteme, spre deosebire folosirea limbajului UML (Unified Modeling Language). Dezvoltarea noilor sisteme încă are un rol important de jucat în procesul arhitectural enterprise.

UML este un limbaj care ajută dezvoltatorii să specifice, vizualizeze și să documenteze modele de sisteme software. Este adresat în special arhitecților de sistem și inginerilor software. A fost dezvoltat ca un mijloc de a eficientiza procesul de dezvoltare a software-ului, de la design-ul arhitectural la implementarea aplicației pentru a fi utilizată de către un comitet tehnic.

BPMN se adresează analiștilor în afaceri, arhitecților de sistem și inginerilor în software. A fost dezvoltat ca o modalitate de a simplifica întregul ciclu de viață al dezvoltării unui proces de afaceri creat de către un comitet de oameni de afaceri.

UML definește un număr de diagrame care pot fi încadrate într-una din trei categorii: structura statică a aplicației; comportamentul dinamic; gestionarea și organizarea soluțiilor software. Dintre aceste categorii, diagrama de comportament dinamic este cea mai folosită pentru modelarea proceselor în afaceri, pentru a realiza diagrame cum ar fi: diagrama de activitate UML și diagrama cazurilor de utilizare.

BPMN este legat de UML în sensul că definește o notație grafică pentru procesele de afaceri, similară cu diagramele de comportament UML. Totuși BPMN și UML au abordări foarte diferite referitoare la modelarea proceselor de afaceri.

UML oferă o abordare orientată spre obiect pentru modelarea aplicațiilor, în timp ce BPMN folosește o abordare a proceselor centrice. Majoritatea metodelor UML cer că întâi să fie găsit obiectul folosind o structură statică, și apoi cer să fie construită o diagramă de comportament dinamică pentru a evidenția modul de acționare a obiectelor. Ca și fel de modelare, această metodă nu le este familiară multor analiști de afaceri.

BPMN oferă o abordare de procese centrică care este mai naturală și mai intuitivă pentru un analist în afaceri. Cu BPMN, fluxurile de control și fluxurile de mesaje ale proceselor sunt modelate întâi. Un obiect model pentru proces este definit mai degrabă implicit, decât explicit. BPMN oferă, de asemenea, opțiunea de modelare explicită a obiectelor care pot fi expuse prin intermediul serviciilor în fluxurile de procese.

UML este o asamblare de diagrame care sunt rezultatul celor mai bune practici colective ale diferiților practicanți fondatori. Din nefericire, acest lucru înseamnă că diagramele sunt o agregare și că nu au fost create în mod specific pentru a lucra una cu alta. Drept consecință, dezvoltatorii își pot modela doar o parte din aplicații cu ajutorul UML; nivelul detaliat de implementare nu este acoperit.

În contrast, BPMN, definește un singur tip de diagramă care are mai multe înfățișări derivate din același proces de bază al meta-modelului. Rezultatul natural al acestui lucru este acela că implementarea într-un limbaj de execuție de procese în afaceri, pur și simplu devine o altă viziune logică a procesului.

În cele din urmă, UML nu definește niciun meta-model de execuție pentru procesele de afaceri modelate. În schimb, orice meta-model de execuție trebuie definit folosind Model Drive Architecture (MDA). BPMN este bazat pe executarea proceselor de către meta-modelul BPML și astfel nu sunt necesari pași adiționali pentru modelarea proceselor pe deplin executabile.

1.1.12.1. Legătura dintre BPMN și UML

Se anticipează că BPMN și UML vor co-exista. Vor fi utilizatori tehnici care nu vor dori să folosească BPML ca metodă principală de lucru și care vor utiliza în continuare UML. Figura 39 arată că BPMN poate fi folosit pentru a crea soluții care să ruleze direct pe BPMS sau care să fie folosite drept analist de afaceri pentru dezvoltări ulterioare folosind UML. În acest scenariu utilizatorii UML ar considera procesele de afaceri pur și simplu o altă componentă.

Figura 39. BPMN și UML

1.1.13. Prezențe pe piața Business Process Integration

Printre liderii acestei piețe îi enumerăm pe: BEA Systems, CrossWorlds Software, Iona Technologies, Mercator Software, Sybase, SeeBeyond, Software AG, Vitria Technology. În studiul nostru ne-am oprit asupra a trei din aceste soluții: Sybase Business Integrator, SeeBeyond eBusiness Integrator Suite și IBM Business Process Manager.

1.1.13.1. Sybase

Cunoaștem numele companiei Sybase de pe piața aplicațiilor cu baze de date. Ultimele informații, confirmă poziția importantă Sybase după IBM, Oracle și Microsoft.

Venind în sprijinul companiilor care acceptă noile provocări în domeniul automatizării proceselor, Sybase oferă suita Sybase Business Integrator. În principal, oferta BPI automatizează procesele de afaceri, integrează procesele cu sistemele interne, realizează interacțiunile pe lanțul valoric și monitorizează activitatea e-business. Spre deosebire de, deja tradiționalele Enterprise Applications Integration, suita BPI este o clasă de aplicații de întreprindere, o soluție cuprinzătoare care oferă toate componentele necesare pentru automatizarea procesului de afaceri în același timp cu integrarea acestui proces în interiorul și în afara cadrului întreprinderii (http://www.sybase.com/content/1018514/BPI_SuiteWP.pdf).

Sybase BI Suite integrează procesele de afaceri desfășurate prin sisteme diferite, inclusiv servicii B2B, aplicații CRM, sisteme ERP, aplicații moștenite, soluții supply chain, site-uri web, portaluri, sisteme workflow, servere mobile și alte aplicații. Cu această suită sunt proiectate rapid, dezvoltate, conduse și gestionate procesele de afaceri în condițiile unei vizibilități depline, a transparenței sistemului informațional.

Componentele suitei Sybase BPI sunt: New Era of Networks e-Biz Integrator; New Era of Networks Process Server; New Era of Networks BizTracker; New Era of Networks Adapter for XML; Sybase Enterprise Application Server (EAServer); Sybase Web Services Integrator.

New Era of Networks e-Biz Integrator ajută întreprinderile să integreze aplicațiile noi și sistemele existente în soluții coerente, în care circuitele informaționale se desfășoară flexibil, eficient, rapid și la costuri mici. Transformă automat datele de la sursă în formatul cerut de echipamente, sisteme de operare sau aplicații și transmite rapid mesajele respectând regulile de lucru (http://www.sybase.com/content/1018514/BPI_SuiteWP.pdf).

New Era of Networks Process Server contribuie la integrarea aplicațiilor noi și a celor existente. În e-business, aplicațiile interne trebuie să se integreze cu lanțul de procese al clienților, furnizorilor și partenerilor, indiferent de platforma hardware, sistemele de operare, programele de aplicații, bazele de date și protocoalele de comunicații existente. Aplicația Sybase gestionează procesele de afaceri bazate pe platforma XML, instrumentele de dezvoltare și proiectare precum și mediile specializate pentru funcționarea on-line printr-o platformă unică. Întreprinderea poate să proiecteze și să implementeze un proces de afaceri rapid și ușor; poate să gestioneze circuitele de afaceri la viteza Internet, să monitorizeze procese complexe de afaceri în timp real și să auditeze aceste procese. Process Server include un mediu de dezvoltare grafică a proceselor, ajutând companiile să conceptualizeze rapid, să proiecteze, vizualizeze, dezvolte și să mențină procesele printr-o interfață grafică intuitivă. Transferul de cunoștințe între analist – dezvoltător – manager – analist proces se realizează simplu și eficient (http://www.sybase.com/content/1018514/BPI_SuiteWP.pdf).

Figura 40. Business Process Integration (Gruden și Strannegard, 2003)

New Era of Networks BizTracker contribuie la monitorizarea și măsurarea performanței sistemelor. Biz Tracker monitorizează și urmărește circuitul mesajelor pe parcursul proceselor extinse de afaceri, oferind multiple modalități de analiză și statică a tranzacțiilor desfășurate. O altă facilitate este posibilitatea vizualizării istoricului mesajelor pentru tranzacții, inclusiv conținutul și atributele, identificare erorilor și reprocesarea sau reluarea operațiunilor tranzacționale nereușite. Același instrument face posibilă măsurarea performanței și complexității proceselor de afaceri prin calcularea ratelor de desfășurare a fiecărei tranzacții, a performanțelor și a timpilor de procesare (http://www.sybase.com/content/1018514/BPI_SuiteWP.pdf).

New Era of Networks Adapter for XML contribute la comunicarea în limbaj XML. Rularea tranzacțiilor de afaceri presupun intrări și ieșiri dintr-una sau mai multe aplicații back-end. Adaptoarele sunt piese din infrastructură care completează tranzacțiile. Rolul lor este de a facilita transferul datelor spre și de la sistemele back-end prin reformatarea datelor sursă în format XML (http://www.sybase.com/content/1018514/BPI_SuiteWP.pdf).

Figura 41. Sybase Business Process Integrator (http://www.sybase.com/content/1018514/BPI_SuiteWP.pdf)

Sybase Enterprise Application Server (EAServer) este o aplicație server e-business construită pe arhitectura multi-strat care oferă un mediu cu performanțe înalte, scalabil și securizat. Sybase EAServer suportă platformele Java 2 Platform Enterprise Edition, COM și Corba și oferă, în același timp, un mediu stabil de dezvoltare a aplicațiilor (http://www.sybase.com/content/1018514/BPI_SuiteWP.pdf).

Sybase Web Services Integrator contribuie la implementarea B2B. Aplicația are ca misiune principală dezvoltarea de aplicații colaborative inter-organizaționale cu ebXML, RosettaNet, și Sybase. Companiile (din cadrul unui lanț valoric) pentru realizarea tranzacțiilor publice, comunică printr-un mediu sigur cu partenerii de afaceri (http://www.sybase.com/content/1018514/BPI_SuiteWP.pdf).

Suita Sybase BPI permite organizațiilor să desfășoare toate tipurile de aplicații e- business: Enterprise Application Integration (EAI), Business-to-Consumer (B2C), Business-to-Business (B2B) sau B2B integrat cu EAI (B2Bi). Platforma este o veritabilă infrastructură e-business ce completează proiectele EAI din cadrul organizațiilor. Prin integrarea strategică a soluțiilor de întreprindere și a platformelor Sybase Suite sprijină întreprinderile să proiecteze rapid, să dezvolte, să gestioneze și să adauge continuu noi procese în condițiile menținerii controlului și vizibilității afacerii.

1.1.13.2. SeeBeyond

SeeBeyond are o bază de peste 1.600 de clienți în întreaga lume, printre care: ABB, ABN Amro, Barnes&Noble.com, Ericsson, General Motors, Hewlett-Packard, Pfizer, Vodafone, suita sa tehnologică fiind prezentă pe piață încă din 1991.

SeeBeyond este unul din liderii mondiali între furnizorii de soluții de integrare e- business, oferind o platformă care facilitează fluxul de informații în cadrul și între întreprinderi în timp real. Firma are contracte de parteneriat de consultanță economică și tehnologică cu majoritatea companiilor de top (KPMG, Price Water House Coopers, Cap Gemini & Ernst Young, EDS, Accenture), ca și parteneriate software cu SAP, Siebel, Oracle, BroadVision, Commerce One (http://www.seebeyond.com).

Produsul său, eBusiness Integration Suite, oferă o infrastructură scalabilă și ușor de implementat pentru integrarea aplicațiilor, conectivitatea business-to-business și optimizarea proceselor economice. Sunt acoperite toate platformele majore de sisteme de operare și de baze de date, iar standardele de dezvoltare suportate sunt extrem de diverse: CORBA, SMTP, XML, X12, SAP ALE, EDI, Acord, MQSeries, Peoplesoft. În ce privește conectorii/adaptorii disponibili pentru software-ul proprietar, lista este extrem de lungă: Bloomberg, Clarify, Lotus Notes, Oracle, Peoplesoft, SAP, Siebel, Ariba, CGI, Commerce One, Websphere (http://www.seebeyond.com).

Suita tehnologică de le SeeBeyond include foarte multe componente, printre care (http://www.seebeyond.com):

eGate Integrator, platforma de integrare e-business, fundamentul întregii suite tehnologice, care asigură fluxul dinamic al informațiilor între aplicații și sisteme, către clienți și parteneri, cu un grad ridicat de performanță, flexibilitate și viteză de implementare.

eInsight Business Process Manager, vizează gestiunea proceselor economice și optimizarea acestora.

eXchange Partner Manager, destinat întreținerii relațiilor business-to-business, într-o diversitate de scenarii de conectare.

eXpressway Integrator, pentru conectarea sistemelor partenerilor, oferind acces la piețele electronice publice sau private.

eIndex Global Identifier, pentru gestiunea informațiilor despre clienți din diferitele sisteme răspândite în cadrul întreprinderii, oferind o imagine unică, în timp real.

1.1.13.3. IBM Business Process Manager

IBM Business Process Manager este o platformă cuprinzătoare de gestionare a proceselor operaționale, care asigură vizibilitatea completă și informațiile necesare pentru gestionarea proceselor operaționale. Furnizează instrumente și un mediu runtime pentru design-ul, execuția, monitorizarea și optimizarea proceselor, precum și suport de bază pentru integrarea sistemelor. Produsul poate fi configurat să suporte diverse niveluri de complexitate și implicare cu gestiunea procesului operațional.

Componentele IBM Business Process Manager furnizează o magazie unificată BPM; unelte pentru autori, administratori și utilizatori și o platformă runtime. Următoarea diagramă ilustrează o configurație IBM Business Process Manager obișnuită.

Din mediile de creație IBM Process Designer și IBM Integration Designer, dezvoltatorii se conectează la IBM Process Center. Din oricare dintre aceste unelte de dezvoltare aplicație bazate pe GUI, dezvoltatorii pot crea, testa, depana și implementa aplicații operaționale. În mediile de creație Process Designer și Integration Designer, designer-ii de procese și servicii creează aplicații proces implementabile și truse de unelte reutilizabile. Aplicațiile proces conțin modele de procese și implementări de servicii, inclusiv fișierele de suport care sunt necesare. Aplicațiile proces sunt stocate în magazia Process Center astfel încât să poată fi partajate.

Figura 42. IBM Business Process Manager

Process Center include două servere, serverul Process Center și serverul Performance Data Warehouse. Aceste servere permit dezvoltatorilor care lucrează în Process Designer să-și ruleze aplicațiile proces și să-și depoziteze datele de performanță pentru testarea și redarea în timpul eforturilor de dezvoltare. Performance Data Warehouse extrage datele urmărite din serverul Process Server sau Process Center la intervale regulate.

Process Center suportă de asemenea numeroase funcții administrative. Din consola Process Center, administratorii instalează aplicații proces care sunt pregătite pentru intermediere, testare sau producție pe serverele de proces. Administratorii pot gestiona de asemenea instanțe care rulează ale aplicațiilor proces din medii configurate.

Din consola de administrare a proceselor și din consola de administrare a performanței, administratorii pot gestiona și menține toate serverele runtime.

Utilizând Process Portal, participanții la proces se pot conecta la serverul Process Center sau la un Process Server din orice mediu runtime configurat, dacă un proces este dezvoltat, testat sau a fost lansat către un mediu de producție.

IBM Business Process Manager reprezintă o platformă BPM singulară care combină capabilitățile centrate pe integrare și cele umane într-un produs unificat. Diferite configurații ale produsului sunt disponibile pentru diferiți utilizatori și îndeplinesc diferite necesități în întreprindere. Configurațiile produselor pot fi combinate pentru creațiile în colaborare și mediile runtime implementate pe rețea.

Process Server oferă un singur mediu runtime BPM care poate suporta un interval de procese operaționale precum și orchestrare de servicii și capabilități de integrare.

IBM Business Process Manager include un set de unelte de administrare pentru a ajuta în realizarea de taskuri care variază de la instalare și gestionare de instantanee până la administrarea proceselor și lucrul cu resurse din mediul IT.

IBM Business Process Manager oferă unelte de linie de comandă, interfețe de scriptare și interfețe de programare pentru administrarea mediului runtime. Uneltele de linie de comandă sunt programe simple rulate dintr-un prompt linie de comandă al unui sistem de operare pentru a realiza taskuri specifice. Utilizând aceste unelte, se pot porni și opri serverele de aplicații, verifica starea serverului, adăuga sau înlătura noduri și alte taskuri.

Programul de scriptare wsadmin (WebSphere administrativ) este un mediu de interpretare a comenzii non-grafic care permite rularea de opțiuni administrative într-un limbaj de scriptare și lansarea în execuție de programe de limbaje de scriptare pentru executare. Acesta suportă aceleași taskuri ca și consola administrativă, precum și multe dintre taskurile consolei Process Center. Unealta wsadmin este intenționată pentru medii de producție și operații nesupravegheate.

Consola administrare proces este folosită pentru a administra serverele de proces, inclusiv utilizatorii și instantaneele instalate pentru fiecare server. În plus, aceasta oferă unelte pentru a ajuta gestionarea cozilor și memorarea în cache.

Consola administrare proces include inspectorul de proces, o unealtă pentru vizualizarea și gestionarea instanțelor de proces pentru aplicații de proces care rulează pe un server de proces specific.

Consola de administrare Business Performance include unelte pentru gestionarea depozitelor de date de performanță. Se poate utiliza această unealtă pentru gestionarea cozilor de server și monitorizarea performanței serverului.

Consola administrativă este folosită pentru a administra aplicații, servicii și alte resurse într-un domeniu de celulă, nod, server sau cluster. Se poate utiliza consola cu servere autonome și cu manageri de implementare care gestionează toate serverele dintr-o celulă într-un mediu de rețea.

Widget-urile de administrare oferă o cale de a gestiona și monitoriza anumite componente ale soluției de gestiune proces operațional, inclusiv module și servicii Advanced Integration Service.

Process Designer permite dezvoltatorilor de procese să re-utilizeze elementele existente și în aplicațiile de proces și peste acestea. De exemplu, se cunosc servicii ce există deja și care includ antrenori și alte elemente partajate de care au nevoie și alți dezvoltatori, acele elemente se pot accesa și reutiliza, incluzându-le pe acestea într-o trusă de unelte. Apoi, din aplicația de proces, se poate adăuga o dependență la trusa de unelte în care se află elementele partajate. Acest lucru permite folosirea unuia din serviciile existente atunci când se alege implementarea pentru o activitate. Elementele din trusa de unelte pot de asemenea fi utilizate de către alți dezvoltatori în diferite aplicații de proces.

IBM Process Center servește, deci, ca o magazie centrală pentru toate aseturile de proiect create în Process Designer. Atunci când mai mulți clienți Process Designer se conectează la Process Center, utilizatorii pot partaja elemente, cum ar fi procesele și serviciile și pot vedea, de asemenea, schimbările realizate de alți utilizatori pe măsură ce se întâmplă.

Process Center poate fi utilizată, de asemenea, ca un magazie pentru aseturile create în IBM Integration Designer.

Utilizând inspectorul, dezvoltatorii individuali pot rula procese și servicii pe Process Center Runtime-ul server sau la distanță Process Server. Inspectorul din IBM Process Designer este cheia pentru o abordare repetată pentru a procesa dezvoltarea. O echipă întreagă de dezvoltare poate utiliza Inspectorul pentru a demonstra proiectarea și implementarea procesului curent în sesiunile playback. Sesiunile playback ajută capturarea informațiilor importante de la diferiți deținători de acțiuni (stakeholder) într-un proces, precum management, utilizatori finali și analiști business. Aplicarea unei abordări iterative dezvoltării procesului asigură îndeplinirea scopurilor și nevoilor tuturor celor implicați de către aplicațiile de proces.

1.1.14. Tendințe BMPN

Modelarea proceselor de afaceri pentru SOA (Software Oriented Arhitecture) și dezvoltarea suportului IT au devenit priorități în domeniul tehnologiilor informaționale.

Abordarea SOA se bazează pe servicii și procese, acestea din urmă fiind axate pe compoziția serviciilor, serviciile devenind, astfel, activități proces.

Experiența a arătat că implementarea și optimizarea proceselor sunt cei mai importanți factori pentru asigurarea succesului proiectelor SOA. Valoarea SOA pentru afaceri este dată de optimizarea proceselor. Pentru a le optimiza, este necesar ca procesele relevante să fie cunoscute și înțelese, fapt ce nu poate fi realizat fără modelarea proceselor de afaceri. Această abordare are însă de trecut peste golul semantic dintre modelarea procesului și aplicația în sine (Ward-Dutton și Macehiter, 2005).

Pentru ca aceste proiecte să aibă succes este necesară o abordare pragmatică asupra modelării proceselor de afaceri, prin utilizarea BPMN și a mapării automate din BPMN în BPEL – standard esențial pentru executarea proceselor de afaceri în SOA.

De asemenea, o importanță deosebită trebuie acordă tehnologiilor înrudite, cum ar fi: BRM (Business Rules Management) și BAM (Business Activity Monitoring), tehnologii ce joacă un rol important în succesul BPM (Basu și Blanning, 2003).

În timp ce BPEL a captat destul de multă atenție în cadrul comunității dezvoltatorilor, BPMN a ajuns să dețină o importanță deosebită în comunitatea afacerilor. Tehnologiile construite pe ambele standarde promit să îmbunătățească comunicarea între analiști și dezvoltatori, o dată cu simplificarea dezvoltării aplicațiilor SOA. Provocările rămân, însă, la nivelul traducerii modelelor de afaceri construite pe baza BPMN în aplicații scrise în BPEL.

Notațiile BPMN oferă un set de standarde pentru descrierea modului în care trebuie să arate elementele ce se vor regăsi în aplicație. Acesta a câștigat popularitate datorită faptului că, organizațiile au învățat să utilizeze analizele proceselor de afaceri într-o manieră în care să poată fi create aplicații, ce se vor plia pe specificul afacerii lor.

Dan Scholler, directorul de cercetarea de la Gartner afirma că interesul cel mai mare apare atunci când imaginea frumoasă nu numai că mă ajută să înțeleg, ci mă ajută să construiesc. Acesta este de părere că pe viitor, nu se poate vorbi de o perioadă în care să desenezi o imagine și să o rulezi pe un fel de instanță a unei tehnologii, indiferent de producătorul acesteia, deoarece vor exista în continuare o multitudine de dependențe (Lawton).

1.2. Process Mining

Bazele de date pot ajunge în zilele noastre pînă la dimensiuni exprimate în terabytes (mai mult de 1015 biți de date). În interiorul acestor masive de date se găsesc informații de o importanță strategică. Se pune problema cum putem trage o concluzie semnificativă despre acest masiv de date având în vedere diversitatea informației conținută.

Cel mai nou răspuns este data mining, tehnică folosită în industrie atât pentru a crește veniturile, cât și pentru a reduce costurile. Câștigurile potențiale sunt enorme. Organizații inovatoare din întreaga lume folosesc deja tehnologia data mining pentru a localiza și apela la clienți cu potențial financiar, pentru a reconfigura ofertele lor de produse pentru a mări vânzarile și să minimizeze pierderile datorate erorilor sau fraudelor.

1.2.1. Necesitatea apariției unei noi tehnici de manipulare a datelor

Procesul data mining folosește o varietate largă de unelte de analiză a datelor pentru a descoperi tipare și relații de legătură între date care pot fi folosite pentru a face predicții valide.

Primul și cel mai simplu pas analitic în data mining este descrierea datelor (trecerea în revista a tuturor atributelor statistice precum valorile medii și abaterile standard, vizualizarea folosind grafice și grafuri și căutarea potențialelor legături semnificative între variabile, precum valori care apar frecvent). Trebuie accentuat că în data mining, colectarea, explorarea și selectarea datelor semnificative are o importanță critică.

Însă numai descrierea datelor nu poate oferi și un plan de acțiune.Trebuie construit și un model predictiv bazat pe tiparele determinate din rezultatele cunoscute și apoi trebuie testat acest model pe rezultate diferite de cele inițiale. Un model reușit nu trebuie niciodată confundat cu realitatea (se știe că o hartă a drumurilor nu este o reprezentare fidelă a drumului), dar poate fi un ghid practic pentru a înțelege o afacere.

Ultimul pas într-o tehnică data mining este verificarea empirică a modelului. De exemplu, dintr-o bază de date a clienților care deja au răspuns la o anumită ofertă, se poate construi un model care prezice care potențiali cumpărători vor răspunde aceleași oferte.

Tehnicile data mining se referă la automatizarea procesului de căutare a tiparelor în masive de date și de găsirea răspunsurilor la întrebările: Care tipare sunt interesante? Care tipare sunt false? Care tipare pot fi exploatate?

1.2.2. Posibilități oferite de tehnicile de data mining

O tehnică data mining este o unealtă, care necesită îndrumare umană experimentată. Nu este suficient ca tehnica aleasă să fie implementată în baza de date și să se aștepte ca aceasta să atenționeze utilizatorul în momentul în care vede un tipar interesant. Existența tehnicilor data mining nu elimină nevoia ca utilizatorul să-și cunoască afacerea, să-și înțeleagă datele și metodele analitice. O tehnică data mining asistă analiștii prin găsirea tiparelor și relațiilor dintre date, dar nu spune valoarea tiparului pentru organizație. Mai mult, tiparul descoperit de această tehnică trebuie verificat în lumea reală (Kudyba și Hoptroff, 2001).

Trebuie amintit că relațiile predictive găsite prin intermediul tehnicilor data mining nu sunt neapărat cauzele unei acțiuni sau comportament. De exemplu, o tehnică data mining poate determina că bărbații cu venituri între anumite limite care se abonează la o anumită revistă sunt posibili cumpărători ai unui produs care se dorește a fi vândut. În timp ce se folosește acest tipar, țintind către cumpărători care să se încadreze în el, nu trebuie să se presupună că vreunul din factori îi determină să cumpere acel produs.

Pentru mai multă siguranță în obținerea unor rezultate semnificative, este foarte importantă înțelegerea datelor. Calitatea ieșirilor va fi deseori sensibilă la valori ale datelor, care sunt diferite de valorile tipice din baza de date, la categorii irelevante sau categorii care variază împreună (precum vârsta și data nașterii), la felul cum sunt codificate datele, la datele care sunt luate în calcul și datele care sunt excluse. Sensibilitatea algoritmilor la astfel de probleme variază, dar nu este recomandabil să se depindă doar de un produs al unei tehnici data mining pentru a lua toate deciziile corecte (Ullman).

O tehnică de forare în date nu descoperă automat soluții fără îndrumare. Decât să se fixeze un scop vag, precum cererea ajutorului pentru a crește numărul de răspunsuri la o anumită ofertă, mai bine se forează pentru a găsi caracteristicile celor care răspund unor anumite solicitări și fac o importantă achiziție. Tiparele pe care o tehnică data mining le va găsi pentru cele două scopuri pot fi foarte diferite.

Deși o unealtă eficientă de tip data mining ferește oarecum utilizatorul de complexitatea tehnicilor statistice, cere ca acesta să înțeleagă activițile uneltelor pe care le alege și algoritmii pe care acestea se bazează. Alegerile pe care utilizatorul le face în programarea instrumentelor și optimizările asupra lor va afecta acuratețea și viteza modelelor (Kudyba și Hoptroff, 2001).

O tehnică data mining nu înlocuiește analiștii în afaceri sau managerii, ci le oferă o unealtă nouă și puternică pentru a-și îmbunătăți munca pe care o fac. Orice companie care își cunoaște afacerea are în vedere tipare importante pe care angajații le-au observat de-a lungul anilor. Ceea ce poate să facă o tehnică data mining este să confirme astfel de observații empirice și să găsească tipare noi și subtile care produc creșteri stabile, sau uneori adevărate explozii.

1.2.3. Tehnicile de data mining și depozitarea datelor

În mod frecvent, datele care urmează a fi prelucrate în cadrul data mining sunt mai întâi extrase din depozitul de date al unei întreprinderi într-o bază de date de forare. Este avantajos dacă datele fac parte deja dintr-un depozit. Problema curățării datelor pentru un depozit de date și pentru o tehnică data mining sunt similare. Daca datele au fost deja curățate pentru un depozit atunci este destul de probabil că nu vor mai avea nevoie de alte verificări pentru a fi forate. Mai mult, deja au fost rezolvate probleme de consolidare a datelor și aranjate proceduri de întreținere (Kudyba și Hoptroff, 2001).

Baza de date pentru data mining este mai degrabă un subset logic decât fizic al depozitului de date, aceasta dacă depozitul poate suporta resursele adiționale cerute de data mining. Daca nu, este mai bine să se folosească o bază de date separată.

Un depozit de date nu este o cerință obligatorie pentu o tehnică data mining. Construirea unui depozit uriaș, care adună date din surse multiple, rezolvă problema integrității datelor și încarcă datele într-o bază de date de interogare, însă poate presupune un efort imens, câteodată durând ani întregi și costând sume uriașe. Se poate oricum să se foreze datele dintr-una sau mai multe baze de date operaționale sau tranzacționale pur și simplu extrăgându-le într-o bază de date din care se poate doar citi informație. Această bază de date nouă funcționează ca un subset de date (Kudyba și Hoptroff, 2001).

Figura 43. Depozitarea datelor

1.2.4. Descrierea datelor pentru data mining

Înainte de a putea fi construit un model predictiv eficient, trebuie să fie înțelese datele. Se începe prin a aduna o varietate de caracteristici numerice (incluzând descrieri statistice precum mediile, abaterile standard, etc) și prin a observa distribuția datelor. Se pot construi și tabele pivot pentru date multidimensionale.

1.2.4.1. Sumarizare și vizualizare

Datele pot fi continue, având orice valoare numerică sau categoricale, potrivindu-se în clasele discrete. Datele categoricale pot fi mai departe definite fie ca ordinale, având o anumită ordine (high, medium, low), sau nominale (neordonate).

Uneltele grafice și de vizualizare sunt un ajutor vital în pregătirea datelor și importanța lor pentru că analiza eficientă a datelor nu poate fi supraevaluată. Vizualizarea datelor oferă cel mai adesea ideea care conduce la noi intuiții și succes. Câteva dintre cele mai comune și utile dispuneri grafice ale datelor sunt histogramele, sau schemele care afișează distribuția valorilor. Se pot vizualiza scheme de împrăștiere, în două sau trei dimensiuni, ale diferitelor perechi de variabile. Abilitatea de a adăuga o a treia, de a supraîncărca variabile mărește puternic folosirea din plin a anumitor tipuri de grafică (Ullman).

Vizualizarea funcționează pentru că exploatează banda mai largă a informațiilor grafice în comparație cu cea a textului sau a numerelor. Permite oamenilor să vadă pădurea și să se concentreze și asupra copacilor. Tiparele, relațiile, valorile excepționale și valorile lipsă sunt adesea mai ușor de preceput când sunt prezentate grafic, decât atunci când sunt prezentate ca o listă de numere sau text (Kudyba și Hoptroff, 2001).

Problema în folosirea vizualizării provine din faptul că modelele au mai multe dimensiuni sau variabile, însă oamenii sunt restricționați la a arăta acele dimensiuni pe un monitor bidimensional sau foaie de hârtie (de exemplu, dacă se dorește vizualizarea relației dintre riscul de credit și vărstă, sex, stare civilă, ani vechime în muncă). În mod consecvent, uneltele de vizualizare trebuie să folosească reprezentări inteligente, pentru a cuprinde n dimensiuni în două. Unelte de vizualizare din ce în ce mai puternice și mai sofisticate sunt dezvoltate, dar de cele mai multe ori necesită ca oamenii să-și formeze ochii prin practică pentru a înțelege informația afișată. Utilizatorii care nu disting culorile sau cei care nu au orientare în spațiu, pot avea, de asemenea, probleme cu uneltele de vizualizare (Kudyba și Hoptroff, 2001).

1.2.4.2. Clustering

Clusteringul împarte o bază de date în grupuri diferite. Scopul clustering-ului este acela de a găsi grupuri care sunt foarte diferite unele de altele și pe acei membri care sunt foarte asemănători unii cu alții. Spre deosebire de clasificare, nu se știe care va fi cluster-ul, când se începe, sau după care atribute datele vor fi grupate. În mod normal, cineva care are cunoștințe în domeniul afacerilor trebuie să interpreteze cluster-ul. De obicei este necesară modificarea cluster-ului prin excluderea variabilelor care au fost angajate în exemple de grupuri pentru că pe baza examinării, utilizatorul le identifică drept irelevante. După ce au fost găsite cluster-ele care împart rezonabil baza de date, aceste clustere pot fi apoi folosite să clasifice și date noi. Câțiva dintre cei mai întâlniți algoritmi folosiți pentru clustering includ hărți Kohonen și K-means (Kudyba și Hoptroff, 2001).

1.2.4.2.1. Definiție și exemple de clustering

A nu se confunda clustering-ul cu segmentarea. Segmentarea se referă la problema generală a identificării grupurilor care au caracteristici comune. Clustering-ul este un mod de a segmenta datele în grupuri care nu sunt definite anterior, în timp ce clasificarea este un mod de a segmenta datele asignându-le la grupuri definite anterior.

Skycat a împărțit 2*103 corpuri cerești în stele, galaxii, quasari, etc. Fiecare corp era un punct într-un spațiu cu șapte dimensiuni și fiecare dimensiune reprezenta radiația într-o bandă a spectrului. Sloan Sky Survey este un program mai ambițios, încercând catalogarea întregului univers vizibil.

Documentele pot fi gândite ca puncte într-un spațiu cu un număr foarte mare de dimensiuni, unde, fiecare dimensiune corespunde unui cuvânt posibil. Poziția documentului într-o dimensiune este dată de numărul de apariții ale cuvântului în document (sau doar 1 dacă apare și 0 în caz contrar). Clusterele cu documente în acest spațiu de cele mai multe ori corespund cu grupuri de documente cu același subiect.

1.2.4.2.2. Măsurarea distanțelor

Pentru a discuta dacă un set de puncte sunt suficient de apropiate pentru a forma un cluster, este nevoie de o măsurare a distanței D(x,y), care arată cât de departe este punctul x de punctul y. Axiomele distanței sunt (Kudyba și Hoptroff, 2001):

D(x,x) = 0 (distanța de la un punct la el însuși este nulă).

D(x,y) = D(y,x) (distanța este simetrică).

D(x,y) D(x,z) + D(z,y) (inegalitatea triunghiului).

Adesea, punctele pot fi gândite ca plutind într-un spațiu euclidian k-dimensional cu distanța dintre două puncte, x = (x1, x2,…, xk) și y = (y1, y2,…, yk), dată de una din formulele (Kudyba și Hoptroff, 2001):

Distanța comună (norma L2): D(x,y) = .

Distanța Manhattan (norma L1): D(x,y)=.

Maximul distanței (norma L∞): D(x,y)= .

Când nu există un spațiu euclidian în care să fie plasate punctele, clustering-ul devine mai dificil, însă măsurarea distanței are sens și în spații neeuclidiene, după cum reiese și din exemplul următor: Paginile web pot fi privite ca puncte într-un spațiu cu 10n dimensiuni, unde fiecare dimensiune corespunde unui cuvânt. Ținând cont de faptul că, oricum calculul distanței într-un spațiu cu atât de multe dimensiuni ar fi imposibil, o abordare mai bună a calculului este cea bazată pe produsul vectorial al vectorilor x și y, având de a face doar cu acele cuvinte care apar atât în x cât și în y. Trebuie calculată lungimea vectorilor implicați, care este radicalul sumei pătratelor numărului de apariții pentru fiecare cuvânt. Suma produselor aparițiilor fiecărui cuvânt în fiecare document se împarte la fiecare lungime pentru a obține un produs vectorial normalizat. Scăzând această cantitate din 1 se obține distanța dintre x și y (Kudyba și Hoptroff, 2001).

De exemplu, presupunând că există doar patru cuvinte care prezintă interes și vectorii x = (2, 0, 3, 1) și y = (5, 3, 2, 0) care reprezintă numărul de apariții al acestor cuvinte în două documente. Produsul vectorial xy este dat de: 2 * 5 + 0* 3 + 1 * 0 = 16.

Lungimea primului vector este:, iar lungimea celui de-al doilea vector este:, de unde: D(x,y) = 1- = 0. Adică x și y sunt practic același document; desigur, nu au același subiect, dar în mod sigur vor ține de același cluster.

1.2.4.2.3. Clasificarea algorimilor de clustering

Algoritmii de clusting comportă următoarea tipologie: algoritmi care folosesc o abordare centroidă și algoritmi care folosesc o abordare ierarhică.

În fiecare cluster se calculează centroizi (puncte centrale), iar punctele sunt asignate clusterului care are centroidul cel mai aproape de ele (Ullman).

În definirea algoritmilor care folosesc o abordare ierarhică, se începe prin a presupune că fiecare punct formează un cluster (Ullman). Apoi, în mod repetat, clusterele apropiate se unesc folosind o funcție care măsoară cât de apropiate sunt două clustere (de exemplu distanța dintre centroizi) sau cât de bun va fi clusterul rezultat (de exemplu distanța medie a punctelor din cluster, față de centroidul rezultat).

1.2.4.2.4. Algoritmul K-Means

Este un algoritm bazat pe memorie. Principiul algoritmului este următorul: algoritmul alege k centroizi de clustere, asignează un punct la un cluster alegând cel mai apropiat centroid (Kudyba și Hoptroff, 2001). În timp ce noi puncte sunt asignate la un cluster, centroidul se poate schimba.

Pentru k=2 se alege exemplul a cinci puncte în spațiul bidimensional și se asignează în ordine punctele 1, 2, 3, 4 și 5. Punctele 1 și 2 sunt asignate unor clustere și devin, pentru moment, centroizii lor. Când se ia în considerare punctul 3, presupunem că este mai aproape de 1, deci 3 este asignat aceluiași cluster cu punctul 1, al cărui centroid se mută în punctul a. Când asignăm punctul 4, observăm că se află mai aproape de 2 decât de a, deci 4 se alătură clusterului în care se află și 2, al cărui centroid se mută în b. În sfârșit, punctul 5 este mai aproape de a decât de b, deci se alătură clusterului {1,3}, al cărui centroid se mută în c.

Figura 44. Algoritmul K-Means

Centroizii pot fi inițializați alegând puncte suficient de depărtate de alți centroizi, până când obținem k elemente.

În timpul calculului putem decide să despărțim un element și să unim două pentru a menține totalul la k; un criteriu de a face acest lucru este reducerea distanței medii dintre puncte și centroizii lor.

După ce au fost localizați centroizii pentru k clustere, se pot reasigna toate punctele, deoarece unele puncte care au fost asignate anterior pot ajunge mai aproape de alți centroizi, după cum aceștia se schimbă.

Dacă nu suntem siguri de valoarea lui k, putem încerca diferite valori pentru acesta.

Considerând datele din figura următoare, este clar că numărul corect de clustere este trei, însă putem încerca mai întâi pentru k=1. Atunci toate punctele se află într-un singur cluster și distanța medie față de centroid este mare.

Presupunând k=2, unul dintre cele trei clustere va fi de sine stătător, iar celelalte două vor fi forțate să se unească, după cum sugerează liniile îngroșate. Distanța medie a punctelor față de centroid se va micșora considerabil. Pentru k=3, fiecare cluster va fi de sine stătător și distanța va scădea și mai mult. K se poate mări la 4 și atunci unul dintre clustere va fi artificial partiționat în două clustere apropiate selectate prin liniile mai subțiri. Distanța medie față de centroid va mai scădea puțin, dar nu prea mult și este o greșeală să încercăm creșterea lui k.

Figura 45. Algoritmul K-Means

Figura 46. Algoritmul K-Means

1.2.4.2.5. Algoritmul BFR

Bazat pe tehnica anterioară, acest algoritm citește datele o singură dată și le memorează. Algoritmul lucrează cel mai bine când datele urmează o distribuție normală în jurul unui punct central, poate cu o abatere standard diferită în fiecare dimensiune. Figura următoare demonstrează cum ar putea arăta datele care aparțin unui cluster tipic cu două dimensiuni. Un centroid, marcat cu semnul „+” are puncte împrăștiate în jurul său cu o deviație standard în spațiul orizontal de două ori mai mare decât cea din spațiul vertical. Aproximativ 70% din puncte vor fi în interiorul elipsei , 95% vor fi în elipsa 2, 99% vor fi în elipsa 3, iar 99.99% vor fi în elipsa 4.

După ce a lucrat la modelarea Skycat, Usama Fayyad a gândit probabil clusterele precum galaxii. Un cluster este compus din:

Un miez central, setul de înlăturat (DS – Discard Set) și este format din punctele care aparțin cu siguranță clusterului. Toate punctele din acest set sunt înlocuite cu niște statistici. Deși punctele sunt numite de înlăturat, ele au un rol important în reglarea algoritmului, deoarece ele determină poziția centroidului și deviația standard a clusterelor în fiecare dimensiune.

Figura 47. Miezul central al clusterului

Un set de reducere (CS – Compression Set), format din puncte care înconjoară subgalaxiile. CS constă în puncte care sunt suficient de apropiate unele de altele încât să poată fi înlocuite cu o statistică, așa cum DS este pentru cluster. Oricum, sunt suficient de îndepărtate de orice centroid încât să nu putem fi siguri cărui cluster îi aparțin.

Stelele individuale nu fac parte din galaxie sau subgalaxie și formează setul de reținut (RS – Retained Set). Aceste puncte nu pot fi asignate niciunui cluster, și nici nu pot fi grupate într-un subcluster al CS. Sunt stocate în memoria principală, ca puncte individuale, împreună cu statisticile despre DS și CS.

Datele statistice folosite să reprezinte fiecare cluster din DS și CS sunt:

Numărul de puncte N;

Vectorul sumelor coordonatelor punctelor din fiecare dimensiune; vectorul se numește SUM și componenta sa din dimensiunea i este SUMi;

Vectorul sumelor pătratelor coordonatelor punctelor din fiecare dimensiune, numit SUMSQ și componenta sa din dimensiunea i este SUMSQi.

Se observă că aceste tipuri de informații, în număr de 2k + 1 în cazul a k dimensiuni, sunt suficiente pentru a efectua calculele statistice importante pentru clustere și subclustere și este mai convenabil să se mențină pe parcursul adăugării de noi puncte la clustere.

De exemplu: coordonata yi a centroidului clusterului în dimensiunea i este SUMi/N; variația în dimensiunea i este: , iar deviația standard σi?este radicalul acestei expresii.

La fiecare încărcare a punctelor în memorie BFR selectează centroizii celor k clustere folosind algoritmi precum: se alege un set de puncte, se optimizează clusterele și se aleg centroizii. Tot setul de puncte care se va încărca ulterior în memorie.

Figura 48. Procesarea punctelor în BFR

Se calculează care puncte sunt suficient de aproape, deci pot fi incluse în DS și caracteristicile lor (N, SUM, SUMSQ) vor fi combinate cu calculele statistice precedente ale clusterului. BRF oferă două moduri de a determina dacă un punct este suficient de aproape de un centroid pentru a intra în DS:

Se aleg toate punctele ale căror raze Mahalanobis sunt mai mici decât o anumită valoare, de exemplu, de patru ori deviația standarda clusterului. Această rază este de fapt distanța față de centroid, împărțită în fiecare dimensiune i prin σi, deviația standard în acea dimensiune. Mai exact, dacă μi este media în dimensiunea i, atunci raza pentru punctul y = (y1, y2, …) este: Ry = .

În funcție de numărul de puncte în diferite clustere verificăm dacă (măcar cu o oarecare probabilitate) cel mai apropiat centroid curent se va deplasa în viitor suficient de departe de punctul y și alt centroid se va muta suficient de aproape de y, mai aproape chiar decât fusese primul. Este puțin probabil ca cel mai apropiat centroid pentru y va fi mereu diferit, apoi y va fi asignat la DS și plasat în clusterul celui mai apropiat centroid.

Se ajustează valorile N, SUM și SUMSQ pentru fiecare cluster pentru a lua în calcul și punctele introduse în DS.

Se încearcă asignarea la clustere a punctelor care nu au fost plasate în DS, inclusiv punctele din RS din etapele anterioare. Dacă se găsește un cluster a cărui varianță este dincolo de o limită aleasă, atunci aceste puncte vor fi considerate ca un subcluster, înlocuite cu statisticile lor și considerate o parte din CS. Toate celelalte puncte sunt plasate în RS.

Dacă considerăm cazul contopirii unui nou subcluster cu unul precedent din CS, testul trebuie făcut pentru a vedea dacă acest lucru este avantajos și constă în compararea varianței setului de puncte combinate cu limita aleasă. Trebuie observat că statisticile memorate despre subclusterele din CS sunt suficiente pentru a calcula varianța setului combinat.

Dacă ne aflăm la ultima etapă (nu mai avem date), atunci putem asigna clusterele din CS și punctele din RS celor mai apropiate clustere chiar dacă par destul de îndepărtate de centroidul clusterului

1.2.4.2.6. Fastmap

Scalarea multidimensională are o complexitate în timp de cel puțin O(n2) pentru n puncte, deoarece trebuie calculate distanțele cel puțin odată. Maparea rapidă este o metodă care ganerează k pseudo-axe care servesc la plasarea a n puncte într-un spațiu k-dimensional, cu o complexitate în timp de O(nk). Fastmap alege k perechi de puncte (ai, bi), fiecare servind drept capete pentru una dintre cele k axe. Folosind teorema cosinusurilor, putem calcula proiecția xi a oricărui punct c de pe linia ab, folosind doar distanțele între puncte și nicio altă coordonată presupusă.

Figura 49. Maparea rapidă

x =

După ce s-a ales o pereche de puncte (a,b) ca axă, o parte din distanța dintre oricare puncte c și d se calculează prin proiecțiile lui c și d pe pe linia ab, iar restul distanței ține de altă dimensiune. Dacă proiecțiile lui c și d sunt x și y, atunci înlocuim distanța dată dintre c și d cu o distanță curentă dintre c și a dată de formula:

Figura 50. Distanța curentă

Acesta este principiul algoritmului de Fastmap (Kudyba și Hoptroff, 2001): calculează pentru fiecare punct c, k proiecții pe care le notăm cu c(1),c(2),…,c(k) pe k axe care sunt determinate de perechile de puncte (a1, b1), (a2, b2),…, (ak, bk).

Pentru i=1, 2, … ,k se parcurg următorii pași:

Folosind distanța curentă Dcurent, se aleg ai, bi, după cum urmează:

Se alege un punct aleator c;

Se alege un punct ai pe cât de departe posibil de ci folosind Dcurent;

Se alege bi pe cât de departe posibil de ai.

Pentru fiecare punct x, se calculează x(i) folosind formulele cosinusurilor;

Se schimbă definiția lui Dcurent, astfel:

1.2.4.2.7. Clustering ierarhic

Este o tehnică generală care prezintă pericolul unei complexități de O(n2) pentru clustering-ul a n puncte în clustere ierarhice (Ullman).

Fiecare punct ocupă un singur cluster, inițial.

Se selectează în mod repetat două clustere să se unească; în general se aleg două clustere care sunt cele mai apropiate, dar există mai multe metode de a determina apropierea: măsurarea distanței dintre centroizi; minimul distanței dintre punctele din cluster; maximul distanței dintre punctele din cluster; distanța medie dintre nodurile din cluster (Kudyba și Hoptroff, 2001).

Încheierea procesului de unire are loc când se consideră că avem destul de puține clustere: prin abordare k-means (se doresc k clustere); se oprește procesul de unire când singurele clustere care mai pot rezulta din unire nu mai îndeplinesc niște criterii precum: distanța medie a punctelor față de centroid este prea mare.

1.2.4.2.8. Algoritmul GRGPF

Algoritmul presupune că există o măsură a distanței, D, dar nu și un spațiu euclidian. Mai presupune că sunt prea multe date pentru a fi păstrate în memorie. Structura folosită pentru a stoca clusterele este un R-tree. Nodurile arborelui sunt blocuri de date care diferă dacă nodurile sunt interioare sau sunt frunze (Kudyba și Hoptroff, 2001):

În frunze sunt stocate date statistice despre clustere asemănătoare cu cele din BFR. Oricum, din momentul în care nu este spațiu euclidian, apar și diferențe.

În nodurile interioare, sunt păstrate mostre de clustroizi din clusterele reprezentate de descendenții acestor noduri. Se face un efort în a trece subclusterele în fiecare clasă a subarborilor. Ca în orice R-tree, nodurile interioare oferă informații despre regiunea aproximativă unde sunt găsite clusterele și descendenții lor. Când se dorește inserarea unui punct într-un cluster se începe de la rădăcină și se coboară în arbore, alegând doar acele căi de-a lungul cărora se poate găsi un cluster rezonabil de apropiat, judecând după mostrele din fiecare nod.

1.2.4.2.9. Algoritmul CURE

Întorcându-ne la clustering-ul în spațiul euclidian, problema rezolvată de CURE este cea a variabilelor care nu urmează o distribuție normală, după cum cere algoritmul BFR, de unde multe lucruri încep să nu mai funcționeze în abordarea k-means.

Figurile următoare sugerează două posibile probleme. În prima figură, chiar dacă k = 4 este numărul potrivit de clustere (cercurile solide reprezintă granițele clusterelor) un algoritm care încearcă să minimizeze distanțele față de un centroid poate să grupeze punctele după cum sugerează liniile punctate, cu clusterul mare împărțit în trei părți și cu cele trei clustere mai mici combinate într-unul.

Figura 51. Algoritmul CURE

În cea de a doua figură, un cluster mai mare poate fi interpretat ca mai multe clustere rotunde, din moment ce acest lucru ar minimiza distanța medie dintre puncte și centroizi (se observă însă că, folosind raza Mahalonobis, un cluster care este întins într-o direcție este recunoscut ca circular, și nu ne așteptăm ca algoritmul BFR să greșească).

Figura 52. Algoritmul CURE

Etapele algoritmului sunt (Kudyba și Hoptroff, 2001):

Se începe cu o memorie plină de puncte aleatoare. Punctele se asignează la clustere folosind abordarea ierarhică. Se observă că clusteringul ierarhic tinde să evite problemele figurilor anterioare căt timp clusterele corecte au o densitate mare a punctelor;

Pentru fiecare cluster se alege o mostră de c puncte, pentru un c constant. Aceste puncte sunt alese pe cât posibil de împrăștiate, apoi mutate treptat către mijloc, după cum urmează: se alege primul punct al mostrei ca fiind punctul clusterului cel mai departe de centroid; se aleg în mod repetat puncte pentru mostră, alegând acel punct al clusterului a cărui distanță minimă față de un punct deja ales este pe cât de mare posibil; când sunt alese c puncte pentru mostră, se mută toate mostrele spre centroid cu un procent al distanței față de acesta. Drept urmare, punctele mostrelor trebuie să fie puncte reale ale clusterului. Efectul rezultat este acela că mostrele devin puncte tipice, împrăștiate în jurul clusterului, indiferent de forma clusterului.

Se asignează toate punctele, inclusiv cele implicate în etapele 1 și 2 celui mai apropiat cluster, unde, cel mai apropiat înseamnă cu cea mai mică distanță față de un punct al mostrei.

1.2.4.3. Analiza legăturilor

Analiza legăturilor este o abordare descriptivă de explorare a datelor, care ajută la identificare relațiilor între valorile dintr-o bază de date. Cele mai întâlnite abordări ale analizei legăturilor sunt descoperirea asocierilor și descoperirea secvențelor. Descoperirea asocierilor găsește reguli despre obiecte care apar împreună într-un eveniment, precum o tranzacție de achiziție. Analiza coșului de cumpărături este un bine cunoscut exemplu de descoperire a asocierilor. Descoperirea secvenței este similară, ținând cont de faptul că secvența este o asociere relativă la timp (Kudyba și Hoptroff, 2001).

Asocierile sunt scrise A ⇒ B, unde A se numește antecedent sau parte stângă (LHS), iar B se numește consecvent sau parte dreaptă (RHS). De exemplu: în regula de asociere Dacă oamenii cumpără un ciocan, apoi cumpără și cuie, antecedentul este cumpără un ciocan, iar consecventul este cumpără cuie.

Este ușor să se determine proporția de trazacții care conțin un anumit obiect sau un set de obiecte: pur și simplu le numărăm. Frecvența cu care o anumită asociere, setul ciocan și cuie, apare în baza de date se numește suportul său sau preponderență. Dacă, să zicem, 15 tranzacții din 1000 constau din ciocan și cuie, suportul acestei asocieri va fi de 1.5. Un suport scăzut (de exemplu o tranzacție dintr-un milion) poate indica faptul că respectiva asociere nu este foarte importantă sau poate indica prezența unor date greșite.

Pentru a descoperi reguli semnificative, trebuie privită și frecvența relativă a apariției acestor obiecte sau a combinației lor. Fiind dată apariția obiectului A (antecedentul), cât de des obiectul B (consecventul) are loc? Adică, care este probabilitatea lui B, fiind dat A? Folosind exemplul anterior, asta ar însemna să se întrebe când oamenii cumpără ciocan, cât de des cumpără și cuie? Un alt termen pentru predictibilitate este acela de încredere. Încrederea este calculată ca o fracție: (frecvența lui A și B) / (frecvența lui A).

Lift este o altă măsură pentru puterea unei asocieri (Kudyba și Hoptroff, 2001). Cu cât mai mare lift-ul, cu atât mai mare este influiența apariției lui A asupra probabilității ca să apară și B. Lift-ul este calculat ca fiind fracția (încrederea lui A ⇒ B) / (frecvența lui B): lift pentru ciocan ⇒ cuie: 3.75 %; lift pentru ciocan și cuie ⇒ lemn: 16.5 %

Algoritmii de asociere găsesc aceste reguli făcând echivalentul sortării datelor în timp ce se numără aparițiile și astfel se pot calcula încrederea și suportul. Eficiența cu care se poate face acest lucru este una dintre diferențierile dintre algoritmi. Unii algoritmi vor crea baze de reguli, factori de încredere și suporturi, care pot fi interogate.

Alt atribut comun pentru generatorii de reguli de asociere este abilitatea de a specifica o ierarhie a obiectelor (Kudyba și Hoptroff, 2001). În exemplu, ne-am uitat la toate cuiele și ciocanele și nu la tipuri individuale. Este important să se aleagă un nivel potrivit de agregare sau este puțin probabil să găsim asocierile care ne interesează. O ierarhie a obiectelor îți permite să controlezi nivelul de agregare și să experimentezi cu diferite nivele.

Trebuie amintit faptul că asocierile sau secvențele de reguli nu sunt reguli propriu-zise, ci mai degrabă descrieri ale relațiilor într-o anumită bază de date. Nu există o testare formală a modelelor pe alte date pentru a mări puterea de predicție a acestor reguli. Mai degrabă există o presupunere implicită conform căruia, comportamentul din trecut va continua și în viitor.

Este în general dificil să decizi ce să faci cu regulile de asociere descoperite. În planificarea magazinului, de exemplu, a așeza unele articole lângă altele asociate, poate reduce valoarea totală a coșului de cumpărături – clienții cumpără mai puține lucruri neplanificate, în timp ce merg prin magazin în căutarea articolelor dorite. Intuiția, analiza și experimentarea sunt de obicei folosite pentru a obține orice beneficiu de pe urma regulilor de asociere.

Figura 53. Analiza legăturilor

Metodele grafice pot fi, de asemenea, foarte folositoare în vizionarea legăturilor (Kudyba și Hoptroff, 2001). În figura următoare, fiecare cerc reprezintă o valoare, sau un eveniment. Liniile care conectează cercurile arată legăturile. Liniile mai groase reprezintă legături mai puternice sau mai frecvente, evidențiind potențial relații mai importante precum asocierile. De exemplu, privind la baza de date de asigurări, pentru a detecta fraude potențiale, se poate descoperi faptul că un anumit doctor și avocat lucrează împreună la un număr mare de cazuri.

1.2.5. Data mining și OLAP

Una dintre cele mai comune întrebari ale profesioniștilor care procesează date este în legătură cu diferența dintre data mining și OLAP (On-Line Analytical Processing). Cele două tehnici sunt unelte diferite, care se pot completa însă una pe cealaltă.

OLAP face parte din spectrul uneltelor folosite ca suport pentru decizii. Interogările tradiționale și uneltele de raport descriu ceea ce este într-o bază de date. OLAP merge mai departe: este folosit pentru a răspunde de ce anumite lucruri sunt adevărate. Utilizatorul formulează o ipoteză despre o relație și apoi o verifică cu o serie de interogări asupra datelor. De exemplu, un analist încearcă determinarea factorilor care duc la refuzul unui împrumut. El poate presupune inițial că oamenii cu venituri mici prezintă riscuri mari de creditare și apoi poate analiza baza de date cu OLAP pentru a verifica ipoteza făcută. Dacă acea ipoteză nu a reieșit din datele analizate, analistul poate privi datoriile mari ca un determinant al riscului. Dacă datele nu au susținut nici această ipoteză el poate încerca să folosească drept predictor pentru riscul creditului atât datoriile, cât și venitul.

Cu alte cuvinte, analistul OLAP generează o serie de tipare ipotetice și relații și folosește interogările asupra bazelor de date pentru a le confirma, sau pentru a le respinge. Analistul OLAP este esențial pentru procesul de deducție. Dar în momentul în care numărul variabilelor de analizat este de ordinul sutelor devine mult mai dificil și durează mult mai mult găsirea unei ipoteze bune (este vorba despre siguranța că nu există o explicație mai bună decât cea găsită) și despre analiza bazelor de date cu OLAP pentru confirmarea sau respingerea acestei ipoteze.

Data mining este diferită ca tehnică de OLAP pentru că în loc să verifice tipare ipotetice, folosește ea însăși datele pentru a descoperi asemenea tipare. Este în mod esențial un proces de inducție. De exemplu, presupunând că analistul care voia să identifice factorii de risc pentru un împrumut folosește o unealtă data mining. Aceasta poate descoperi că oamenii cu venituri mici și datorii mari prezintă riscuri mari pentru împrumut (ca și anterior) dar poate merge mai departe și să descopere un tipar pe care analistul nu l-a gândit, precum faptul că și vârsta este un determinant al riscului.

În acest sens, OLAP și data mining se pot completa una pe cealaltă, ca tehnici. Înainte de a acționa conform tiparului, analistul are nevoie să știe care sunt implicațiile financiare dacă se va folosi tiparul descoperit. OLAP permite analistului să răspundă la acest gen de întrebări. Mai mult, OLAP este de asemenea complementar în stările incipiente ale procesului de descoperire a cunoștințelor, deoarece poate ajuta la explorarea datelor, de exemplu, prin concentrarea atenției asupra unor variabile importante, prin identificarea excepțiilor sau prin găsirea interacțiunilor. Acest lucru este important pentru că, cu cât sunt înțelese mai bine datele, cu atât mai eficient este procesul de descoperire a cunoștințelor.

1.2.6. Data mining, învățarea automatelor și statistica

Data mining profită de progresele făcute în domeniul inteligenței artificiale și statisticii. Ambele discipline au lucrat asupra problemelor de recunoaștere a tiparelor și clasificarea lor. Ambele comunitați și-au adus contribuții importante pentru înțelegerea și aplicarea rețelelor neuronale și ale arborilor de decizie.

Data mining nu înlocuiește tehnicile statistice tradiționale. Mai degrabă, este o extensie a metodelor statistice care este parțial un rezultat al schimbărilor majore în comunitatea statistică. Dezvoltarea celor mai multe tehnici statistice a fost până de curând bazată pe teoria elegantă și metodele analitice care au lucrat destul de bine pe o cantitate modestă de date de analizat. Puterea crescută a computerelor și prețul lor mai mic, alături de nevoia de a analiza seturi imense de date, cu milioane de linii, au permis dezvoltarea de noi tehnici bazate pe explorarea prin forță brută a soluțiilor posibile (Kudyba și Hoptroff, 2001).

Noile tehnici includ algoritmi relativ recenți precum rețelele neuronale și arbori de decizie, dar și noi abordări ale vechilor algoritmi, precum analiza diferențelor. Tehnicile statistice tradiționale se bazează pe modelatoare pentru a exprima forma funcțională și interacțiunile.

Punctul cheie în data mining este aplicarea acestor tehnici statistice sau de inteligență artificiala în probleme comune ale afacerilor într-un mod în care aceste tehnici sunt accesibile atât celor care lucrează cu cunoștințe, cât și profesioniștilor în statistică. Data mining este o unealtă prin care se crește productivitatea celor care încearcă să construiască modele predictive.

1.2.7. Data mining și tendințele hardware și software

Puternica scădere a prețurilor discurilor de stocare pentru computere în ultimii ani a schimbat economia în ceea ce privește colectarea și stocarea cantitaților imense de date. Scăderea costurilor și în privința procesoarelor a fost la fel de puternică. Fiecare generație de chip-uri mărește considerabil puterea CPU pe lângă alte scăderi pe curba prețurilor. Acest lucru se reflectă în prețul RAM, unde costul unui megabyte a scăzut de câteva sute de ori în doar câțiva ani.

În timp ce puterea unui CPU individual a crescut considerabil, s-a avansat cu cercetarea și în domeniul arhitecturii calculatoarelor paralele. Virtual, astăzi toate serverele suportă CPU multiple și, folosind multiprocesarea simetrică și ciorchini de astfel de servere SMP pot fi create – sisteme ce permit la sute de CPU să lucreze pentru găsirea unor tipare în date.

Progresul făcut în sistemele de management al bazelor de date, profitând de acest paralelism în hardware, este benefic pentru data mining. Pentru o problemă complexă de data mining, care cere acces la multe baze de date existente, accesul nativ DBMS asigură cele mai bune performanțe posibile.

Rezultatul tuturor acestor tendințe descrise este acela că multe bariere de performanță pentru găsirea tiparelor în cantități imense de date au fost eliminate.

1.2.8. Modele și algoritmi de data mining

Scopul tehnologiilor data mining este de a produce cunoștințe noi conform cărora să acționeze utilizatorul. Acesta construiește un model al realității bazat pe date colectate dintr-o varietate de surse care pot include tranzacțiile corporației, istoria clienților și informații demografice, date de control al procesului și baze de date externe relevante precum informații de la biroul de credit sau date despre starea vremii. Rezultatul construirii modelului este o descriere a tiparelor și relațiilor între date care pot fi folosite cu încredere pentru predicții.

1.2.8.1. Data mining predictiv

Pentru a evita confundarea diferitelor aspecte ale tehnicilor data mining, ajută să avem o imagine a ierarhiei alegerilor și deciziilor de care ai nevoie înainte de a începe: scopul afacerii; tipul predicției; tipul modelului; algoritmul; produsul.

1.2.8.1.1. Ierarhia alegerilor

Pe cel mai înalt nivel se află scopul afacerii: care este scopul final al forării acestor date? De exemplu, ca să căutăm tipare în date pentru a ajuta la reținerea clienților profitabili putem construi un model pentru a prezice care clienți vor aduce profituri mari și un al doilea model pentru a identifica clienții pe cale să se retragă. Cunoștințele asupra nevoilor și obiectivelor organizației vor conduce la formularea scopului modelelor.

Pasul următor este decizia asupra cărui tip de predicție este cel mai potrivit: clasificare: a prezice în ce categorie sau clasă se încadrează un caz; regresie: a prezice ce valoare numerică va avea o variabilă (dacă este o variabilă carre variază în timp se numește predicție în serie în timp)

După aceea se poate alege tipul modelului: o rețea neuronală pentru a realiza regresia și un arbore de decizie pentru clasificare. Deasemenea, există modele statistice tradiționale, poți să alegi dintre regresia logistică, analiza discriminanților sau modele liniare generale. Cele mai importante tipuri de modele de date pentru data mining sunt descrise în secțiunile următoare:

Pentru construirea unor modele sunt disponibile o serie de algoritmi; se poate construi o rețea neuronală folosind metoda back propagation sau funcții cu baza radială. Pentru arborii de decizie se poate alege din: CART, C5.0. Câțiva dintre acești algoritmi sunt deasemenea discutați în secțiunile următoare.

Când se selectează un produs data mining trebuie ținut cont de faptul că acestea implementează un anumit algoritm în diferite moduri, chiar dacă sunt identificați de aceleași nume. Aceste diferențe de implementare pot afecta caracteristici operaționale, precum folosirea memoriei și depozitarea datelor și caracteristici ale performanței precum viteza și acuitatea.

1.2.8.1.2. Terminologie

În modelele predictive, valorile claselor pe care le prezicem sunt numite răspunsuri, subordonate sau variabile țintă. Valorile folosite pentru a face predicțiile se numesc predictori sau variabile independente.

Modelele predictive sunt construite sau antrenate folosind date pentru care valoarea variabilelor răspuns este deja cunoscută. Acest fel de antrenament este adeseori numit învățare supervizată deoarece valorile calculate sau estimate sunt comparate cu rezultatele cunoscute (dimpotrivă, tehnicile descriptive precum clustering-ul sunt numite adeseori învățare supervizată, deoarece nu există rezultate deja cunoscute, pentru a îndruma algoritmii).

1.2.8.1.3. Tipologie

Problemele de clasificare țintesc să identifice caracteristicile care îndică grupul de care aparțin fiecare caz. Tiparul poate fi folosit atât pentru a înțelege datele existente și pentru a prezice în ce mod noi operații ale lor se vor comporta. De exemplu, dacă dorim să prezicem dacă indivizii pot fi clasificați în: cei care răspund la o solicitare directă prin poștă, sau cei care ar fi mai tentați de un serviciu de telefonie la distanță. Data mining crează modele de clasificare examinând datele deja clasificate (cazurile) și găsind intuitiv tipare predictive. Aceste cazuri existente pot proveni dintr-o bază de date existentă, precum cea a oamenilor care au urmat un anumit tratament medicamentos sau au apelat la un nou serviciu de telefonie. Pot deasemenea proveni dintr-un experiment în care o monstră din întreaga bază de date este testată în lumea reală și rezultatul este folosit pentru a creea clasificări. Câte o dată, un expert clarifică o monstră dintr-o bază de date și această clasificare este apoi folosită pentru a crea modelul care va fi aplicat întregii baze de date.

1.2.8.1.4. Regresie

Regresiile folosesc valori existente pentru a prezice ce alte valori vor apărea. În cel mai simplu caz, regresiile folosesc tehnici statice standard precum regresia liniară. Din păcate, multe probleme ale lumii reale nu sunt proiecții liniare simple ale valorilor b#%l!^+a?precedente. De exemplu, volumul vânzărilor, prețurile stocurilor și rata rebuturilor sunt foarte dificil de prezis pentru că pot depinde de interacțiuni complexe ale mai multor variabile de predicție. Tocmai de aceea, tehnici mai complexe (regresie logistică, cuburi de decizie sau rețele neuronale). Ar putea fi necesare pentru a prezice variabilele viitoare. Acelorași tipuri de modele pot fi folosite atât pentru regresie cât și pentru clasificare, De exemplu, algoritmul pentru arbori de decizie CART (arbori de clasificare și regresie) poate fi folosit atât pentru a construi arbori de clasificare (pentru a clasifica variabilele de răspuns categorice) cât și pentru arbori de regresie (pentru a prevedea variabilele de răspuns continue). Rețelele neuronale pot deasemenea crea atât modele de clasificare cât și modele de regresie.

1.2.8.1.5. Șiruri temporale

Șirurile temporale prezic valori viitoare necunoscute bazate pe serii de predictori care variază în timp. La fel ca la regresii, folosesc rezultate cunoscute pentru a ghida predicțiile. Modelele trebuie să țină cont pe perioadele de timp, în special de ierarhizarea perioadelor (incluzând varietatea definițiilor precum săptămâna de lucru de 5 sau 7 zile, anul de 13 luni, etc.), de sezoane, vacanțe, aritmetica datelor și considerații speciale precum cât anume din trecut este relevant.

1.2.8.2. Modele data mining

Să examinăm în cel fel anumiți algoritmi și tipuri de modele sunt folosite pentru a fora în date. Cele mai multe produse folosesc variații ale algoritmilor care au fost publicați în reviste specializate în informatică sau statistică, cu implementarea lor specifică, adaptată la scopurile individuale ale ofertanților. De exemplu, mulți ofertanți vând arbori de decizie CART sau CHAID îmbunătățiți pentru a lucra cu computere paralele. Alți ofertanți au algoritmi proprii care fără a fi extensii sau variante îmbunătățite ale unor abordări publicate, pot merge destul de bine.

Cele mai multe dintre modelele și algoritmii discutați în această secțiune pot fi văzuți ca generalizări al multiutilizatului model de regresie liniară. Un efort intens a fost depus în statistică, informatică, inteligență artificială și inginerie pentru a depăși limitările modelului de bază. Caracteristicile comune ale multor tehnologii noi vor privi mecanismul de găsire a tiparelor ca fiind mai mult condus de date decât de utilizatori. Adică, relațiile sunt găsite inductiv de software, bazându-se pe date existente și nu cerând modelatorului să specifice formale funcționale și interacțiunile.

Poate cel mai important lucru de amintit este acela că niciunul dintre modele sau algoritmi poate fi sau ar trebui fi folosit în mod exclusiv. Pentru orice problemă dată însăși natura datelor va afecta alegerea modelelor și a algoritmilor. Nu exsită un cel mai bun model sau algoritm. Ca urmare, este nevoie de o varietate mare de unelte și tehnologii pentru a găsi cel mai bun model posibil.

1.2.8.2.1. Rețele neuronale

Rețelele neuronale prezintă un interes particular deoarece oferă mijloace de modelare eficientă a problemelor complexe în care pot fi folosite de variabile de predicție care pot interacționa în multe feluri (adevăratele rețele neuronale, biologice, sunt defapt cu mult mai complexe). Rețelele neuronale pot fi folosite în probleme de clasificare (unde rezultatul este o variabilă categorică) sau pentru regresii (unde rezultatul este o variabilă continuă).

O rețea neuronală începe un strat al intrărilor unde fiecare nod corespunde unei variabile de predicție. Aceste noduri de intrare sunt conectate la un număr de noduri dintr-un strat ascuns. Fiecare nod de intrare este conectat cu fiecare nod din stratul ascuns. Nodurile din stratul ascuns pot fi controlate cu nodurile din alt strat ascuns sau dintr-un start de ieșire. Stratul de ieșire constă în una sau mai multe variabile de răspuns.

După stratul de intrare, fiecare nod primește o serie de intrări, le înmulțește cu o pondere de legătură Wxy, le adună, le aplică o funcție (numită funcție de activare) și trece rezultatul nodului sau nodurilor din stratul următor. De exemplu, valoarea trecută de la nodul 4 la nodul 6, este funcția de activare aplicată pentru: [W14*val. nodului 1]+[W24*val. nodului 2].

Figura 54. Rețele neuronale

Fiecare nod poate fi văzut ca o variabilă de predicție sau ca o combinație de variabile de predicție. Nodul 6 este o combinație neliniară a valorilor din nodurile 1 și 2 din cauza funcțiilor de activare aplicată valorilor însumate în stratul ascuns. De fapt, atunci când funcția de activare este liniară și nu există strat ascuns, rețelele neuronale sunt echivalente cu regresiile liniare și atunci când funcțiile de activare nu sunt liniare și au anumite formule de calcul, rețelele neuronale sunt echivalente cu regresiile logistice.

Ponderile de legătură sunt parametri necunoscuți care sunt estimați prin metode de antrenare. Inițial, cea mai folosită metodă de antrenare era back propagation; metodele mai noi includ algoritmi complecși precum: algoritmi genetici, Levenbrg-Marquardt, Newton, etc. Fiecare metodă de antrenare are un set de parametri care controlează diferite aspecte ale antrenării precum evitarea optimelor locale sau ajustarea vitezei de conversie.

Arhitectura sau topologia unei rețele neuronale este dată de numărul de noduri și de straturi ascunse și de felul în care acestea sunt legate. În proiectarea rețelelor neuronale, fie utilizatorul, fie soft-ul trebuie să aleagă numărul de noduri ascunse sau straturi ascunse, funcțiile de activare și limitele ponderilor. Deși există câteva modele de îndrumare se pot experimenta arhitecturi noi cu aceste valori.

Unul dintre cele mai întâlnite tipuri de rețele neuronale este rețeaua feed-forward- backpropagation. Pentru a simplifica modelul, se consideră doar cazul unui singur strat ascuns.

Antrenarea backpropagation este o versiune a pantei descendente, un tip de algoritm care încearcă să reducă o valoare țintă (eroare, în cazul rețelelor neuronale) la fiecare pas. Algoritmul procedează în felul următor:

Feed-forward: Valoarea nodului de ieșire este calculată pe baza valorilor nodurilor de intrare și un set de ponderi inițiale. Valorile din nodurile de intrare sunt combinate în stratul ascuns și valorile din acele noduri sunt combinate în valoarea de ieșire.

Backpropagation: Eroarea ieșirii este calculată ca fiind diferența dintre ieșirea calculată și ieșirea dorită (valori reale găsite în setul de antrenare). Apoi, eroarea din valoarea de ieșire este atribuită nodurilor din stratul ascuns proporțional cu ponderile lor. Acest lucru permite calculul unei erori pentru fiecare nod de ieșire și fiecare nod ascuns din rețea. În sfârșit, erorile de la fiecare nod de ieșire sau ascuns sunt folosite de algoritm să ajusteze ponderile spre un nod vizat astfel încât să îi reducă eroarea.

Acest proces este repetat pentru fiecare linie din setul de antrenare. Fiecare pas din fiecare linie a setului de antrenare se numește epocă. Setul de antrenare va fi folosit în mod repetat până când eroarea nu mai scade. În acel moment, rețeaua neuronală se consideră a fi antrenată pentru a găsi tiparul în setul de test.

Din cauza numărului mare de parametri care pot exista în straturile ascunse, o rețea neuronală cu suficient de multe noduri ascunse va potrivi până la urmă un set de antrenare dacă este lăsată activă o perioadă de timp suficientă, dar nu se cunosc rezultatele pe care le va da pe un set de date. Pentru a evita rețelele neuronale supraîncărcate care lucrează bine numai cu date din setul de antrenare trebuie știut când să se oprească antrenarea. Cât timp rata erorii pe datele de antrenare pot descrește, datele ar putea fi supraîncărcate.

Graficul din figura următoare, arată cum setul de date de test poate ajuta la evitarea supraîncărcării. Se poate observa cum rata erorii descrește cu fiecare pas pe care rețeaua îl face cu datele, dar rata erorii pentru datele de test își atinge minimul și apoi începe să crească. Având în vedere că scopul tehnicilor data-mining este de a face predicții pe seturi de date diferite de setul de test se observă că se obțin rezultate mai bune dacă se renunță la folosirea unei rețele neuronale care minimizează eroarea în datele de test și nu în datele de antrenare.

Figura 55. Evitarea supraăncărcării

Rețelele neuronale diferă în multe privințe de celelalte metode statistice. În primul rând, o rețea neuronală are de obicei mai mulți parametri decât are în mod normal un model statistic tipic. De exemplu, sunt 13 parametri (9 ponderi și 4 constante) în rețeaua schițată anterior. Deoarece parametri sun în număr atât de mare, și datorită numeroaselor combinații de parametri rezultate în predicții similare, valorile devin de neinterpretat și rețeaua se transformă într-o cutie neagră. În realitate, un anumit rezultat poate fi asociat cu mai multe seturi diferite de ponderi. Drept urmare, ponderile rețelei nu ajută în general la înțelegerea substraturilor procesului care generează predicția, dar tehnica este utilă în multe aplicații. De exemplu, la o bancă se poate dori recunoașterea automată a unor aplicații scrise de mână dar fără ase ține cont de forma sau relația funcțională dintre pixeli și caracterele pe care le reprezintă. Câteva dintre multele aplicații în care sute de variabile sunt introduse ca date în modele cu mii de parametri (ponderi ale nodurilor) includ modelarea uzinelor chimice, a roboților și a piețelor financiare sau crearea unor tipare în probleme precum recunoașterea sunetelor, a imaginilor sau a caracterelor scrise de mână.

Unul dintre avantajele modelelor bazate pe rețele neuronale este acela că pot fi ușor implementate pentru a funcționa pe computere paralele de capacități mari, astfel încât fiecare nod estecalculat simultan.

Utilizatorii trebuie să fie conștienți de câteva lucruri în ceea ce privește rețelele neuronale: în primul rând, rețelele neuronale nu sunt ușor de interpretat, nu există aplicații raționale pentru deciziile sau predicțiile pe care o rețea neuronală le face. În al doilea rând, rețelele neuronale tind să supraîncarce datele de antrenare, lucru care poate fi evitat doar dacă se iau măsuri restrictive, precum: scăderea ponderilor sau validarea încrucișată. Acest fapt se datorează numărului mare de parametri ai rețelei care, dacă i se pemite să fie de o dimensiune suficientă va încărca arbitrar orice set de date în mod corect și le va antrena spre convergență. În al treilea rând, rețelele neuronale cer un anumit timp de antrenare exceptând cazurile în care problema este măruntă. În orice caz, odată antrenată, o rețea poate oferi predicții rapide. În al patrulea rând, rețelele nu cer o pregătire a datelor mai puțin elaborată decât orice altă metodă, ci dimpotrivă, cer chiar o pregătire temeinică. Unul dintre lucrurile care se știu despre rețelele neuronale este că datele de orice calitate pot fi folosite pentru a obține predicții rezonabile. Cele mai reușite implementări ale rețelelor neuronale (sau arbori de decizie, sau regresii logistice sau orice altă metodă) presupun o curățare foarte atentă a datelor, selecție, preparare și pre-procesare. De exemplu, rețelele neuronale cer ca toate variabilele să fie numerice. Din acest motiv, date categorice precum stratul sunt de obicei desfăcute în mai multe variabile de dihotomie, fiecare cu valorile 0 (nu aparține unui anumit strat) și 1 (dacă aparține acelui strat). Creșterea numărului de variabile care rezultă de aici poartă numele de explozie categoricală. În ultimul rând, rețelele neuronale au tendința de a lucra cel mai bine când setul de date este suficient de mare. Deoarece sunt atât de flexibile, ele vor conduce la multe tipare false în situații de legătură slabă între date.

1.2.8.2.2. Arbore de decizie

Arborii de decizie sunt moduri de a reprezenta o serie de reguli care duc la o clasă sau o variabilă. De exemplu, dacă se dorește clasificarea celor care au depus pentru un împrumut în cei care prezintă un risc mic de creditare și cei care prezintă un risc mare de creditare. Un arbore de decizie simplu rezolvă problema ilustrând în același timp toate componentele de bază ale unui arbore de decizie: nodurile de decizie, crengile și frunzele.

Figura 56. Arbore de decizie

Prima componentă este nodul de decizie vârf sau nodul rădăcină, care specifică un test ce va fi aplicat. Nodul rădăcină din acest exemplu este venit > sumă_prag. Rezultatele aplicării acestui test determină despărțirea arborelui în ramuri, fiecare reprezentând unul dintre răspunsurile posibile. În acest caz, testul venit > sumă_prag poate avea răspunsurile da sau nu, și astfel se obțin două ramuri.

În funcție de algoritm, fiecare nod poate determina două sau mai multe ramuri. De exemplu, algoritmul CART generează arbori cu două ramuri la fiecare nod. Un astfel de arbore se numește arbore binar. Când sunt permise mai mult de două ramuri la un nod, vorbim despre un arbore multi-căi.

Fiecare ramură va conduce fie la un alt nod de decizie, fie la margine arborelui, unde se găsesc nodurile frunză. Prin parcurgerea unui arbore, se pot asigna valori sau clase unui subiect, prin alegerea ramurii de parcurs în continuare, începând de la rădăcină și mergând din nod în nod, până se atinge un nod frunză. Fiecare nod folosește datele din proces pentru a alege ramura potrivită.

Având în față un arbore precum cel din exemplu, și o cerere de împrumut, personalul care se ocupă de împrumuturi la o bancă poate determina dacă cel care a depus cererea prezintă un risc mare sau mic de creditare. Un individ cu un venit mai mare decât o sumă_prag și cu datorii mari ar fi clasificat ca prezentând un risc mare de creditare, pe când un individ cu un venit mai mic decât suma_prag, dar cu o vechime în muncă mai mare de cinci ani, ar fi clasificat ca prezentând un risc mic de creditare.

Modelul arborilor de decizie este uzual folosit în data mining pentru a examina datele și a construi arborele și regulile care vor fi folosite pentru a face predicții. La construirea arborilor de decizie, pot fi folosiți diferiți algoritmi, precum: CHAID (Chi-squared Automatic Interaction Detection), CART (Clasification and Regression Trees), Quest și C 5.0.

Arborii de decizie cresc pe baza unei împărțiri iterative a datelor în grupuri discrete, scopul fiind maximizarea distanței dintre grupuri la fiecare împărțire.

Una dintre diferențele dintre metodele bazate pe arbori de decizie constă în felul în care acestea măsoară distanța. În timp ce detalii precum măsurarea sunt dincolo de scopul acestei introduceri, fiecare despărțire poate fi gândită ca o separare a datelor în grupuri noi, care sunt pe cât posibil de diferite unele de altele. Acest lucru mai este numit și purificarea grupurilor. Față de exemplul anterior, în care datele aveau doar două clase de ieșire posibile, risc mare – risc mic, este preferabil ca fiecare dată separată în urma unei decizii să se regăsească într-un grup pur cu apariții într-un singur astfel de grup și nu în mai multe.

Arborii de decizie care sunt folosiți pentru predicții cu variabile categorice sunt numiți arbori de clasificare, deoarece împart datele în categorii sau clase. Arborii de decizie folosiți pentru predicții cu variabile continue sunt numiți arbori de regresie.

Exemplul prezentat anterior este unul foarte simplu. Un astfel de arbore este ușor de înțeles și de interpretat. Oricum, arborii pot deveni foarte complicați: să ne imaginăm doar complexitatea unui arbore de decizie, derivat dintr-o bază de date cu sute de atribute și variabile de răspuns cu zeci de clase de ieșire. Un astfel de arbore ar fi extrem de dificil de înțeles, deși fiecare cale spre o frunză este foarte clară. În acest sens, un arbore de decizie își poate explica predicțiile, ceea ce este un avantaj foarte important.

Aceasta claritate poate fi însă înșelătoare. De exemplu,o ramificare puternică a unui arbore de decizie implică o precizie care este foarte rar reflectată în realitate (de ce cineva al cărui salariu este mai mare cu unitate decât o sumă prag prezintă un risc mic de creditare, în timp ce altcineva, al cărui salariu avea aceeași valoare cu suma_prag, în aceleași condiții cu precedentul, prezintă un risc mare de creditare ?). Mai mult, din moment ce mai mulți arbori pot reprezenta adesea aceleași date, cu acuratețe egală, ce interpretare ar trebui dată regulilor?

Arborii de decizie fac pași puțini prin date, un pas pentru fiecare nivel al arborelui și lucrează bine cu multe variabile de predicție. Drept urmare, modelele pot fi construite rapid și sunt adaptabile la seturi mari de date.

Arborii lăsați să crească fără graniță durează mult mai mult până sunt construiți și devin neinteligibili, dar în primul rând, de cele mai multe ori supraîncarcă datele. Dimensiunea unui arbore poate fi controlată prin reguli de oprire care limitează creșterea. Una dintre cele mai intâlnite reguli de oprire este limitarea adâncimii maxime a unui arbore. O altă regulă de oprire este stabilirea unei limite pentru numărul de ramuri în care se poate despărți un nod.

O alternativă la regulile de oprire este scurtarea arborelui. Arborele este lăsat să crească până la dimensiune maximă și apoi, fie folosind euristici încorporate, fie prin intervenția utilizatorului, arborele este tăiat până la cea mai mică dimensiune care nu-i compromite acuratețea. De exemplu, o ramură sau subarbore despre care utilizatorul crede b#%l!^+a?că este irelevantă deoarece are foarte puține cazuri, poate fi îndepărtată. Algoritmul CART scurtează arborii în urma validării încrucișate, deci după ce verifică dacă gradul de creștere a acurateții justifică nodul în plus.

Unul dintre lucrurile care se reproșează arborilor de decizie este faptul că fac separări în noduri, folosind un algoritm Greedy, în cadrul căruia decizie pe baza căreia variabilele sunt separate nu ține cont de efectul pe care separarea îl poate avea asupra viitoarelor separări. Cu alte cuvinte, decizia de separare este făcută într-un nod, în momentul în care s-a ajuns la nod și nu se revine niciodată asupra ei. În plus, toate separările sunt făcute secvențial, astfel încât fiecare separare depinde de precedenta. Astfel, toate separările viitoare depind de prima separare, ceea ce înseamnă că soluția finală poate fi complet diferită dacă la un moment dat s-a făcut o altă separare. Încercarea de a face separări bazate pe două sau mai multe nivele în același timp încă nu dă rezultate îmbunătățite. Astfel de încercări sunt incă în faza de încercare, dar solicită intensiv resurse de calcul și astfel nu sunt disponibile pentru implementări in scopuri comerciale.

Mai mult decât atât, algoritmii folosiți pentru separare iau în calcul fiecare variabilă de predicție pe rând. Și, în timp ce acesta este unul dintre motivele pentru care un astfel de model se construiește repede (limitează numărul testărilor regulilor de separare posibile), în același timp determină o detectare greoaie a relațiilor dintre variabilele de predicție.

Arborii de decizie care nu sunt limitați la separări univariabile, pot folosi mai multe variabile de predicție la o singură regulă de separare. Un astfel de arbore de decizie poate permite combinații liniare ale variabilelor și mai este cunoscut sub numele de arbore „oblic”. Un criteriu pentru separare ar putea fi: salariu < 0.35 * ipoteca. Separarea pe combinații logice de variabile precum salariu > suma_prag1 sau ipotecă < sumă_prag2 este un alt tip de separare multivariabilă.

Arborii de decizie manevrează inclusiv date non-numerice. Abilitatea de a accepta date categorice minimizează numărul de transformări asupra datelor și explozia de variabile de predicție inerentă în cazul rețelelor neuronale. Câțiva arbori de clasificare au fost proiectați pentru astfel de date și ca urmare, lucrează mai bine când variabilele de predicție sunt categorice. Predictorii continui pot fi folositi în mod frecvent în astfel de cazuri, prin conversia variabilelor continue la un set de șiruri. Unii arbori de decizie nu suportă variabile de răspuns continue (nu putem construi arbori de regresie), caz în care variabilele de răspuns din setul de antrenare trebuie deasemenea transformate în clase de ieșire.

1.2.8.2.3. Modelul MARS

La mijlocul anilor ’80, inventatorul algoritmului CART, Jerome H. Friedman, a dezvoltat o metodă destinată să îndrepre neajunsurile algoritmului său.

Principalele dezavantaje pe care el voia să le elimine erau: predicția discontinuă (separări dure); dependența tuturor separărilor de precedentele separări; interpretabilitatea redusă, datorată interacțiunilor, mai ales a celor de ordin mare.

Astfel, el a dezvoltat algoritmul MARS. Ideea care stă la baza acestei metode este una simplă, dezavantajele algoritmului CART fiind amortizate prin: înlocuirea ramurilor discontinue la un nod cu o linie continuă de tranzit modelată printr-o pereche de linii drepte; la sfârșitul procesului de construire a modelului, liniile drepte de la fiecare nod sunt înlocuite cu o funcție care le aproximează, numită spline (riglă); nu mai este necesar ca viitoarele separări să depindă de precedentele.

Din păcate, asta înseamnă că metoda MARS distruge structura de arbore ridicată de CART, și nu poate induce reguli. Pe de altă parte, această metodă găsește în mod automat și afișează cere mai importante variabile de predicție, precum și interacțiunile dintre acestea. În plus, ilustrează și dependența răspunsului de fiecare predictor. Rezultatul este o unealtă automată de regresie non-liniară.

Ca și în cazurile rețelelor neuronale sau arborilor de decizie, modelul MARS are tendința de a supraîncărca datele de antrenare și acest lucru poate fi evitat în două feluri: se poate face o validare încrucișată și algoritmul poate fi potrivit astfel încât să determine predicții bune cu datele din setul de test, sau există destui parametri interni pe care algoritmul le poate folosi, astfel încât să-și valideze singur datele.

1.2.8.2.4. Reguli de inducție

Metoda regulilor de inducție constă în aplicare unui set de reguli pentru a determina clasificări. Deși arborii de decizie pot determina și ei un astfel de set de reguli, metoda regulilor de inducție generează un set de reguli independente care nu formează cu necesitate un arbore (este chiar puțin probabil). Deoarece generatorul de reguli nu forțează separări la fiecare nivel și poate înainta în date, este capabil să găsească tipare diferite (uneori chiar mai bune) pentru clasificare. Spre deosebire de arbori, regulile generate s-ar putea să nu acopere toate situațiile posibile. Tot o diferență față de arbori este și faptul că regulile pot duce uneori la conflicte, caz în care este necesar să se aleagă regula ce va fi aplicată. Una dintre metodele cele mai obișnuite de a rezolva conflicte este de a asigna coeficienți de încredere regulilor și de o folosi pe aceea cu coeficientul mai mare.

1.2.8.2.5. Metoda celor mai apropiați vecini

Când se încearcă rezolvarea unor noi probleme, sunt luate în calcul și soluțiile unor probleme similare. Metoda celor mai apropiați vecini (K – nearest neighbor) este o tehnică de clasificare care folosește o versiune a metodei însăși. Decide în ce clasă să încadreze un nou subiect, examinând un număr de k subiecți similar (vecini). Calculează numărul de subiecți pentru fiecare clasă și asignează noul subiect acelei clase căreia îi aparțin cei mai mulți dintre vecinii săi.

Figura 57. Metoda celor mai apropiați vecini

N reprezintă noul subiect, iar X și Y subiecții care țin de clasele X, respectiv Y. Interiorul elipsei reprezintă vecinătatea lui N. Se obsevă că N va fi asignat clasei X, deoarece cei mai mulți dintre vecinii săi aparțin acestei clase.

Primul pas în aplicarea acestei metode constă în găsirea unui mod de a măsura distanța dintre atributele datelor și în calculul acestei distanțe. Acest lucru este banal când se lucrează cu date numerice, însă în cazul variabilelor categorice este nevoie de tehnici speciale (de exemplu, cum se calculează distanța dintre galben și albastru?). Odată calculate distanțele dintre subiecți, se selectează un set de subiecți deja clasificați pentru a-l folosi ca bază pentru clasificarea noilor subiecți, după care se va decide cât de mare va fi vecinătatea în cadrul căreia se vor face comparațiile și cum se vor determina vecinii.

Această metodă solicită intens resursele unui sistem de calcul, deoarece timpul de calcul crește factorial, odată cu numărul de subiecți testați. În timp ce aplicarea unei rețele neuronale sau a unui arbore de decizie asupra unui nou subiect este un proces rapid, algoritmul celor mai apropiați vecini cere noi calcule pentru fiecare subiect în parte. Pentru a mări viteza de lucru a algoritmului, o soluție ar fi memorarea tuturor datelor. MBR (Memory Based Reasoning) se referă de obicei la seturi memorate de date, care țin de acest algoritm.

Modelele construite de algoritmul celor mai apropiați vecini, sunt ușor de înțeles, când este implicat un număr mic de variabile de predicție. Pot fi folosite pentru a construi modele care implică tipuri de date diferite de cele obișnuite, precum datele de tip text. Singura cerință pentru a putea utiliza astfel de tipuri de date este existența unei metrici adecvate.

1.2.8.2.6. Regresii logistice

Regresia logistică este o generalizare a regresiei liniare. Se folosește pentru variabilele de predicție binare (cu valori precum da/nu sau 0 și 1) și, ocazional, pentru variabilele multiclasă. Deoarece variabila de răspuns este discretă, nu poate fi modelată direct prin regresie liniară. Din această cauză, în loc să se prezică dacă un eveniment (variabila de răspuns) va avea loc, se construiește un model pentru a prezice logaritmul șansei ca evenimentul să aibă loc. Acest logaritm se numește log odds sau transformare logit.

Șansa se calculează ca raportul dintre probabilitatea ca un eveniment să aibă loc și probabilitatea ca evenimentul să nu aibă loc și are aceeași interpretare ca șansa calculată la jocurile de noroc sau la pariurile sportive.

Când se spune că șansele sunt de 3 la 1 ca o anumită echipă să învingă într-un meci spunem că probabilitatea ca echipa să câștige este de trei ori mai mare decât probabilitate ca ea să piardă, deci există o șansă de 75% ca ea să câștige și 25% șanse ca ea să piardă.

O terminologie asemănătoare se poate aplica și în cazul șansei obținerii unui răspuns la o ofertă din partea unui anumit client (cu un anumit venit, cu o anumită stare civilă, etc.). Dacă spunem că șansele sunt de trei la unu ca subiectul sa răspundă pozitiv, spunem că probabilitatea ca acel tip de client să răspundă pozitiv este de trei ori mai mare ca probabilitatea unui răspuns nefavorabil.

După ce a fost calculat logaritmul, rezultatului i se aplică funcția inversă pentru a afla șansa. O șansă de 62% poate însemna că subiectulva fi asignat clasei cu valorile 1 sau da.

Regresia logistică este o unealtă de modelare foarte puternică, însă presupune că variabila de răspuns (logaritmul, și nu evenimentul însuși) este liniar în coeficienții variabilelor de predicție. Mai mult, modelatorul, pe baza experiței sale în prelucrarea datelor, trebuie să aleagă valorile de intrare potrivite și să specifice relațiile lor funcționale cu variabila de răspuns. Astfel, modelatorul trebuie să aleagă de exemplu între variabilele venit, (venit)2 sau log(venit) pentru predicția sa. În plus, modelatorul b#%l!^+a?trebuie să adauge limite pentru fiecare interacțiune.

Este de datoria modelatorului să aleagă variabilele potrivite, expresiile lor corecte și să țină cont de posibilele interacțiuni între ele. Aceste lucruri cer efectiv o mare pricepere și experientă din partea analistului.

Rețelele neuronale, pe de altă parte folosesc straturile lor ascunse pentru a forma termeni neliniari și interacțiuni în moduri semiautomate. Utilizatorii folosesc un set diferit de abilități analitice pentru a aplica cu succes rețelele neuronale. De exemplu, alegerea unei funcții de activare va afecta viteza cu care o rețea neuronală se antrenează.

1.2.8.2.7. Analiza discriminantă

Analiza discriminantă este cea mai veche tehnică de clasificare matematică, fiind publicată pentru prima dată de R. A. Fisher în 1936. Această tehnică găsește hiperplane (linii, în spațiul bidimensional, plane, în spațiul tridimensional, etc.) care separă clasele. Modelul rezultat este foarte ușor de interpretat deoarece tot ceea ce utilizatorul trebuie să facă este să determine de c parte a liniei (sau hiperplanului) se află un punct. Antrenarea este simplă și gradată. Tehnica este foarte sensibilă la tiparele dintr-o mulțime de date. Este folosită foarte des în cadrul unor discipline precum medicina, științele sociale, biologia, etc.

Analiza discriminantă nu este o tehnică des utilizată în data mining din trei motive: presupune că toate variabilele de predicție urmează o distribuție normală (histograma lor are forma unui clopot), ceea ce nu este adevărată; variabilele categorice neordonabile (roșu, albastru, verde) nu pot fi folosite; granițele care separă clasele sunt toate forme liniare (linii, plane) dar, câteodată, datele pur și simplu nu pot fi separate în acest mod.

Versiuni mai recente ale analizei discriminante corectează câteva dintre aceste probleme permițând granițelor să fie atât liniare, cât și pătratice, ceea ce mărește semnificativ sensibilitatea la unele cazuri. Există și tehnici care înlocuiesc presupunerea de normalitate cu o estimare a distribuției reale (înlocuiesc curba teoretică a clopotului cu histograma variabilelor de predicție).

1.2.8.2.8. Modelul aditiv generalizat

Există o clasă de modele care extinde atât regresia liniară cât și pe cea logistică, cunoscută sub numele de clasa modelelor aditive generalizate sau GAM. Ele sunt numite aditive deoarece se bazează pe presupunerea că modelul poate fi scris ca o sumă de funcții posibil neliniare, una penru fiecare predictor. GAM pote fi folosit atât pentru regresii cât și pentru clasificarea unui răspuns binar. Variabila de răspuns poate fi, virtual, orice funcție aplicată predictorilor cu condiția să nuprezinte discontinuități. De exemplu, funcția venit/delicvență este o funcție complicată aplicată variabilei venit, conform căreia, inițal, delicvența scade odată cu creșterea venitului. Apoi începe să crească din nou la venituri moderate pentru a-și atinge vârful înainte de a scădea pentru venituri mari. Într-un asemenea caz, un model liniar poate trece cu vederea legătura dintre venit și delicvență datorită comportamentului neliniar al funcției. Modelul aditiv generalizat, folosind puterea calculatoarelor în locul teoriei funcționalelor va determina o curbă netedă, vizualizând relațiile exact așa cum au fost descrise anterior. Cel mai des întâlnit procedeu de estimare este cel de backfeetting. În locul estimării unui număr mare de parametrii, ca în cazul rețelelor neuronale, GAM face un pas înainte și folosește estimarea unei valori de ieșire pentru fiecare valoare de intrare (un punct – o estimare).

1.2.8.2.9. Boosting

În cazul în care se construiește un model folosind un subset al setului de date, și apoi se construiește un alt model folosind același algoritm dar alt subset de date, se poate ajunge la rezultate complet diferite. După validarea celor două modele, poate fi ales acela care se apropie cel mai mult de obiectivul propus. Rezultatele se pot chiar îmbunătăți dacă se construiesc mai multe modele care sunt supuse la vot, predicția făcându-se după votul majorității. Desigur, orice interpretabilitate a predicției este pierdută însă acest lucru poate fi compensat prin calitatea rezultatelor.

Această abordare a datelor stă la baza metodei boosting, o tehnică publicată pentru prima oară în 1996 de către Freund și Schapire. Astfel, metoda alege la întâmplare subseturi de date și constuiește modele de clasificare pentru fiecare. Setul de antrenare este schimbat în funcție de rezultatele date de modelul precedent. Clasificarea finală asignează un subiect clasei la care a fost asignat de cele mai multe clasificări. Algoritmii de boosting au evoluat față de cel original dar ideea care stă la bază a rămas aceeași.

Metoda boosting a devenit o unealtă auxiliară foarte populară pentru tehicile de data mining.

1.2.8.2.10. Algoritmi genetici

Algoritmii genetici nu sunt folosiți pentru a găsi tipare ci pentru a ghida procesul de învățare al algoritmilor ce țin de data mining, precum rețelele neuronale. Algoritmii b#%l!^+a?genetici se comportă ca metode de căutare ghidată a modelelor potrivite în spațiul soluțiilor.

Sunt numiți algoritmi genetici deoarece se încadrează în tiparul evoluției biologice în care membrii unei generații (sau modele) se întrec în a trece caracteristicile lor generaței viitoare (de modele), până când cel mai bun este găsit. Informația care se moștenește este conținută în cromozomii care dețin parametrii pentru construirea unui model.

De exemplu, în construirea unei rețele neuronale, algoritmii genetici pot înlocui backpropagation și deveni o cale de a ajusta ponderile. O alternativă ar fi folosirea algoritmilor genetici pentru a găsi cea mai bună arhitectură și, în acest caz, cromozomii ar conține numărul de straturi ascunse și numărul de noduri din fiecare strat.

Algoritmii genetici sunt o abordare interesantă a problemei optimizării modelelor, însă au dezavantajul de a suprasolicita resursele computaționale.

1.2.8.3. Modelul episoadelor

În modelul episoadelor, datele sunt vâzute ca o înșiruire de evenimente; fiecare eveniment are un tip și un timp al apariției. Un exemplu de tip de eveniment ar putea fi: Switch-ul 34 a fost supraîncărcat și a trebuit să piardă un pachet de date.

Este un eveniment mult prea general pentru a avea un timp anume. Multe evenimente pot apărea în același timp și nu este nici o garanție că în fiecare unitate de timp are loc un eveniment.

1.2.8.3.1. Monotonia episoadelor și algoritmul Al-Priori

Fiind dat un interval de timp W (intervalul de timp în care poate avea loc un eveniment), un episod este frecvent dacă are loc în cel puțin s intervale, unde s este o limită dată. Aceeași secvență de evenimente poate să apară ca un episod în mai multe intervale consecutive; se consideră o apariție pentru fiecare astfel de interval. Oricum, în nici un interval nu putem considera același episod de mai multe ori, chiar dacă acel episod este construit din mai multe seturi diferite de evenimente în același interval.

Episoadele frecvente sunt monotone: daca un episod E este frecvent, atunci și orice alt episod format prin eliminarea unor evenimente din E este frecvent. Astfel, episoadele frecvente pot fi construite descrescător, folosind un algoritm A-Priori:

Fie {Ci}i >0 mulțimea episoadelor candidate formate din i evenimente, și {Li}i >0 mulțimea episoadelor frecvente, formate din i evenimente.

C1 este un set cu toate tipurile de evenimente.

Se construiește Ci+1 din Li, unde Ci+1 este mulțimea tuturor episoadelor E, formate din i+1 evenimente, pentru care, dacă ștergem orice eveniment, se obține un eveniment din Li.

1.2.8.3.2. Verificarea episoadelor

Problema în transformarea lui Ci în Li este trecerea o singură dată prin date cu numărarea aparițiilor fiecărui episod din Ci. Un algoritm banal poate privi pe rând fiecare interval de lungime W și, pentru fiecare episod candidat se verifică dacă are loc în acel interval; Dacă da, atunci numărul aparițiilor episodului crește cu 1.

1.2.8.3.2.1. Episoadele paralele

Scopul algoritmului MTV este de a căuta proporțional cu aparițiile tuturor evenimentelor din toate episoadele candidate care au acele evenimente, inclusiv subepisoade sau episoade compuse. Algoritmul a fost dezvoltat în clase și pare mult prea puțin restrictiv, deoarece nu presupune imposibilitatea unui eveniment de a apărea de mai multe ori într-un interval. Pentru a descrie cum datele sunt parcurse o singură dată pentru a calcula Li din Ci, considerând fiecare interval în parte, de la începutul secvenței, sunt necesare următoarele structuri de date:

Pentru fiecare eveniment A:

A.count – numără aparițiile evenimentului A în intervalul curent;

A.contains – o listă a tuturor episoadelor E care conțin evenimentul A.

Pentru fiecare episod candidat E:

E.startingTime – momentul de început al intervalelor consecutive în care E a fost prezent, până la intervalul curent;

E.support – numărul de intervale în care E apare, fără să se ia în calcul intervalele de la E.startingTime până la intervalul curent;

E.missing – numărul de evenimente A din E care nu au loc în intervalul curent, de unde E este prezent într-un interval, doar dacă E.missing = 0 pentru acel interval.

Algoritmul arată ce se întâmplă când intervalul înaintează cu câte o unitate de timp.

Trebuie luate în calcul situațiile speciale în care un eveniment A nu se mai încadrează într-un interval și aceea în care un eveniment B intră într-un interval.

Cazul 1: Un eveniment A nu se mai încadrează într-un interval. b#%l!^+a?

A.count – – ;

If (A.count == 0) /* A nu se mai încadrează în interval */

For (all E in A.contains)

{

E.missing + +;

If (E.missing==1) /*Episodul E nu se mai încadrează în interval*/ E.support += (E.startingTime – currentTime);

}

Cazul 2: Un eveniment nou B se încadrează în interval.

B.count + + ;

If (B.count == 1) /* B este un eveniment nou în interval */

For (all E in B.contains)

{

E.missing – -;

If (E.missing==0) /* Episodul E este nou în interval */ E.startingTime = currentTime;

}

1.2.8.3.2.2. Episoadele seriale

Pentru verificarea unui episod serial (A1, A2, …, An) este simulat un automat finit nedeterminist (AFN) care recunoaște șirul A1A2…An. În timp ce verifică evenimentele din date, se urmăresc stările în care se află AFN.

Figura 58. Episoadele seriale

(qi)i=1,n – stări ale AFN

Presupunând că structura datelor este aceeași ca la verificarea episoadelor paralele, AFN este folosit pentru diferite episoade E, astfel: starea AFN nu se modifică dacă simbolul de intrare nu este un eveniment care face parte din episod, de unde structura acestui automat nu necesită timp decât dacă episodul face parte din A.contains, pentru evenimentul curent A; în timp ce se simulează, se păstrează pentru fiecare stare în care AFN se află curent, cel mai recent punct din care am fi putut începe automatul și am fi obținut acea stare. Această valoare este: momentul curent, dacă am indus starea q1; momentul stării qi+1 dacă am indus starea qi prin citirea evenimentului Ai; același moment cu precedentul, dacă ne aflăm în qi și următoarea intrare este diferită de Ai; dacă AFN pentru episodul E intră în starea acceptată qn, dar nu a mai fost în acea stare, atunci E.startingTime ia valoarea momentului curent asociat cu qn; dacă orice moment asociat cu o stare este mai mic decât momentul curent din care scădem lungimea W a intervalului de timp, atunci se șterge acea stare din setul de stări în care se află AFN. Dacă o stare acceptată este pierdută, atunci la E.support se adaugă E.startingTime din care scădem momentul curent.

Presupunem că evenimentul E este (A, B, C). AFN pentru E este:

Figura 59. AFN

Fie setul de date (A,B,A,B,C), toate evenimentele având loc în intervalul curent. Stările în care intră AFN sunt următoarele:

Figura 60. Stările AFN

1.2.8.3.2.2. Episoadele compuse

Pentru a extinde verificările anterioare (pentru episoade paralele și seriale) trebuie construite mecanisme speciale pentru fiecare subepisod. Intră în sarcina fiecărui mecanism al unui subepisod să raporteze mecanismului supraepisodului (supraepisoadelor) din care face parte subepisodul dacă acesta nu este prezent, sau dacă este prezent, să raporteze care este cel mai recent moment în care se poate considera că acesta a început: dacă subepisodul este o compunere paralelă de evenimente și/sau alte subepisoade se folosește o structură de date ca la verificarea episoadelor paralele, însă valoarea A.count pentru un eveniment A se înlocuiește cu cel mai recent moment de început pentru episodul compus; pentru episoade seriale se menține automatul, însă intrările sunt aparițiile subepisoadelor sale; E.startingTime și E.support se păstrează doar pentru episoadele din C1 și nu pentru subepisoade.

1.2.9. Modelarea procesului de data mining

Ținând cont de faptul că o abordare sistematică este esențială într-un proces data mining, consultanții de specialitate au specificat un model general al procesului, construit pentru a ghida utilizatorul (mai ales un începător în construirea modelelor de predicție) printr-o secvența de pași care conduce la rezultate reușite. Printre cele mai des folosite specificații sunt: 5 A’s (Assess, Access, Analyse, Act and Automate); SEMMA (Sample, Explore, Modify, Model and Asses); CRISP-DM (Cross Industry Standard Process for Data Mining) și Two Crows Model.

1.2.9.1. Definirea problemei

În primul rând, o condiție prealabilă în descoperirea cunoștințelor este înțelegerea datelor și a problemei. Fără această înțelegere, niciun algoritm, indiferent de gradul lui de complexitate, nu poate oferi rezultate în care se poate avea încredere. Pe această înțelegere se bazează competența de a identifica problemele de rezolvat, prepararea datelor pentru prelucrare sau interpretarea corectă a rezultelor. Pentru a profita din plin de rezultatele oferite de tehnicile de data mining trebuie descrise cu claritate obiectivele; dacă, de exemplu se dorește creșterea răspunsurilor la o campanie de oferte prin poșta electronică, în funcție de un scop specific, care poate fi creșterea numărului de răspunsuri sau creșterea valorilor răspunsurilor se construiesc două modele diferite.

1.2.9.2. Crearea bazei de date

Acest pas, împreună cu următoarele două constituie miezul procesului de preparare a datelor. Împreună, solicită mai mult efort sau resurse temporale decât toți ceilalți pași la un loc. Pot apărea repetări iterative ale preparării datelor și construirii modelului pe măsură ce modelul care solicită modificarea datelor învață. Executarea pașilor de preparare a datelor poate ocupa de la 50% până la 90% din timpul și resursele întregului proces de descoperire a cunoștințelor.

Datele ce urmează a fi forate trebuie strânse în baze de date. Acest fapt nu solicită în mod necesar existența unui sistem de management al bazei de date. În funcție de cantitatea, complexitatea și felul în care vor fi folosite, datele pot fi gestionate printr-un flat-file sau spreadsheet.

În general, nu este recomandabil să se folosească depozitul de date deja existent ci să se creeze un data mart separat. Forarea datelor necesită un acces intens la depozitul de date, ceea ce poate duce la probleme de alocare a resurselor și de acces la date al altor utilizatori; în foarte multe cazuri, vor fi necesare joncțiuni de tabele ceea ce va duce la accesarea simultană a unei importante părți a depozitului de date.

Mai mult ca sigur vor fi necesare modificări asupra datelor din depozit, importuri de date din alte depozite pentru suprapunere, adăugări de câmpuri calculate pe baza câmpurulor deja existente sau supravegheri pentru obținerea de noi date. Un alt analist, care și el construiește un model, poate la rândul lui să ceară aceleași tipuri de modificări asupra datelor din depozit. În orice caz, nici o modificare asupra datelor din depozit nu este binevenită, ținând cont că depozitul de date este una dintre cele mai importante resurse pentru o corporație, de exemplu.

Încă un motiv pentru crearea unei baze de date separată este acela că structura b#%l!^+a?unui depozit de date al unei corporații ar putea să nu suporte cu ușurință explorările necesare pentru înțelegerea datelor, acestea incluzând rezumate ale datelor, rapoarte multi-dimensionale (tabele pivot) și diferite tipuri de vizualizări și grafice.

În sfârșit, se recomandă stocarea datelor în structuri care cer un design diferit decât cel folosit de depozitul inițial. Datorită acestor cerințe este mai sigură folosirea unei baze de date diferită de depozitul corporației însă, structura acestuia oferă resursele necesare procesului de data mining și este suficient de flexibilă, acesta poate constitui o bază de date pentru forare.

Pașii în construirea unei baze de date pentru forare sunt: colectarea datelor; descrierea datelor; selectarea datelor; evaluarea calității datelor și curățarea lor; consolidare și integrare; construirea unei metastructuri; încărcarea bazei de date; întreținerea bazei de date. Acești pași nu constituie o secvență cu o ordine strictă: ordinea executării pașilor este impusă de necesități.

Primul pas în colectare este identificarea sursei de unde vor fi preluate datele necesare. Colectarea poate fi precedată de o sesiune de strângere de date, deoarece există posibiltatea ca anumite date necesare să nu fi fost colectate. Sunt cazuri în care pot fi necesare și date externe, dintr-o bază de date publică (precum ce a informațiilor despre starea vremii) sau o bază de date deținută de o altă corporație. Un raport de colectare a datelor conține proprietățile diferitelor seturi de date, printre care ar trebui incluse: sursa datelor (internă sau extern), proprietarul, persoana sau organizația responsabiliă cu întreținerea datelor, dimensiunea în tabele, celule, înregistrări, dimensiunea în biți, mediul fizic de stocare, necesitățile de securizare, restricțiile de folosire și necesități particulare.

A doua etapă constă în descrierea conținutului fiecărui fișier sau tabelă din baza de date. Un raport asupra descrierii datelor poate conține informații generale precum: numărul de câmpuri sau coloane, numărul înregistrărilor incomplete, denumirile câmpurilor, etc, iar pentru fiecare câmp în parte sunt necesare informații despre: tipul datelor, descriere, sursa câmpului, unitatea de măsură, numărul valorilor unice, lista valorilor, intervalul de valori, numărul valorilor lipsă, informații despre colectare (când, cum, unde ?), chei pentru relații.

Următorul pas în prepararea unei baze de date pentru data mining este selectarea unui subset de date, pentru forare. Nu este vorba despre un set de exemplificare sau despre alegerea variabilelor pentru predicție, ci mai degrabă este o eliminare grossieră a datelor nerelavante sau nedorite. Alte criterii pe baza cărora se elimină date pot fi restricțiile impuse de resurse, restricțiile de acces la date sau probleme de calitate.

Pentru a obține rezultate bune (modele reușite) este nevoie de date „bune” (se aplică GIGO – Garbage In Garbage Out) . Un estimator al calității datelor identifică trăsături ale datelor care vor afecta calitatea modelului. În esență, se încearcă nu numai asigurarea corectitudinii și consistenței valorilor ci și satisfacerea necesităților ca toate datele să măsoare aceleași lucruri în același mod

Există mai multe tipuri de probleme privind calitatea datelor, precum: valori incorecte, asocieri incorecte, lipsa unei valori sau lipsa de consecvență.

Lipsa datelor poate fi o problemă periculoasă pentru proces. Dacă ar fi să se elimine toate înregistrările cu cel puțin un câmp lipsă, s-ar putea ajunge la o bază de date redusă în dimensiuni, sau cu o imagine nesemnificativă a întregii baze. Faptul că valoarea unui câmp lipsește nu afectează întotdeuna întreaga bază de date (de exemplu, clienții bine situați financiar lasă câmpul venituri necompletat). Merită osteneala să se creeze o nouă variabilă care să înlocuiască valorile lipsă, să se construiască un model folosind-o și să se compare rezultatul cu unul obținut prin completarea valorilor lipsă pentru a vedea care duce la o predicție mai bună.

O altă abordare a acestei probleme este calculul unei valori de substituție. Cele mai folosite strategii de calcul pentru valorile lipsă sunt: valoarea modală (pentru variabile nominale), mediana (pentru variabile ordinale) sau mijlocul (pentru variabile continue). O strategie mai puțin folosită este asignarea unei valori unui câmp necompletat pe baza distribuției valorilor celorlalte câmpuri. De exemplu dacă informațiile din baza de date sunt 40% despre femei și 60% despre bărbați, atunci în 40% din cazurile valorilor lipsă pentru câmpul sex acesta va fi înlocuit cu femeie, iar în restul de 60% cu bărbat. Câteodată, modelele sunt construite folosind tehnici data mining pentru a prezice valorile lipsă. Această metodă dă de obicei rezultate mai bune decăt un simplu calcul, dar necesită mai multe resurse temporale.

Nu toate problemele întâlnite în procesul de evaluare a calității datelor pot fi rezolvate și de multe ori este nevoie să se lucreze pe cât de mult posibil fără a le rezolva și chiar este preferabil și mai puțin costisitor înlocuirea rezolvării lor cu proceduri și validări, pentru a evita problemele de calitate ce pot apărea în viitor. Oricum, construirea unui model cu datele care există este posibilă, în speranța că problemele evitate vor fi rezolvate într-o etapă viitoare.

Datele necesare construirii unui model se pot afla într-o singură bază de date, sau în mai multe. Baza de date sursă poate fi baza de date de tranziție, folosită de sistemul b#%l!^+a?operațional al unei companii. Alte date pot fi in depozite construite în scopuri speciale, sau în baze de date ce aparțin altor companii.

Etapa de integrare și consolidare combină date din diferite surse într-o unică bază pentru forare și are ca cerință principală rezolvarea conflictelor între valorile datelor provenite din surse diferite. Datele care nu sunt potrivite cum trebuie, sunt o sursă majoră de probleme de calitate. În multe cazuri există diferențe semnificative între modurile cum datele sunt definite și folosite în baze de date diferite. Unele neconcordanțe sunt ușor de acoperit precum diferite adrese pentru același client, însă cu cât aceste diferențe sunt mai subtile, cu atât sunt mai greu de rezolvat. De exemplu, același client poate figura sub nume diferite sau, mai grav, să aibă numere de identificare multiple. Același nume poate fi folosit pentru entități diferite (omonime) sau nume diferite pot fi folosite pentru aceeași entitate (sinonime). Pot apărea incompatibilități în legătură cu unitățile folosite, mai ales când datele provin din țări diferite (de exemplu moneda).

Informațiile descrise în rapoartele despre setul de date și despre date, în general, reprezintă baza pentru metastructură. În esență, aceasta este o bază de date despre baza de date însăși și oferă informații care vor fi folosite în crearea bazei de date propriu-zise, precum și informații care vor fi folosite de analist în înțelegerea datelor și construirea modelelor.

În cele mai multe cazuri, datele trebuie încărcate în propria bază de date. Odată adunate, integrate și curățate datele, este necesară încărcarea lor propriu-zisă în baza de date. În funcție de tipul de gestionare al bazei de date și de resursele hardware, în funcție de cantitatea și complexitatea datelor, aceasta se poate dovedi o sarcină serioasă care poate necesita experiența în sisteme informaționale a profesionaliștilor.

O dată creată, o bază de date trebuie întreținută: are nevoie în permanență de: copii de siguranță periodice, activitatea trebuie monitorizată, sau pot fi necesare reorganizări ale stocării datelor pe disc pentru a îmbunătăți performanțele. Pentru o bază de date de dimensiuni mari și complexă, mentenanța necesită și serviciile specialiștilor în domeniu.

1.2.9.3. Explorarea datelor

Explorarea datelor constă în vizualizare, analiza legăturilor și alte tehnici discutate în capitolul anterior. Scopul este identificare celor mai importante câmpuri în predicția unei ieșiri și determinarea valorilor derivate care ar putea fi folositoare. Într-un set de date cu sute de mii de coloane, explorarea datelor necesită resurse temporale imense. O interfață potrivită și un răspuns rapid al computerului sunt foarte importante, deoarece explorarea își poate pierde semnificația când trebuie să aștepți chiar și 20 de minute pentru un grafic.

1.2.9.4. Prepararea datelor pentru modelare

Acesta este pasul final în prepararea datelor înainte de începerea construirii modelului. Pașii de parcurs în această etapă sunt: selectarea variabilelor; selectarea liniilor; construirea noilor variabile; transformarea variabilelor.

În mod ideal, nu trebuie luate în calcul toate varaibilele disponibile, prelucrate cu unelte de data mining și să se afle care sunt cei mai buni predictori. În practică însă, acest lucru nu funcționează. Unul dintre motive ar fi faptul că timpul pe care îl consumă construirea unui model crește odată cu numărul de variabile. Un alt motiv este obținerea de modele incorecte în momentul în care sunt luate în calcul coloane de variabile nesemnificative. O eroare comună este de exemplu folosirea unei variabile de predicție a cărei valoare ar putea fi calculată pe baza valorii variabilei de răspuns. Se poate ajunge la situația în care se încearcă prezicerea vârstei folosind data nașterii.

În timp ce unii algoritmi de data mining vor ignora automat variabile irelevante și țin cont de câmpuri care variază împreună, în practică este recomandabil să se evite dependența de algoritm în această problemă. Deseori, cunoștințele umane în domeniul problemei asigură alegerea celor mai bune soluții. De exemplu, includerea codului numeric personal sau a numărului de asigurări sociale ca variabile de predicție nu poate avea nici o implicație benefică și în cel mai rău caz poate reduce ponderea altor variabile de predicție.

Ca și în cazul selectării variabilelor, se încearcă folosirea tuturor liniilor de date existente în construirea modelului. Însă, în cazul unei mari cantități de date, poate dura mult prea mult timp, sau poate necesita folosirea unui calculator mai puternic.

Ca urmare, în cazul în care baza de date este de mari dimensiuni, se recomandă extragerea unor mostre. Acest lucru nu produce pierderi de informații, cât timp selectarea mostrei se face cu atenție, pentru a asigura faptul că extragerea este pur și simplu întâmplătoare. Având de ales între a investiga câteva modele construite pe baza tuturor datelor sau a investiga mai multe modele construite pe o mostră, abordarea din urmă ajută de cele mai multe ori la dezvoltarea unui model mai robust.

În cazul în care se dorește eliminarea datelor care sunt clar irelevante, deși în unele cazuri acestea pot conține înformații importante în construcția modelului, ele pot fi b#%l!^+a?ignorate poe baza priceperii analistului.

Adesea este necesară construirea unor noi variabile de predicție, derivate de datele luate în calcul. De exemplu, pentru prezicerea riscului de creditare, folosind un raport datorii/venituri în loc de variabilele venit și datorii, se poate ajunge la rezultate mult mai bune și mai ușor de înțeles. Anumite variabile care au un impact mic folosite singure cer combinarea lor cu altele, folosind operații aritmetice sau algebrice (sume, fracții, etc.). În cazul în care anumite variabile iau valori într-un interval foarte mare, dimensiunea intervalului poate fi redusă prin folosirea de exemplu a logaritmului venitului în locul venitului.

Unealta aleasă poate impune restricții asupra reprezentării datelor (de exemplu, explozia categoriilor folosită în rețelele neuronale). Variabilele pot fi aduse într-un anumit interval precum [0,1]. Mulți arbori de decizie folosiți pentru clasificare cer date continue precum venitul grupat pe categorii: mare, mediu, mic. Codarea aleasă poate influența rezultatul modelului.

1.2.9.5. Construirea modelului pentru data mining

Cel mai important lucru de care trebuie ținut cont în construirea unui model este acela că este un proces iterativ. Trebuie exploatate mai multe modele pentru a-l găsi pe acela care se potrivește cel mai bine problemei. Ceea ce se învață în căutarea unui model bun te poate trimite înapoi sa faci modificări în datele pe care le folosești, sau să faci modificări în chiar enunțul problemei.

O dată ce a fost ales tipul predicției ce urmează a fi făcută (clasificare sau regresie) trebuie ales un tip de model pentru a face această predicție. Acesta poate fi un arbore de decizie, o rețea neuronală sau o regresie logistică. Alegerea tipului de model poate influența procesul de preparare a datelor.

De exemplu, o rețea neuronală va necesita o explozie categorică a variabilelor. Sau modelul poate cere ca datele să urmeze un anumit format, ceea ce va necesita transformarea acestora. Din momentul în care datele sunt pregătite, se poate începe antrenarea modelului.

Procesul de contruire a modelelor de predicție cere o antrenare bine definită și un protocol de validare astfel încât să asigure cele mai clare și robuste predicții. Acest tip de protocol este numit învățare supervizată. Scopul învățării supervizate este de a antrena modelul pe un subset al setului de date și apoi de a-l valida pe restul setului datelor.

Un model se consideră a fi construit când se încheie ciclul de antrenare și testare. Câteodată, un al treilea set de date numit set de date de validare, este necesar deoarece datele de test ar putea influența etape ale modelului, iar setul de validare funcționează ca o măsură independentă de asigurare a acurateții modelului.

Antranarea și testarea modelului necesită ca datele să fie separate în cel puțin două grupe: unul pentru antrenarea modelului (estimarea parametrilor modelului) și unul pentru testarea modelului. Dacă nu sunt folosite seturi diferite de date, acuratețea modelului poate fi supraestimată. După ce modelul este generat folosind o bază de antrenare, este folosit să prezică o bază de date de test, și rata acurateții rezultate este un estimator bun pentru felul în care modelul se va comporta în baze de date similare cu baza de date de antrenare și de test. Nu garantează faptul că modelul este corect. Spune doar că dacă aceeași tehnică este folosită într-o succesiune de baze de date cu date similare cu cele din setul de test și cel de antrenare, acuratețea medie va fi apropiată de cea obținută în acest fel.

Cea mai comună metodă de testare este validarea simplă. Această se aplică în felul următor: se separă o anumită parte a datelor din baza de date și se formează o bază de date de test care nu se folosește sub nici o formă în construirea modelului sau estimări. Această parte a datelor reprezintă de obicei un procent între 5% și 33% din baza de date inițială. Pentru ca toate calculele viitoare să fie corecte, separarea datelor în două grupuri trebuie făcută la întâmplare, astfel încât setul de antrenare și setul de test să reflecte în cel mai bun mod modelarea.

După construirea unui model din corpul de date principal, acesta este folosit pentru prezicerea claselor sau valorilor bazei de date de test. Împărțind numărul clasificărilor incorecte la numărul total de cazuri, obținem data erorii.Împărțind numărul clasificărilor corecte la numărul total de cazuri, obținem rata de acuratețe.

În contruirea unui singur model, chiar și validarea simplă trebuie făcută de câteva zeci de ori. De exepmplu, când se folosește o rețea neuronală, câteodată fiecare pas de antrenare prin rețea este confruntat cu o bază de date de test. Antrenarea se oprește când rata de acuratețe nu se mai îmbunătățește.

În cazul în care se lucrează cu o cantitate modestă de date (câteva sute de linii) pentru construirea unui model, nu se mai poate sustrage un procent din cantitatea de date pentru o validare simplă.

Validarea încrucișată este o metodă care permite folosirea tuturor datelor. Datele sunt împărțite la întâmplare în două seturi egale pentru a estima acuratețea predicției modelului. Mai întâi se construiește un model bazat pe primul set care este b#%l!^+a?folosit pentru a prezice rezultate, iar în al doilea set, se calculează rata erorii. Apoi, rolurile celor două seturi se schimbă. În final, se construiește un model folosind toate datele.

În mod normal, se folosește cazul general al validării încrucișate de ordin n. În această metodă, datele sunt împărțite la întâmplare în n grupe disjuncte. De exemplu, presupunem că datele au fost împărțite în zece grupe. Primul grup este pus deoparte pentru teste, iar celelalte nouă sunt folosite in construirea unui model. Modelul construit pe procentul de 90% din date este folosit apoi pentru a prezice grupul pus deoparte. Procesul se repetă de zece ori, după cum fiecare grup din cele zece este lăsat deoparte, iar celelalte nouă sunt folosite în construirea care va prezice grupul lăsat deoparte. În final, modelul este construit folosind toate datele. Media celor zece rate de eroare prezise este folosită ca rată a erorii pentru modelul final.

Bootstrapping este o altă metodă pentru a estima eroarea unui model bazat pe un set mic de date. La fel ca în cazul validării încrucișate, modelul este construit pe setul de date întreg. Apoi, mai multe seturi de date numite mostre de bootstrap sunt extrase din setul de date originale. După ce este extras fiecare subiect, este înlocuit și un nou subiect este selectat, până când este creată o întreagă mostră de bootstrap. Se observă că înregistrările pot apărea de mai multe ori în timp ce este extras un set de date. Un model este construit pe baza acestui set și se calculează o rată a erorii. Aceasta se numește eroare de resubstituire. Se crează de obicei mostre numeroase, cam peste o mie. Eroarea finală estimată pentru modelul construit pe întregul set de date este calculată ca fiind media estimațiilor erorilor din fiecare mostră.

Pe baza rezultatelor construirii modelului, se poate dori construirea unui alt model folosind aceeași tehnică, dar parametri diferiți, sau se poate încerca folosirea altor algoritmi sau unelte. De exemplu, o altă abordare poate crește acuratețea. Nici o tehnică sau unealtă nu este perfectă pentru toate datele și este dificil, dacă nu imposibil să ne asigurăm înainte de început, care tehnică va funcționa mai bine. Este normal să se construiască modelel numeroase, înainte de a găsi un model satisfăcător.

1.2.9.6. Evaluare și interpretare

După construirea unui model trebuie evaluate rezultatele acestuia și interpretate semnificațiile lor. Trebuie amintit că rata de acuratețe găsită în timpul testărilor se aplică numai în cazul datelor, pe baza cărora modelul a fost construit. În practică, acuratețea poate varia dacă datele asupra cărora modelul diferă în puncte esențiale față de setul inițial. Este important de reținut faptul că acuratețea, de una singură, nu este în mod necesar cel mai bun criteriu de selecție a unui model. Trebuie știut mai mult despre tipul erorilor și consturile asociate lor.

Pentru probleme de clasificare, o matrice de confuzie este o unealtă folositoare în înțelegerea rezultatelor. O matrice de confuzie confruntă realitatea cu valorile din clasele de predicție. Nu ilustrază numai cât de bine se poate prezice un model, dar prezintă și detaliile necesare pentru a înțelege unde lucrurile au început să funcționeze în mod greșit. Tabelul din figura următoare reprezintă o matrice de confuzie. Coloanele arată clasele reale, iar liniile arată clasele prezise. Deci diagonala va ilustra predicțiile corecte. În matricea de confuzie se observă că modelul a prezis 38 din cei 46 de subiecți din clasa B în mod corect, deci a greșit doar in 8 cazuri, pe care le-a trimis 2 în clasa A și 6 în clasa C. Această matrice conține mult mai multă informație decât o rată de acuratețe care spune că au fost clasificate corect 123 de cazuri din 150.

Tabelul 4. Matrice de confuzie

În particular, dacă s-ar asocia costuri diferite la diferite erori, un model cu o acuratețe scăzută per total poate fi preferabil unuia cu o acuratețe ridicată, dar cu un cost mai mare datorată acestui tip de erori pe care le face. Presupunând că în matricea de confuzie fiecare răspuns corect are o valoare de 10 puncte, și fiecare răspuns incorect pentru clasa A costă 5 puncte, pentru clasa B costă 10 puncte și pentru clasa C costă 20 de puncte, atunci valoarea netă a matricii ar fi: (123*10)-(5*5)-(12*10)-(10*20) = 885

Dacă se schimbă matricea de confuzie cu următoarea reprezentată mai jos, rata de acuratețe scade la 79%, însă valoarea netă va fi mai mare: (118*10)-(22*5)-(7*10)-(3*20) = 940

Tabelul 5. Matrice de confuzie

Deci, dacă se dorește maximizarea valorii unui model, nu se recomandă alegerea unui model cu o acuratețe mai mică, deși are o valoare a matricii mai mare.

Graficul câștigului este deasemenea un ajutor în evaluarea utilității unui model. Arată în ce fel răspunsurile sunt schimbate la aplicarea modelului. Rata de schimb poartă numele de lift. De exemplu, în loc de o rată a răspunsurilor de 10%, când un procent întâmplător de 10% din populație este solicitat, rata de răspuns a unui procent de 10% anume ales este de peste 30%. În acest caz, valoare lift-ului este 3.

Figura 61. Graficul câștigului

O altă componentă a interpretării este aprecierea valorii unui model. Reamintim că un tipar poate fi interesant, dar acționând conform lui costă mai mult decât veniturile sau economiile pe care le generează. Graficul ROI (Return on Investment) este un exemplu bun pentru felul în crae atașarea unor valori unui răspuns și costul unui program poate oferi îndrumare adiționala în alegerea unei decizii. În acest caz, ROI este definit ca raportul dintre profit si cost. Se observă că după 80% valorile pentru ROI devin negative, iar valoarea maximă este atinsă la 20%.

Ca alternativă, se poate folosi graficul profitabilității unui model (prfitul este calculat ca venitul din care se scad costurile).

După cum s-a arătat, oricât de mare ar fi acuratețea unui model, nu există garanții că acesta va reflecta situații reale. Un model valid nu este în mod necesar un model corect. Una dintre principalele cazuri ale acestei probleme este faptul că un model implică mereu noi presupuneri. De exemplu, rata inflației poate nu a fost inclusă ca variabilă într-un model care prezice înclinația unui individ de a cumpăra, dar un salt al ratei inflației de la 3% la 17% va afecta în mod sigur comportamentul individului. Deasemenea, toate datele folosite pentru a construi modelul pot fi complet rupte de realitate, într-un anumit fel, ceea ce va conduce la un model incorect.

De aici, se trage concluzia că este foarte importantă testarea unui model în lumea reală. Dacă un model este folosit pentru a selecta un subset de subiecți de pe o lista, se recomandă testarea subiecților pentru a verifica modelul. Dacă un model este folosit pentru a prezice riscul de creditare, modelul trebuie încercat pe un set redus de aplicanți pentru astfel de cereri, înainte de aplicarea pe întregul set de subiecți. Cu cât este mai mare riscul asociat unui model incorect, cu atât este mai importantă efectuarea unui experiment pentru verificarea rezultatelor modelului.

1.2.9.7. Aplicarea modelului și analiza rezultatelor

Din momentul în care un model pentru data mining este construit și validat, acesta poate fi folosit într-unul din următoarele moduri:

Analistul recomandă acțiuni bazate pe simpla vizionare a modelului și a rezultatelor. De exemplu, analistul poate privi cluster-ele pe care le-a identificat modelul, regulile definite de model, sau la graficele ROI.

Aplicarea modelului asupra seturilor diferite de date. Modelul poate fi folosit pentru a însemna înregistrări pe baza clasificării lor, sau pentru a asigna scoruri precum probabilitatea unei acțiuni. Modelul poate selecta câteva înregistrări dintr-o bază de date și să le supună unei analize mai amănunțită cu o unealtă OLAP. b#%l!^+a?

Adesea, modelele sunt parte a unui proces din cadrul unor afaceri precum: analiza riscului, autorizarea creditului sau detectarea fraudelor. În aceste cazuri, modelul este încorporat într-o aplicație. De exemplu, un model predictiv poate fi integrat într-un proces de cerere a unui împrumut pe baza unei ipoteci pentru a ajuta personalul în evaluarea aplicantului. În alt caz, modelul poate fi incastrat într-o aplicație precum un inventar și să dicteze sistemului generarea automată a unei cereri de aprovizionare, când nivelul inventarului prezis scade sub o anumită limită.

Un model data mining este adesea aplicat unui singur eveniment sau unei singure tranzacții. Perioada de timp necesară procesării unei noi tranzacții sau intervalul după care o nouă tranzacție sosește, va determina dacă un algoritm paralel este necesar sau nu. Astfel, în timp ce cererile de împrumut pot fi ușor evaluate pe un calculator cu performanțe medii, în monitorizarea tranzacțiilor făcute cu ajutorul cardurilor sau a apelurilor realizate de pe telefoane celulare necesită un sistem paralel pentru a face față unei rate de tranzacție foarte mare.

În timp ce servește o aplicație complexă, o tehnică data mining este de obicei doar o mică parte a procesului final. De exemplu, descoperirea cunoștințelor prin intermediul tehnicilor data mining, poate fi combinată cu cunoștințele experților în domeniu, și aplicată datelor din baza de date și din tranzacțiile viitoare. În sistemul de detectare a fraudelor, tiparele cunoscute de fraudă pot fi combinate cu tiparele descoperite. Când cazuri suspecte de fraudă sunt prezentate investigatorilor pentru evaluare, aceștia pot avea nevoie să acceseze înregistrările bazei de date în legătură cu alte reclamații depuse de același reclamant sau care implică aceeași reclamați.

Întotdeauna trebuie măsurat gradul de funcționare a unui model, după ce a fost folosit. Oricum, faptul că modelul funcționează bine nu înseamnă că acest lucru se va întâmpla mereu și performanțele sale trebuie monitorizate permanent. În timp, toate sistemele evoluează. Experții în vânzări știu că tiparele de achiziție se schimbă în timp. Variabile externe precum rata inflației se pot schimba îndeajuns încât să modifice comportamentul oamenilor. Deasemenea, din timp în timp un model trebuie retestat, reantranat și poate chiar reconstruit. Graficele diferențelor dintre valorile prezise și observate sunt o cale excelentă de a monitoriza rezultatele modelului. Astfel de grafice sunt ușor de folosit și de înțeles, nu cer calcule intensive și pot fi construite în cadrul soft-ului care impelmentează modelul. Astfel, sistemul se poate monitoriza singur.

1.2.10. Aplicații ale tehnicilor de data mining

În evaluarea uneltelor de data mining, acestea trebuie privite în întregul lor ansamblu. Uneltele de data mining nu pot fi categorisite pur și simplu cu finalitate înaltă sau cu finalitate redusă deoarece produsele sunt mult prea bogate in funcționalități pentru a fi judecate după o singură dimensiune.

1.2.10.1. Categorii de produse data mining

Există trei tipuri principale de produse data mining:

Unelte folosite pentru analiza OLAP (identifică cele mai importante dimensiuni și segmente asupra cărora trebuie îndreptată atenția): Business Objects Business Miner și Cognos Scenario;

Unelte pure data mining, care sunt reglate pentru rezolvarea unei game largi de probleme: IBM Intelligent Miner, Oracle Darwin, SAS Entreprise Miner, SGI Mine Set, SPSS Clementine;

Unelte care implementează procese specifice afacerilor, pentru care data mining este parte integrală; pot fi cumpărate pachete personalizate pentru afaceri cu unelte data mining incorporate; Oricum, chiar și soluția împachetării uneltelor data mining cere construirea unor modele care să se potrivească datelor utilizatorului. În unele cazuri, pachetul poate necesita o fază de dezvoltare completă a modelului care poate dura luni de zile.

Selecția uneltelor de data mining se aplică celor din ultimele două categorii, dar oricât de detaliată ar fi o listă a capabilităților creată pentru a descie un produs data mining, nimic nu înlocuiește testare efectivă a uneltei. Chiar dacă aceste liste sunt parte componentă a procesului de selecție, ele nu sunt folosite decât pentru a elimina produsele care nu îndeplinesc toate cerințele necesare.

1.2.10.2. Capabilități fundamentale

În funcție de împrejurări (arhitectura sistemului, resurse de personal, dimensiunea bazei de date, complexitatea problemei) unele produse data mining vor fi mai adecvate decât altele, pentru cerințele utilizatorului. Evaluarea unui produs data mining implică cunoașterea capabilităților lui în anumite domenii cheie, care poate nu sunt atinse în prezentările de marketing. De exemplu, lucrarea Data Mining ’99: Technology Report conține răspunsurile a 24 de vânzători la chestionare care acoperă aceste domenii pentru 26 de produse data mining.

Arhitectura sistemului. Produsul poate fi făcut pentru a lucra pe un b#%l!^+a?calculator, sau cu o arhitectură client-server. Însă nu dimensiunea mașinii pe care ruleaza programul este un identificator de încredere pentru complexitatea problemei. Produse foarte sofisticate care pot rezolva probleme complexe și care să necesite utilizatori pricepuți, pot rula la fel de bine pe un calculator sau pe un sistem client-server.

Prepararea datelor. Este pe departe aspectul data mining care necesită cele mai multe resurse temporale. Include funcții precum: curățarea datelor (lucru cu datele lipsă, identificarea violărilor integrității); descrierea datelor (calculul valorilor din linii, al distribuției valorilor, etc); transformările datelor (adăugarea de noi coloane, efectuarea unor calcule pe baza coloanelor existente, gruparea variabilelor continue în arii de valori, explziile variabilelor categorice în variabile de dihotomie); extragerea de mostre pentru construirea unui model sau pentru crearea de seturi de date de antrenare sau validare; selectarea predictorilor din spațiul variabilelor și identificarea coloanelor liniare;

Accesul la date. Unele unelte de data mining cer ca datele să fie extrase din baza de date țintă într-un format intern. O tehnică data mining trebuie să fie capabilă să acceseze direct structuri de date pentru a maximiza performanțele și a profita de avantaje precum accesul paralel la baza de date. Nici un produs însă nu poate suporta întreaga varietate de servere de baze de date.

Algoritmi. Trebuie înțelese caracteristicile algoritmilor pe care produsele data mining le folosesc pentru a determina dacă se potrivesc caracteristicilor problemei. În particular, trebuie învățat cum un algoritm tratează tipuri de date ale răspunsului și ale variabilelor de predicție, cât de repede se antrenează și cât de repede lucrează cu date noi. O altă trăsătura importantă a unui algoritm este sensibilitatea la date irelevante. Datele reale au coloane irelevante, subiecți care nu se încadrează în tiparul găsit de model și valori lipsă sau incorecte. Ne punem întrebarea câte astfel de date poate ignora un algoritm până când acuratețea lui scade. În unele cazuri, simpla adăugare de date reduce problemele, dar însăși adăugarea de date noi reprezintă o problemă care poate reduce acuratețea.

Interfețe către alte produse. Există mai multe unelte care pot ajuta utilizatorul să-și înțeleagă datele înaintea de construirea unui model și să interpreteze rezultatele modelului. Acestea includ tradiționalele rapoarte, unelte grafice și de vizualizare și unelte OLAP. Software-ul de data mining care asigură căi facile de integrare cu produsele altor companii oferă utilizatorilor căi multiple de a exploata la maxim procesul de descoperire a cunoștințelor.

Evaluarea modelului și interpretarea. Există unelte care îndrumă utilizatorul în înțelegerea rezultatelor printr-o ofertă de indici de măsură a calității, precum: acuratețea, importanța, etc. într-un format ușor de manevrat precum matrici de confuzie sau grafice ROI, sau prin prezentări grafice ale rezultatelor.

Desfășurarea modelului. Rezultatul unui model poate fi aplicat prin introducerea lui într-o bază de date sau prin extragerea de informații din cadrul lui. Când este necesară aplicarea modelului asupra noilor subiecți care apar, este în general necesară și încorporarea modelului într-un program, folosind un cod generat de o uneealtă data mining. Una dintre problemele cheie în desfășurarea modelelor este efectuarea transformărilor necesare pentru a face predicții și multe dintre uneltele de data mining consideră acest lucru o sarcină separată pentru utilizator sau programator.

Scalabilitatea. Cât de eficientă este o unealtă în lucrul cu cantități mari de date, atât linii cât și coloane, sau cu tehnici de validare sofisticate? Aceste provocări cer abilitatea de a profita de resursele hardware. Ce tipuri de paralelism suportă tehnica? Algoritmii de data mining scriși pentru structuri uniprocesor nu vor rula mai rapid pe sisteme paralele, ci trebuie rescriși pentru a lua în calcul structura paralelă și există două moduri de a realiza acest lucru:

Bucăți independente ale aplicației, sunt asignate la diferite procesoare. Cu cât mai multe procesoare, cu atât mai multe bucăți pot fi executate simultan. Acest mod poartă numele de „paralelism inter-modele” și este util în construirea mai multor modele independente. De exemplu, o aplicare a unei rețele neuronale poate construi diferite modele cu fiecare procesor simultan, folosind arhitecturi care diferă prin numărul de b#%l!^+a?noduri sau de strate ascunse.

În cazul în care construirea unui model durează foarte mult este nevoie ca acest model să fie descompus în sarcini executate fiecare de către un procesor și apoi recombinate în răspuns. Acest mod poartă numele de paralelism intra-modele.

Înterfața cu utilizatorul. Pentru a ușura construirea unui model, unele produse oferă o interfață grafică pentru construirea semiautomată a modelelor, în timp ce altele pot oferi un limbaj de descriere.

Unele produse pot oferi generatoare de cod ce pot fi include în limbaje de programare. Însă, datorită deciziilor tehnice foarte importante în prepararea și selectarea datelor și alegerea strategiei de modelare, chiar și o interfață grafică ce simplifică construirea modelului cere experiență pentru găsirea celor mai eficiente modele. Interfața cu utilizatorul a unui produs trebuie evaluată în funcție de adaptabilitatea la fiecare categorie de utilizatori.

1.2.10.3. Forarea în WWW

Scopul este crearea unor baze de date structurate conținând informații utile prin extragerea automată a acestor informații din cadrul World Wide Web sau din alte surse Internet. Această aplicație va permite tratarea WWW ca o imensă bază de date care poate fi forată cu ajutorul limbajelor de manipulare a bazelor de date și prin metode de inferență deductivă.

Acest lucru va oferi: unelte de recuperare a datelor mult mai puternice decât actualele căutări după cheie; dezvoltarea unor asistenți virtuali bazați pe cunoștințe care folosesc WWW ca bază de cunoștințe; noi abordări ale tehnicii data mining în cadrul căreia bazele de date curente vor fi mărite prin adăugarea de informații extrase de pe WWW.

Abordarea tehnică a acestei probleme constă în dezvoltarea unor algoritmi de învățare automată care pot fi antrenați să extragă informații prin monitorizarea WWW. Este suficient ca utilizatorul să definească clase și relații care să fie extrase și să ofere exemple de antrenare acestor algoritmi. Sistemul folosește datele de antrenare pentru a învăța proceduri originale de extragere a informațiilor din paginile WWW.

Au fost dezvoltați câțiva algoritmi pentru a rezolva această problemă, precum: algoritmi care clasifică paginile WWW după cuvintele conținute; algoritmi care învață să identifice subcâmpuri relevante în textul unui document.

S-a demonstrat că aceste metode pot învăța să extragă informații despre universități, studenți,cursuri și proiecte, de exemplu, cu o precizie de aproximativ 70%. Proiectele curente caută să îmbunătățească acuratețea acestor informații, prin: implicarea analizei lingvistice a textelor; ierarhizarea claselor și a relațiilor; algoritmi care învață dintr-o combinație de date de antrenare etichetate și neetichetate.

De asemenea, se încearca explorarea folosirii informației extrase. De exemplu, se încearcă crearea unui agent expert care acceptă descrierea textuală a unui proiect și apoi localizează cel mai adecvat expert în această problemă pentru consultanță.

1.2.10.3.1. Ierarhizarea paginilor

Este o tehnică folosită pentru a descoperi cele mai importante pagini de web. Definiția importanței este una recursivă: o pagină este importantă, dacă alte pagini importante sunt legate de ea.

Dacă se crează o matrice stochastică a rețelei, aceasta este definită astfel: fiecărei pagini i îi corespunde elementul de pe coloana i și linia i din matrice; dacă pagina j are n succesori (legături) atunci elementul ij este 1/n dacă pagina i este unul dintre succesori și 0 în caz contrar.

Premisele care stau la baza acestei matrici sunt: ne imaginăm că inițial fiecare pagină are o singură unitate de importanță: pe rând, fiecare pagină va împărți importanța cu succesorii săi și va primi importanță de la predecesori; eventual, importanța fiecărei pagini atinge o limită care va fi componenta sa în eigen vector-ul” principal al matricii; importanța este de asemenea probabilitatea ca un navigator pe web, începând de la o pagină aleatoare și urmărind legături aleatoare din fiecare pagină să ajungă la pagina în discuție.

Considerând WWW ca fiind format doar din trei pagini: Netscape, Microsoft și Amazon, legate astfel:

Figura 62. Iearhizarea paginilor

Fie [n,m,a] vectorul importanțelor celor trei pagini: Netscape, Microsoft și Amazon, în această ordine. Atunci ecuația care descrie valorile acestor trei variabile este:

Figura 63. Ecuația care rescrie valorile

De exemplu, prima coloană a matricii reflectă faptul că Netscape împarte importanța între ea însăși și Amazon. A doua coloană indică faptul că Microsoft ofertă toată importanța sa paginii Amazon. Se pot rezolva astfel de ecuații începând cu presupunerea că n = m = a = 1 și aplicând repetat matricea estimației curente acestor valori. Primele patru iterații oferă următoarele estimații:

Figura 64. Matricea estimației curente

La sfârșitul calculelor, soluția este n = a = 6/5, m = 3/5, ceea ce înseamnă că Netscape și Amazon au aceeași importanță și de două ori importanța paginii Microsoft.

Nu se vor obține niciodată valori absolute pentru n, m, a din momentul în care presupunerea inițială a fost arbitrară. Deoarece matricea este stochastică (suma pe fiecare coloană este 1) procesul descris anterior converge către eigen vectorul principal.

1.2.10.3.2. Probleme cu grafurile rețelei reale

Deadends (înfundături): o pagină care nu are succesori nu are unde să-și transmită importanța și, eventual, aceasta se va scurge din web;

Spider traps (capcane): un grup format din una sau mai multe pagini care nu au legături în afara grupului, fapt care va cauza acumularea întregii importanțe a web-ului.

Presupunem că pagina Microsoft nu mai are nici o legătură în afara ei. Noua rețea va arăta astfel.

Figura 65. Înfundături

Și matricea de tranziție este:

Figura 66. Matricea de tranziție

Primii patru pași ai soluției iterative sunt:

Figura 67. Pașii soluției iterative

Se observă o scădere continuă a valorilor care în cele din urmă vor deveni 0, deci toată importanța se va scurge.

Presupunem că pagina Microsoft are legătură numai cu ea însăși, devenind astfel o capcană. Noua rețea va arăta astfel.

Figura 68. Capcane

Și matricea care descrie tranzițiile este:

Figura 69. Matricea de tranziție

Primii pași ai soluției iterative sunt:

Figura 70. Pașii soluției iterative

Se observă că valoarea lui m converge spre 3, pe când celelalte converg la 0.

1.2.10.3.3. Soluții Google pentru problemele rețelei

În loc să se aplicea matricea direct, fiecare pagină este taxată cu un procent din importanța ei și importanța taxată este distribuită tuturor paginilor:

După ce se aplică o taxă de 20%, ecuația devine:

Figura 71. Ecuație

Soluția acestei ecuații este:

Figura 72. Soluție

Aceasta reprezintă o distribuție a importanței mult mai rezonabilă decât în exemplele anterioare.

1.2.10.3.4. Dispozitive antispam

Prin spamming se înțelege încercarea mai multor site-uri web de a părea legate de un anumit subiect care să atragă navigatorii, fără să aibă într-adevăr acel subiect.

Google, ca oricare alt motor de căutare, încearcă să potrivească cuvintele din cererea navigatorului cu cuvintele din pagina web însă, spre deosebire de acestea, Google încearcă să înțeleagă ceea ce alte pagini spun despre o altă pagină în textele ancoră, îngreunând astfel încercarea paginii de apaărea legată de alt subiect.

Folosirea rangului unei pagini pentru a măsura importanța, mai degrabă decât naivul număr de legături spre pagină oferă de asemenea protecție împotriva spammingului; vechea măsură putea fi păcălită de spammeri care pot crea 1000 de pagini care se leagă mutual una de cealaltă, în timp ce rangul paginii nu recunoaște importanța niciuneia dintre acele pagini.

1.2.10.3.5. Centri și autorități

În mod intuitiv, centrii și autoritățile sunt definite mutual recursiv: un centru se leagă la mai multe autorități, și o autoritate este legată la mai mulți centri:

Autoritățile se dovedesc a fi pagini care oferă informații în legătură cu un subiect;

Centrii sunt pagini care nu oferă informație, dar spun unde se găsește informația;

Se folosește o matrice similară cu cea a rangului paginilor, dar fără restricția stochastică; fiecare legătură se contorizează cu unu, indiferent câți succesori sau predecesori are o pagina;

Aplicarea repetată a matricii duce la divergență dar se pot introduce și valori de scalare care să păstreze valorile calculate pentru autorități și centri, pentru fiecare pagină, în limite finite.

Se definește matricea A ale cărei linii și coloane corespund paginilor web, cu intrările:

Figura 73. Intrări

Se obsevă că AT, transpusa matricii A, seamănă cu matricea folosită pentru calculul rangurilor, dar AT are valoarea 1, unde matricea pentru rang are fracții.

Fie a și h vectori ale căror componente corespund gradului de autoritate și de centru al paginii i. Fie λ și μ factori de scalare potriviți care urmează a fi determinați. Putem exprima:

h = λAa: gradul de centru al fiecărei pagini este suma autorităților tuturor paginilor legate de ea, scalate prin λ. b#%l!^+a?

a = μATh: autoritatea fiecărei pagini este suma gradelor de centru al tuturor paginilor legate de ea, scalată prin μ.

Relațiile 1 și 2 pot fi transformate și se obțin două ecuații în care vectorii a și h sunt calculați doar în funcție de propriile valori:

Figura 74. Ecuație

Drept urmare, se pot calcula valorile pentru a și h și rezultă vectorii principali pentru matricile A și AT.

Figura 75. Centri și autorități

Matricile pentru acest exemplu sunt:

Figura 76. Matrici

Dacă folosim λ=μ=1 și presupunem că vectorii h = [hn,hm,ha] și a = [an,am,aa] sunt fiecare egali cu vectorul [1,1,1], atunci primele trei iterații ale ecuațiilor pentru a și h sunt:

Figura 77. Iterații ale ecuaților

1.2.10.3.6. Găsirea seturilor neobișnuite de obiecte

Problema care se pune este găsirea seturilor de cuvinte care apar împreună neobișnuit de des pe Web, precum: New și York sau {ducesa, de, York}.

Dacă trei cuvinte: a, b, c apar în 1% din toate documentele și S={a,b,c} apare în 0.1% din documente, atunci gradul de interes pe care îl prezintă S este:

Figura 78. Gradul de interes

În cazul în care apar mai mult de 108 cuvinte diferite pe Web, nu este posibil să se ia în calcul toate perechile de cuvinte.

1.2.10.3.7. Motorul DICE

Motorul DICE (Dynamic Itemset Counting Engine) vizitează în mod repetat paginile de Web, într-o manieră round-robin. De fiecare dată numără aparițiile anumitor seturi de cuvinte și al tuturor cuvintelor din set, luate individual. Numărul de seturi luate în calcul este suficient de mic încât numărătoarea să poată folosi memoria principală.

La un anumit interval, de exemplu la fiecare 5000 de pagini, DICE retestează seturile pe care le calculează. Lasă deoparte acele seturi care prezintă mai puțin interes și le înlocuiește cu alte seturi.

Alegerea noilor seturi se bazează pe observația verificată de experimente conform căreia acele cuvinte care apar într-un set de mare interes apar cu o probabilitate mai mare de apariție în alte seturi de mare interes. Astfel, când selectează noi seturi de cuvinte pentru a reîncepe numărătoarea, DICE înclină în favoarea cuvintelor care apar deja în seturi de mare interes. Oricum, nu se bazează exclusiv pe acele cuvinte căci, în caz contrar nu va putea găsi niciodată seturi de mare interes compuse din multe cuvinte pe care nu le-a verificat. Câteva (dar nu toate) din construcțiile pe care DICE le folosește pentru a creea seturi noi sunt: două cuvinte aleatoare – aceasta este singura regulă care este independentă de presupunerea anterioară și ajută la pătrunderea de noi cuvinte în memorie; un cuvânt dintr-un set interesant și un cuvânt aleator; două cuvinte din două seturi interesante diferite; reuniunea a două seturi interesante a căror intersecție conține două sau mai multe cuvinte; setul {a, b, c}, dacă toate seturile {a, b}, {b, c}, {a, c}sunt interesante.

1.2.10.3.8. Construirea tiparelor din apariții ale datelor

Aparițiile datelor se grupează după ordine și centri. De exemplu, un grup poate să corespundă aparițiilor cu ordinea titlu apoi autor și centrul </I> by.

Pentru fiecare grup, se găsește cel mai lung prefix, sufix, sau prefix URL comun.

Dacă este trecut testul de specificitate al tiparului, atunci acesta este acceptat.

Dacă testul nu este trecut, se încearcă separarea grupului în două, prin creșterea lungimii prefixului URL cu un caracter și se repetă procesul de la pasul doi. Dacă este imposibilă separarea grupului (deoarece există un singur URL), atunci nu se poate crea un tipar din grup.

Presupunem că grupul în cauză conține trei URL-uri: www.stanford.edu/class/cs345/index.html, www.stanford.edu/class/cs145/intro.html, www.stanford.edu/class/cs140/readings.html. Prefixul comun este www.stanford.edu/class/cs. Dacă ar trebui separat grupul, atunci următorul caracter, care la o adresă este 3 și la celelalte este 1, separă grupul în două, cu aparițiile de pe prima pagină mergând într-un grup și cu cele de pe următoarele două în alt grup.

Fiind date mai multe tipare, aparițiile datelor se găses astfel: se găsesc toate adresele, care se potrivesc cu prefixul URL în cel puțin un tipar; pentru fiecrae din acele pagini, se scanează textul, folosind expresii regulate, construite din prefixul, centrul și sufixul tiparului; se extrage din fiecare potrivire titlul și autorul, conform ordinii specificate în tipar.

1.2.10.4. Învățarea automatelor

Scopul cercetării posibilității roboților de a învăța este acela de a dezvolta algoritmi și tehnici de învățare în cazul roboticii. De exemplu, este încurajată cercetarea metodelor de achiziționare a modelelor spațiale bazate pe date înregistrate de roboți mobili, iar datele obținute sunt folosite de tehnicile de învățare pentru a genera autocontrol pentru acești roboți.

Cercetarea acestei posibilități poate duce la o familie de roboți mai puternică. Abilitatea de a învăța din experiență va da posibilitatea acestor roboți de a conlucra cu o mare varietate de sarcini și în medii mai puțin predictibile decât roboții actuali. Pentru a dezvolta această abilitate la roboți, este necesară o înțelegere atentă a felului cum se extrag cunoștințele dintr-o cantitate mare de date numerice și grafice furnizate de senzori, o analiză a interacțiunii cu mediile fizice în timpul învățării și construirea unor algoritmi de învățare eficienți.

Una dintre direcțiile de cercetare este studierea cauzului roboților cu viață lungă, care înfruntă o întreagă colecție de sarcini de învățare. Au fost dezvoltați algoritmi speciali care studiază tehnicile de învățare cunoscute și generează „meta-cunoștințe” generale folosite pentru a dirija învățarea când robotul înfruntă noi sarcini de învățare. Ca urmare, roboții au fost învățați să învețe.

O altă direcție de cercetare este utilitatea modelelor statistice în contextul b#%l!^+a?roboticii. Până acum, statistica a fost aplicată cu succes în probleme ale roboticii, precum: localizare, mapare, recunoașterea obiectelor, navigare și explorare.

1.2.10.4.1. Aspecte generale

Învățarea acoperă o gamă largă de procese, motiv pentru care este dificil să se definească precis. O definiție din dicționar conține fraze precum: A obține cunoștințe sau a înțelege cunoștințele prin studiu, instruire sau experiență și modificări ale pornirilor comportamentale în urma experienței.

Zoologii și fiziologii studiază învățarea la animale și la oameni. Există câteva paralele între învățarea la animale si învățarea automatelor, multe tehnici folosite în învățarea automatelor derivând din eforturile fiziologilor de a-și prezenta teoriile referitoare la învățarea la animale și la oameni prin intermediul unor modele informatice; este posibil însă și faptul ca unele dintre conceptele și tehnicile studiate de cercetătorii în domeniul automatelor să lumineze anumite aspecte al învățarii biologice.

În ceea ce privește automatele, se poate spune că un automat învața în momentul în care își schimbă structura, programul sau datele, pe baza unor intrări sau ca răspuns la informații externe, în așa fel încât performanțele sale viitoare să crească. Unele dintre aceste schimbări, precum adăugarea unei inregistrări la baza de date, țin de alte domenii și nu se poate spune că automatul a învățat, însă când performanțele unui dispozitiv de recunoaștere a vorbirii se îmbunătățesc după ce a ascultat mai multe fragmente din discusul unei persoane, este justificat să se spună că automatul a învățat.

Învățarea auotmatelor se referă de obicei la schimbări în sisteme care îndeplinesc sarcini asociate cu inteligența artificială (I.A.). Astfel de sarcini implică recunoaștere, diagnoză, planificare, controlul roboților, predicție, etc. Schimbările pot fi fie îmbunătățiri ale sistemelor deja existente, fie sinteze ale unor noi sisteme.

Se pot pune întrebările: De ce automatele trebuie să învețe?, De ce nu se proiectează automate care să acționeze cum dorim încă de la început?, și există mai multe răspunsuri.

Deja s-a menționat ajutorul oferit în înțelegerea modului în care învață oamenii sau animalele, însă există și mai multe motive inginerești, precum:

Unele sarcini nu pot fi definite decât prin exemple; Se pot specifica perechi de intrare – ieșire, însă nu și relația precisă dintre intrări și ieșirile dorite; Automatele trebuie să fie capabile să porducă ieșiri corecte pentru un număr mare de intrări și deci să-și ajusteze funcția de intrare-ieșire pentru a aproxima relația dintre intrări și ieșiri din exemple.

Este posibil ca în aglomerări mari de date să existe relații și corelații; Metodele folosite pentru învățarea automatelor pot fi folosite pentru a extrage aceste relații (data minig);

Experții umani proiectează automate care de cele mai multe ori nu funcționează la fel de bine în diferite medii; de fapt, anumite caracteristici ale mediului de lucru pot fi imcomplet cunoscute în momentul proiectării. Metodele de invățare a automatelor pot fi folosite pentru ajustarea în funcție de mediu a proiectelor existente.

Cantitatea de cunoștințe disponibilă în legătură cu anumite sarcini poate fi prea mare pentru a putea fi codată de experții umani; Automatele care invață aceste cunoștințe gradat pot fi capabile să cuprindă mai mult decât ar fi vrut experții umani să codeze.

Mediile de lucru se schimbă în timp; automatele care se adaptează la un mediu în schimbare ar reduce nevoia constantă de reproiectare;

Informații noi despre sarcini sunt descoperite in mod constant; Vocabularul se schimbă; există mereu evenimente noi în lume; reproiectarea sistemelor I.A. conform noilor informații nu este practică, însă metodele de învățare a automatelor pot fi capabile să țină pasul cu schimbările.

1.2.10.4.2. Contribuții la învățarea automatelor

Cercetarea în învățarea automatelor se bazează pe cercetări în alte domenii de tradiție, fiecare din acestea aducând diferite metode și un vocabular specific și toate acestea sunt acum asimilate într-o disciplină unificată. Câteva dintre aceste discipline sunt:

Statistica. Una dintre cele mai vechi probleme în statistică este estimarea cât mai bună a valorilor unei funcții necunoscute într-un punct nou, fiind cunoscute valorile în anumite puncte. Metodele statistice de rezolvare a acestei probleme pot fi considerate instanțe ale învățării automatelor, deoarece regulile de decizie și estimare depind de un grup de mostre extrase din mediul problemei. b#%l!^+a?

Modele neuronale. Elemente non-liniare cu intrări ponderate sunt propuse ca modele simple ale neuronilor biologici. Modelatorii acestor elemente sunt interesați cât de aproape aceste rețele aproximează fenomenul de învățare al creierelor biologice. Multe tehnici de învățare a automatelor sunt bazate pe rețele de elemente non-liniare (rețele neuronale).

Teoria controlului pentru adaptare. Teoreticienii studiază problema controlării unui proces cu parametri necunoscuți care trebuie estimați în timpul desfășurării acestuia. Adesea, parametrii se schimbă în timpul unei operații și procesul de control trebuie să țină o evidență a acestor schimbări. O astfel de problemă o reprezintă controlul roboților bazat pe impulsuri senzoriale.

Modele psihologice. Psihologii au studiat performanțele umane în diferite sarcini de învățare, ceea ce a dus la dezvoltarea unei noi ramuri: învățarea dirijată.

Inteligența artificială. Încă de la început, cercetarea in inteligența artificială a fost îndreptată către învățarea automatelor. Cercetătorii I.A. au explorat rolul analogiilor în învățare și felul in care acțiuni viitoare și decizii pot fi bazate pe cazuri precedente. Direcții noi sunt: descoperirea regulilor pentru sisteme expert folosind metode bazate pe arbori de decizie și programarea logico-inductivă.

Modele evoluționiste. În natură, speciile evoluează pentru a acționa mai bine conform nevoilor proprii. Deoarece distincția dintre „a evolua” și „a învăța” poate fi destul de neclară în domeniul computerelor, tehnicile care modelează anumite aspecte ale evoluției biologice au fost propuse ca metode de învățare pentru a îmbunătăți performanțele programelor computerelor. Algoritmii genetici și programarea genetică sunt cele mai cunoscute tehnici folosite în această evoluție.

1.2.10.4.3. Învățarea probabilă aproximativă corectă

S-a pus problema calculului unei funcții fiind dat un set de valori de intrare și de ieșire; prin diferite prelucrări ale datelor se poate ghici aproximativ corect valorile funcției pentru alte intrări. Pe scurt, fiind dat un set de tipare de antrenare potrivite încât să permită alegerea unei funcții consistente cu un set de mostre etichetate să se poată vorbi de probabilitatea ca funcția aleasă să fie aproximativ corectă (probabilitatea de eroare să fie foarte mică), de unde denumirea de învățare probabilă aproximativ corectă (PAC Learning).

1.2.10.4.4. Aplicații în lumea reală

Conceptele legate de invățarea automatelor nu ar prezenta la fel de mult interes dacă ar fi irelevante pentru problemele lumii reale. Tehnici ale învățării automatelor au fost aplicate cu succes în diferite aspecte ale activității umane. Câteva dintre aceste aplicații sunt:

Prevederea supraîncărcărilor electrice, folosind un sistem de reguli bazat pe metoda K-nearest neighbour (1987);

Clasificarea stelelor și a galaxiilor (1993);

Sistemul Sharp de recunoaștere a caracterelor chinezești (poate procesa 200 de caractere pe secundă și are o acuratețe mai mare de 99%); recunoaște mai mult de 300 de caractere;

Rețeaua neuronală Fujitsu pentru monitorizarea producției de oțet (opearează încă din 1990).

În concluzie, este relativ ușor in zilele noastre să găsim exemple de aplicații ale tehnicilor de învățare a automatelor. Acest lucru nu ar trebui să ne surprindă, ținând cont de faptul că multe dintre aceste tehnici pot fi văzute ca extensii ale unor binecunoscute metode statistice care sunt aplicate cu succes de mulți ani.

1.2.11. Succesul în data mining

Există două lucruri esențiale care duc la succesul în data mining. Primul este formularea precisă a problemei care se încearcă a fi rezolvată. O afirmație concentrată dă de obicei cele mai bune rezultate. Al doilea lucru este folosirea datelor care trebuie. După ce au fost alese dintre datele care stau la dispoziție sau după ce au fost cumpărate din date externe, este necesară combinarea lor în moduri semnificative pentru interogare.

Cu cât constructorul de model se poate juca cu datele, construi modele, evalua rezultate și lucra cu mai multe date, într-o anumită unitate de timp, cu atât mai bun va fi modelul rezultat. Drept urmare gradul în care uneltele data mining suportă această explorare interactivă a datelor este mai important decât algoritmul pe care îl folosește. În mod ideal, uneltele de explorare a datelor (grafico-vizuale sau interogative) sunt bine integrate cu b#%l!^+a?algoritmii sau analizele care construiesc modele. b#%l!^+a?

1.3. Process Execution

Sinteza sistemelor de detecție și diagnosticare se face în colaborare cu tehnologul de proces, care proiectează și studiază procesului tehnologic considerat. Cunoașterea unor modele matematice generale facilitează identificarea unor modele matematice viabile, suficient de precise pentru aceste tipuri de sisteme de monitorizare și reprezintă una dintre problemele des întâlnite în practica curentă, premergătoare etapei de proiectare a unei strategii de conducere complexe.

Dificultățile întimpinate la dezvoltarea analitica a unor modele ale sistemelor de monitorizare pot fi surmontate printr-o dezvoltarea a unor modele experimentale, pe baza unor măsurători efectuate asupra proceselor. Pe baza acestor modele matematice pot fi sintetizate și dezvoltate diverse strategii de monitorizare.

1.3.1. Aspecte generale

În domeniul ingineriei sistemelor de conducere automate au apărut și s-au dezvoltat noi domenii de aplicații practice. Noul concept de detecție a defectelor reprezintă un astfel de domeniu nou în sistemele automate, care s-a dezvoltat pe baze științifice generale. Acest nou concept a dus la apariția unui subdomeniu în cadru sistemelor automate. Numeroase lucrări științifice și cărți au fost publicate în literatura de specialitate internațională în domeniul detecției defectelor.

Dezvoltarea domeniului detecției și diagnosticării defectelor se bazează, în cadrul tuturor proceselor industriale, pe dezvoltarea tehnologiei echipamentelor de conducere în timp real. În cadrul acestor procese de producție se pot utiliza în prezent, cu o mare eficiență, o multitudine de date culese din proces, pentru reducerea timpului de execuție, creșterea calității produselor, într-un cuvânt optimizarea acestor procese. În paralel cu dezvoltarea echipamentelor numerice de conducere s-au dezvoltat și numeroase metode de monitorizare, bazate pe cunoștințele despre proces. O astfel de metodă este și utilizarea unor metode analitice, cum este cea a estimării parametrilor. În acest mod de detecție și diagnosticare a defectelor se utilizează modele matematice ale proceselor, care trebuiesc determinate cu mare precizie. Multe procese tehnologice se desfășoară în prezent sub o conducere automată și în cazul lor utilizarea detecției și monitorizării defectelor reprezintă un progres tehnologic.

Operațiile de măsurare și de prelucrare a datelor se efectuează la nivelul cel mai de jos. Următorul nivel constă în conducerea automată, bazată pe reacție și reglare. Prin reglare anumite mărimi ale procesului u – mărimi de intrare de conducere și y – mărimi de ieșire, reglate, sunt ajustate în concordanță cu mărimile de intrare de prescriere w și mărimile de intrare perturbatoare v. Al doilea nivel conține supervizarea sau monitorizarea procesului, în cadrul căreia are loc detecția, identificarea și diagnosticarea defectelor din proces și din sistemul de conducere automată. Prin detecția defectelor se înțelege indicarea în mod automat a stărilor nedorite sau nepermise ale procesului. Pe baza identificării și diagnosticării defectelor se iau decizii și se acționează adecvat pentru readucerea procesului și a sistemului de conducere automată la starea normală de funcționare (recuperare), eliminarea defectelor și readucerea la starea de funcționare sigură, oprirea procesului, comutarea sistemelor de conducere redondante sau reconfigurarea structurii de conducere automată. Nivelele superioare pot avea diverse sarcini, cum ar fi: optimizare, coordonare și conducere centralizată, cu scopul realizării unor cerințe economice sau de organizare. La nivelele inferioare este necesar un timp redus de răspuns, ele acționând local, pe când la nivele superioare acțiunea se desfășoară global.

Procesele tehnologice moderne sunt procese complexe, care operează cu un număr mare de mărimi, care sunt reglate în bucle de reglare închise. O detecție a defectelor în aceste sisteme efectuată la timp reduce timpul de execuție, crește siguranța procesului și reduce costurile de producție. Procesele de producție moderne sunt dotate cu numeroase instrumente de măsură, care furnizează numeroase date. Aceste date devin disponibile pentru detecția și diagnosticarea defectelor. Metodele convenționale au limitele lor în ce privește capacitatea de a detecta și a diagnostica defectele în aceste procese multivariabile. De aici a apărut necesitatea dezvoltării unor metode eficiente de monitorizare a proceselor, cum este cazul metodei analitice cu estimare a parametrilor.

Pentru aplicarea acestor metode de monitorizare în sistemele industriale reale este necesar să se depună mari eforturi științifice și tehnice. Dintre multiplele domenii în care s-a dezvoltat în ultimii ani utilizarea tehnologiilor de detecție și diagnosticare a se pot enumera, cu precădere: acționări electrice, centrale atomice, vehicule rutiere, ferate, aeriene, și spațiale, nave, instalații chimice etc.

Tehnicile de monitorizare a proceselor pot fi modelate, simulate și implementate utilizând programe specializate, cum ar fi Matlab și Simulink.

Metodele de detecție bazate pe modele analitice sunt sprijinite de asemenea prin utilizarea unor concepte de estimare a parametrilor. Cercetările în domeniu s-au concentrat pe pe aceste metode, care se utilizează ca o alternativă la alte metodele convenționale cum b#%l!^+a?ar fi: controlul statistic al calității sistemelor, metode bazate pe cunoștințe, analiza variantei canonice, analiza componentei principale, sau analiza bazată pe discrimant.

Procesele conduse convențional cu regulatoare standard, de exemplu de tip PID, sunt proiectate să mențină condiții de funcționare satisfăcătoare compensând efectele perturbațiilor și schimbările apărute în proces. Aceste sisteme de conducere pot compensa un număr mare de tipuri de perturbații, dar sunt anumite schimbări în proces la care ele nu pot face față în mod corespunzător. Aceste schimbări se numesc defecte. Un defect se definește ca o deviație nepermisă a cel puțin unei proprietăți caracteristice, sau a unei mărimi, ale unui sistem (diverși parametri: rezistență sau inductanță electrică, cuplu mecanic, coeficient de frecare, moment de inerție, tensiune sau curent electric, temperatură, presiune, sau indicatori de calitate, cum ar fi de exemplu suprareglajul și altele). Printre tipurile de defecte întâlnite în practică sunt: modificarea parametrilor procesului, modificarea parametrilor perturbațiilor, probleme ale elementelor de execuție și probleme ale traductoarelor. Scurtcircuitarea rezistenței unui motor, sau creșterea coeficientului de frecare la arborele unei mașini electrice sunt exemple de schimbări ale valorilor parametrilor proceselor. Un exemplu de schimbare a parametrilor perturbațiilor este o schimbare extremă în cuplul de sarcină al unei mașini de lucru sau o modificare majoră a temperaturii mediului ambient. Un exemplu de problemă la un element de execuție este distrugerea tranzistoarelor într-un convertor de putere. O problemă de traductoare este apariția unei deviații permanente la un traductor de măsură.

Pentru a fi siguri că procesul se desfășoară cu satisfacerea specificațiilor de calitate, defectele din proces trebuiesc detectate, diagnosticate și eliminate. Aceste sarcini se regăsesc în activitatea de monitorizare a procesului. De-a lungul anilor au fost dezvoltate diverse metode pentru monitorizarea proceselor. Metoda analitică bazată pe estimare s-a impus printre aceste metode. Scopul monitorizării proceselor este asigurarea efectuării cu succes a operațiunilor planificate prin recunoașterea anomaliilor din comportarea procesului. Informațiile achiziționate din și despre proces permit nu numai o bună informare a personalului asupra stării procesului, ci de asemenea aceste informații constituie un suport pentru efectuarea de remedieri adecvate a comportării anormale a procesului. Și ca rezultate se obține o reducere a duratei de execuție, se asigură o siguranță sporită în lucru și se reduc costurile de producție. Pe măsură ce procesele industriale devin tot mai complexe, mai integrate, defectele care apar în cadrul lor pun la o mai grea încercare proiectanții și aceste defecte nu mai pot fi tratate cu metode convenționale, apelându-se la metode ale inteligenței artificiale, cum ar fi logica fuzzy și rețelele neuronale.

Sistemele industriale complexe sunt dotate cu numeroase echipamente de măsură, ceea ce a dus la obținerea unei cantități mari de informații disponibile în monitorizarea proceselor. Iar aceste procese sunt conduse cu echipamente numerice, calculatoare care au devenit tot mai puternice. Disponibilitatea datelor culese în timpul unor condiții de lucru în caz de defect este esențială pentru monitorizarea proceselor. Capacitatea de memorare și viteza de calcul a calculatoarelor permit utilizarea de algoritmi de monitorizare a proceselor care utilizează o mare cantitate de date. Procesele industriale sunt conduse în timp real cu echipamente numerice, cum ar fi calculatoare PC, procesoare de semnal numeric și programe performante. Aceste structuri de conducere reprezintă o bază pentru aplicații care se pretează la implementarea unor astfel de algoritmi de monitorizare.

1.3.2. Proceduri de monitorizare a proceselor

În cadrul monitorizării proceselor se regăsesc patru proceduri și anume: detecția defectelor, identificarea defectelor, diagnosticarea defectelor și refacerea procesului.

Detecția defectelor se face atunci când are loc un defect. Detecția timpurie asigură atenționări importante a problemelor care pot apărea, pentru luarea de măsuri adecvate pentru înlăturarea unor defecte majore.

Identificarea defectelor constă în identificarea mărimilor măsurabile sau observabile, cele mai relevante pentru diagnosticarea defectelor. Scopul acestei proceduri este de a concentra atenția operatorilor și inginerilor de proces spre subsistemele cele mai importante pentru diagnosticarea defectelor, astfel încât efectul defectului să poată fi eliminat într-un mod cât mai eficient.

Prin diagnosticarea defectelor se determină ce defect a avut loc și cauza stării sistemului, observată în afara sistemului de conducere automată. Sau, mai bine zis, se determină tipul, locul și amplitudinea defectului și momentul apariției lui. Diagnosticarea este procedura cea mai importantă pentru contracararea sau eliminarea defectului.

Recuperarea procesului, în urma intervenției în proces, constă în înlăturarea efectului defectului și este procedura necesară pentru închiderea buclei de monitorizare. Dacă în cadrul unui proces s-a detectat un defect atunci cele patru proceduri de monitorizare trebuie aplicate în ordinea amintită mai sus, altfel se efectuează doar procedura de detecție. În practică nu este necesar implementarea tuturor celor patru proceduri pentru monitorizarea unui proces. De exemplu, o defecțiune poate fi diagnosticată fără identificarea mărimilor afectate de defect și apoi se poate reface modul de lucru normal al procesului. Adesea scopul monitorizării procesului este dor de a da indicații operatorilor și inginerilor de proces, b#%l!^+a?fără a realiza un sistem automat de monitorizare. După ce a apărut o defecțiune, procesul poate fi refăcut, reconfigurat sau reparat și se poate întoarce la strategia de conducere anterioară. Câteodată, după ce a fost diagnosticat precis un defect, nu se poate determina o metodă corespunzătoare de contraatacare a defectului. În acest caz o abordare potrivită ar putea fi întoarcerea la strategia de conducere considerată standard. Pentru evaluarea performanțelor regulatoarelor au fost dezvoltate câteva metode și acestea pot fi utilizate pentru determinarea strategiei de conducere la care trebuie să se întoarcă sistemul, pentru refacerea în mod satisfăcător a performanțelor procesului industrial. De exemplu, în cazul unei probleme la un traductor de măsură, se poate aplica o tehnică de refacere a traductorului pentru restabilirea sistemului de reglare în buclă închisă.

1.3.3. Măsuri de monitorizare a proceselor

În cadrul supravegherii procesului se iau câteva măsuri, bazate pe diverse metode și teorii, cum ar fi: statistică matematică, clasificarea formelor și teoria sistemelor. Aceste măsuri reprezintă comportarea procesului. Principiul constă în a converti data obținute on-line de la proces în câteva măsuri pentru a asista operatorul să determine starea de operare a procesului și diagnosticarea defectelor. Limitele detecției defectelor trebuie să fie menționate în aceste măsuri. O defecțiune se detectează atunci când în urma evaluării unei măsuri se determină depășirea limitelor impuse. Pe această cale, o măsură este capabilă să definească o comportare greșită a procesului, în concordanță cu starea în afara condițiilor normale d funcționare a procesului. În aceste măsuri valoarea mărimii poate fi comparată cu valorile altor mărimi pentru a se determina care este mărimea cea mai afectată de defect. Defectele pot fi de asemenea diagnosticate și prin dezvoltarea și compararea măsurilor care reprezintă cu precizie diverse defecte ale procesului. Scopul monitorizării proceselor este de a dezvolta măsuri care prezintă o sensibilitate și o robustețe maximă la toate defectele posibile. Datorită faptului că defectele se manifestă pe diverse căi nu toate defectele pot fi detectate și diagnosticate doar numai prin unele măsuri. Fiecare măsură caracterizează un defect într-o manieră diferită, o măsură va fi mai sensibilă la anumite defecte și mai puțin sensibilă la alte defecte, comparativ cu alte măsuri. Aceste aspecte arată că sunt necesare mai multe măsuri de monitorizare a unui proces, fiecare măsură fiind adaptată unui anumit proces și unor anumite defecte. Diversele măsuri dezvoltate în practică sunt clasificate prin asociere la diverse abordări teoretice: metode statistice de achiziție și prelucrare de date, metode analitice și metode bazate pe cunoștințe.

Datele sunt culese direct din proces. Sistemele industriale moderne sunt sisteme mari, cu multe date. Ele sunt dotate cu multe instrumente de măsură, care furnizează o mare cantitate de date. Dar, o cantitate mare de date, achiziționate de la proces, nu poate fi prelucrată de creierul unui operator uman. Prin metodele statistice de prelucrare a datelor se urmărește să se transforme informația de mari dimensiuni într-o informație utilă de mai mici dimensiuni, în care să se sintetizeze ce este mai important. Astfel, pentru prelucrarea datelor se utilizează metode din statistica matematică. În acest caz dezavantajul metodei este dat de faptul că metodele statistice necesită o mare și foarte variată cantitate de date.

Metodele analitice utilizează modele matematice, care sunt adesea construite pe baza modelelor matematice primare obținute din legile fizice, care guvernează procesul, exprimate prin ecuații integro-diferențiale. Metodele analitice sunt aplicabile la sisteme care au modele matematice satisfăcătoare, prevăzute cu diverse traductoare. Cazul mașinilor electrice se pretează la așa ceva, deoarece mașinile electrice sunt bine descrise prin modelele lor cu fazori spațiali, ele putând fi dotate cu diverse traductoare de turație, poziție, curent, tensiune sau flux. Majoritatea modelelor analitice se bazează pe estimarea parametrilor, observatoare de stare și relații de paritate. Metodele analitice se aplică la sisteme cu un număr mic de mărimi de intrare, stare și de ieșire, cum este și cazul sistemelor de conducere automată a mașinilor electrice. Deoarece metodele analitice necesită modele matematice detaliate este mai dificil ca ele să fie aplicate la sisteme mari. Principalul avantaj al metodelor analitice constă în aceea că ele asigură ca strategia de monitorizare să se bazeze pe o înțelegere corectă a procesului, și anume atunci când se utilizează un model adecvat al acestuia.

Metodele bazate pe cunoștințe utilizează modele calitative pentru dezvoltarea unor măsuri de monitorizare. Metodele bazate pe cunoștințe se pretează în cazurile în care pentru sistemele monitorizate nu se dispune de modele, sau acestea au modele complexe sau puternic neliniare. Măsurile bazate pe cunoștințe se aplică prin intermediul sistemelor expert, analizei cauzale sau recunoașterii formelor. Și aceste metode se aplică la sisteme cu un număr mic de mărimi. Pentru o aplicare ușoară a acestor metode este necesară dezvoltarea e pachete de programe specializate.

1.3.4. Metode de monitorizare a proceselor

În ultimii ani au fost dezvoltate diferite metode de detecție a defectelor. Detecția defectelor în procesele tehnice, elemente de execuție sau traductoare se face prin măsurarea mărimilor de intrare u și de ieșire y disponibile.

În cadrul monitorizării procesului se consideră că acesta lucrează în buclă deschisă. Se pot face distincții între procese liniare și neliniare, între regimurile lor de funcționare b#%l!^+a?dinamice sau statice. Cele mai importante metode utilizate pentru detecția defectelor sunt: estimarea parametrilor, estimarea stărilor și ecuașiile de paritate. Estimarea parametrilor asigură determinarea modificărilor care apar în parametrii proceselor. Estimarea stărilor asigură determinarea modificărilor care apar la mărimile de stare ale proceselor sau în erorile de ieșire. Ecuațiile de paritate oferă erorile de ieșire sau erorile polinomiale. Cantitățile măsurate sau estimate, cum sunt: semnalele de intrare și ieșire, parametrii, mărimile de stare sunt în general mărimi stohastice, cu variații aleatoare, caracterizate prin valori medii și repartiții de probabilitate. Ele au variații față de valoarea lor considerată normală din cadrul procesului neafectat de defect. Simptomele analitice e obțin ca schimbări raportate la valori normale. Dacă se utilizează un prag fix, se poate face întotdeauna un compromis între detecția unor mici defecte și alarme false datorate depășirilor valorilor normale pe timp scurt. Pentru îmbunătățirea deciziei se utilizează metode de detecție a modificărilor care apar, prin estimarea modificărilor față de valoarea medie și compararea lor cu deviațiile standard. Logica fuzzy permite ca în această abordare să se aleagă funcții de apartenență definite pe universuri de discurs specifice domeniului e valori în care apar defectele.

În cadru diagnosticării defectelor se determină tipul defectului, ca și dimensiunea acestuia, locul în care a apărut și momentul la care a fost detectat. Procedura de diagnosticare se bazează pe observarea în proces a simptomelor de defect.

Pentru aceasta, una din metode constă în utilizarea sistemelor expert, bazate pe cunoștințe euristice și mecanisme de inferență. Aceste sisteme expert imită raționamentul uman în diagnosticarea defectelor. Experiența umană dintr-un anumit domeniu poate fi exprimată prin reguli, care pot fi combinate cu informații provenite din ecuațiile fizico-matematice ale legilor care guvernează procesul sau cu o descriere structurală a sistemului. Sistemele expert sunt capabile să capteze raționamentul uman de diagnosticare, care nu se poate exprima prin modele matematice.

O altă metodă o constituie recunoașterea formelor, care realizează asociații dintre datele din proces clasificate ca forme și clasele de defecte, fără a utiliza un model explicit al procesului, al stării sau structurii lui. Pentru recunoașterea formelor se utilizează rețele neuronale, de tipul feedforward, sau cu reacție, antrenate cu metode de gradient sau cu algoritmi genetic. Aceste tehnici pot fi asociate tehnicilor de tratare a datelor, pentru modelarea unor relații care să descrie aplicații matematice dintre datele din proces ca forme și clasele de defecte clasificate ca forme. Rețelele neuronale sunt tratate ca și cutii negre, care pot învăța asociații de forme, prezentate la intrările și ieșirile lor, prin sesiuni de antrenare.

Toate metodele, bazate atât pe date statistice, modele analitice sau cunoștințe au avantajele și dezavantajele lor, astfel încât utilizarea unei singure metode nu este cea mai bună soluție.

1.3.5. Metodele analitice

După cum s-a prezentat anterior, metodele de monitorizare a procesului pot fi caracterizate ca fiind bazate de date, analitice sau bazate pe cunoștințe. Un inginer bine pregătit trebui să fie familiarizat cu obstacolele din cadrul metodelor analitice și cu cele din cadrul metodelor bazate pe cunoștințe, pentru că acestea au avantaje în unele probleme de monitorizare a procesului. De asemenea, multe dintre măsuri pot fi asociate cu mai multe abordări.

Metodele analitice generează caracteristici folosind ecuații matematice detaliate, bazându-se pe date măsurate de intrare u, de stare x și de ieșire y. Caracteristicile folosite frecvent includ reziduurile r, calculul parametrilor p și calculul stărilor estimate. Erorile sunt detectate sau diagnosticate prin compararea caracteristicilor observate cu cele asociate condițiilor de operare normală, fie direct, fie după câteva transformări.

Metodele analitice care folosesc reziduurile ca și caracteristici sunt numite metode redondante analitice. Reziduurile sunt rezultatul controlului de consistență între observațiile cu privire la model și ecuațiile matematice. Reziduurile nu vor fi 0, din cauza erorilor, a perturbațiilor, a zgomotului sau a erorilor de modelare.

După cum vom vedea, în cadrul proiectării unui sistem de monitorizare a procesului bazat pe redondanță analitică apare distincția între reziduurile determinate de erori și cele determinate de alte variații.

În situația preferată reziduurile sau transformările reziduurilor vor fi destul de mari când există erori și vor fi mai mici când există perturbații, zgomot, sau erori de modelare. În orice caz, o metodă de redondanță analitică se va folosi într-o decizie de diagnosticare bazată pe reziduuri.

Cele trei modalități principale de a genera reziduuri sunt estimarea parametrilor, observatorii și relațiile de paritate.

Pentru estimarea parametrilor, reziduurile sunt diferența între parametrii nominali ai ecuației și parametrii estimați de ecuație. Deviațiile în parametrii ecuației sunt baza detectării și izolării erorilor.

Metoda bazată pe observatori reconstruiește datele de ieșire ale sistemului prin b#%l!^+a?măsurători sau un set de măsurători cu ajutorul observatorilor. Diferența între datele de ieșire măsurate și cele estimate e folosită drept vector al reziduurilor.

Relațiile de paritate verifică consistența ecuațiilor matematice ale sistemului în raport cu măsurătorile. Relațiile de paritate sunt supuse unei transformări dinamice liniare, cu reziduurile transformate folosite pentru a depista și a izola erorile.

Când există o ecuație primară clară sau un alt tip de ecuație matematică, abordarea analitică poate furniza o monitorizare a procesului mai bună în comparație cu abordările pe bază de date sau cu cele bazate pe cunoștințe. Abordările analitice pot de asemenea încorpora foarte ușor informații din graficul de procedee folosite în proces.

Terminologia monitorizării procesului variază în funcție de domenii. Definiția detectării erorii este foarte consistentă, în timp ce o varietate de definiții ce se suprapun e folosită pentru identificarea erorilor și diagnosticarea lor. Unul din termenii care se cere a fi definit este izolarea erorii, care e definită în general prin determinarea locației exacte a erorii sau a componentei care prezintă eroarea, adică stabilirea componentei eronată. Izolarea erorii furnizează mai multe informații decât o procedură de identificare a erorii în care sunt determinate doar variabilele de observare asociate cu eroarea.

Izolarea erorii nu furnizează la fel de multe informații ca și procedura de diagnosticare a erorii, în care sunt determinate tipul, magnitudinea și timpul erorii. Mai exact, o singură componentă poate avea mai multe tipuri de erori care-i sunt asociate. De exemplu, o valvă poate fi închisă permanent sau închisă ocazional. O procedură de izolare a erorii poate localiza componenta (valva), dar ar fi nevoie de o procedură de diagnosticare a erorii pentru a se determina tipul de eroare și stadiile de izolare.

În continuare se definesc erorile de adunare și de înmulțire și se descrie felul în care aceste erori afectează dinamica procesului. Se prezintă apoi abordările analitice bazate pe estimarea parametrilor, estimatorii/observatorii de stare și relațiile de paritate.

1.3.6. Descrierea erorilor

Pentru un sistem multivariabil liniar, în timp discret, cu mărimile de intrare și mărimile de ieșire , modelul matematic intrare stare ieșire, în forma canonică, fără erori, fără mărimi perturbatoare și nici zgomot, este:

unde:este vectorul mărimilor de stare; t – timpul; A – matricea sistemului; B – matricea de intrare; C – matricea de ieșire; D – matricea de stare.

Erorile care pot fi modelate ca și modificări necunoscute în semnale în sistem sunt numite erori de adunare.

1.3.7. Estimarea parametrilor

Metoda estimării parametrilor este potrivită dacă erorile procesului sunt asociate cu modificări în parametrii modelului matematic, adică în cazul erorilor multiplicative și dacă există un model matematic potrivit. Parametrii modelului sunt în general nemăsurabili, dar pot fi estimați folosind tehnici de estimare a parametrilor, tehnici care pot fi implementate recursiv, pentru a reduce volumul de calcule. Construirea modelului, începând cu modelul primar, facilitează corelarea parametrilor modelului direct de parametrii care au o semnificație fizică în proces. Pragurile pot fi plasate pe diferențele individuale între parametrii nominali și estimarea parametrilor, sau pe o combinație a acestor diferențe. În practică există multe aplicații bazate pe metoda estimării parametrilor.

Metoda estimării parametrilor constă în următorii pași:

Scrierea modelului procesului pentru variabilele măsurabile de intrare u(t) și variabilele de ieșire y(t), folosind ecuațiile de conservare și relații fenomenologice (de exemplu: echilibrul de fază, ecuațiile constitutive ale fluidelor). Ecuația procesului leagă variabilele de intrare u(t) și parametrii ecuației fizice pj de variabilele de ieșire y(t).

Dacă e necesar, se fac presupuneri simplificatoare sau se adună parametrii ecuației fizice pj ca să poată fi studiată problema estimării parametrilor pentru noii parametri Өj, adică astfel încât noii parametri să poată fi determinați în mod unic. În timpul acestui pas este de asemenea folositor să se redefinească variabilele astfel încât cele noi să intre în mod liniar în ecuația procesului, pentru că acest lucru va simplifica problema estimării parametrilor.

Estimarea parametrilor modelului Өj pe baza măsurătorile recente ale mărimilor de intrare u(t) și ale mărimilor de ieșire y(t). Dacă Өj apar liniar în ecuațiile procesului atunci se poate scrie o ecuație de estimare.

Calcularea estimărilor parametrilor fizici din parametrii estimați ai modelului. Dacă în cadrul modelului s-a folosit unirea parametrilor, atunci în unele cazuri se pot determina doar combinații ale parametrilor fizici pj.

Indicarea erorilor, dacă modificarea parametrilor fizici este mai mare b#%l!^+a?decât a celor din datele de lucru. Izolarea erorilor prin compararea modificărilor parametrilor fizici cu observațiile stocate în baze de date istorice.

1.4. Enterprise Architecture

Pentru a permite fiecărei versiuni a regulii operaționale sau a componentei de tip selector ce aparține de aplicația de proces să își utilizeze propriile metadate dinamice (logică pentru reguli sau rutare), modificați codul (refactorizați) pentru spațiul de nume țintă, astfel încât acesta să fie unic pentru fiecare versiune a aplicației de proces.

1.4.1. Arhitectura sistemului

Arhitectura de implementare conține procese software numite servere, unități topologice referite ca noduri și celule și magazia de configurare utilizată pentru memorarea informațiilor de configurare.

1.4.1.1. Celulele

O celulă este un concept de configurare, o cale pentru administratori de a asocia logic nodurile unul cu celălalt. Administratorii definesc nodurile care alcătuiesc o celulă în funcție de criteriile specifice care au sens în mediile lor organizaționale.

Datele de configurare administrative sunt memorate în fișiere XML. O celulă reține fișiere de configurare master pentru fiecare server din fiecare nod din celulă. Fiecare nod și server are, de asemenea, propriile fișiere locale de configurare.

Modificările fișierului local de configurare a unui nod sau a unui server sunt temporare dacă serverul aparține celulei.

Când sunt efective, modificările locale .nlocuiesc configurațiile celulei. Modificările fișierelor de configurare ale serverului master și ale nodului master făcute la nivelul celulei înlocuiesc orice modificare temporară făcută asupra nodului când documentele configurației celulei sunt sincronizate cu nodurile. Sincronizarea apare la evenimente desemnate, cum ar fi pornirea unui server.

1.4.1.2. Serverele

Serverele furnizează funcționalitatea de bază. Servere de proces extind sau măresc abilitatea unui server de aplicații de a manipula module SCA (Service Component Architecture). Alte servere (manageri de implementare și agenți de nod) sunt utilizate pentru gestionarea serverelor Process.

Un Process Server poate fi un server autonom sau un server gestionat. Un server gestionat poate fi eventual membru unui cluster. O colecție de servere gestionate, cluster-e de servere și alte middleware-uri se numește un mediu de implementare. Într-un mediu de implementare, fiecare server sau cluster gestionat este configurat pentru o anumită funcție în mediul de implementare (de exemplu, gazdă destinație, gazdă modul de aplicație sau server Common Event Infrastructure). Un server autonom este configurat să furnizeze toate funcțiile cerute.

Serverele asigură mediul runtime pentru modulele SCA, pentru resursele care sunt utilizate de către acele module (surse de date, specificări de activare și destinații JMS) și pentru resurse livrate (destinații de mesaje, containere Business Process Choreographer și servere Common Event Infrastructure).

Un agent de nod este un agent administrativ ce reprezintă un nod din sistemul dvs. și gestionează serverele acelui nod. Agenții de nod monitorizează serverele de pe un sistem de gazdă și rutează cererile administrative către servere.

Agentul de nod este creat când nodul este federalizat unui manager de implementare.

Un manager de implementare este un agent administrativ care furnizează o vizualizare centralizată de gestionare pentru mai multe servere și cluster-e.

Un server autonom este definit de un profil autonom; un manager de implementare este definit de un profil corespunzător; serverele gestionate sunt create într-un nod gestionat, ce este definit de un profil personalizat.

Un server autonom asigură un mediu pentru implementarea modulelor SCA într-un proces server. Acest proces server include, dar nu este limitat la o consolă administrativă, o țintă de implementare, suportul de mesaje, managerul de reguli de proces operațional și un server Infrastructură eveniment comun.

1.4.1.3. Profilurile

Un profil definește un mediu runtime unic, cu fișiere de comandă, fișiere de configurare și fișiere istoric separate.

Profilurile definesc trei tipuri diferite de medi: server autonom, manager de implementare și nod gestionat.

1.4.1.4. Managerii de implementare

Un manager de implementare este un server care gestionează operațiile pentru un grup sau celulă logică a altor servere.

Managerul de implementare este locația centrală pentru administrarea serverelor și a b#%l!^+a?cluster-elor.

La crearea unui mediu de implementare, profilul managerului de implementare este primul profil pe care îl creați. Managerul de implementare are o consolă Primii pași, de la care puteți porni și opri managerul de implementare și porniți consola administrativă. Folosiți consola administrativă a managerului de implementare pentru a gestiona serverele și cluster-ele din celulă. Aceasta include configurarea serverelor și a cluster-elor, adăugarea serverelor la cluster-e, pornirea și oprirea serverelor și a cluster-elor și implementarea modulelor SCA.

1.4.1.5. Nodurile

Un nod este o grupare logică de servere gestionate.

De obicei, un nod corespunde unui sistem informatic logic sau fizic cu o adresă IP gazdă distinctă. Nodurile nu se pot extinde pe mai multe calculatoare. De obicei, numele nodului sunt identice cu numele gazdă pentru calculator.

Nodurile din topologia Network Deployment pot fi gestionate sau negestionate. Un nod gestionat are un proces al agentului de nod care gestionează configurația sa și serverele. Nodurile negestionate nu au un agent de nod.

Un nod gestionat este un nod care este federalizat către un manager de implementare și care conține agent nod și poate conține servere gestionate. Într-un nod gestionat, puteți configura și rula serverele gestionate.

Serverele gestionate care sunt configurate pe un nod formează resursele mediului de implementare. Aceste servere sunt create, configurate, pornite, oprite, gestionate și șterse folosind consola administrativă a managerului de implementare.

Un nod gestionat are un agent nod care gestionează toate serverele de pe un nod.

Când un nod este federalizat, este creat automat un proces agent nod. Acest agent nod trebuie să ruleze pentru a putea gestiona configurația profilului.

Totuși, agentul nod nu trebuie să ruleze pentru ca aplicațiile să poată rula sau configura resursele din nod.

Un nod gestionat poate conține unul sau mai multe servere, care sunt gestionate de un manager de implementare. Puteți implementa soluții pentru servere într-un nod gestionat, dar nodul gestionat nu conține o galerie de eșantioane de aplicații. Nodul gestionat este definit de un profil personalizat și are o consolă Primii pași.

Un nod negestionat nu are un agent de nod care să îi gestioneze serverele.

Nodurile negestionate din topologia Network Deployment pot avea definiții de servere cum ar fi servere web, dar nu definiții de servere de aplicații. Nodurile negestionate nu pot fi niciodată federalizate. Prin urmare, un agent de nod nu poate fi adăugat niciodată la un nod negestionat. Alt tip de nod negestionat este un server autonom. Managerul de implementare nu poate gestiona acest server autonom deoarece nu este cunoscut de celulă. Un server autonom poate fi federalizat. Când este federalizat, un agent de nod este creat în mod automat. Nodul devine un nod gestionat în celulă.

1.4.1.6. Agenții de nod

Agenții de nod sunt agenți administrativi care rutează cereri administrative la servere.

Un agent de nod este un server care rulează pe fiecare calculator gazdă care participă la configurația Network Deployment. Este pur și simplu un agent administrativ și nu este implicat în funcții care deservesc aplicații. Un agent de nod găzduiește, de asemenea, alte funcții administrative importante precum servicii de transfer de fișiere, sincronizare de configurare și monitor de performanță.

1.4.2. Instalarea aplicației Oracle SQL Developer Data Modeler

Oracle SQL Developer Data Modeler nu necesită un proces de instalare. Pentru utilizarea aplicației este suficientă descărcarea ei de pe site-ul Oracle (http://www.oracle.com/technetwork/developer-tools/datamodeler/downloads/index.html) și dezarhivarea pe un suport de memorie (inclusiv stick). După dezarhivare, pentru deschiderea aplicației pe un sistem Windows se dă dublu-click pe fișierul datamodeling.exe (datamodeling64.exe în cazul în care sistemul de operare este sub 64 de biți).

Una dintre cele mai frecvente erori care apare la lansarea aplicației este absența fișierului msvcr71.dll. Soluționarea ei presupune copierea fișierului respectiv în directorul corespunzător aplicației (de exemplu, d:\datamodeler).

Figura 79. Eroare de instalare

1.4.3. Proiecte Data Modeler

La prima deschidere, Data Modeler creează un proiect implicit care poate fi salvat cu CTRL+S (sau cu opțiunea Save din meniul File). b#%l!^+a?

Pe disc se va salva atât un fișier cu extensia .dmd, cât și un subdirector cu același nume cu cel al proiectului. Când se dorește copierea unui proiect de pe calculator, trebuie copiate ambele obiecte – atât fișierul *.dmd, cât și subdirectorul proiectului.

Deschiderea unui proiect se realizează după deschiderea aplicației Data Modeler (NU cu dublu click pe denumirea proiectului) prin secvența de opțiuni File à Open și selectarea fișierului *.dmd de pe suportul de stocare. Opțiunea CTRL+O nu are întotdeauna aceeași funcționalitate cu File à Open: (1) dacă este poziționat cursorul pe o diagramă, combinația de taste CTRL+O deschide proiecte, (2) dacă este poziționat cursorul în fereastra Browser, CTRL+O deschide fișiere text (este proiectat pentru scripturi).

Componentele principale ale ferestrei Data Modeler sunt: bara de meniuri, bara de instrumente – care conține opțiuni diferite corespunzătoare tipului de diagramă/model curent, zona de navigare, zona de afișare a mesajelor și suprafața de lucru.

Figura 80. Componentele ferestrei Data Modeler

1.4.4. Crearea diagramelor fluxurilor de date

În partea stângă este afișată zona de navigare (Browser) care prezintă, într-o structură ierarhică, diagramele proiectului. Crearea diagramelor fluxurilor de date se realizează prin accesarea componentei Process Model cu click dreapta pe semnul „+” și apoi click dreapta pe Data Flow Diagrams à New Data Flow Diagram.

Dacă este deja creată o diagramă și se dorește vizualizarea ei, se alege opțiunea Show după selectarea acesteia. Închiderea unei diagrame (nu a proiectului) nu echivalează cu pierderea ei, ci doar cu ascunderea temporară, lucru care se poate realiza și cu click dreapta pe numele diagramei din fereastra Browser și alegerea opțiunii Hide.

Obiectele specifice diagramelor fluxurilor de date se pot introduce utilizând următoarele pictograme din bara de instrumente afișată sub meniul principal al aplicației, prezentate în ordinea afișării lor:

Select – activarea modului de selecție când se dorește mutarea, redimensionarea sau ștergerea obiectelor;

New Process – introducerea sistemului și proceselor/subproceselor din cadrul diagramei de context și, respectiv, a diagramelor fluxurilor de date;

New External Agent – introducerea entităților externe (sursă/destinație sau agent extern);

New Flow – introducerea fluxurilor de date (după selectarea opțiunii se dă click pe obiectul sursă, se eliberează butonul mouse-ului și apoi click pe obiectul destinație);

New Note – crearea unei casete de observații în cadrul diagramei;

Delete – ștergerea unui obiect (operațiunea se poate realiza și cu tasta Delete după selectarea obiectului care va fi șters);

Zoom In – micșorarea dimensiunii de afișare a diagramei curente;

Zoom Out – mărirea dimensiunii de afișare a diagramei curente;

Fit Screen – afișarea diagramei proporțional cu spațiul de lucru în funcție de numărul de obiecte pe care le conține;

Default Size – revenirea la dimensiunea implicită a diagramei;

Find – căutarea unui obiect din cadrul diagramei.

Numai primele patru pictograme sunt specifice diagramelor fluxurilor de date, restul fiind disponibile pentru toate componentele aplicației

Figura 81. Opțiuni pentru crearea obiectelor specifice

1.4.4.1. Crearea unui proces

Crearea sistemului din cadrul diagramei de context sau a unui proces/subproces din diagramele fluxurilor de date se realizează prin selectarea opțiunii New Process prezentată anterior și apoi click pe suprafața de lucru. Pe ecran este afișată fereastra Process Properties în care poate fi creat dicționarul de date al obiectului curent.

În fereastra menționată poate fi introdus numele sistemului/procesului dar și alte proprietăți. După închiderea ei, reafișarea se poate realiza prin accesarea opțiunii Properties din meniul contextual al obiectului selectat. Încă de pe acum pot fi intuite diferențe dintre un astfel de instrument de tip C.A.S.E. și instrumente ce asigură doar o simplă desenare (de exemplu, Drawing-ul din Word): pentru fiecare obiect din diagramă se memorează o serie de proprietăți într-o mini bază de date, ce va servi mai târziu la functionalități de analiză a corectitudinii diagramelor, de generare a unor rapoarte și chiar de generare de cod.

În fereastra dicționarului de date, pentru un proces, se poate specifica, la proprietatea Type, dacă acel proces se descompune în subprocese – este de tip Composite sau nu (este de tip Primitive). După alegerea opțiunii Composite nu se poate reveni la opțiunea Primitive, decât prin ștergerea obiectului.

Figura 82. Stabilirea proprietăților sistemului, procesului sau subprocesului creat

Figura 83. Stabilirea tipului Composite pentru sistem sau pentru un proces care va descompus ăn subproces

Pentru procesele de tip Composite este afișat un triunghi în colțul din dreapta sus al obiectului, iar în structura arborescentă din stânga (în fereastra Browser), în dreptul procesului, apare semnul „+”, care, dacă este accesat se poate vizualiza diagrama în care va fi descompus procesul.

Alte proprietăți care pot fi specificate în dicționarul de date sunt:

Tipul prelucrării: manuală sau automată (interactivă sau pe loturi) de la opțiunea Mode;

Frecvența procesului ca unitate de timp și prioritatea lui pe o scară de evaluare cu următoarele valori: Scăzută, Medie, Ridicată sau Nespecificată (Frequency/Priority);

Momentul (ora) din fiecare zi când procesul respectiv va ajunge la intensitatea sa cea mai mare (Peak periods);

Informațiile asociate procesului (Information Structures);

Evenimentele (Event) asociate fiecărui proces;

Afișarea fluxurilor de intrare (Incoming Flows) și de ieșire (Outgoing b#%l!^+a?Flows) aferente procesului curent;

Documentele (Documents) prelucrate în cadrul procesului;

Schimbările solicitate pentru procesul respectiv (Changes Requests), inclusiv starea lor curentă (propuse, acceptate, implementate, în curs de implementare sau respinse).

Descrierea unui proces de prelucrare se poate realiza la proprietatea Comments.

Figura 84. Descrierea unui proces de prelucrare

Procesele sunt numerotate, implicit, în ordinea introducerii lor. Schimbarea numerelor asociate se poate realiza din fereastra cu proprietăți a diagramei afișată la click dreapta pe suprafața de lucru și selectarea opțiunii Properties, din meniul contextual. Opțiunea aferentă acestei operațiuni este Process Order/Number.

Opțiunea aferentă acestei operațiuni este Process Order/Number.

Următoarele proprietăți sunt disponibile și la restul componentelor din cadrul diagramelor fluxurilor de date:

Comments – inserarea unui comentariu de tip text pentru diagrama curentă;

Notes – observații suplimentare, ca de exemplu cele necesare implementării sau detalii privind diagrama;

Responsible Parties – departamentul, persoana etc. responsabile cu derularea proceselor/subproceselor din cadrul diagramei;

Documents – detalii despre documentele utilizate sau obținute din procesele/subprocesele componente ale diagramei curente.

Summary – afișează informații generale privind diagrama curentă.

Trecerea la următorul nivel de descompunere se realizează prin click dreapta pe obiectul corepunzător procesului ce va fi detaliat și alegerea opțiunii Go To Diagram din meniul contextual. Opțiunea este disponibilă numai pentru procesele de tip Composite.

Figura 85. Modificarea ordinii proceseloe

Figura 86. Descompunerea unui proces compozit

Operațiunea conduce la crearea unei noi diagrame de nivel inferior care preia ca nume denumirea procesului care a fost descompus.

În diagrama nouă vor fi preluate automat, din diagrama părinte, locurile de stocare și entitățile externe aflate în legătură cu procesul descompus. Fluxurile de date trebuie create din nou precizându-se fluxul corespunzător din aceeași diagramă părinte.

1.4.4.2. Crearea unei entități externe

Crearea unei entități externe se realizează prin click pe pictograma New External Agent () din bara de instrumente și desenarea ei pe spațiul alb al diagramei. Din fereastra dicționarului de date poate fi selectat tipul entității externe (componentă organizațională, sistem informatic, rol/funcție sau alt tip).

În Oracle Data Modeler, un obiect (inclusiv o entitate externă) poate fi introdus într-o diagramă o singură dată (nu pot exista două obiecte de același tip cu aceeași denumire).

Descrierea entității externe care furnizează și/sau primește informații din sistemul supus analizei se poate realiza la proprietatea Comments, iar observațiile la proprietatea Notes pentru a fi luate în considerare la proiectarea noului sistem.

Figura 87. Selectarea tipului de entitate externă

Figura 88. Descrierea unei entități externe

În fereastra External Agents Properties sunt disponibile opțiuni pentru vizualizarea fluxurilor de date pe care entitatea externă le trimite (Incoming Flow) și le primește de la sistemul analizat (Outgoing Flows).

Figura 89. Precizarea altor observații în legătură cu entiatea externă descrisă

1.4.4.3. Crearea unui flux de date

Crearea unui flux de date se realizează prin selectarea pictogramei New Flow, urmată de click pe obiectul sursă și apoi pe cel destinație. Denumirile fluxurilor nu sunt afișate implicit pe 10 săgețile aferente acestora. Opțiunea de afișare este disponibilă din meniul contextual al diagramei: Show Label. Dacă la crearea unui flux nu se deschide fereastra dicționarului de date pentru a modifica numele implicit al acestuia, se dă click dreapta pe linia fluxului (NU pe numele lui) și se alege opțiunea Properties. Dacă sunt desenate două sau mai multe fluxuri între două obiecte și în diagramă este afișată o singură linie, înseamnă că fluxurile sunt suprapuse și trebuie mutate.

Figura 90. Rearanjarea automată a fluxurilor de date

Se recomandă desenarea fluxurilor după ce au fost introduse toate celelalte obiecte și au fost încadrate în poziția finală. Când este mutat un obiect, fluxurile își schimbă poziția automat, suprapunându-se. De aceea este necesară rearanjarea fluxurilor pentru realizarea unei diagrame ușor de urmărit (inteligibile). Rearanjarea automată a fluxurilor se poate obține și cu opțiunea Straighten Lines din meniul contextual, prin click dreapta pe spațiul alb al diagramei.

Mecanismul de descompunere a fluxurilor în subfluxuri este generalizat în Oracle Data Modeler, ca și cum toate fluxurile s-ar împăți în subfluxuri. La introducerea unui flux într-o diagramă (de exemplu, diagrama fluxurilor de date de nivel 0), în condițiile în care același flux a fost introdus într-o diagramă superioară (de exemplu, diagrama de context), nu există posibilitatea să fie ales din dicționarul de date fluxul și să fie introdus în diagrama de nivel inferior. În astfel de situații, se introduce un nou flux, se scrie eventual același nume și se alege, obligatoriu, în dicționarul de date, de la Parent Flow, fluxul părinte.

După selectarea fluxului părinte și închiderea ferestrei, dacă se deschide din nou fereastra de proprietăți a acelui flux, la opțiunea Parent Flow va fi afișat tot primul flux din listă, în ordine alfabetică. Legătura ierarhică stabilită se păstrează însă, chiar dacă nu vizual. Se poate verifica existența acestei dependențe astfel: ștergerea fluxului din diagrama-părinte va conduce și la ștergerea automată din diagrama-copil.

Figura 91. Selectarea fluxului părinte

Pentru descrierea structurii fluxurilor în cadrul diagramelor fluxurilor de date în semestrul I (analiză) se vor folosi proprietățile Comments si/sau Notes. Operațiunea se va realiza detaliat în semestrul următor (proiectare), la diagrama entitate-relație.

Figura 92. Descrierea unui flux de date prin componente

Figura 93. Descrierea unui flux de date prin raportarea la locul de stocare pe care îl actualizează

1.4.4.4. Crearea unui loc de stocare

Începând cu diagrama fluxurilor de date de nivel 0, pot fi introduse locurile de stocare, folosind a patra pictogramă din bara de instrumente – New Information Store. În dicționarul de date poate fi precizat tipul locului de stocare: RDBMS (bază de date), File (fișier), Object (obiect) sau Temporary (informații cu caracter temporar – când sunt disponibile datele respective).

Figura 94. Selectarea tipului locului de stocare

Similar proprietăților asociate fluxurilor, pentru locurile de stocare se vor descrie structurile corespunzătoare la proprietățile Comments sau Notes, urmând ca în semestrul următor (la proiectare) să se detalieze descrierea la diagrama entitate-relație.

Figura 95. Structura locului de stocare Materiale

1.4.5. Analiza corectitudinii diagramelor

După crearea diagramelor se poate verifica respectarea regulilor specifice Data Modeler cu opțiunea Tools Design Rules Design Rules sau direct cu combinația de taste SHIFT+ALT+R. Din fereastra afișată trebuie selectată, din secțiunea din stânga, o regulă sau un grup de reguli și se apasă pe butonul Apply Selected. În partea din dreapta a ferestrei va fi afișată listă cu atenționări (Warning) și/sau erori (Error), care trebuie corectate.

Figura 96. Atenționări și erori ale diagramelor

Soluționarea erorilor și atenționărilor se poate realiza prin dublu-click pe descrierea lor în fereastra Design Rules, prezentată în figura anterioară. Acțiunea deschide dicționarul de date al obiectului pentru care a fost emisă atenționarea/eroarea și unde poate fi realizată corecția. b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a? b#%l!^+a?

CAPITOLUL AL II-LEA

DEZVOLTAREA APLICAȚIEI

2.1. Business Use Case

Pentru a exemplifica utilitatea modelului BPMN vom descrie în cele ce urmează modul în care compania cercetată și-a reproiectat cu succes procesul de management al service-ului, obținând performanțe notabile.

2.1.1. Motivație

Utilizatorii au fost puși în situația de a lucra cu o interfață și un mediu de lucru nou, cu procese noi – pentru îndeplinirea unor sarcini pe care obișnuiau să le facă într-un anumit mod și cu o perioadă de training, ce a fost scurtată de la zece săptămâni la patru. Perioada de trening limitată a fost insuficientă pentru ca utilizatorii să-și dezvolte aptitudinile necesare utilizării sistemului.

2.1.2. Principalele activități ale unei agenții de publicitate

Descrierea activităților principale ale agentiei are în vedere stabilirea obiectivelor sistemului informatic în raport cu particularitățile activității unei agentii de publicitate, cerințele conducerii acesteia și prioritățile stabilite prin legislația în materie.

Clientii care constituie piata tinta a agentiei sunt clientii care au nevoie de servicii de relativ ieftine si nu solicita servicii extra.

2.1.2.1. Activitatea de urmărire a agenției

Se refera la materializara tranzactiilor care au loc in cadrul agentiei si asigurarea colaborarilor la nivelul gestiunilor ofertelor si cererilor, al gestiunilor contractelor si al editarilor de rapoarte si documentatii.

2.1.2.2. Activitatea de gestiune a utilizatorilor

Grupurile de utilizatori ai sistemului informatic sunt organizate dupa urmatoare criterii: personalul agentiei; cei cu drepturi de acces preferential (agentii imobiliari si adminstratorul de sistem); după durata existentei (grupuri temporare, creeate la apariția unor drepturi de care pot beneficia numai anumite persoane, și permanente).

2.1.2.3. Activitatea de gestionare a cererilor

Activitatea de constituire și actualizare a ofertelor si cererilor agentiei se desfașoară între clientul agentiei persoană fizică sau juridică și agentul publicitar. Această activitate este formată din următoarele operații complexe: solicitarea unei oferte de către client; selectare oferta; definitivarea contractului; procesarea facturii si efectuarea platii

În scopul derulării acestor operații complexe se desfășoară următoarele fluxuri informaționale:

Activitatea 1: Clientul isi expune dorinta agentului publicitar, asta contine datele generale pentru a identifica mai usor agentul oferta.

Activitatea 2 : Clientul acceseaza baza de date adaugand cererea si in cazul in care este disponibil ceva apropiat de dorinta clientului se selecteaza si i se prezinta aceasta.

Activitatea 3: In cazul in care se finalizeaza actiunea cu un contract, se emite în final factura către client.

2.1.2.4. Activitatea de gestiune a contractelor

Activitatea 1: Agentul publicitar poate adauga un contract, poate realiza modificari si are drept de anulare a acestui, el mai poate face cautarii in baza de date.

Activitatea 2: A doua activitate surprinde situatia in care deja contractul este finalizat, se realizeaza vizualizare a si tiparirea acestuia.

2.1.3. Definirea obiectivelor sistemului informatic al unei agenții de publicitate

Obiectivele sistemului informatic reprezintă scopuri imediate și de perspectivă privind perfecționarea activității în general, precum și conducerea activității în vederea ridicării nivelului de informare operativă și previzională a structurilor organizatorice si de conducere.

Obiectivele sistemului informatic presupun abordarea și rezolvarea informatică a unor probleme cu caracter sintetic, într-o manieră sistematică. Aceste obiective au caracteristici generale și specifice ce depind de cadrul legislativ-normativ, dotarea cu tehnică de calcul, cu masini pentru deplasare și cerințele dezvoltării economice, imediate și de perspectivă, ale agentiei respective. Programul informatic este complex si propriu si inglobeaza atat activitatile realizate de agent cat si de administratorul de sistem. In acest fel faciliteaza folosirea programului prin controlul asupra drepturilor și obligațiilor utilizatorilor.

2.1.4. Modelarea sistemului informatic al unei agenții de publicitate

Pentru modelarea sistemelor informatice , vom folosi Unified Modeling Language?(UML), un limbaj vizual de modelare, acesta nefiind încă un limbaj vizual de programare, deoarece nu dispune de întreg sprijinul semantic și vizual pentru a înlocui limbajele de programare.

Limbajul este destinat vizualizării, specificării, construirii și documentării sistemelor de aplicații, dar are limitări în ceea ce privește generarea codului. UML reunește cele mai bune tehnici și practici din domeniul ingineriei programării, care și-au dovedit eficiența în construirea sistemelor complexe.

Pentru descrierea unui sistem sunt necesare un număr de view-uri, fiecare reprezentând o proiecție a descrierii întregului sistem și care reflectă un anumit aspect al acestuia. Fiecare view este descris folosind un număr de diagrame care conțin informații relative la un anumit aspect particular al sistemului. Aceste view-uri se completează reciproc, deci este posibil ca o anumită diagramă să facă parte din mai multe view-uri.

2.1.5. Nivelul cazurilor de utilizare

Acest view surprinde funcționalitatea sistemului, așa cum este ea percepută de actorii externi care interacționează cu sistemul, de exemplu utilizatorii acestuia sau alte sisteme. În componența lui intră diagrame ale cazurilor de utilizare și ocazional, diagrame de activitate.

Cei interesați de acest view sunt deopotrivă clienții, designerii, dezvoltatorii dar și cei care vor realiza testarea și validarea sistemului.

2.1.5.1. Diagrama principală a cazurilor de utilizare

Diagrama ofera o imagine de ansamblu asupra principalelor activitati desfasurate in cadrul unei institutii bancare. Actorul a fost intitulat agent publicitar si este cel care beneficiaza si in acelasi timp efectueaza toate activitatile prezente in diagrama. Fiecare dintre actiunile reprezentate in diagrama generala a cazurilor de utilizare vor fi reluate si prezentate pe larg, punandu-se in evidenta toate activitatile care le compun.

Figura 97. Diagrama cazului de utilizare principal

Actorul – agent publicitar – se ocupa de primirea clientilor, cautarea in baze de date si intocmirea contractelor. În aceasta situatie interactiunea actorului cu sistemul consta în consultarea disponibilului prin verificarea optiunilor mentionate de client. Astfel, actorul ofera un raspuns promt, fara a pierde timpul cu notarea informatiilor si cu verificarile.

Cazurile initiale: acceptare/respingere cerere si documentare privind detaliil rezervarii, devin acum un singur caz.

Practic, singura responsabilitate a personalului este de a furniza aplicatiei datele rezervarii. Nu este necesara completarea vreunui formular ci doar cautarea datelor. Actualizarea disponibilului este automata.

2.1.5.2. Diagrame detaliate ale cazurilor de utilizare

Adaugarea unei oferte sau a unei cereri se face cu ajutorul calculatorului, in diverse situatii poate interveni necesitatea modificarii datelor unui contract, in caz de neplata de exemplu se anuleaza contractul. Nu se completeaza nici un formular de anulare a contractului acest lucru facandu-se automat, agentul (actorul) face modificarea respectiva sau anulare, iar disponibilul agentiei se actualizeaza automat.

Figura 98. Diagrama de gestiune a utilizatorilor

Figura 99. Diagrama de gestiune a ofertelor și cererilor

Contractul este documentul care contine toata informatia relevanta despre un client si imobil. Toate aceste informatii mai sunt introduse si in program de gestiune, astfel in orice moment daca intereseaza se poate face o cautare rapida. Astfel asa apare si clasa client. Formular_ înregistrare are mai putine atribute, deoarece prin crearea clasei client anumite informatii nu mai sunt dublate. De asemenea, a fost introdusao clasa Utilizator, clasa utilizata pentru accesul la aplicatie, respectiv pentru monitorizarea accesului la aplicatie.

Figura 100. Diagrama de evidență a contractelor

2.2. Specificații, arhitectură și funcționalități

În cadrul proiectului se aplică metoda detecției și diagnosticării defectelor bazată pe estimarea parametrilor.

2.2.1. Modelarea procesului de afaceri

În vederea aprovizionării cu produse publicitare de la agentiile de portofoliu, societatea încheie un contract cu un furnizor (activitatea Încheiere contract) Contractul este reprezentat printr-un obiect dată asociat fluxului de mesaj dintre cei doi participani la proces: furnizorul si societatea.

O primă condiție pentru ca aprovizionarea să poată fi realizată este legată de termenul de valabilitate a contractului. În cadrul modelului, punctul de ramnificație pentru alternativele care vor fi urmate în funcție de îndeplinirea sau neîndeplinirea acestei condiții este reprezentat print-un punct de decizie bazat exclusiv pe evenimente.

În cazul în care termenul de valabilitate a expirat, contractul încetează. Această situație este reprezentată prin activitatea Încheiere contract, activitate care generează obiectul dată Contract închis.

În situația în care contractul se află în termenul de valabilitate (alternativa implicită din cadrul modelului, marcată prin caracterul „\”), se verifică o a doua condiie, legată de valoarea mărfurilor livrate, valoare care nu trebuie să depăsească valoarea contractată a mărfurilor: dacă valoarea mărfurilor livrate depăseste valoarea contractată, contractul încetează; dacă valoarea mărfurilor livrate <= valoarea contractată, se realizează aprovizionarea cu mărfuri (sub-procesul Aprovizionare mărfuri).

Pe baza unui contract societatea se poate aproviziona de mai multe ori cu mărfuri de la furnizor, motiv pentru care sub-procesul Aprovizionare mărfuri este repetitiv, aspect marca prin poziționarea simbolului în partea inferioară a sub-procesului.

După ce primeste mărfurile si factura de la furnizor, societatea plăteste factura. Plata facturii implică desfăsurarea mai multor activităi, fiind reprezentată în model prin subprocesul Plată factură care poate fi detaliat în funcie modalitatea concretă prin care se realizează plata. Pentru ca plata să se realizeze este necesară atât primirea mărfurilor, cât si primirea facturii. Acest aspect este reprezentat printr-un punct de decizie paralel prin care sunt compuse cele două fluxuri aferente activitășilor Primire factură si Primire mărfuri.

Procesul de aprovizionare cu mărfuri de la furnizor se încheie atunci când au fost s-a realizat aprovizionarea cu mărfuri la nivelul valorii contractate sau atunci când contractul încetează.

Figura 101. Modelarea procesului de afaceri

2.2.2. Simularea procesului

Diagramele au fost concepute pe înțelesul conduceri, suferind un proces de reanalizare și detaliere, astfel încât, să îndeplinească atât necesarul de informații, cât și dialectul limbajului cerut de instrumentul de simulare.

2.2.2.1. Descrierea succintă a activităților întreprinse

Modelul de notație ales pentru reproiectare este modelul BPMN, deoarece organizația dorea să folosească diagramele pentru o eventuală implementare într-un sistem de management al proceselor de afaceri, ce va utiliza ca limbaj de notație BPMN-ul. Pentru modelarea diagramelor a fost aleasă aplicația Microsoft Visio.

Pe lângă acest motiv principal, argumentele care au reprezentat baza deciziei, au fost: ușurința înțelegerii limbajului de către utilizatorii non-specialiști, utilizarea din ce în ce mai răspândită a limbajului – modelul devenind un instrument de comunicare excelent în colaborarea cu partenerii de afaceri și expresivitatea notațiilor.

Reproiectarea procesul de management al service-ului a fost împărțită în trei etape: realizarea diagramei procesului actual, realizarea diagramei procesului reproiectat și simularea costului și a beneficiilor reproiectării.

2.2.2.2. Realizarea diagramei procesului actual

Având în vedere faptul că în cadrul acestei companii nu a fost niciodată realizată o documentație de analiză sau de descriere a proceselor, analiza a început cu o etapă de colectare a datelor despre: intrările, ieșirile și activitățile desfășurate.

După ce documentația pentru interviuri a fost finalizată, timp de șase săptămâni diagrama procesului actual a fost concepută și rafinată pe parcursul a 12 iterații. În timpul iterațiilor, procesul a fost rafinat de o manieră top-down: s-a identificat fiecare proces, s-a pus

În corelație cu restul proceselor, s-a detaliat fiecare activitate și s-au evidențiat greșelile de flux.

Principala problemă întâmpinată de analiști a fost identificarea fluxului corect. Având în vedere că politicile de coordonare a activităților au fost foarte vag definite, analiștii s-au confruntat cu situația în care o anumită activitate se desfășura în funcție de interpretarea angajatului responsabil de sarcina respectivă.

În această etapă, autorii au remarcat flexibilitatea limbajului BPMN la descrierea unor situații nemaiîntâlnite, precum: posibilitatea vizualizării diagramei la diferite niveluri de abstractizare, în funcție de necesitățile de înțelegere ale utilizatorului și buna cooperare cu angajații, determinată de înțelegerea diagramei procesului.

2.2.2.3. Simularea costului și a beneficiilor reproiectării

Simularea a evidențiat faptul că modelul reproiectat ar elibera resurse temporale, resurse ce pot fi transformate în extra capacitate și, în cele din urmă, în profit.

În urma utilizării modelului BPMN în cazul studiat, s-au desprins următoarele concluzii și observații: modelul poate exprima orice tip de proces, activitate sau sistem din lumea reală, prin faptul că dispune de un set de notații și extra notații foarte bine documentate; modelul reprezintă un standard în domeniu, fiind un bun instrument de comunicare între companiile aflate pe același lanț de distribuție; modelul poate fi utilizat cu succes în reproiectarea unui proces sau sistem, mai ales datorită faptului că, pe lângă calitățile descriptive, dispune de un limbaj expresiv, ce facilitează comunicarea cu angajații pe tema reproiectării procesului; modelul a fost acceptat relativ ușor de către angajații organizației. Diagrama permite vizualizarea pe diferite niveluri de abstractizare – utilizatorii simpli pot vizualiza diagrama conform nivelul lor de înțelegere.

Pentru o modelare cât mai precisă în folosirea modelului pentru simularea efectelor reproiectării, este indicată folosirea unui număr restrâns de notații.

2.2.3. Proiectarea

Diagramele de activitate permit o mai buna intelegere a operatiilor, in special a celor foarte complexe. Prin intermediul acestor diagrame sunt evidentiate detaliile din cadrul unor operatii ala claselor.

Aceste digrame sunt reprezentate sub forma unui tip de stare care specifica activitatea unei anumite clase. Diferenta consta ca un grafic de stare reprezinta intregul obiect, in timp ce o diagrama de activitate reprezinta in mod tipic doar o operatie in cadrul unui obiect.

2.2.3.1. Diagrame de activități

Figura 102. Diagrama de activitate

Figura 103. Rafinarea diagramei de activitate

2.2.3.2. Diagrama claselor

Figura 104. Diagrama de clase

2.2.3.3. Rafinarea diagramei de clase

Diagrama obtinuta anterior poate fi rafinata prin utilizarea relatiilor de generalizare/ specializare. Acestea sunt mecanisme care permit partajarea caracteristicilor commune intre calse pastrand totodata diferentele dintre acestea.

Diagrama de stare a clasei Contract evidentiaza starile prin care trece un contract de la incheierea lui si pana la faza de tiparire. Odata realizat un contract el poate fi semnat de ambele parti sau poate fi anulat, putand ajunge astfel la una din starile contract incheiat, contract sters.

In cazul in care contractul dintre agentie si client este semnat atunci se reciteste si se tipareste.

Toate aceste actiuni sunt reprezentate in diagrma de stare a clasei contract.

Figura 105. Rafinarea diagramei de clase

2.2.4. Implementarea

Sistemul proiectat pentru gestionarea unei agentii imobiliare va fi implementat in Visual C++ utilizand facilitatea programului RationalRose de a genera o parte a codului.

Pentru exemplificare se va genera cod pentru clasa AGENTI, respectiv CLIENTI.

// Copyright (C) 1991 – 1999 Rational Software Corporation

#if defined (_MSC_VER) && (_MSC_VER >= 1000)

#pragma once

#endif

#ifndef _INC_AGENTI_45A9AA43003D_INCLUDED

#define _INC_AGENTI_45A9AA43003D_INCLUDED

//##ModelId=45A9AA43003D

class Agenti

{

public:

//##ModelId=45A9AD1D000E

logare();

//##ModelId=45A9AD27001E

validare();

};

#endif /* _INC_AGENTI_45A9AA43003D_INCLUDED */

// Copyright (C) 1991 – 1999 Rational Software Corporation

#if defined (_MSC_VER) && (_MSC_VER >= 1000)

#pragma once

#endif

#ifndef _INC_CLIENTI_45A9A82802BE_INCLUDED

#define _INC_CLIENTI_45A9A82802BE_INCLUDED

//##ModelId=45A9A82802BE

class Clienti

{

public:

//##ModelId=45A9A8A00108

creare_client();

//##ModelId=45A9A8A900F9

verificare_client();

//##ModelId=45A9A8C40118

modificare_date();

};

#endif /* _INC_CLIENTI_45A9A82802BE_INCLUDED */

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

// Copyright (C) 1991 – 1999 Rational Software Corporation

#include "stdafx.h"

#include "Clienti.h"

//##ModelId=45A9A8A00108

Clienti::creare_client()

{

}

//##ModelId=45A9A8A900F9

Clienti::verificare_client()

{

}

//##ModelId=45A9A8C40118

Clienti::modificare_date()

{

}

// Copyright (C) 1991 – 1999 Rational Software Corporation

#include "stdafx.h"

#include "Agenti.h"

//##ModelId=45A9AD1D000E b#%l!^+a?

Agenti::logare()

{

}

//##ModelId=45A9AD27001E

Agenti::validare()

{

}

********************************************************************.

2.2.5. Desfășurarea

Diagrama de desfasurare modeleaza procesoare si echipamente fizice, securitatea si componentele care sunt plasate pe procesoarele fizice.

Elementele componente sunt:

Calculator – folosit pentru rularea aplicatiei;

Server – pentru stocarea bazei de date;

Periferice: imprimanta si scanerul.

2.2.6. Realizarea diagramei procesului reproiectat

Pornind de la diagrama procesului actual, de la problemele evidențiate și urmărind îmbunătățirea eficacității și a eficienței, s-a demarat etapa de reproiectare. În acest caz, eficacitatea presupune îndeplinirea funcțiilor procesului de management al service-ului, iar eficiența implică realizarea activităților cu resurse cât mai puține.

S-a constatat, astfel, că 6 din cele 12 funcții ale procesului de management al service-ului trasate de conducere, nu erau îndeplinite în totalitate sau nu în mod profesionist. De asemenea, resursa timp nu era utilizată eficient, cauza fiind lipsa de comunicare și managementul defectuos al comenzilor și a atribuirii sarcinilor către mecanici, calificați pentru acea operațiune. Din dorința de a face economie participanților la proces le-au fost atribuite prea multe sarcini, fapt ce a condus la scăderea eficienței sarcinilor de bază.

Reproiectarea procesului de management al service-ului a constat în redefinirea sarcinilor, a fluxului de activități și a procesului de alocare a sarcinilor.

În această etapă autorii au fost surprinși de faptul că angajații, deși lucrând de mult timp în companie și având o anumită cultură cu privirea la modul în care ar trebui să se desfășoare lucrurile, au început să citească diagrama relativ ușor și chiar să propună diferite idei cu privire la îmbunătățirea activităților efectuate de ei.

2.3. Raportul de test

Spre deosebire de view-ul cazurilor de utilizare, un view logic descrie atât structura internă a sistemului (clase, obiecte și relații) cât și colaborările care apar când obiectele trimit unul altuia mesaje pentru a realiza funcționalitatea dorită. Structura statică este descrisă în diagrame de clasă, în timp ce pentru modelarea dinamicii sistemului se folosesc diagramele de stare, de secvență, de colaborare sau de activitate.

Prin urmare, cei care sunt interesați de acest tip de vizualizare a sistemului sunt designerii și dezvoltatorii.

Diagrama de clase este mai importanta diagrama in cadrul analizei si proiectarii orientate obiect. Scopul ei este acela de a structura natura statica a claselor. Ea contine clasele si legaturile dintre clase.

Clasele utilizate in proiectarea sistemului informatic sunt:

TIP_IMOBIL: cuprinde urmatoarele atribute: tip_imob, pret, descriere si operatii: initializare.

IMOBIL: cuprinde urmatoarele atribute: tip_imob, marca, stare, mentiuni si operatii: initilaizare, raport_grup, selectare_imobil, modificare_stare.

AGENTI: cuprinde urmatoarele atribute: marca, cont, parola, nume, functie, cnp, data_nasterii, prenume, localitate, adresa, telefon, e_mail, studii, pregatire, tip_contract, vechime si operatii: logare si validare.

CLIENTI: cuprinde urmatoarele atribute: marca, nume, cnp, data_nasterii, prenume, localitate, adresa, telefon, e_mail, tip_contract si operatii: creare_client, verificare_client, modificare_client.

FORMULAR_INREGISTRARE: cuprinde urmatoarele atribute: marca, nr_inreg, data_s si operatii: creare inregistrare si consulatare.

UTILIZATOR: cuprinde urmatoarele atribute: cont, parola, tip_cont, stare si operatii:creare_cont, creare_parola si login.

CONTRACT: cuprinde urmatoarele atribute: marca, data_s, tip_imobil, avans, mod_plata si operatii: completare_contract, modificare_contract, stergere_contract, generare_lista.

FACTURA: cuprinde urmatoarele atribute: nr_factura, nr_inreg si operatii: creare_factura, vizualizare_factura, tiparire.

DISPONIBIL: cuprinde urmatoarele atribute: date, tip_imob si operatii: initializare, consultare, incrementare, decrementare.

2.3.1. Diagrama de clase fără atribute și operații

Figura 106. Diagrama de clase fără atribute și operații

Intre clasele utilizate in proiectarea sistemului informatic au fost stabilite legaturi. Sensul sagetilor evidentiaza parcursul informatiilor intre clasele sistemului.

2.3.2. Diagrama de stare

Diagramele de stare realizate identifica evenimentele care fac tranzitia unui obiect dintr-o stare in alta. Aceste diagrame descriu toate operatiile si atributele unei clase in timpul unui eveniment. Diagrama identifica stimulii care declanseaza actiunea. Ea include numele starii, oricarei variabile, in timp ce obiectul este in functiune, si evenimentul care declanseaza tranzitia la o noua stare.

Figura 107. Diagrama de stare

2.3.3. Diagrama de secvență

Diagramele de secventa dezvolta in mod natural scenariile cazurilor de utilizare. Acestea transforma evenimentele identificate in scenariile cazurilor de utiliare intr-o reprezentare grafica a utilizarilor sistemului de catre un actor. Fiecare eveniment are ca rezultat un mesaj trimis unui obiect cu perspective ca acel obiect va realize o operatie.

Diagrama de secventa descrie cronologic interactiunea obiectelor, identificand mesajele schimbate intre obiecte ca raspuns la un eveniment, impreuna cu secventa mesajelor. Este o vizualizare a intercomunicarii claselor pentru un anumit scenariu al cazurilor de utilizare.

Figura 108. Diagrama de secvență pentru logare

Se refera la cazul de utilizare Logare. Agentul si administratorul trebuie sa se logeze înainte de a putea face orice consultare sau actualizare. Astfel se poate stii cine a accesat aplicatia, si în caz de erori se cunoaste din cauza cui a survenit eroarea. Se realizeaza validarea numelui de utilizator si a parolei. În functie de raspuns se accepta sau nu accesul la aplicatie.

Diagrama de secvență pentru stabilire disponibil se refera la cazul de utilizare particular Stabilire disponibil. În momentul în care se ofera un raspuns pozitiv clientului, se trece la introducerea datelor in program. Primul pas consta în verificarea existentei ofertelor care sa se plieze pe ceea ce doreste clientul.

Diagrama de secvență pentru încheiere contract se pliază pe cazul de utilizare particular Incheiere contract. În momentul în care se ofera un raspuns pozitiv clientului, se trece la completarea contractului. Primul pas consta în verificarea existentei clientului. Daca acesta nu exista, datele sale vor fi salvate. Se purcede la inregistrarea contractului propriu-zis. La momentul salvarii automat va fi decremetat disponibilul agentiei.

Figura 109. Diagrama de secvență pentru încheiere contract

Figura 110. Diagrama de secvență pentru modificare contract

Diagrama de secvență pentru ștergere contract se referă la cazul de utilizare Stergere contract. În momentul anularii unui contract, disponibilul este actualizat automat, pentru inchirierea sau vanzarea care se dorise.

Figura 111. Diagrama de secvență pentru ștergere contract

Figura 112. Diagrama de secvență pentru modificare date client

Diagrama de secvență pentru Înregistrare client se refera la cazul de utilizare particular Înregistrare client. Agentul publicitar verifica daca datele clientului apar in baza de date. Daca nu a fost atunci se înregistreaza datele clientului si dorinte acestuia.

Figura 113. Diagrama de secvență pentru Înregistrare client

Figura 114. Diagrama de secvență pentru Emitere Factură

2.3.4. Diagrama de colaborare

Diagramele de colaborare se obtin cu usurinta din diagramele de secventa. Ele descriu o examinare nonsecventiala a modului in care interactioneaza obiectul. Aceste diagrame suporta multiple modalitati de modelare a obiectului.

Intersectarea diagramelor de secventa cu diagramele de colaborare duce la obtinerea unor operatiuni intensificate si descoperirea unor atribute aditionale.

Ambele diagrame furnizeaza puncte de vedere diferite ale aceleiasi informatii. Ambele arata implementarea unui scenariu al cazului de utilizare.

Figura 115. Diagrama de colaborare asociată

2.3.5. Diagrama BPMN a procesului de solicitare

Figura 116. Diagrama BPMN a procesului de solicitare

2.4. Concluzii

Conform informațiilor prezentate mai sus, BPMN mai are o cale lungă de parcurs. Se speră ca pe viitor să se observe o interacțiune mai mare a BPMN cu utilizatorii de bază, cu scopul de a se asigura faptul că următoarele versiuni vor oferi un suport real pentru utilizatorii finali în modelarea proceselor. Un alt punct extrem de important ce va trebui atins pe viitor, constă în integrarea cu BPEL, pentru a oferi un suport real în dezvoltarea aplicațiilor, prin generarea automată a codului. Odată ce acest punct va fi atins, BPMN va deveni un concurent redutabil pentru UML (Unified Modeling Language), datorită faptului că este mai ușor de înțeles și de folosit de către nespecialiști. Într-o lume aflată într-o permanentă schimbare, în care tehnologia de ieri e deja istorie, în care tendința este de a se apela la servicii ce pot fi accesate de oricine, oriunde, oricând și de pe orice fel de platformă, va reprezenta oare BPMN standardul viitorului în ceea ce privește modelarea proceselor de afaceri? Un lucru este cert, tehnologiile câștigătoare ale viitorului vor fi cele capabile să se adapteze cel mai rapid la schimbările pieței, fapt, ce va necesita o flexibilitate crescută la nivelul întregii afaceri. Iar această flexibilitate nu va putea fi atinsă decât pe baza unor procese bine modelate ale afacerii.

CONCLUZII ȘI CONTRIBUȚII PERSONALE

O notație standard de modelare utilizată de către furnizorii de modelare, analiștii în afaceri și comunitatea IT este fundamentală în gestionarea proceselor de afaceri și în alinierea lor cu arhitecturile tehnologiei informației (IT).

Executarea proceselor de afaceri este o paradigmă alternativă de dezvoltare la tehnicile tradiționale de dezvoltare. Dezvoltarea în mod tradițional nu va dispărea, de fapt este fundamentală în susținerea implementării de business process management servers (BPMS’s).

Modelarea folosind BPMN este esențială pentru înțelegerea și comunicarea proceselor de afaceri în interiorul organizației. BPMN furnizează o creștere puternică pentru celelalte tehnici de modelare cum ar fi modelarea de date, design de aplicații și sisteme cu UML, XML și arhitectura rețelelor. Aceste tehnici de modelare îi permit unei firme să înțeleagă și să definească arhitectura de afacere, ceea ce îi permite să reacționeze rapid la schimbări, într-un mod mai puțin riscant.

Simplificarea și demistificarea serviciilor web și a modului lor de a fi folosite în lumea de afaceri este cheia pentru a ne ajuta clienții să aibă succes pe piață pe care concurează.

În concluzie putem afirma cǎ soluțiile Business Process Management (BPM) sunt deja niște soluții dovedite care asigurǎ creșterea performanțelor, a productivității și reducerea timpului de prelucrare prin automatizarea și optimizarea proceselor complexe gestionând fluxul activitǎții în toată organizația. Având standarde flexibile, personalizate și bazate pe o arie mare de aplicabilitate, soluțiile BPM pot fi puse în practică rapid și se conformeazǎ ușor nevoilor beneficiarilor creând o infrastructurǎ care conecteazǎ utilizatorii și aplicațiile.

Soluțiile BPM ajutǎ la transformarea performanței afacerilor într-un avantaj competitiv prin:

Mǎrirea agilitǎții și accelerarea rǎspunsurilor în afaceri și evenimente tranzacționale;

Optimizarea eficienței operaționale și utilizarea resurselor;

Impunerea standardelor organizaționale și îmbunǎtǎțirea stabilitǎții proceselor;

Scǎderea timpului de lucru în timp ce faciliteazǎ luarea unor decizii optime;

Reducerea dificultătii de integrare a oamenilor, proceselor și sistemelor deja existente.

BIBLIOGRAFIE

Ambler, S. W. (2007). Agile Modeling and the Rational Unified Process (RUP). John Wiley & Sons.

Andone I., M. Vergara, V. Păvăloaia (2009). Modelarea afacerii întreprinderii – procese – reguli. Iași: Ed. Tipo Moldova.

Anupindi, R., S. Chopra, S. Deshmukh, J. Mieghem, E. Zemel (1999). Managing Business Process Flows. Englewood Cliffs: Prentice Hall.

Appleby, R. C. (1993). Modern Business Administration. Londra: Ed. Pitman Publishing.

Ariton, V. (2004). Fundamente ale tehnologiei informației și comunicațiilor. București: Ed. Didactică și Pedagogică.

Ariton, V. (2007). Sisteme informatice cu baze de date. Ed. Europlus.

Basu, A., R. W. Blanning (2003). „Synthesis and Decomposition of Processes in Organizations”, în Information Systems Research.

Briol, Patrice (2008). BPMN, The Business Process Modeling Notation Pocket Handbook. Ed. Inginerie des Pocessus.

Casati, F., S. Ceri, B. Pernici, G. Pozzi (2005). Conceptual Modeling of Workflows.

Chang, J. F. (2006). Business Process Management Systems – Strategy and Implementation. New York: Auerbach Publications.

Chekowaym C., K. Kirk, D. Sillivan (1972). Simulink User’s Guide. Mathworks Inc.

Cozgarea, G. (2010). Metodologii orientate pe obiecte utilizate in proiectarea sistemelor informatice. Ediția a II-a. Ed. Infomega. Disponibil la adresa web: http://www.omg.org/spec/BPMN/2.0.

Crăciunoiu, V. (1973). Elemente de execuție. București: Ed. Tehnică.

Curiac, D., I. Filip (1995). Sisteme de conducere a proceselor continue. Timișoara: Ed. Mirton.

Dumitrache, I. et al. (1993). Automatizări electronice. București: Ed. Didactică și Pedagogică.

Florescu, V. (2002). Grupul BDASEIG. Baze de date. Fundamente teoretice și practice. Ed. InfoMega.

Fotache, D., L. Hurbean (2004). Soluții informatice integrate pentru gestiunea afacerilor. București: Ed. Economică.

Fu-Ren, Lin, Meng-Chyn Yang, Yu-Hua Pai (2002). „A Generic Structure for Business Process Modeling”, în Business Process Management Journal, 8(1), pp. 19-41.

Goldratt, E. M. (1997). Critical Chain. Great Barrington. MA: The North River Press Publishing Corp.

Gruden, A., P. Strannegard (2003). „Business Process Integration: The Next Wave”, în Business Integration Journal. Ianuarie. Disponibil la adresa web: http://www.bijonline.com.

Harrington, H. J., E. K. C. Esseling, H. van Nimwegen (1997). Business Process Improvement Workbook: Documentation, Analysis, Design, and Management of Business Process Improvement.

Havey, M. (2005). Essential Business Process Modeling. Ed. O’Reilly Media.

Heravizadeh, M., J. Mendling, M. Rosemann (2009). „Dimensions of Business Processes Quality (QoBP)”, în D. Ardagna et al. (eds.), BPM 2008 Workshops, LNBIP 17, Springer-Verlag Berlin Heidelberg, pp. 80-91.

Hollingsworth, David. Workflow Management Coalition – The Workflow Reference Model. Disponibil la adresa web: http://www.wfmc.org.

Ionescu, T. (1982). Sisteme și echipamente pentru conducerea proceselor. București: Ed. Didactică și Pedagogică.

Juric, M., A. Sasa. Effective Process Modeling with BPM & BPMN. Disponibil la adresa web: http://refcardz.dzone.com/refcardz/bpm-bpmn.

Kabilan, Vandana (2005). Contract Workflow Model Patterns Using BPMN. Royal Institute of Technology and Stockholm University.

Kleinhempel, S., Ș. I. Nițchi, L. Rusu (2010). „Business Process Management in Service-Oriented Companies”, în Informatica Ecomonica Magazine, vol. 14(3).

Kudyba S., R. Hoptroff (2001). Data Mining and Business Intelligence: A Guide to Productivity. Ed. Idea Group Publishing.

Lawton, George, Co-Evolution of BPMN and BPEL Drives BPM in SOA Setting. Disponibil la adresa web: http://www.nadelphelan.com/content/factoids/bibpmanalytics/co-evolution-of-bpmn-and-bpel-drives-bpm-in-soa-settings/.

Leach, L. P. (2000). Critical Chain Project Management. Boston: Artech House Professional Development Library.

Lungu, I. et al. (2002). Sisteme informatice. București: Ed. Economică.

Moore, Andrew W. (2001). Decision Trees. Carnagie: Mellon University, School of Computer Science.

Moore, Andrew W. (2001). PAC Learning. Carnagie: Mellon University, School of Computer Science.

Moore, Andrew W. (2001). Regression and Classification with Neuronal Networks. Carnagie: Mellon University, School of Computer Science.

Murray, C. (2009). Oracle SQL Developer Data Modeler User's Guide. Ediția a II-a. Disponibil la adresa web: http://docs.oracle.com/cd/E15276_01/doc.20/e13677.pdf.

Nilsson, Nils J. (2001). Introduction to Machine Learning. Stanford Universiy, Department of Computer Science.

Pant, Kapil, Matias Juric (2008). Business Process Driven SOA using BPMN and BPEL: From Business Process Modeling to Orchestration and Service Oriented Architecture. Ed. PACKT.

Porter, M. E., V. E. Millar (1985). „How Information Gives You Competitive Advantage”, în Harvard Business Review.

Rand, G. K. (2000). „Critical Chain: The Theory of Constraints Applied to Project Management”, în International Journal of Project Management, 18(3), pp. 173-177.

Recker, Jan (2006). Process Modeling in the 21st Century. BPTrends.

Recker, Jan (2008). BPMN Modeling – Who, Where, How and Why, BPTrends. Disponibil la adresa web: http://www.sparxsystems.com/press/articles/pdf/bpmn_survey.pdf.

Reese, G. (2009). Cloud Application Architectures: Building Applications and Infrastructure in the Cloud.

Rusu, Lucia, Martin Iuga, Simona Marțiș (2011). „Business Process Development Using Agile Methodology”, în 18th International Economic Conference – IECS 2011 – Crises After The Crisis. Inquiries From A National, European And Global Perspective. Sibiu: SICOMAP, 19-20 Mai, pp. 215-224.

Silver, B. Argint (2008). BPMS Watch: BPMN's Three Levels. Disponibil la adresa web: www.bpminstitute.org.

Tcherevik, D., „Integrated Content Management”, în Business Integration Journal. Februarie. Disponibil la adresa web: http://www.bijonline.com.

Ullman, J. D. Data Mining. Stanford University. Disponibil la adresa web: www.thearling.com/dmintro/dmintro.html.

Umble, M., E. Umble (2000). „Manage Your Projects for Success: An Application of the Theory of Constraints”, în Production and Inventory Management Journal, vol. 41(2), pp. 27-32.

Van Huizen, G., „The New Economics of Integration”, în Business Integration Journal. Iulie. Disponibil la adresa web: http://www.bijonline.com.

Vîrlan, G., C. M. Podoleanu, C. Zamfir (2006). Elemente de informatică aplicată. București: Ed. Didactică și Pedagogică.

Voloșencu, C. (2007). Detecția și diagnosticarea defectelor. Timișoara: Universitatea Politehnica.

Voloșencu, C. (2001). Sisteme de conducere a proceslor continue. Timișoara: Universitatea Politehnica.

Ward-Dutton, N., N. Macehiter (2005) „Business Process Management, A Holistic View”, în DMReview.

White, S. A (2005). BPMN Fundamentals, OMG PM ABSIG Meeting Notes. Burlinggame, California. Disponibil la adresa web: http://www.omg.org/docs/pm/05-12-06.ppt.

White, Stephen. Introduction to BPMN. Disponibil la adresa web: http://www.bpmn.org/Documents/ OMG_BPMN_Tutorial.pdf.

Zaharie, D. (2002). Proiectarea sistemelor informatice de gestiune. București: Ed. Economică.

Zur Muehlen, Michael, Danny T. Ho (2008). „Service Process Innovation: A Case Study of BPMN in Practice”, în Ralph Sprague Jr. (ed.), Proceedings of the 41st Hawai International Conference on System Sciences. Waikoloa, HI, 7-10 Ianuarie January 7-10,

***, Introduction to Data Mining and Knowledge Discovery. Ediția a III-a. Two Crows Corporations. Disponibil la adresa web: www.andypryke.com/university/thedatamine.html.

http://camunda.org/bpmn/tutorial.html.

http://www.adoit-community.com/.

http://www.adonis-community.com/.

http://www.agilemodeling.com/essays/agileModelingRUP.htm/.

http://www.agir.ro/univers-ingineresc/_inteligenta_afacerii__si_contributia_ sistemelor_informatice_inteligente_1387.html.

http://www.bmpn.org/.

http://www.brainstorm-group.com/.

http://www.conspectus.com/.

http://www.cordys.com/.

http://www.eaijournal.com/.

http://www.elfconsulting.ro/.

http://www.esomar.org/.

http://www.esspl.com/Methodology/SoftwareProcess/tabid /83/Default.aspx.

http://www.intalio.com/.

http://www.neweraofsoftware.com/saas.aspx/.

http://www.oasis-open.org/.

http://www.omg.org/bpmn/Documents/6AD5D16960.BPMN_and_BPM.pdf.

http://www.omg.org/bpmn/Documents/BPMN_Sections_1_and%202CMP.pdf.

http://www.omg.org/bpmn/Documents/OMG_BPMN_Tutorial.pdf.

http://www.omg.org/spec/BPMN/2.0/.

http://www.opengroup.org/togaf/.

http://www.pontsystems.eu/ro/23-Inteligen-a-in-afaceri-minerit-de-date.

http://www.processmaker.com/tutorials/.

http://www.sap.com/.

http://www.seebeyond.com/.

http://www.sheltonblog.com/.

http://www.sybase.com/content/1018514/BPI_SuiteWP.pdf.

http://www.wfmc.org/.

BIBLIOGRAFIE

Ambler, S. W. (2007). Agile Modeling and the Rational Unified Process (RUP). John Wiley & Sons.

Andone I., M. Vergara, V. Păvăloaia (2009). Modelarea afacerii întreprinderii – procese – reguli. Iași: Ed. Tipo Moldova.

Anupindi, R., S. Chopra, S. Deshmukh, J. Mieghem, E. Zemel (1999). Managing Business Process Flows. Englewood Cliffs: Prentice Hall.

Appleby, R. C. (1993). Modern Business Administration. Londra: Ed. Pitman Publishing.

Ariton, V. (2004). Fundamente ale tehnologiei informației și comunicațiilor. București: Ed. Didactică și Pedagogică.

Ariton, V. (2007). Sisteme informatice cu baze de date. Ed. Europlus.

Basu, A., R. W. Blanning (2003). „Synthesis and Decomposition of Processes in Organizations”, în Information Systems Research.

Briol, Patrice (2008). BPMN, The Business Process Modeling Notation Pocket Handbook. Ed. Inginerie des Pocessus.

Casati, F., S. Ceri, B. Pernici, G. Pozzi (2005). Conceptual Modeling of Workflows.

Chang, J. F. (2006). Business Process Management Systems – Strategy and Implementation. New York: Auerbach Publications.

Chekowaym C., K. Kirk, D. Sillivan (1972). Simulink User’s Guide. Mathworks Inc.

Cozgarea, G. (2010). Metodologii orientate pe obiecte utilizate in proiectarea sistemelor informatice. Ediția a II-a. Ed. Infomega. Disponibil la adresa web: http://www.omg.org/spec/BPMN/2.0.

Crăciunoiu, V. (1973). Elemente de execuție. București: Ed. Tehnică.

Curiac, D., I. Filip (1995). Sisteme de conducere a proceselor continue. Timișoara: Ed. Mirton.

Dumitrache, I. et al. (1993). Automatizări electronice. București: Ed. Didactică și Pedagogică.

Florescu, V. (2002). Grupul BDASEIG. Baze de date. Fundamente teoretice și practice. Ed. InfoMega.

Fotache, D., L. Hurbean (2004). Soluții informatice integrate pentru gestiunea afacerilor. București: Ed. Economică.

Fu-Ren, Lin, Meng-Chyn Yang, Yu-Hua Pai (2002). „A Generic Structure for Business Process Modeling”, în Business Process Management Journal, 8(1), pp. 19-41.

Goldratt, E. M. (1997). Critical Chain. Great Barrington. MA: The North River Press Publishing Corp.

Gruden, A., P. Strannegard (2003). „Business Process Integration: The Next Wave”, în Business Integration Journal. Ianuarie. Disponibil la adresa web: http://www.bijonline.com.

Harrington, H. J., E. K. C. Esseling, H. van Nimwegen (1997). Business Process Improvement Workbook: Documentation, Analysis, Design, and Management of Business Process Improvement.

Havey, M. (2005). Essential Business Process Modeling. Ed. O’Reilly Media.

Heravizadeh, M., J. Mendling, M. Rosemann (2009). „Dimensions of Business Processes Quality (QoBP)”, în D. Ardagna et al. (eds.), BPM 2008 Workshops, LNBIP 17, Springer-Verlag Berlin Heidelberg, pp. 80-91.

Hollingsworth, David. Workflow Management Coalition – The Workflow Reference Model. Disponibil la adresa web: http://www.wfmc.org.

Ionescu, T. (1982). Sisteme și echipamente pentru conducerea proceselor. București: Ed. Didactică și Pedagogică.

Juric, M., A. Sasa. Effective Process Modeling with BPM & BPMN. Disponibil la adresa web: http://refcardz.dzone.com/refcardz/bpm-bpmn.

Kabilan, Vandana (2005). Contract Workflow Model Patterns Using BPMN. Royal Institute of Technology and Stockholm University.

Kleinhempel, S., Ș. I. Nițchi, L. Rusu (2010). „Business Process Management in Service-Oriented Companies”, în Informatica Ecomonica Magazine, vol. 14(3).

Kudyba S., R. Hoptroff (2001). Data Mining and Business Intelligence: A Guide to Productivity. Ed. Idea Group Publishing.

Lawton, George, Co-Evolution of BPMN and BPEL Drives BPM in SOA Setting. Disponibil la adresa web: http://www.nadelphelan.com/content/factoids/bibpmanalytics/co-evolution-of-bpmn-and-bpel-drives-bpm-in-soa-settings/.

Leach, L. P. (2000). Critical Chain Project Management. Boston: Artech House Professional Development Library.

Lungu, I. et al. (2002). Sisteme informatice. București: Ed. Economică.

Moore, Andrew W. (2001). Decision Trees. Carnagie: Mellon University, School of Computer Science.

Moore, Andrew W. (2001). PAC Learning. Carnagie: Mellon University, School of Computer Science.

Moore, Andrew W. (2001). Regression and Classification with Neuronal Networks. Carnagie: Mellon University, School of Computer Science.

Murray, C. (2009). Oracle SQL Developer Data Modeler User's Guide. Ediția a II-a. Disponibil la adresa web: http://docs.oracle.com/cd/E15276_01/doc.20/e13677.pdf.

Nilsson, Nils J. (2001). Introduction to Machine Learning. Stanford Universiy, Department of Computer Science.

Pant, Kapil, Matias Juric (2008). Business Process Driven SOA using BPMN and BPEL: From Business Process Modeling to Orchestration and Service Oriented Architecture. Ed. PACKT.

Porter, M. E., V. E. Millar (1985). „How Information Gives You Competitive Advantage”, în Harvard Business Review.

Rand, G. K. (2000). „Critical Chain: The Theory of Constraints Applied to Project Management”, în International Journal of Project Management, 18(3), pp. 173-177.

Recker, Jan (2006). Process Modeling in the 21st Century. BPTrends.

Recker, Jan (2008). BPMN Modeling – Who, Where, How and Why, BPTrends. Disponibil la adresa web: http://www.sparxsystems.com/press/articles/pdf/bpmn_survey.pdf.

Reese, G. (2009). Cloud Application Architectures: Building Applications and Infrastructure in the Cloud.

Rusu, Lucia, Martin Iuga, Simona Marțiș (2011). „Business Process Development Using Agile Methodology”, în 18th International Economic Conference – IECS 2011 – Crises After The Crisis. Inquiries From A National, European And Global Perspective. Sibiu: SICOMAP, 19-20 Mai, pp. 215-224.

Silver, B. Argint (2008). BPMS Watch: BPMN's Three Levels. Disponibil la adresa web: www.bpminstitute.org.

Tcherevik, D., „Integrated Content Management”, în Business Integration Journal. Februarie. Disponibil la adresa web: http://www.bijonline.com.

Ullman, J. D. Data Mining. Stanford University. Disponibil la adresa web: www.thearling.com/dmintro/dmintro.html.

Umble, M., E. Umble (2000). „Manage Your Projects for Success: An Application of the Theory of Constraints”, în Production and Inventory Management Journal, vol. 41(2), pp. 27-32.

Van Huizen, G., „The New Economics of Integration”, în Business Integration Journal. Iulie. Disponibil la adresa web: http://www.bijonline.com.

Vîrlan, G., C. M. Podoleanu, C. Zamfir (2006). Elemente de informatică aplicată. București: Ed. Didactică și Pedagogică.

Voloșencu, C. (2007). Detecția și diagnosticarea defectelor. Timișoara: Universitatea Politehnica.

Voloșencu, C. (2001). Sisteme de conducere a proceslor continue. Timișoara: Universitatea Politehnica.

Ward-Dutton, N., N. Macehiter (2005) „Business Process Management, A Holistic View”, în DMReview.

White, S. A (2005). BPMN Fundamentals, OMG PM ABSIG Meeting Notes. Burlinggame, California. Disponibil la adresa web: http://www.omg.org/docs/pm/05-12-06.ppt.

White, Stephen. Introduction to BPMN. Disponibil la adresa web: http://www.bpmn.org/Documents/ OMG_BPMN_Tutorial.pdf.

Zaharie, D. (2002). Proiectarea sistemelor informatice de gestiune. București: Ed. Economică.

Zur Muehlen, Michael, Danny T. Ho (2008). „Service Process Innovation: A Case Study of BPMN in Practice”, în Ralph Sprague Jr. (ed.), Proceedings of the 41st Hawai International Conference on System Sciences. Waikoloa, HI, 7-10 Ianuarie January 7-10,

***, Introduction to Data Mining and Knowledge Discovery. Ediția a III-a. Two Crows Corporations. Disponibil la adresa web: www.andypryke.com/university/thedatamine.html.

http://camunda.org/bpmn/tutorial.html.

http://www.adoit-community.com/.

http://www.adonis-community.com/.

http://www.agilemodeling.com/essays/agileModelingRUP.htm/.

http://www.agir.ro/univers-ingineresc/_inteligenta_afacerii__si_contributia_ sistemelor_informatice_inteligente_1387.html.

http://www.bmpn.org/.

http://www.brainstorm-group.com/.

http://www.conspectus.com/.

http://www.cordys.com/.

http://www.eaijournal.com/.

http://www.elfconsulting.ro/.

http://www.esomar.org/.

http://www.esspl.com/Methodology/SoftwareProcess/tabid /83/Default.aspx.

http://www.intalio.com/.

http://www.neweraofsoftware.com/saas.aspx/.

http://www.oasis-open.org/.

http://www.omg.org/bpmn/Documents/6AD5D16960.BPMN_and_BPM.pdf.

http://www.omg.org/bpmn/Documents/BPMN_Sections_1_and%202CMP.pdf.

http://www.omg.org/bpmn/Documents/OMG_BPMN_Tutorial.pdf.

http://www.omg.org/spec/BPMN/2.0/.

http://www.opengroup.org/togaf/.

http://www.pontsystems.eu/ro/23-Inteligen-a-in-afaceri-minerit-de-date.

http://www.processmaker.com/tutorials/.

http://www.sap.com/.

http://www.seebeyond.com/.

http://www.sheltonblog.com/.

http://www.sybase.com/content/1018514/BPI_SuiteWP.pdf.

http://www.wfmc.org/.