CUNOAȘTE INTUIT, Prelegere, Modelarea proceselor de afaceri folosind BPwin

Modelarea proceselor de afaceri se face de obicei folosind instrumente de caz. Aceste instrumente includ BPwin (tehnologia PLATINUM), Silverrun (tehnologia Silverrun), Oracle Designer (Oracle), Rational Rose (Rational Software), etc.

BPwin acceptă trei metodologii de modelare: modelare funcțională ( IDEF0 ); descrierea proceselor de afaceri ( > diagrame de flux de date ( DFD ).

Banc de lucru BPwin

BPwin are o interfață de utilizator destul de simplă și intuitivă. Când porniți BPwin, în mod implicit, apare bara de instrumente principală, o paletă de instrumente (al cărei aspect depinde de notația selectată) și, în partea stângă, navigatorul de model - Model Explorer (Fig. 7.1).

La crearea unui model nou, apare un dialog în care trebuie să specificați dacă modelul va fi creat din nou sau dacă va fi deschis dintr-un fișier sau din depozitul ModelMart, apoi introduceți numele modelului și selectați metodologia în care va fi construit modelul (Fig. 7.2).

După cum sa menționat mai sus, BPwin acceptă trei metodologii - IDEF0 , >DFD , fiecare dintre acestea rezolvând propriile sarcini specifice. În BPwin, este posibil să se construiască modele mixte, adică un model poate conține atât diagrame IDEF0, cât și >DFD în același timp. Compoziția paletei de instrumente se schimbă automat la trecerea de la o notație la alta.

prelegere

cunoaște

Construirea unui model> La etapele inițiale ale creării unui IS, este necesar să înțelegem cum funcționează organizația care va fi automatizată. Managerul cunoaște bine meseria în general, dar nu încapabil să pătrundă în detaliile muncii fiecărui angajat obișnuit. Un angajat obișnuit știe bine ce se întâmplă la locul său de muncă, dar poate să nu știe cum lucrează colegii săi. Prin urmare, pentru a descrie activitatea întreprinderii, este necesar să se construiască un model care să fie adecvat domeniului subiectului și să conțină cunoștințele tuturor participanților la procesele de afaceri ale organizației.

Cel mai convenabil limbaj de modelare a proceselor de afaceri este IDEF0, unde sistemul este reprezentat ca un set de activități sau funcții care interacționează. O astfel de orientare pur funcțională este fundamentală - funcțiile sistemului sunt analizate independent de obiectele pe care operează. Acest lucru vă permite să modelați mai clar logica și interacțiunea proceselor organizației.

Procesul de modelare a unui sistem în IDEF0 începe cu crearea unei diagrame de context - o diagramă a celui mai abstract nivel de descriere a sistemului în ansamblu, care conține definiția subiectului modelării, scopul și punctul de vedere asupra modelului.

Subiectul este înțeles ca sistemul însuși, în timp ce este necesar să se stabilească exact ce este inclus în sistem și ce se află în afara acestuia, cu alte cuvinte, pentru a determina ce vor fi considerate în continuare componente ale sistemului și ce ca un extern. influență. Definirea subiectului sistemului va fi influențată semnificativ de poziția din care este considerat sistemul și de scopul modelării - întrebări la care modelul construit trebuie să răspundă. Cu alte cuvinte, la început este necesar să se determine zona de modelare. Descrierea zonei atât a sistemului în ansamblu, cât și a componentelor sale este baza pentru construirea modelului. Deși se presupune că aria poate fi ajustată în timpul simulării, în general ar trebui formulată inițial, deoarece este zona care determină direcția simulării. LaLa formularea unei zone, trebuie luate în considerare două componente - lățimea și adâncimea. Lățimea implică definirea limitelor modelului - ceea ce va fi considerat în interiorul sistemului și ceea ce va fi în exterior. Adâncimea determină la ce nivel de detaliu este complet modelul. Atunci când se determină adâncimea sistemului, este necesar să se țină cont de constrângerile de timp - complexitatea construirii unui model crește exponențial odată cu creșterea adâncimii de descompunere. După definirea limitelor modelului, se presupune că noi obiecte nu trebuie introduse în sistemul modelat.

Scopul simulării

Scopul modelării este determinat din răspunsurile la următoarele întrebări:

  • De ce ar trebui modelat acest proces?
  • Ce ar trebui să arate modelul?
  • Ce poate obține un client?

Punct de vedere (Point de vedere).

Punctul de vedere este înțeles ca perspectiva din care a fost observat sistemul la construirea modelului. Deși opiniile diferitelor persoane sunt luate în considerare la construirea unui model, toți trebuie să adere la același punct de vedere asupra modelului. Punctul de vedere ar trebui să fie în concordanță cu scopul și limitele simulării. De regulă, se alege punctul de vedere al persoanei responsabile pentru lucrarea modelată în ansamblu.

Modelul IDEF0 presupune prezența unui scop clar definit, a unui singur subiect de modelare și a unui punct de vedere. Pentru a introduce zona, scopul și punctul de vedere în modelul IDEF0 în BPwin, selectați elementul de meniu Model / Model Properties, care apelează dialogul Model Properties (Fig. 7.3). În fila Scop, introduceți obiectivul și punctul de vedere, iar în fila Definiție, definiți modelul și descrieți zona.

intuit

Modelele AS-IS și TO-BE. De obicei, se construiește mai întâi un model al organizării existente a muncii - AS-IS (ca atare). Analiza modelului funcţional permiteînțelegeți unde sunt cele mai slabe puncte, care vor fi avantajele noilor procese de afaceri și cât de profunde vor fi aduse structurii existente a organizației de afaceri. Detalierea proceselor de afaceri vă permite să identificați deficiențele organizației, chiar și acolo unde funcționalitatea la prima vedere pare evidentă. Neajunsurile găsite în modelul AS-IS pot fi corectate la crearea modelului TO-BE (cum va fi) - un model al unei noi organizări a proceselor de afaceri.

Tehnologia de proiectare IS presupune mai întâi crearea unui model AS-IS, analiza acestuia și îmbunătățirea proceselor de afaceri, adică crearea unui model TO-BE, și numai pe baza modelului TO-BE un model de date, se construiește un prototip și apoi versiunea finală a IS.

Uneori, actualele modele AS-IS și viitoarele TO-BE sunt foarte diferite, astfel încât trecerea de la starea inițială la cea finală devine neevidentă. În acest caz, este nevoie de un al treilea model care să descrie procesul de tranziție de la starea inițială la cea finală a sistemului, deoarece o astfel de tranziție este și un proces de afaceri.

Rezultatul descrierii modelului poate fi obținut în Raportul model. Dialogul de setări pentru raportul modelului este apelat din elementul de meniu Instrumente/Rapoarte/Raport model.

În dialogul de setări, selectați câmpurile necesare și este afișată automat ordinea în care informațiile sunt transmise în raport (Fig. 7.4).

cunoaște

Pe fig. 7.5 prezintă un raport generat de câmpurile de mai sus.