Note pentru afaceri

Muzica ne-a legat
A devenit secretul nostru

Toate epigrafele acestui articol sunt preluate din piesa „Music has connected us” a grupului Mirage.

În muzica clasică, muzicianul este instrumentul în mâinile compozitorului și cântă notele. În muzica populară, de cele mai multe ori muzicienii scriu singuri muzica, iar arta improvizației nu implică deloc note. Adevărat, celebrele improvizații, devenite clasice, sunt apoi transferate în note și au o nouă viață: aranjamentul se schimbă, se adaugă un nou sunet și o stare de spirit nouă.

La fel este și o afacere care a crescut ca o improvizație pricepută pentru a trece la un nou nivel necesită punerea pe hârtie a faptelor pentru a analiza ceea ce se întâmplă și a lua decizii pentru îmbunătățire.

Recent, din ce în ce mai des puteți găsi descrieri ale proceselor de afaceri (BP) realizate, după cum se spune, "pe cont propriu". Această împrejurare m-a determinat să scriu acest articol. Din nefericire, majoritatea documentelor care s-au întâmplat să fie văzute au fost de puțin folos pentru o problemă serioasă. Nu se poate spune că s-au înșelat fundamental, dar o serie de omisiuni i-au stricat atât de mult încât se dorea să uite imediat de existența lor. Care sunt aceste omisiuni și cum să le rezolvăm, ne vom da seama în cursul acestui articol, abordând treptat esența problemei. Vom încerca să evităm un număr mare de detalii tehnice, dar nu le putem evita complet, pentru că. subiectul conversației o cere.

Sunt pe cont propriu
Nu găsesc toate răspunsurile

Acest articol se adresează celor care doresc să economisească la descrierea proceselor de business prin încredințarea pregătirii documentului unor specialiști interni. La urma urmei, o descriere a proceselor de afaceri nu este un lucru obligatoriu pentru o companie și totul funcționează fără ea. Dar în orice companie stabilă există un mecanism de transfer de autoritate, acesta se numește „fișe de post”. Dacă afacerea este complexă, iar poziția este cheia, atunci este util să desenezi fișe de post pentru a fi mai ușor de înțeles. Acumularea proceselor de afaceri într-o descriere generală este necesară pentru a face afacerea mai transparentă, mai ales pentru vânzarea acesteia.

Documentul „Descrierea BP” devine deosebit de relevant de îndată ce este nevoie de reorganizare (sau, așa cum este acum la modă să se spună - reinginerie) a companiei. În acest caz, documentul este utilizat pentru:

1. Pe ea, ca pe o hartă de luptă, marcați esența transformărilor planificate,
2. Introduceți un participant la transformări la zi,
3. Cu un stilou și nu pe degete, setați sarcina șefilor de departamente și specialiștilor externi.

Există avantaje în a pregăti un document pe cont propriu:

• Iese mai ieftin;
• Specialist intern, mai bine versat în practicile afacerii sale natale.

Un consultant terț va trebui mai întâi să studieze terminologia și caracteristicile cheie ale subiectului, standardele din industrie. Acest lucru necesită timp. Adevărat, el știe mai bine cum și ce să descrie. Există anumite reguli, notații general acceptate și software special. Un exemplu de astfel de notație poate fi văzut în Fig. 1 și fig. 2.

Notație IDEF0

Un exemplu de descriere a unui BP folosind IDEF0

Nu ne da prelegeri

Nu-mi da lecții
Mamă, e inutil

De asta avem nevoie? - Directorul va cere, presupunând în mod rezonabil că respectarea tuturor standardelor va crește semnificativ costul rezultatului. Unul dintre directorii pe care i-am cunoscut a raționat astfel: "Invitarea unui specialist din exterior este o afacere costisitoare, dar sarcinile noastre sunt simple - de ce avem nevoie de toate aceste notații. Și asta trebuie să plătiți."

Sunt de acord, dacă sarcinile sunt simple, de ce să îngrădești grădina. Și dacă sunt complexe, atunci este necesar să se simplifice și să nu se complice cu notații fanteziste. La urma urmei, nu există avantaje evidente din utilizarea cârligelor frumoase. Dacă nu există unele evidente, asta nu înseamnă că nu există. Aceste reguli și notații nu sunt inventate pentru a nu se plictisi consultantul... Oricine este în afaceri știe foarte bine că nu tot ce este util este evident. Ei bine, să căutăm un pozitiv ascuns și pentru asta ne uităm în istoria problemei.

Piața descrierii PSU există de foarte mult timp. Cu toate acestea, în ultimul deceniu și jumătate, el a făcut o descoperire rapidă, datorită apariției unei noi industrii - automatizarea contabilității și managementului în întreprinderi. Piața în creștere a oferit o șansă noilor veniți care au venit cu noi notații să pătrundă și să-și pună locul. De exemplu, pe piața rusă în ultimii ani, campaniile masive de publicitate și informare ale IDS Scheer (principalul furnizor al ARIS - vezi Fig. 3) au creat un strat de specialiști în descrierile proceselor automate.

Utilizarea notației ARIS necesită o cantitate mare de detalii în procesele de afaceri.

Introducerea sistemelor de clasă ERP (gestionarea resurselor), CRM (relații cu clienții), MRP (planificarea producției) duce inevitabil la o schimbare a proceselor, iar dacă aceasta nu este planificată din timp, rezultatul poate fi mai rău decât ți-ai dori. În plus, automatizarea înseamnă lucrul cu informații, ceea ce înseamnă că este util să știi ce informație este generată de cine, de unde provine și unde se duce. Dar notațiile speciale pentru introducerea automatizării nu au prins rădăcini la noi și sunt rar folosite.

Descrierea proceselor de afaceri din Rusia este o tendință relativ recentă, în ciuda numărului impresionant de GOST din acest domeniu (3.1109, 34, ISO etc.). Acum, cu calitatea descrierii propriilor procese de afaceri, lucrurile stau cel mai bine în bănci. Cert este că, spre deosebire de alte structuri comerciale, o bancă este o organizație de infrastructură și, prin urmare, se află în cadrul strict al reglementărilor definite de lege. Banca funcționează pe principiul managementului de zi cu zi. Ca urmare, chiar și descrierea simplificată a proceselor de afaceri ale Băncii (în limba rusă fără utilizarea notațiilor) se dovedește a fi mai detaliată, deoarece se bazează pe o bază construită pe volume de reglementări care definesc standarde, terminologie, roluri și reguli. Aceste standarde sunt limbajul comun în mediul bancar și descrierea proceselor de afaceri va fi ușor de citit pentru orice specialist.

În structurile comerciale, descrierea proceselor de afaceri necesită un glosar preliminar de termeni. Și începând să-l pregătească și să-l coordoneze, mulți se confruntă cu faptul că aceleași lucruri în diferite departamente sunt numite diferit. Intrând în detalii, se dovedește că diferite nume poartă într-adevăr diferite nuanțe de semnificație. Armonizarea terminologiei este unul dintre procesele cele mai consumatoare de timp pentru descrierea BP. Este important să începeți și să rulați acest proces. Pot prelua cea mai mare parte a muncii de la propriile divizii ale companiei, deoarece nevoia de a-și reglementa activitățile duce la o mai bună organizare a proceselor și a procedurilor.

Când este necesară o descriere pentru automatizare, este posibilă și succesiunea inversă. Schimbarea proceselor de afaceri se face in paralel cu implementarea sistemului informatic, iar descrierea noilor procese de afaceri se realizeaza „in hot pursuit” si este una cu documentatia sistemului.

portativ

Am uitat totul
Am fost învățați de atâția ani

Destul de ciudat, dar alegerea notării și corectitudinea descrierii sunt mai critice pentru întreprinderile mici și mijlocii. Companiile mari tind să aibă mai multă elasticitate a procesului datorită interschimbabilității angajaților. Pentru o afacere mică, în care execuția punctelor critice se reduce la 2-3 factori de decizie, o indicare incorectă a traseului procesului poate da naștere la un concept fundamental greșit al soluției. Deoarece rezultatul este critic, instrumentul este, de asemenea, important, dar cum să îl alegeți?

Fiecare notație este adaptată unei game specifice de sarcini. Vom lua în considerare cea mai urgentă sarcină de schimbare a proceselor de afaceri ca parte a unui proiect de automatizare a managementului. În aceste scopuri, există un set bun de instrumente care este utilizat pe scară largă: acestea sunt GOST-urile rusești, același ARIS și IDEF, precum și EPC (Fig. 4 și Fig. 5).

Notație EPC

Descrierea unui proces de afaceri folosind EPC

Dacă cartea este scrisă într-o anumită limbă, atunci cel mai important lucru este să ai un cititor care să cunoască această limbă și să o poată citi. Pe baza acestui fapt, cel mai comun standard pentru descrierea TA este cel mai bun.

Atunci când alegeți o notație, abilitatea de a utiliza un instrument software familiar este, de asemenea, un criteriu important. De exemplu, Microsoft Business Solution în 2002 a oferit notația On-Target pentru sistemul informațional Navision, însoțită de o soluție software specială. Acesta este cazul când este mai bine să alegeți altceva - nu numai că, nimeni nu cunoaște notația On-Target, dar și mediul software va lua timp pentru a o studia. Un exemplu pozitiv, aș numi utilizarea notației IDEF și programul Visio, care este foarte comun și are setul necesar de instrumente pentru desenarea diagramelor IDEF (Fig. 6).

Procesele de afaceri IDEF realizate în Visio

Desigur, descrierea BP poate fi făcută pur și simplu în cuvinte, precum și desenată cu diferite simboluri (din propria invenție), așa cum pare de înțeles. A avea o astfel de descriere este mai bine decât nimic, dar standardele sunt totuși utile.

Plenitudinea și profunzimea sunetului

Nu știu ce mă atrage aici

1. ia mult timp
2. unele detalii se vor modifica în timpul creării documentului.

O greșeală comună este încercarea de a se potrivi descrierilor pentru a se potrivi cu notația. De exemplu, încercați să descrieți procedurile în formatul ARIS, de exemplu. pentru a realiza o redundanță evidentă în descriere atunci când nu este necesară.

Dar, o greșeală mai frecventă este adâncimea insuficientă a documentului. Ca urmare, se obține un document formal care nu este potrivit pentru muncă, deoarece toate detaliile importante trebuie clarificate în cadrul procesului.

Melodia este o succesiune de sunete, nu note

uita de această zi
Nimeni nu are nevoie de luptă

Deci puteți descrie BP și doar cuvinte, fără nicio notație. Cu notația, desigur, este mai corect, dar acest lucru nu este important. Descriere BP nu este un produs final, ci doar un instrument pentru noi realizări. Aceasta înseamnă că trebuie adaptat pentru utilizare activă ulterioară. Principala problemă a majorității documentelor de tip „do-it-yourself” este inconvenientul de a le folosi. De exemplu, un astfel de document a constat dintr-o descriere făcută în Microsoft Word și desene realizate în PowerPoint, era teribil de incomod să sari de la program la program, a durat mult timp pentru a le aduce pe toate într-un singur document. Se pare că documentul ar trebui să aibă următoarele proprietăți:

1. Să aibă o ordine clară și o grupare a secțiunilor, de ex. fii holistic din punct de vedere conceptual (de obicei, asta înseamnă că dacă ești un concept, atunci ai învățat cum să-l folosești);
2. Identificați clar unitățile de afaceri și oferiți-le nume și numerotare ușor de înțeles;
3. Identificați clar procesele de afaceri și, de asemenea, acordați-le un nume și o numerotare clare;
4. Elementele trebuie numerotate astfel încât să se evite confuzia (acest lucru facilitează foarte mult căutarea): de exemplu, Departamentul nr. 1 ar trebui să aibă în document numărul Otd001, iar Procesul de afaceri nr. 1 să aibă numărul BP001;
5. Documentul trebuie să aibă o secțiune de conținut cu o structură arborescentă;
6. O companie este un organism integral și niciun proces de afaceri nu stă în aer - este întotdeauna conectată cu alte unități de afaceri, cu unități de afaceri și departamente. Hyperlinkurile pot fi folosite pentru a reflecta aceste legături - acest lucru va facilita căutarea de informații și trecerea de la un obiect la altul.

Pentru acest caz, puteți utiliza orice editor de text care acceptă hyperlinkuri.

Unii oameni cred că într-un grup muzical profesionist este suficient să ai unul sau doi muzicieni adevărați. Niciun cunoscător sincer al muzicii nu va fi de acord cu asta. Aceste conversații apar din cauza lipsei de profesioniști și de persoane creative.

Afacerile au provocări similare. Sunt puțini specialiști buni care își cunosc compania din cap până în picioare și sunt foarte ocupați. Analizând procesele de afaceri pe cont propriu, economisim bani și poate economisim timp. Dar nu este întotdeauna posibil să le rupeți pe cele mai bune pentru descrierea PSU. Puteți încredința rutina unor artiști cu un rang inferior, dar atunci există riscul de a întârzia procesul. Necunoașterea principiilor de construire a unor astfel de documente implică riscul de ineficacitate (rezultatul este inutilizabil, este la fel cu absența acestuia).

Cea mai bună calitate și rapiditate în pregătirea unui document este posibilă într-o alianță, un specialist cheie și un consultant cu experiență. Rezultatul va fi un limbaj agreat pentru descrierea proceselor de afaceri (adică, terminologia afacerii companiei) și descrierea însăși în detaliu suficientă pentru a rezolva problemele ulterioare.

Repet toată persuasiunea ca răspuns
Nu ne vom despărți, nu

Vă reamintim că toate epigrafele acestui articol sunt preluate din piesa „Music Tied Us” a grupului Mirage

Un consultant extern va scrie documentul într-un limbaj de notare pe care alți consultanți îl înțeleg și adesea mai potrivit pentru caz. Nu înțelegi toate aceste cârlige? Dar aceste notații nu sunt deloc dificile, poate că merită să le înveți?

Scopul EPC este planificarea și descrierea fluxurilor de lucru, la nivelul inferior (operațional), procesele de afaceri. Elementele principale pentru construirea diagramelor sunt evenimentele și funcțiile. Procesele de afaceri, în diagrama EPC, sunt descrise ca secvențe de evenimente și funcții alternative.

Domeniul de aplicare al EPC

Diagrama EPC este o diagramă grafică standardizată pentru modelarea proceselor de afaceri, aplicabilă pentru:

• Modelarea și documentarea proceselor de afaceri așa cum sunt (ca atare)
• Descrierea posibilelor îmbunătățiri ale proceselor de afaceri existente (care urmează)
• Identificarea tuturor participanților la proces
• Identificarea tuturor sistemelor informatice, resurselor si documentelor implicate in proces

Pentru a vă face o idee mai bună despre diagrama EPC, vă sfătuim să vizitați linkurile:

• Introducere în EPC

  Link-ul duce la o introducere în EPC. Vă sugerăm să vizitați mai întâi linkul.

• Elementele și structura EPC Charting

  Link-ul duce la descrierea unde sunt prezentate cele mai importante elemente grafice ale diagramei. Prezentarea elementelor și utilizarea lor este perfect structurată, vă va fi foarte convenabil să navigați.

• Exemple de reguli pentru construirea diagramelor EPC

  Linkul duce la un document în care sunt descrise exemple de diagrame. P.S. În acest caz, ne interesează doar informațiile prezentate în capitolul al patrulea de la pagina 86.

Alte materiale utile:

• Link-ul conduce la o colecție de materiale de instruire privind metodologia ARIS.

O diagramă funcțională EPC trebuie să înceapă cu cel puțin un eveniment de pornire (evenimentul de pornire poate urma interfața de proces) și să se termine cu cel puțin un eveniment de sfârșit (evenimentul de sfârșit poate preceda interfața de proces).

Evenimentele și funcțiile în cursul procesului trebuie să se alterneze. Deciziile cu privire la continuarea procesului sunt luate de funcții.

Numărul recomandat de funcții din diagramă nu este mai mare de 20. Dacă numărul de funcții din diagramă depășește semnificativ 20, atunci există posibilitatea ca procesele de la nivelul superior să fie identificate incorect și modelul să fie corectat.

Evenimentele și funcțiile trebuie să conțină exact o conexiune de intrare și una de ieșire, reflectând progresul procesului.

Evenimentele și declarațiile din jurul funcției din diagrama de suprapunere trebuie să fie evenimentele și declarațiile de început/rezultat din diagrama de descompunere a funcției.

Diagrama nu trebuie să conțină obiecte fără o singură conexiune. Fiecare operator de îmbinare trebuie să aibă cel puțin două legături de intrare și doar una de ieșire, operatorul de ramificare trebuie să aibă o singură legătură de intrare și cel puțin două de ieșire. Operatorii nu pot avea mai multe conexiuni de intrare și de ieșire în același timp. Dacă un operator are o conexiune de intrare de la elementul „eveniment”, atunci trebuie să aibă o conexiune de ieșire la elementul „funcție” și invers. Un singur eveniment nu trebuie să fie urmat de operatori „SAU (SAU)” sau „XOR (SAU exclusiv)”. Operatorii pot îmbina sau ramifica numai funcții sau numai evenimente.

Orez. 2.62 Exemplu de diagramă de proces în notație EPC

Orez. 2.63 Exemplu de situație acceptabilă 3	Orez. 2.64 Exemplu de situație acceptabilă 4

Un exemplu de situație invalidă.

Orez. 2.65 Exemplu de situație inacceptabilă

Metode statistice de control al procesului

Sunt date exemple ale celor mai populare metode de analiză statistică și este propus un mecanism de evaluare a acestora.

Analiza diagramei Pareto

Tot felul de probleme apar constant în întreprinderile industriale: apariția defectelor, defecțiuni ale echipamentelor etc. În majoritatea cazurilor, marea majoritate a defectelor și pierderilor aferente apar dintr-un număr relativ mic de motive, ponderea costurilor materialelor fiind de aproximativ 70 - 80%. Pentru a afla care dintre aceste cauze sau factori sunt principalii, se construiește o diagramă Pareto.

Diagrama Pareto este un instrument care vă permite să prezentați și să identificați în mod obiectiv principalele cauze care afectează problema studiată. Există două tipuri de diagrame Pareto: după rezultatele activității și după cauze.

Diagrama de performanță este concepută pentru a identifica problema principală și reflectă următoarele rezultate nedorite de performanță:

Cost: volumul pierderilor, costurile;

· Siguranta: accidente, accidente;

· Condiții de livrare: nerespectarea termenelor, lipsa stocurilor.

Diagrama Cauze Pareto reflectă cauzele problemelor care apar în timpul producției:

· Executant de lucru: tură, echipă etc.;

· Echipamente: mașini, agregate, unelte etc.;

· Metode de lucru: succesiunea operaţiilor, condiţiile de producţie;

· Măsurători: precizie, reproductibilitate, stabilitate.

Construcția diagramei Pareto constă din următorii pași.

Etapa 1. Determinați ce probleme trebuie investigate și cum să colectați date; cum să le clasificăm. Setați metoda și perioada de colectare a datelor.

Pasul 2: Elaborați o listă de verificare a înregistrării datelor care să enumere tipurile de informații colectate.

Pasul 3. Completați foaia de introducere a datelor și calculați totalurile.

Pasul 4. Elaborați un șablon de tabel pentru verificările datelor, oferind un grafic pentru totalurile pentru fiecare caracteristică verificată în mod individual, suma acumulată a numărului de defecte, procentele din total și procentele acumulate. Aranjați datele în ordinea importanței.

Tabelul 3.1.1 Construirea unei diagrame Pareto

Pasul 5. Desenați o axă orizontală și două verticale. Axe verticale: pe axa din stânga se aplică o scară cu un interval de la 0 la numărul corespunzător totalului general; pe axa dreaptă - o scară cu un interval de la 0 la 100%. Împărțiți axa orizontală la numărul de caracteristici controlate.

Orez. 3.1.1 Diagrama Pareto

Pasul 6. Construiește un grafic cu bare, în care fiecare tip de căsătorie are propriul său dreptunghi.

Pasul 7. Desenați o linie cumulativă.

Când construiți o diagramă, ar trebui să acordați atenție următoarelor puncte:

· Diagrama este cea mai eficientă dacă numărul de factori este 7 - 10;

· La prelucrarea datelor este necesară stratificarea acestora în funcție de parametrii individuali (timpul de selecție a datelor, tipul produselor, lotul de materiale, operatorul etc.);

· Dacă factorul „celălalt” este prea mare, analiza conținutului acestui factor trebuie repetată;

 Diagrama trebuie realizată sistematic. Pareto pentru același proces, care vă va permite să urmăriți tendința numărului de defecte pentru fiecare factor (Fig. 3.1.1).

Standardul EPC

EPC (Event-Driven Process Chain, lanț de procese de evenimente) este o notație pentru afișarea progresului unui proces, ale cărui elemente cheie sunt Evenimente și Funcții. Notația EPC a fost dezvoltată în anii 90 ai secolului XX. EPC a fost inventat de profesorul german Wilhelm-August Scheer ca parte a metodologiei ARIS.

O diagramă a procesului de afaceri într-un EPC trebuie să înceapă și să se termine cu un eveniment. Funcția trebuie să fie întotdeauna urmată de un eveniment, adică execuția funcției creează un eveniment (stare). Documentele, legăturile organizaționale, fluxurile de informații și materiale, elementele sistemului informațional (software, baze de date) au o denumire grafică proprie. Pentru ramificarea proceselor se folosesc operatorii AND, SAU, SAU exclusiv.

EPC este utilizat la nivelurile inferioare ale descrierii modelului de afaceri atunci când sarcina este de a descrie fluxul detaliat al unui proces de afaceri. Funcțiile EPC pot fi descompuse (defalcate în procese de afaceri detaliate numai în notație EPC).

Dezavantajele EPC includ faptul că această notație are un set foarte larg de elemente grafice, care pot fi greu de înțeles în comparație cu alte notații. Pentru a dezvolta procese în această notație și pentru a le citi, este necesară pregătirea preliminară a angajaților.

Avantajele EPC includ capacitatea de a descrie execuția unui proces de afaceri într-un mod foarte detaliat și precis, de a arăta într-o diagramă într-o formă grafică toți performerii, toate obiectele folosite. De asemenea, avantajul diagramelor EPC este faptul că, ca și diagramele IDEF0, pot indica datele de intrare și ieșire ale fiecărei funcții, pot urmări logica mișcării datelor de intrare și ieșire de la bloc la bloc. În plus, spre deosebire de același IDEF0, a devenit posibilă paralelizarea procesului, direcționându-l doar de-a lungul uneia dintre ramurile alternative (în IDEF0, dacă adăugăm paralelism în execuție, atunci toate funcțiile paralele vor fi executate simultan). Avantajul mi s-a părut și abilitatea de a preciza interpretul pentru fiecare etapă (a se citi: funcții). Însă, în IDEF0, executantul este specificat la fiecare nivel de descompunere o dată, iar în numele lui sunt trase săgeți la toate blocurile pe care le execută. În EPC, pentru a calcula câte acțiuni efectuează un executant, trebuie să parcurgeți toate blocurile de acțiuni și să verificați dacă executorul de care avem nevoie este indicat pe el.

Această notație s-a dovedit a fi foarte atractivă din punctul de vedere al monitorizării execuției procesului - fiecare funcție va transfera cu siguranță sistemul într-o stare nouă, ceea ce înseamnă că după executarea fiecărei funcții, sistemul poate fi verificat dacă trecerea la starea dorită a fost într-adevăr făcută.

În general, notația EPC este recunoscută la nivel mondial ca una dintre cele mai bune notații pentru construirea proceselor de afaceri și modelarea funcționării unei întreprinderi.

Alegerea metodei de modelare

Metodologia BPMN a fost aleasă pentru a modela procesul de afaceri necesar. Această alegere se datorează faptului că notația BPMN vă permite să afișați cu cea mai mare acuratețe procesele logice care apar atunci când efectuați sarcini care necesită o descriere foarte precisă a secvenței de acțiuni, să demonstreze interacțiunea dintre angajați și client și, de asemenea, vă permite pentru a arăta intervalul de timp dintre executarea unor sarcini.

Fiecare lucru este o formă de manifestare a diversităţii infinite.

Kozma Prutkov

Introducere în notația eEPC

În prezent, există multe principii diferite de reprezentare grafică a proceselor de afaceri, numite notații. De ce sunt multe? Această întrebare a fost pusă de zeci de ani de către toți cei care se confruntă cu nevoia de a descrie procesele de afaceri. Să ne uităm la motive. Sunt trei (dupa parerea mea):

• - Sarcini diverse. Nu toate notațiile sunt la fel de convenabile pentru rezolvarea diferitelor probleme. De exemplu, o notație poate fi convenabilă pentru un proces de afaceri de nivel superior și deloc convenabilă pentru descrierea unui flux de lucru.

Diferiți dezvoltatori de astfel de notații. În momente diferite, diferiți dezvoltatori au încercat să vină cu noi principii pentru descrierea circuitelor. Au făcut acest lucru din bune intenții, când în practică au întâlnit o situație în care notația pe care o foloseau nu putea reflecta subtilitățile necesare (sau nu în mod clar). Uneori, în procesul evoluției, astfel de notații au devenit, parcă, paralele, adică. arată diferit, dar rezolvă aceleași sarcini.

Dorința de a ieși în evidență. Acesta este momentul în care, din motive necunoscute, apare brusc o nouă notație, care nu are nimic remarcabil în sine, dar, din anumite motive, este promovată de creatorul ei drept cel mai perfect know-how. Acest lucru se mai întâmplă.

Scopul acestui articol nu este să ia în considerare toate tipurile de notații (nu le numesc în mod deliberat), ci să mă opresc pe o descriere detaliată a notației pe care am ales-o pentru proiectele mele în procesul de căutare îndelungată a celei mai optime opțiuni. .

Dacă cineva este interesat să știe ce sunt alte notații și la ce sunt folosite, plănuiesc să fac acest lucru într-un alt articol, care se va numi „Hai să vorbim despre notații”, dar asta este încă în planuri.

Este timpul să începem povestea noastră despre o notație eEPC foarte interesantă, simplă și practică (în traducere: o descriere extinsă a lanțului de procese de evenimente). În traducerea sa literală, este dezvăluit și scopul principal: o descriere a lanțului proceselor de afaceri. Principalul „truc” al notației este în principiul „evenimentului”, pe care îl vom analiza în detaliu.

Care sunt avantajele notației eEPC:

1. În primul rând, aceasta nu este o notație pură. Acestea. dacă în unele notații există un set rigid de elemente și reguli pentru utilizarea lor (altfel totul va deveni confuz), atunci principiul eEPC vă permite să adăugați propriile elemente. Cum este furnizat? Desigur, există un anumit „nucleu” în jurul căruia se construiește totul, adică. un set de reguli clare prin care se construiește schema și după care se citește apoi. În plus, puteți adăuga propriul element, include regulile de utilizare a acestuia în propriul standard corporativ (pentru a exclude activitatea de amatori care poate încurca schema și poate complica lizibilitatea acesteia) și atât! Acesta este un punct foarte important. În plus, puteți seta orice alte restricții și reguli în standardul dvs. corporativ.
2. eEPC conține elemente de logică. Acest lucru vă permite să construiți scheme cu condiții care sunt necesare pentru a descrie activitatea („dacă contractul este de acord, atunci ...., în caz contrar ...”)
3. Simplitatea elementelor vă permite să desenați diagrame atât în ​​produse software, cât și în orice alt mod, chiar și pe hârtie, nu vă veți încurca.
4. eEPC este atât de ușor de învățat și de înțeles încât poate fi folosit în viața reală, nu doar pentru a aduna praf într-un dulap. Va dura aproximativ 2 ore pentru a învăța regulile (dacă studentul dorește).

Desigur, ca tot ce este în lumea asta, are dezavantajele ei. Dar utilizarea rațională le reduce la minimum. Principalul dezavantaj, în opinia mea, este faptul că dacă folosim instrumente simple (adică programe pentru desenarea diagramelor, și nu pentru modelarea proceselor de afaceri), atunci nu avem o singură bază de date de obiecte. În plus, este dificil să controlați intrările și ieșirile (este necesar să le controlați, adică să veniți cu o modalitate de astfel de control, dacă este necesar). Dar, pe de altă parte, utilizarea instrumentelor complexe de modelare a proceselor de afaceri costă sume destul de impresionante, iar proiectul cu utilizarea lor se măsoară în milioane. Și astfel avem un instrument foarte economic și ușor de înțeles. Pentru a fi mai precis, acest neajuns se referă în mod specific la metoda de descriere pe care o iau în considerare, adică. folosind MS Visio sau software similar. Dacă utilizați sisteme specializate pentru descrierea proceselor de afaceri care suportă baze de date cu obiecte, atunci acest dezavantaj poate fi evitat. Ei bine, este timpul să începem...

Principalul „nucleu” al notației eEPC

După cum am menționat deja, în traducerea literală a abrevierei eEPC se află conceptul de evenimente. Acesta este un punct foarte important pe care se construiește întregul principiu al construirii unui circuit. Deci, există două concepte cheie: „Eveniment” și „Funcție”. Când cineva încearcă pentru prima dată să-și deseneze procesul sub forma unei diagrame eEPC, apare adesea întrebarea care este diferența dintre un eveniment și o funcție? Acest lucru trebuie înțeles clar, altfel veți obține un rezultat imprevizibil. Deci: un eveniment este un fapt de a realiza ceva, și nu are o durată în timp, sau acest timp tinde spre zero (sau nu contează). Mai mult, evenimentul provoacă întotdeauna necesitatea executării funcției, iar execuția funcției se termină întotdeauna cu evenimentul.Să explic cu un exemplu. Telefonul suna. Managerul ridică telefonul. În acest caz, „Telefonul sună” este un eveniment. Conversația telefonică este o funcție. Conversația sa încheiat (închis) - din nou un eveniment. Astfel, se observă un lanț de evenimente: Apel - conversație - sfârșitul apelului. Iar sfârșitul apelului va necesita cel mai probabil executarea unei noi funcții: înregistrarea rezultatului apelului etc.

Să încercăm să-l desenăm. Mai întâi trebuie să vă dați seama cum sunt afișate elementele „Eveniment” și „Funcție”.

Aceste două elemente simple formează baza regulilor de descriere a proceselor de afaceri în notația eEPC. Cred că trebuie să spun câteva cuvinte despre culorile folosite. Dacă ați întâlnit descrierea proceselor în alte notații, de regulă, acestea erau alb-negru. Și acest lucru este corect, nu ar trebui să existe o dependență explicită a conținutului de culoare, deoarece diagrama poate fi desenată cu un creion pe hârtie, imprimată pe o imprimantă alb-negru etc. În acest caz (în eEPC ntation), s-a dezvoltat istoric că elementele au anumite culori. Ca să nu spun că era necesar, dar obiceiul este dezvoltat, iar percepția în formă electronică este mai bună - puteți vedea imediat ce este. Aceste culori pot fi considerate o recomandare. De ce sunt așa? Nu sunt sigur exact, dar mi se pare că ARIS, când a făcut suport pentru notația eEPC în produsul său, le-a dat astfel de culori, au „prins rădăcini”. Apropo, uneori această notație se mai numește și „ARIS”, „ARIS EPC”, ceea ce nu este în întregime corect, deoarece ARIS nu a inventat această notație, ci a susținut-o în programul lor de modelare a proceselor de afaceri. În general, recomand folosirea culorilor. Principalul lucru este că însăși forma elementelor nu ar trebui să fie aceeași (adică să difere doar prin culoare), deoarece în alb și negru, acest lucru poate fi confuz. Există și alte reguli care vă permit să dați „zveltețe” diagramei eEPC, vom vorbi despre ele.

Deci, există un eveniment, există o funcție. Cum sunt ele legate?

Vedem că event1 a dus la necesitatea executării unei anumite funcții, care s-a încheiat cu event2. Dacă se aplică exemplului cu un apel telefonic, atunci va fi astfel:

Linkul eveniment - funcție - eveniment este de obicei afișat de sus în jos pe o singură linie sau de la stânga la dreapta. Direcția lanțului este indicată prin linii de legătură cu săgeți. Pentru a face schema mai vizuală, notația oferă câteva elemente standard:

• Poziție (interpret). Cel care îndeplinește această funcție
• Informație. Orice informație utilizată pentru a îndeplini o altă funcție decât informațiile documentare. De exemplu, un apel telefonic, instrucțiuni pentru efectuarea unei operații etc.
• Document. Elementul „Document” este conceput pentru a afișa medii de informare (hârtie sau electronice). Acestea. prezentarea informaţiilor într-o anumită structură.
• Program (aplicație). Software-ul folosit pentru a îndeplini funcția.

Toate celelalte elemente sunt auxiliare și practic nu sunt reglementate de cerințele eEPC în sine. Cu toate acestea, nu există bariere în a adăuga propriile elemente. Principalul lucru este să remediați acest lucru în standardul intern, astfel încât să existe o înțelegere comună a modului în care arată și de ce sunt utilizate. O astfel de extensie nu încalcă cerințele, dacă conexiunea eveniment-funcție-eveniment nu este încălcată și are scopul doar de a îmbunătăți percepția informațiilor sau de a adapta regulile de descriere la anumite specificități ale industriei. Am adăugat propriul meu set de elemente, despre care voi discuta mai jos.

Încă trebuie să vă dați seama cum ar trebui să fie localizate elementele luate în considerare. Toate aceste elemente trebuie să aibă cumva legătură cu funcția. Este o regulă generală că niciun element altul decât o funcție nu este asociat cu un eveniment. Acestea. toate aceste elemente trebuie conectate cu săgeți la funcție. În ceea ce privește săgețile și direcțiile acestora: se acceptă în general că, dacă nu există o direcție pentru transmiterea informațiilor, atunci este afișată doar o linie în loc de o săgeată. Dacă intră informația (intră în intrare), atunci direcția săgeții este de la obiect la funcție, dacă iese, atunci invers.

Încă câteva cuvinte despre locația acestor elemente pe diagramă și ne putem redesena diagrama, specificând execuția funcției de procesare a apelurilor. Nu există cerințe stricte pentru aranjarea elementelor, dar este obișnuit să le afișați în toate diagramele în același mod (pentru uniformitatea și armonia diagramei). Pentru a unifica vederea externă a diagramelor grafice ale proceselor de afaceri, astfel de reguli trebuie să fie fixate în standardul intern și respectate. Puțin mai târziu voi da câteva recomandări în acest sens. Acum să ne redesenăm diagrama:

Vedem că operatorul procesează un apel primit, acționând în conformitate cu regulile de procesare a apelurilor primite și folosind programul CRM pentru aceasta. Nu sunt folosite nici documentele de intrare, nici de ieșire.

După cum am menționat deja, unul dintre punctele forte ale notației sunt elementele de logică. În același timp, acesta este unul dintre cele mai dificile momente de înțeles. Prin urmare, mai întâi voi da un exemplu și apoi ne vom ocupa separat de elementele logicii.

În exemplul nostru, să fie așa: dacă clientul este interesat, managerul de vânzări lucrează în continuare cu el și face o ofertă comercială, pe care o trimite prin poștă folosind clientul de e-mail MS Outlook. Dacă nu există interes, atunci procesarea apelului este finalizată. În viața reală, ar fi bine să folosim regulile de terminare a apelurilor, dar eu sunt, apropo, în timp ce o simplificăm. Iată ce se întâmplă:

Elemente de logică în schemele de notație eEPC

Elementele logicii sunt simple, dar există unele particularități și reguli pentru ca schema să fie logică și interpretată fără ambiguitate. Cea mai importantă regulă de respectat 100%: deciziile logice pot fi luate numai atunci când o funcție este executată. Acestea. după un anumit eveniment nu poate exista ramificare. De ce? Pentru că în acest caz contrazice însăși conceptul de eveniment – ​​este simplu și instantaneu, fără timp de execuție. De exemplu, dacă sună telefonul și o persoană stă și se gândește dacă să ridice sau nu telefonul, teoretic aceasta va fi deja o funcție în care va lua o decizie. Dar în practică, inclusiv din bunul simț, el încalcă regulile de procesare a apelurilor, tk. el este plătit cu un salariu pentru a procesa aceste apeluri și nu este nimic de argumentat aici (în general, așa cum se arată în diagramă).

În total, se disting 3 elemente de logică:

• I. Când două sau mai multe evenimente au loc în același timp;
• SAU. Când unul sau mai multe evenimente pot avea loc, dar cel puțin unul trebuie să apară;
• EXCLUSIV SAU. Ori unul, ori altul. Acestea. două opțiuni nu sunt posibile în același timp.

După cum puteți vedea, există două opțiuni pentru reprezentarea grafică a elementelor logice. Nu sunt diferiți, complet diferiți. Le-am adus pe amândouă, pentru că. În practică, ambele opțiuni pot fi văzute în diverse surse. Pe care să-l folosiți depinde de dvs. Imi place mai mult primul.

Acum trebuie să ne ocupăm de utilizarea elementelor logice. Mai întâi, să ne uităm la opțiunile întâlnite, apoi să trecem la un exemplu. Să analizăm fiecare element separat.

Element logic „ȘI”. Când o funcție necesită mai multe evenimente pentru a fi executate în același timp:

Exemplu: Dacă perioada de raportare este închisă (evenimentul 1) și a sosit termenul limită pentru transmiterea unui raport către manager (evenimentul 2), angajatul întocmește un raport lunar.

Conectarea elementelor, în cazul în care au loc mai multe evenimente în timpul execuției funcției:

Exemplu: unele lucrări cu un client au fost finalizate. Două evenimente au fost înregistrate simultan: s-au împăcat înțelegeri reciproce (evenimentul 1), actul a fost semnat (evenimentul 2). În practică, acest lucru este rar folosit. De regulă, dacă mai multe acțiuni sunt combinate într-o singură funcție

Conectarea elementelor, dacă în timpul executării mai multor funcții are loc un eveniment:

Exemplu: Depozitarul a ridicat comanda (funcția 1), operatorul a scris documentele (funcția 2), mărfurile sunt gata de expediere (eveniment).

Conectarea elementelor, dacă apariția unui eveniment duce la executarea mai multor funcții:

Exemplu: A sosit un lot de mărfuri (eveniment). Totodată, încep și expedierea mărfurilor comandate anterior de clienți și plasarea mărfurilor rămase în depozit.

Element logic „SAU”.

Elemente de conectare dacă unul dintre evenimente poate determina executarea funcției:

Exemplu: O cerere primită prin telefon (evenimentul 1) sau o cerere primită prin e-mail (evenimentul 2) va duce la necesitatea procesării acesteia.

Elemente de conectare dacă o funcție poate declanșa cel puțin un eveniment:

Exemplu: O factură a fost pregătită și trimisă pentru a fi trimisă unui client. Factura poate fi trimisă prin poștă (evenimentul 1), prin fax (evenimentul 2).

Element logic „SAU EXCLUSIV”.

Elemente de conectare atunci când unul și numai unul dintre evenimente este necesar pentru a executa o funcție:

Exemplu: Un client a venit personal la magazin (evenimentul 1) sau a făcut o comandă prin Internet (evenimentul 2). Trebuie să expediați mărfurile (funcția 1).

Conectarea elementelor, dacă cel puțin unul dintre următoarele evenimente are loc ca urmare a execuției funcției:

Exemplu: O decizie este fie luată, fie nu.

Conectarea elementelor dacă evenimentul are loc după ce una și numai una dintre funcții a fost executată.

Exemplu: Bunurile au fost livrate (evenimentul 1) fie prin transport propriu (Funcția 1) fie de către o companie de transport (funcția 2)

Aplicarea corectă a elementelor logice necesită o anumită practică. Dar nu este greu. Trebuie remarcat faptul că nu toate combinațiile considerate sunt utilizate pe scară largă în practică (în general, acest lucru este determinat de modul de gândire al analistului). Încercați să aplicați elemente de logică în practică. Dacă sunt dificultăți, scrieți-mi, voi încerca să vă ajut.

Extinderea notației cu propriile elemente

După cum am spus, eEPC nu este tocmai o notație, ci reguli de descriere. Și aceste reguli nu interzic adăugarea propriilor elemente la schemă. Principalul lucru este că aceste elemente sunt de înțeles și există un document în care sunt fixate astfel de extensii de elemente. De exemplu, folosesc următoarele elemente suplimentare care au apărut treptat în procesul de descriere a proceselor reale pentru diverse sarcini, de la o simplă descriere până la setarea sarcinilor pentru automatizare.

Fișier de date. Folosit atunci când un fișier de date este creat ca rezultat al unei operații sau un fișier este utilizat pentru a efectua o operație.

Bază de date. Folosit pentru a descrie fluxurile de informații între sisteme automate.

File cabinet. Folosit pentru a afișa un dulap de hârtie sau o arhivă.

fluxul de materiale. Folosit pentru a indica fluxurile de materiale de intrare și de ieșire, precum și resursele consumate în timpul execuției procesului. Fluxul de materiale este afișat în stânga documentelor însoțitoare.

cluster de informații. Folosit pentru a desemna informații structurate (reprezentare entități). Diagrama poate fi folosită pentru a se referi la documente generate programatic folosind aplicații personalizate. În acest caz, elementul „Cluster” este situat în stânga documentului corespunzător. Acestea. indică faptul că utilizatorul nu numai că a creat un document de hârtie, dar a creat și o instanță a acestuia în program.

Convenții privind regulile de plasare a formelor pe o diagramă

Notația eEPC în sine nu impune cerințe stricte privind aranjarea elementelor unul față de celălalt, deși este obișnuit să se deseneze o diagramă de sus în jos sau de la stânga la dreapta. Dacă acest lucru nu este unificat în cazul muncii mai multor specialiști, atunci poate apărea un fel de „vinaigretă”. Pentru a evita acest lucru, se recomandă să dezvoltați și să vă aprobați propriile reguli de aranjare a elementelor. Respect (și recomand) următoarele reguli:

• Secvența evenimentelor și funcțiilor este aranjată de sus în jos (mai bine) sau de la stânga la dreapta (dacă nu este suficient spațiu);
• Elementele care desemnează executanți sunt situate în dreapta funcțiilor;
• Documente primite în partea stângă sus a funcțiilor; direcția săgeții de la documente la funcție;
• Documente de ieșire în partea stângă jos a funcțiilor; direcția săgeții de la funcție la documente;
• Elementul „Informații” este situat în partea dreaptă jos a funcției. Dacă nu există suficient spațiu, este permisă o aranjare arbitrară, cât mai aproape de funcție;
• Elementul „Aplicație” este situat în partea dreaptă sus a funcțiilor. (dacă pentru aceasta sunt folosite depozite de fișiere care nu sunt rapoarte, acestea sunt afișate în mod similar). Comunicare fără săgeată.
• Elementele „Bază de date” și „Fișier card” sunt localizate în mod arbitrar;
• Elementul „Flux de material” este situat în stânga documentelor care îl însoțesc cu referire la document printr-o linie fără săgeată;
• Elementul „Cluster”, atunci când este utilizat în combinație cu cifra „Document” pentru a desemna un document în formă electronică, este situat în partea stângă a documentului corespunzător.

De exemplu: Calculatorul de salarii calculează salariile pe baza documentelor „Tuța de brigadă” care i-au fost furnizate. Totodată, el se ghidează după documentul „Reglementări privind salariile”, calculul se face în programul „1C: ZiK”. Rezultatul calculului este documentul „Vedomosti”.

Identificarea elementelor dintr-o diagramă

După cum știți, o abordare competentă a descrierii proceselor de afaceri presupune identificarea acestora, adică când fiecare proces are propriul nume de cod. În consecință, funcțiile individuale din cadrul unui proces au, de asemenea, propriile nume și identificatori.

Figurile „Document” și „Funcție” fac obiectul unei identificări obligatorii în diagramă.

Documentul se identifică prin indicarea codului raportului sau documentului în colțul din stânga sus în conformitate cu registrul. Documentele primite de la furnizorii de bunuri și servicii (incoming) sunt identificate numai după nume.

O funcție este identificată prin indicarea numărului ordinal al funcției pentru un anumit grup de procese. Acestea. numărul funcției începe întotdeauna cu codul grupului de procese. Problemele identificării grupurilor de procese depășesc domeniul de aplicare al acestui articol, le vom analiza separat. Mai mult, ar trebui să înveți cum să identifici procesele înainte de a începe să le descrii, altfel poate exista dorința de a descrie toate activitățile companiei într-o singură diagramă, așa cum încearcă să facă uneori.

Prin urmare, acum voi arăta doar cu un exemplu cum poate fi reprezentat acest lucru într-o diagramă. Să revenim la exemplul de gestionare a apelurilor. Să presupunem că am atribuit codul „04” departamentului de vânzări, codul „VK” procesului de procesare a contactului primit. Apoi, schema va lua următoarea formă (identificarea este evidențiată cu roșu pentru claritate). Codul documentului indică în același timp și numărul de serie al documentului în registrul general de documente (vom lua în considerare și acest lucru separat când vom ajunge la sondajul sistemului de management al documentelor).

Afișare feedback

Atunci când se construiesc modele, de multe ori devine necesar să parcurgeți procesul în funcție de anumite condiții sau de necesitatea de a afișa activitățile factorilor de decizie. În acest caz, vorbim despre feedback. Pentru a afișa feedback-ul de control, se utilizează principiul „includerii directe” în procesul unei funcții de control suplimentare, urmat de ramificare (folosind elementul logic XOR). De exemplu:

Descriere text a proceselor

Indiferent cât de mult ne străduim să arătăm procesul de afaceri pe o diagramă, nu va fi posibil să obținem detalii complete, altfel vă puteți bloca în lanțuri nesfârșite de elemente și condiții. Pentru a evita acest lucru, precum și pentru a adăuga informații la descrierea procesului care nu pot fi afișate grafic, descrierea este completată cu acompaniament de text. Pentru aceasta, sunt dezvoltate diverse șabloane de text, care sunt completate în timpul procesului de descriere. Formele unor astfel de șabloane pot fi diferite, includ secțiuni separate care descriu intrările și ieșirile, resursele consumate, software-ul utilizat etc.

În cel mai simplu caz, un șablon de descriere a procesului de afaceri ar putea arăta astfel:

Subiecte atât de importante precum colectarea de informații, evidențierea proceselor de afaceri, descompunerea și evidențierea indicatorilor au rămas în afara domeniului de aplicare al acestui articol. Cu siguranță vom studia aceste probleme în numerele viitoare.