Cum să crești profitul și să-ți faci afacerea de succes. Program educațional pentru manageri: modelarea proceselor de afaceri în unu-doi-trei

Ți-ai făcut vreodată ordine în biblioteca de acasă? Cărțile de pe rafturile de cărți stau de obicei așa cum au avut istoric. Dar, dacă biblioteca este mare și cărțile sunt folosite în mod constant, atunci cel mai probabil cărțile vor fi grupate după un anumit principiu. De exemplu, după gen și în cadrul unui gen - în ordine alfabetică. În ambele cazuri, rafturile își îndeplinesc funcția principală - depozitarea cărților. Dar utilizarea bibliotecii este în mod clar mai convenabilă în al doilea caz.

Formalizarea proceselor de afaceri într-o companie este asemănătoare cu sistematizarea cărților într-o bibliotecă - există criterii clare de clasificare și sunt definite principiile utilizării acesteia.

Dacă preferați să vă organizați biblioteca decât să pierdeți timpul căutând cartea potrivită, atunci vă puneți întrebarea: „ce metodă să alegeți?” Grupați cărțile în ordine alfabetică, după titlu sau după autor? Răspunsul, desigur, depinde de sarcinile pe care le îndeplinește biblioteca. Așadar, rezultă că este indicat să identifici și să formulezi aceste sarcini, iar apoi să le evidențiezi pe cele cu cea mai mare prioritate. De exemplu, dacă un copil folosește și biblioteca, atunci este recomandabil să plasați cărțile pentru copii pe rafturile inferioare.

Desigur, puteți lăsa totul așa cum este. Copilul va folosi în continuare sistemul dvs. de stocare a cărților, dar acest lucru nu îl va descuraja să citească? Și nu îți vei face griji pentru copilul tău de fiecare dată când „urcă” în vârf pentru o carte interesantă?

Această abordare este analogă cu optimizarea proceselor de afaceri dintr-o companie. Trebuie să găsim compromisuri și decizii raționale, beneficiind toți participanții la proces în acest moment.

Întrebarea logică este: „Unde este automatizarea în acest exemplu?”

Piața a dezvoltat deja un stereotip tipic (iertați tautologia) privind automatizarea proceselor de afaceri... Vin consultanții, vă iau de la muncă, vă pun întrebări stupide, vă obligă să citiți documente uriașe cu imagini de neînțeles și o grămadă de texte. .. Dar asta e deja stabilit. Lucrările continuă ca de obicei. Toată lumea știe cine ar trebui să facă ce. Răspunsul este în ordinea lucrurilor: „asta nu este pentru mine”... Sarcinile șefului sunt percepute ca o normă, din cauza căreia trebuie să renunți la totul și să alergi undeva, apoi să termini „după șase” ceea ce ai făcut nu am timp de facut.

De regulă, într-o astfel de situație oamenii se gândesc la automatizare atunci când șeful recunoaște brusc pentru sine că este blocat în activități operaționale. Toată munca lui se reduce la distribuirea de instrucțiuni, fără de care afacerea pur și simplu nu poate exista. Și acum „vin consultanții și iau angajații de la locul de muncă”...

De ce să pierzi timpul cu asta? Poate ar fi mai bine să implementăm un fel de sistem CRM?

Implementarea unui sistem CRM în special sau automatizarea în general nu este baghetă, care rezolvă toate problemele. Acesta este un proces destul de „minuțios”. Pentru a automatiza ceva, trebuie să înțelegeți principiile de a face afaceri și să evaluați în mod realist beneficiile. Este ca în exemplul cu biblioteca - mai întâi trebuie să sistematizați și să formalizați procesele, apoi, dacă este necesar, să le optimizați. Automatizarea este, de fapt, doar unul dintre instrumentele de optimizare. Dar dintr-un anumit motiv, de multe ori atunci când se automatizează, problema formalizării și optimizării proceselor nici măcar nu este pusă. Ei bine, da: „totul este deja aranjat, lucrul merge ca de obicei”...

Orice sistem tinde spre o stare de echilibru, prin urmare toate inițiativele interne sunt suprimate de sistemul însuși. Sistemul poate fi schimbat numai prin influență externă. În această influență externă acționează consultanții externi. „Atras” înseamnă „extern”. Acesta este ideea.

Primul lucru care este determinat sunt obiectivele și prioritățile cheie. Apoi posibile modalități de realizare, care, la rândul lor, se reduc la optimizarea activității departamentelor individuale și a angajaților acestora. După diviziunile individuale, este timpul să le organizăm interacțiunea.

Optimizarea este un lucru foarte specific și măsurabil. Sau asta nu este optimizare, ci populism. Dacă îmbunătățim ceva, trebuie să înțelegem clar prin ce parametri se evaluează amploarea acestei îmbunătățiri. Și aici „vin consultanți”... Dar ei nu „te iau de la muncă”, ci te ajută să faci ceea ce organizația în sine nu este capabilă să facă.

Rezultatul este o listă de procese efectuate de departamente și de angajați individuali. În cadrul fiecărui proces, regulile și reglementările și indicatorii cheie „apar”. Rezultatul muncii organizației devine măsurabil, ceea ce înseamnă că organizația devine mai gestionabilă.

Reglementările de lucru sunt formate dintr-un set de operațiuni standardizate, care sunt supuse unor cerințe formale. Și, atunci când există un set clar de operațiuni cu cerințe formalizate pentru implementarea lor și evaluarea eficienței, aici putem vorbi despre automatizare.

Anterior, rezultatele muncii consultanților erau prezentate doar pe hârtie. Astăzi sunt completate tehnologia de informație. Dar, în ambele cazuri, formalizarea este o descriere a principiilor și regulilor organizației. În același timp, automatizarea este un instrument care vă permite să îmbunătățiți performanța anumitor operațiuni. Dar nimic mai mult.

În total, prezența unei descrieri oficiale a proceselor de afaceri vă permite să:
- Evaluează performanța individuală a angajaților, departamentelor și interacțiunile acestora. Dezvăluie puncte slabeși schițați căile de optimizare.
- Definiți clar cerințele (adică evaluați calitatea) pentru mijloacele tehnice utilizate pentru îmbunătățirea eficienței.

Ei bine, trecerea de la cantitate la calitate. Acesta este, ca să spunem așa, pentru desert.

Când totul este „ordonat”, aspectele cheie ale activității organizației sunt revizuite și evaluate, managerul primește oportunitate suplimentară uită-te la „economia” ta de sus, și nu din interior (lucrurile mari se văd de la distanță). Această abordare, la rândul său, aduce rezultate neașteptate...

Un exemplu din viață. În timpul unui proiect de automatizare a proceselor de lucru cu datorii problematice (Colectare), clientul a insistat că nu au fost create acțiuni de reglementare planificate la începutul fiecărui nou caz. La urma urmei, fiecare afacere este unică și necunoscută dinainte, cum va decurge totul și altele asemenea... Dar după formalizare, care a fost efectuată ca parte a analizei proceselor de afaceri, imaginea a fost exact invers. S-a dovedit că tot ceea ce va face un executor individual (un avocat care însoțește cauzele judiciare) se reduce la realizarea exactă a acțiunilor planificate. Și planificarea în sine poate fi formalizată cu ușurință și, în consecință, va fi realizată automat. Desigur, cu control deplin al managerilor asupra procesului.

Adică formalizarea proceselor, în în acest caz,, a făcut posibilă restructurarea calitativă a organizării muncii interpreților și nivelarea factorului uman, care, după cum știm, este cel mai încăpățânat lucru.

Deci, înainte de a automatiza ceva, este extrem de util să formalizezi acest „ceva”.

Anton Timokhin

Manager de proiect al Direcției Dezvoltare a OBNL „ELSIB”

În mediul de afaceri modern, pentru a crește eficiența operațională, tot mai multe companii decid să implementeze proiecte pentru a-și descrie și optimiza procesele de afaceri. Cu toate acestea, astfel de proiecte, ca orice altă activitate de îmbunătățire, pot duce atât la rezultate pozitive, cât și negative. Prin urmare, sper că acest articol îi va ajuta pe managerii care încep să îmbunătățească performanța companiilor lor cu privire la modul de a evita capcanele posibile eroriîn etapele de lucru privind descrierea, optimizarea și implementarea ulterioară a noilor versiuni ale proceselor de afaceri.

Începutul a început

Repet că rezultatul implementării unui proiect de descriere, optimizare și implementare a unor noi versiuni de procese de afaceri poate fi atât pozitiv, cât și negativ, cu pierderi financiare pentru companie dacă munca nu este organizată corect. De ce încep astfel de proiecte?

Putem identifica o serie de motive principale pentru care, în urma diagnosticelor, managerii companiei decid să înceapă să lucreze la formalizarea și optimizarea proceselor de afaceri:

• Efectuarea de lucrări inutile (fără valoare adăugată), variabilitate mare a ciclurilor de lucru;
• Lipsa standardizării și unificării proceselor de afaceri, structura arbitrară a proceselor de afaceri, lipsa documentației care reglementează implementarea acestora;
• Arhitectura ineficientă a fluxurilor de informații (colectare, analiză, stocare a datelor), nivel insuficient de automatizare;
• Număr excesiv de divizii și departamente, dublarea funcțiilor, interacțiune ineficientă între ele;
• Încețoșarea domeniilor de responsabilitate, lipsa de responsabilitate pentru procesul de afaceri și rezultatul acestuia în ansamblu;
• Concentrarea tuturor puterilor la cel mai înalt nivel al ierarhiei, lipsa practicii delegării de competențe;
• Costuri excesive cu forța de muncă pentru activitățile de control și raportare, pierderi semnificative de timp pentru aprobări;
• Sistemul de evaluare a muncii nu motivează angajații să reducă costurile și să îmbunătățească calitatea indicatorii motivaționali sunt controlați de către motivați.

Lista continuă.

După ce a primit un semnal pe baza rezultatelor diagnosticului că există probleme de acest fel în companie, managerul poate concluziona: „trebuie să descriem și să ne optimizăm procesele, iar acest lucru ne va ajuta să scăpăm de toate problemele :) .” În același timp, nu sunt formulate un obiectiv clar și criterii de optimizare. Această abordare a stabilirii sarcinii pentru un proiect în sine are mai multe zone problematice care vor duce inevitabil la consecințe negative, iar probabilitatea de a obține un rezultat pozitiv este minimă:

• Credința oarbă a conducerii de vârf a companiei că introducerea unui nou sistem software (ERP, CRM, MRP etc.), care (conform dezvoltatorilor săi) după implementarea și utilizarea celor mai bune practici încorporate în modelele de referință, va face un miracol și afacerea în sine va începe să se schimbe latura pozitiva…;
• Este un fapt că descrierea proceselor de afaceri este considerată de mulți ca un instrument universal pentru rezolvarea problemelor. Dar, în practică, acest lucru este departe de a fi cazul - o descriere poate ajuta la eliminarea zonelor cu probleme, dar nu singură, ci ca parte a abordare integrată, una dintre componentele căreia poate fi formalizarea proceselor de afaceri ale companiei;
• Nicio problemă de afaceri. Compania funcționează și realizează ceva profit. Da, există unele dificultăți în comunicare, dar nimic mai mult decât „probleme de lucru”. De ce să se schimbe practica existentă de a efectua munca, mai ales că descrierea proceselor de afaceri va necesita investiții în software, pregătirea specialiștilor și distragerea atenției angajaților de la procesul de muncă? O scădere a eficienței companiei și o creștere a costurilor sunt inevitabile dacă obiectivele proiectului nu includ indicatori de business în creștere.

Câteva cuvinte despre optimizare

Descrierea proceselor de afaceri în majoritatea cazurilor este percepută ca un „leac pentru toate bolile”, dar puțini manageri se gândesc de ce este necesar să descriem procesele de afaceri existente? La urma urmei, gama de probleme care pot fi rezolvate prin simpla formalizare a proceselor este limitată, iar în alte cazuri este necesară optimizarea proceselor de afaceri ale companiei.
De regulă, optimizarea este tratată ca un fel de concept abstract, care nu poartă nicio altă sarcină decât cea emoțională: „acum vom rezolva toate problemele”, fără a acorda nicio atenție criteriilor de optimizare - ce proces, cât de mult să îmbunătățim și în ce limite acceptabile.

Dacă de obicei nu există dificultăți în identificarea zonelor de îmbunătățire (de exemplu, „este necesar să se reducă timpul necesar pentru finalizarea procesului de aprobare a cererii unui client”), atunci apar probleme cu identificarea și digitalizarea indicatorilor de îmbunătățire. Multe companii nu folosesc balanced scorecards și devine imposibil să se determine „cât de mult trebuie îmbunătățit” deoarece indicatorii care caracterizează funcționarea unui anumit proces nu sunt definiți și nu sunt calculați. Astfel, măsurarea îmbunătățirii este adesea subiectivă, „prin simțire”.

Un punct separat este stabilirea unor limite acceptabile pentru modificări. Nu este un secret pentru nimeni că managerul sau proprietarul companiei, în stadiul de începere a lucrărilor de îmbunătățire, stabilește o serie de restricții și interdicții, reducând optimizarea la nivelul modificărilor cosmetice care nu sunt în măsură să îmbunătățească radical nimic în situația actuală.

Despre instrumente și metodologii

De regulă, se acordă o atenție minimă problemei alegerii instrumentelor și metodologiilor atunci când se inițiază lucrările de formalizare a proceselor de afaceri. Implicația este că există puține diferențe în ceea ce privește sistemele și metodologiile de modelare a afacerilor de utilizat. Totuși, factorul determinant în alegerea software-ului și a metodologiei ar trebui să fie obiectivele care sunt planificate a fi atinse la implementarea unui proiect pentru a descrie și optimiza procesele de afaceri.

În funcție de obiectivele stabilite, de faza de dezvoltare a organizației și de starea sistemului de management, se pot distinge două abordări pentru formarea modelului de afaceri al unei companii:

• Identificarea și descrierea unui set de procese individuale de afaceri ale companiei - vă permite să identificați rapid relațiile cauză-efect și succesiunea de timp a acțiunilor, formalizați procesele și procedurile cu accent pe identificarea participanților, interpreților, evenimentelor inițiale și finale, succesiunea acțiunilor, mișcarea fluxurilor de obiecte;
• Crearea unui model cuprinzător de procese de afaceri - vă permite să creați un model de afaceri cuprinzător și consistent al companiei, cu accent pe crearea unei descrieri a sistemului, identificarea și descrierea obiectelor de management.

Aceste abordări nu se exclud reciproc, experiența arată că sunt posibile situații când este necesar să se rezolve probleme atât de descriere a sistemului în ansamblu, cât și de descriere a proceselor de afaceri individuale (locale). În acest caz, ar trebui să treceți de la general la specific: creați mai întâi un model al sistemului ca întreg și abia apoi, folosindu-l ca bază, creați modele ale proceselor individuale de afaceri.

Problema alegerii software-ului este de obicei o problemă foarte specializată și este adesea delegată specialiștilor departamentului IT pentru rezolvare cu participarea minimă a managerului companiei. Totuși, nu trebuie să uităm că metodele și instrumentele de descriere a proceselor de afaceri sunt specializate și nu sunt potrivite pentru rezolvarea problemelor cărora nu sunt destinate. O încercare de a utiliza un sistem selectat de specialiști tehnici, conceput pentru a descrie algoritmi și relații la nivel operațional, pentru a forma un model cuprinzător al proceselor de afaceri va necesita cel mai probabil costuri financiare suplimentare pentru finalizarea sistemului, făcând sarcina dificilă, consumatoare de timp. , sau pur și simplu imposibil.

Ce poți obține ca rezultat?

În cele mai multe cazuri, șeful unei companii, atunci când inițiază un proiect pentru a descrie procesele de afaceri, nu ține cont de tot ceea ce a fost descris mai sus, iar însăși ideea de a implementa un astfel de proiect a fost primită de el de undeva din exterior. .

În situația actuală, formularea sarcinii pentru proiect se reduce la „trebuie să descriem procesele de afaceri ale companiei noastre într-un timp scurt”. Dacă încercați să determinați această nevoie și să puneți mai multe întrebări clarificatoare, cel mai probabil răspunsul nu va avea legătură logic cu sarcina în cauză.

Următorul pas este crearea unei unități structurale în companie, în al cărei personal include analiști, sau luarea deciziei de a atrage consultanți terți pentru implementarea proiectului. Opțiuni posibile evoluțiile ulterioare sunt după cum urmează:

• Antreprenorul (analiști ai companiei sau consultanți externi), fără a pune întrebări inutile, începe cu conștiință să desfășoare lucrări la proiect. În același timp, deoarece nu existau instrucțiuni clare despre ce să descrie la începutul lucrării, fie sunt descrise toate procesele la rând, fie cele care sunt determinate de șeful companiei. Zilele trec una după alta, proiectul pare a fi implementat cu succes, dar rezultatul obținut nu justifică investiția. Procesele de afaceri sunt descrise așa cum se întâmplă de fapt în companie, modelele rezultate sunt complexe, confuze și adesea nu sunt potrivite pentru utilizare ulterioară. În ciuda acestui fapt, executivul încearcă să optimizeze procesele, dar din cauza experienței insuficiente în companie, folosind opinia cerc îngust indivizii, fără a ține cont de relațiile dintre procese, de fapt nu îmbunătățește nimic. Ca urmare, se cheltuiește o cantitate semnificativă de timp și resurse, problemele actuale de afaceri nu sunt rezolvate, iar managerul are o experiență negativă care nu îi permite să se întoarcă la o muncă similară în viitor;
• Antreprenorul începe să pună întrebări, clarificând de ce este necesară o descriere a proceselor de afaceri, ce rezultat se preconizează a fi atins, ce criterii de optimizare au fost stabilite. În această etapă, este posibil să primiți feedback negativ serios din partea conducerii companiei, deoarece, în primul rând, pur și simplu nu există răspunsuri, iar în al doilea rând, sarcina de a descrie procesele este formală, nesusținută de un lanț logic de concluzii și subsarcini. Sunt dezvăluite o serie de „trăsături” ale afacerii care sunt neplăcute pentru șeful companiei și la care anterior „a închis ochii”:
  • Dintr-o dată, se dovedește că descrierea proceselor „ca atare” este imposibilă, pur și simplu pentru că compania nu le are - activitățile se desfășoară pe baza experienței angajaților, deciziile sunt luate în funcție de situație și chiar procesele obișnuite sunt efectuate nu așa cum sunt consacrate. în regulamente, dar la fel de convenabil pentru artiști interpreți;
  • Afacerea este expusă la riscuri externe sau interne, nu există indicatori țintă, sistemul de stimulare nu contribuie la îmbunătățirea calității produselor/serviciilor, contabilitatea costurilor este incompletă sau absentă;
  • La descrierea proceselor, este relevată necesitatea unor schimbări semnificative în modelul de afaceri.

Nu uitați că, dacă procesele sunt optimizate în timpul descrierii, atunci după finalizarea proiectului de a descrie și optimiza procesele de afaceri, este nevoie de un alt proiect - introducerea de noi versiuni ale proceselor de afaceri în practica de aplicare de către personalul companiei. Dar acest proiect va necesita mult mai mult efort pentru a schimba bazele care s-au dezvoltat de-a lungul anilor în altele noi, neobișnuite, dezvoltate fără participarea majorității angajaților.

Astfel, descrierea și optimizarea proceselor de afaceri este o sarcină care necesită, pe lângă experiența și cunoștințele analiștilor, interes personal, disponibilitate pentru schimbare, o înțelegere clară a necesității proiectului, precum și modalități de atingere a obiectivelor stabilite. din partea managerului companiei. În caz contrar, atunci când se confruntă cu problemele și întrebările descrise mai sus, când devine necesar să se facă modificări în afacerea existentă, proiectul se va încheia chiar înainte de a începe.

Cele mai bune practici

Sarcinile de descriere a proceselor de afaceri sunt relevante astăzi pentru mulți mari companiile rusești, indiferent de apartenența la industrie. În cele mai multe cazuri, pentru a le rezolva, se formează unități analitice, care creează modele ale afacerii existente, reflectând particularitățile funcționării proceselor interne de afaceri.

Formarea unui model de afaceri cu drepturi depline pentru o companie este o sarcină foarte intensivă în muncă, care necesită o analiză atentă a etapelor cheie înainte de începerea lucrărilor. Problema afacerii, diagrama de rețea, raportarea și reglementarea, profunzimea și metodologia descrierii sunt probleme de bază care trebuie rezolvate înainte de începerea lucrărilor, altfel rezultatul nu se va ridica la nivelul așteptărilor.

Această secțiune conține recomandări pentru pregătirea și implementarea unui proiect pentru a descrie și optimiza procesele de afaceri. Secțiunea a fost pregătită pe baza experienței personale a autorului articolului pe baza rezultatelor implementării proiectului la o întreprindere de inginerie energetică, precum și luând în considerare cele mai bune practici ale altor companii aplicate în timpul lucrărilor.

Ipoteze: proiectul a fost implementat de divizia de analiză internă a companiei, specialiștii diviziei au experiență în implementarea proiectelor în domeniul dezvoltării organizaționale, la momentul începerii lucrărilor firma avea un sistem de management al calității, iar sistemul era utilizat ca un sistem de modelare a afacerilor Studio de afaceri.

Prima etapă - inițierea proiectului

Pentru implementarea proiectului, se formează un grup de management de proiect, se numește un curator de proiect și se emite un ordin de începere a lucrărilor de descriere și optimizare a proceselor de afaceri ale companiei.

Se recomandă desemnarea unui funcționar dintre adjuncți în calitate de supervizor de proiect director general, șefi de departamente care implementează funcții legate de dezvoltarea companiei. Curatorul trebuie să fie învestit cu toate puterile necesare pentru a rezolva problemele legate de implementarea lucrărilor la proiect.

Grupul de management de proiect include analiști specialiști care formează ulterior Centrul de competențe pentru procesele de afaceri ale companiei. In cazul in care firma a implementat si opereaza un sistem de management al calitatii sau un sistem de management integrat, in grupul de management de proiect ar trebui sa fie inclusi si specialisti din departamentul care implementeaza aceste functii. Acest lucru vă va permite să utilizați baza de cunoștințe acumulată pe procese și domenii cu probleme, să integrați funcții pentru descrierea, optimizarea și auditul intern al proceselor de afaceri. Grupurile includ, de asemenea, experți tehnici în diverse domenii de activitate pentru a obține opiniile experților și pentru a rezolva cu promptitudine probleme controversate privind funcționarea proceselor individuale.

Etapa a doua - sarcina de afaceri

Pe stadiu inițial Pentru a descrie și optimiza procesele de afaceri, grupul de management de proiect trebuie să efectueze diagnostice organizaționale. Scopul este de a identifica deficiențele în activitatea companiei, zonele cu probleme și motivele ineficienței proceselor de afaceri; îmbunătățirea calității planificării lucrărilor la proiect.

Diagnosticarea poate fi efectuată în mod clasic (interviu, sesiune strategică, analiza indicatorilor de performanță) sau folosind sistemul online BIZDIAGNOSTICS. Sistemul BIZDIAGNOSTICS este un instrument de management care vă permite să efectuați rapid și cu costuri minime cu resursele un audit intern al companiei și să obțineți informații fiabile și obiective despre calitatea sistemului de management al companiei, să identificați zonele cu probleme și să primiți recomandări pentru eliminarea acestora. Rezultatele diagnosticelor organizaționale stau la baza formulării unei sarcini de afaceri pentru proiect.

O greșeală comună este de a descrie procesele de afaceri de dragul descrierii în sine. O astfel de abordare va duce la o reacție negativă din partea afacerii, care nu va primi rezultate semnificative după munca analiștilor, deoarece modelul de proces de afaceri dezvoltat în sine nu este un rezultat semnificativ. Acest lucru subminează încrederea directorului și a conducerii de vârf a companiei în abordarea procesului în general și managementul proceselor în special, cu decizii organizaționale ulterioare privind „optimizarea” numărului de analiști interni sau oprirea completă a lucrului în această direcție.

Pentru a elimina această situație, în etapa de organizare a muncii, este necesară identificarea consumatorului și formalizarea cerințelor acestuia pentru modelul de proces de afaceri dezvoltat. Este mai bine dacă există mai mulți astfel de consumatori. De exemplu:

• Divizii structurale ale companiei interesate în reglementarea și optimizarea proceselor lor de afaceri;
• Divizii care îndeplinesc funcții de menținere a funcționării și dezvoltării sistemelor de management (sisteme de management al calității, sisteme de management integrate), deoarece fără managementul proceselor, funcționarea eficientă a sistemelor este dificilă;
• Departamentele IT pentru care modelul de proces simplifică definirea algoritmilor de lucru și formalizarea cerințelor pentru sistemele informaționale implementate.

Cerințele consumatorilor fac, de asemenea, posibilă stabilirea unui set de documente care se vor forma pe baza modelului de afaceri dezvoltat al companiei. Aceasta va identifica informațiile (de exemplu, datele necesare pentru a efectua o analiză funcțională a costurilor) care trebuie colectate ca parte a proiectului.

Formalizarea cerințelor consumatorilor sub formă de specificații tehnice va elimina majoritatea lucrărilor „inutile” din proiect, selectați un produs software, în cel mai bun mod posibil corespunzătoare sarcinii și, de asemenea, să obțină un rezultat semnificativ pentru afaceri cu mai puține costuri de timp, financiare și de muncă.

Pe baza rezultatelor diagnosticelor organizaționale și a specificațiilor tehnice, grupul de management al proiectului, după o sesiune cu șeful și top managementul companiei, a formulat o sarcină de business pentru proiect - au fost identificate domenii funcționale de îmbunătățire, criterii de optimizare (ce și cum). mult de îmbunătățit), iar cerințele consumatorilor modelului de afaceri în curs de dezvoltare au fost formalizate. De asemenea, problema afacerii trebuie să definească clar limite clare pentru schimbări (care schimbări de afaceri sunt acceptabile și care sunt inacceptabile). După aprobarea sarcinii de afaceri, este elaborat un program de rețea pentru implementarea proiectului.

Etapa a treia - software

Următorul pas important este selectarea software-ului necesar implementării cu succes a proiectului - un sistem de modelare a afacerii.

Un sistem de modelare de afaceri este un produs software pentru crearea și analiza modelului de afaceri al unei companii, proiectarea de noi procese de afaceri, dezvoltarea și menținerea la zi a unui pachet de documentație de reglementare. Sistemul joacă un rol important în proiectul de descriere a proceselor de afaceri, deoarece oferă un câmp informațional unificat pentru colaborarea analiștilor, oferindu-le instrumentele necesare pentru descrierea, analizarea și optimizarea proceselor de afaceri.

Produsul software a fost selectat după următoarele criterii:

• Abilitatea de a efectua o gamă completă de lucrări privind designul organizațional;
• Sistem automatizat colectarea și analizarea rezultatelor măsurării eficienței proceselor de afaceri ale companiei;
• Generarea automată a unui pachet de documentație de reglementare;
• Folosind notații populare de modelare a proceselor de afaceri, o interfață ușor de utilizat, care nu necesită instruire specializată pentru utilizatori;
• suport pentru sistemul de management al calitatii;
• Posibilitatea de personalizare flexibilă a sistemului (capacitatea de a introduce parametri și directoare utilizator).

După analizarea pieței sistemelor de modelare a afacerilor, s-a decis să folosim în proiectul nostru sistemul Business Studio, care îndeplinește cel mai pe deplin criteriile stabilite.

Etapa a patra - metodologie

Un proiect pentru a descrie procesele de afaceri într-o companie mare duce la dezvoltare cantitate mare modele de proces. Dacă ne imaginăm că toate diagramele sunt desenate diferit, atunci rezultatul rezultat nu va avea nicio valoare practică pentru companie. De aceea este important să se definească reguli clare pentru modelarea proceselor de afaceri într-o companie. În acest scop, este în curs de elaborare un Agreement on Business Process Modeling - un document care definește metodologia de descriere a proceselor de afaceri, procedura de interacțiune între participanții la procesul de descriere și optimizare a proceselor de afaceri, precum și mecanismele de punere în aplicare a pachet generat de documentație de reglementare, menținând starea actuală a modelelor de procese de afaceri dezvoltate.

Acordul de modelare a proceselor de afaceri determină notațiile de modelare utilizate, numărul de niveluri de descompunere (nivelurile de divizare secvențială a unui proces de afaceri în subprocese componente pentru a obține o vedere mai detaliată), relația dintre modelele de proces între ele, pachetele de documentație generată, stabilește reguli de lucru cu obiecte și cărți de referință în modelarea afacerii sistemului, determină parametrii care trebuie completați în sistem. După implementare a acestui document Grupul de management al proiectului este obligat să monitorizeze conformitatea acestuia de către toți angajații companiei implicați în proiect pentru a descrie și optimiza procesele de afaceri. Acest lucru va asigura unificarea modelelor aflate în curs de dezvoltare, va minimiza timpul petrecut pentru eliminarea „erorilor” care apar, inclusiv atunci când lucrați într-un sistem de modelare a afacerilor și va face posibilă obținerea unui pachet de documentație de reglementare care îndeplinește cel mai bine cerințele. consumatorilor pentru descrierea proceselor de afaceri.

Atunci când se determină nivelurile de descompunere a proceselor de afaceri, trebuie să se acorde atenție cerințelor consumatorilor pentru descrierea proceselor de afaceri, valabilitatea acestora, necesitatea și caracterul suficient al detaliilor în descriere. Foarte des, modelele de procese de afaceri sunt descompuse la nivelul acțiunilor individuale ale angajaților acolo unde acest lucru nu este practic. Aceasta duce la o creștere a numărului de modele în curs de dezvoltare, o creștere semnificativă a intensității forței de muncă fără a crește valoarea modelelor de dezvoltare a afacerii, deoarece detaliile excesive nu oferă întotdeauna informații pentru optimizarea proceselor.

Practica arată că fiecare nou nivel de descompunere crește volumul modelelor cu un ordin de mărime. Prin urmare, dacă este necesară optimizarea proceselor și determinarea zonelor de responsabilitate între diviziile structurale ale companiei, ar trebui să limitați detaliile la nivelul diviziei. Atingerea nivelului de acțiuni elementare este utilizată numai dacă modelul este dezvoltat în scopul automatizării sau reglementării activităților interpreților individuali.
La demararea unui proiect, împreună cu definirea cerințelor clienților săi, este necesar să se stabilească ce elemente ale mediului trebuie descrise. Dintre disciplinele care fac obiectul formalizării, trebuie evidențiate următoarele:

• Structura organizatorica;
• Sisteme informatice care susțin execuția proceselor de afaceri;
• Medii de stocare utilizate în procese.

În unele cazuri, modelul generat poate fi completat cu indicatori de performanță, cerințe pentru sistemele informaționale etc. Astfel, modelul de afaceri, pe lângă descrierea propriu-zisă a procesului, integrează diverse domenii, ceea ce îi crește semnificativ valoarea practică pentru analize ulterioare și optimizare.

Etapa cinci - model de afaceri, grupuri de lucru

Schema ulterioară a proiectului este prezentată în detaliu în Figura 1.

Figura 1. Schema fazei principale a proiectului de descriere și optimizare a proceselor de afaceri

Deci, următorul pas este dezvoltarea unui model de proces de afaceri de nivel superior. Vă permite să obțineți o vedere unificată a structurii afacerii. Este mai bine să se formuleze un model cu accent pe crearea de valoare, folosind principiile definirii și construirii lanțurilor valorice. Dezvoltarea modelului se realizează în formatul unei sesiuni strategice sau al unui joc de afaceri cu participarea șefului și a conducerii de top al companiei. Pentru a dezvolta un model de proces de afaceri de nivel superior, este cel mai convenabil să utilizați notația IDEF0.

La elaborarea unui model, se recomandă utilizarea informațiilor despre structura proceselor de afaceri ale companiilor dintr-o industrie similară și modele de referință în industrie. Modelul finit ar trebui să prezinte sistematic procesele de afaceri de nivel superior ale companiei, precum și cele mai importante relații dintre acestea, necesare înțelegerii funcționării afacerii.

Pe baza modelului de afaceri aprobat, sunt numiți proprietari de procese de afaceri (cu accent pe structura organizatorică actuală a companiei), precum și grupuri de lucru pentru a descrie și optimiza procesele de afaceri pentru fiecare dintre procesele de afaceri de nivel superior. Pentru a reglementa activitățile proprietarilor de procese de afaceri, a defini puterile și a delimita responsabilitățile, a Descrierea postului proprietarul procesului de afaceri. Scopul este de a stabili responsabilitatea pentru rezultatul procesului, de a determina responsabilități de serviciu, precum și autoritatea de a controla resursele necesare desfășurării procesului.

Ca parte a proiectului, proprietarii de procese de afaceri sunt responsabili pentru asigurarea implementării lucrărilor la:

• Descrierea și optimizarea proceselor dvs. de afaceri;
• Elaborarea de propuneri de optimizare a proceselor de afaceri;
• Analiza și coordonarea propunerilor de optimizare a proceselor de afaceri generate de participanții la grupul de lucru.

Grupul de management al proiectelor, împreună cu proprietarii de procese de afaceri, formează grupuri de lucru pentru a descrie procesele de afaceri de nivel superior. Grupurile includ manageri și specialiști ai diviziilor structurale ale companiei care, datorită experienței lor în companie sau a componenței responsabilităților postului, au o înțelegere suficientă a procesului de afaceri pentru a fi descris și optimizat. Grupurile de lucru sunt conduse de un lider grup de lucru. El este numit dintre șefii diviziilor structurale care participă la implementarea procesului de afaceri relevant. Mărimea grupului de lucru variază în funcție de „volumul” și complexitatea unui anumit proces de afaceri.

În cadrul proiectului, participanților din grupurile de lucru li se atribuie responsabilități pentru dezvoltarea unui model de procese de afaceri, pregătirea propunerilor de optimizare a proceselor de afaceri, pregătirea și realizarea aprobării pachetului elaborat de documentație de reglementare. Pentru realizarea eficientă a lucrărilor la proiect, timpul de lucru al membrilor grupului este repartizat în proporție de 30/70 (responsabilități proiect/post) din ordinul șefului companiei.

După ce ai făcut toate cele de mai sus activități pregătitoareși instalarea unui sistem de modelare a afacerii pe stațiile de lucru ale utilizatorilor, se asigură instruire membrilor grupurilor de lucru și, dacă este necesar, managerilor de mijloc și superiori ai companiei în metodele și principiile de descriere și optimizare a proceselor de afaceri. Se recomandă împărțirea instruirii în părți teoretice (pentru toată lumea) și practice (pentru participanții la grupul de lucru). Ar trebui să se aloce mai mult timp practicii descrierii proceselor de afaceri și lucrului cu sistemul de modelare a afacerii, lucrând la exemple simple abilități de lucru și demonstrarea greșelilor „clasice”.

Instruirea poate fi asigurată fie de către o terță parte, fie de către membrii echipei de management de proiect, dacă aceștia au suficiente competențe și experiență cu sistemul de modelare de afaceri utilizat.

Etapa a șasea - modelare, optimizare

După instruire, grupurile de lucru analizează activitățile diviziilor structurale, identifică și structurează procesele de afaceri care se desfășoară în acestea. Informațiile sunt introduse în arborele de proces al sistemului de modelare a afacerii, indicând numele procesului, managerul responsabil de implementarea acestuia, participanții, evenimentele de inițiere/încheiere și rezultate.

După identificarea proceselor în formatul jocului de afaceri, se realizează coordonarea încrucișată a proceselor reprezentând nivelul 1 de descompunere a proceselor de afaceri de nivel superior și, dacă este necesar, se perfecționează structura rezultată.

Următorul pas este stabilirea unor relații între subprocesele nivelului I de descompunere prin intrări și ieșiri, umplând modelul cu fluxuri de informații și fluxuri de obiecte. Trecerea la al 2-lea nivel de descompunere, introducerea informațiilor în sistemul de modelare a afacerii și convenirea asupra structurii subproceselor se realizează într-un mod similar.

Pentru a elimina dublarea informațiilor din directoarele sistemului, în această etapă, în grupurile de descriere și optimizare a proceselor de afaceri sunt desemnați persoane responsabile. Ei introduc date în directoare pe baza solicitărilor membrilor grupului.
De asemenea, pentru a crește eficiența muncii grupurilor, structurarea informațiilor în baza de date a sistemului, minimizarea timpului petrecut căutând informații în sistem la introducerea datelor în directoare ale grupului „Obiecte de activitate”, se recomandă crearea o structură de director (de exemplu, așa cum este descris în articolul „Organizarea muncii cu documente pe platforma Business Studio”).

După finalizarea lucrărilor la al 2-lea nivel de descompunere a modelelor de procese de afaceri de nivel superior, granițele subproceselor și proceselor de afaceri de nivel superior sunt coordonate de intrări/ieșiri, începutul și rezultatul procesului. Pentru a minimiza timpul petrecut cu aprobarea, se recomandă desfășurarea acesteia în format de jocuri de afaceri, construite pe principiul rapoartelor, în care grupurile de lucru își „modeliază” procesul, vorbesc despre el din momentul în care începe până la final. se obține rezultatul, iar restul participanților (proprietari de proces, reprezentanți ai proiectului grupului de management, supervizor de proiect, experți tehnici) efectuează ajustările necesare. Dacă este necesar, în timpul jocurilor de afaceri, participanții la joc elaborează decizii comune asupra problemelor controversate care apar în timpul descrierii proceselor de afaceri. De regulă, ca urmare a coordonării, structura proceselor din modelul de afaceri al companiei este ajustată.

Prima versiune rezultată a modelului de afaceri al companiei este supusă unei descompunere ulterioară - sunt dezvoltate modele ale nivelurilor 3 și 4. Coordonarea acestor modele se realizează în formatul unui joc de afaceri cu implicarea proprietarului de proces, a reprezentanților grupului de management de proiect, a proprietarilor de proces care sunt consumatori ai rezultatelor procesului de afaceri și a experților tehnici. În timpul coordonării, este clarificată mișcarea fluxurilor de informații și a fluxurilor de obiecte, sunt clarificate pozițiile managerilor responsabili cu implementarea proceselor, componența participanților la nivelul diviziilor structurale și posturile de angajați.

După primirea celei de-a doua versiuni a modelului de afaceri, se efectuează aprobarea finală a acesteia, rezultatul este a treia versiune de lucru principală, care va sta la baza bazei de cunoștințe corporative privind procesele de afaceri ale companiei. Pe baza acestei baze de cunoștințe se vor lua măsuri pentru optimizarea în continuare a proceselor de afaceri sau dezvoltarea metodelor și procedurilor la nivelul acțiunilor elementare.

Este important ca afacerile să obțină rezultate rapide din investiții. Un proiect care să descrie și să optimizeze procesele de afaceri nu face excepție, mai ales că are ca scop creșterea eficienței companiei în ansamblu. Pentru a prezenta rezultate semnificative într-un interval de timp acceptabil, în etapa de descriere a proceselor de afaceri, se recomandă formularea de propuneri de optimizare a proceselor de afaceri folosind instrumente de identificare și eliminare a pierderilor, principii și metode de optimizare a proceselor de afaceri. Propunerile de optimizare a proceselor de afaceri sunt luate în considerare în timpul jocurilor de afaceri cu participarea reprezentanților grupului de management de proiect, ai proprietarilor de procese și a tuturor părților interesate și, dacă sunt de acord, sunt reflectate în modelul de afaceri dezvoltat.

Etapa a șaptea - implementare

După ce s-a convenit asupra versiunii finale a modelului de proces de afaceri al companiei, activitatea de descriere și optimizare a proceselor de afaceri este transferată în mod permanent - după cum am menționat mai devreme, grupul de management de proiect devine Centrul de competență pentru procesele de afaceri ale companiei, participanții la grupurile de lucru pentru descrierea și optimizarea proceselor de afaceri continuă să își combine activitățile curente în diviziuni structurale companii cu modelarea, analiza și reglementarea proceselor lor de afaceri.

Modelele de procese de afaceri dezvoltate și documentația de reglementare sunt puse în aplicare prin ordin al șefului companiei. Informațiile sunt comunicate angajaților în conformitate cu regulile stabilite de companie, precum și folosind un navigator HTML situat pe resursa rețelei corporative.

Respectarea cerințelor reglementărilor și procedurilor puse în aplicare se verifică în cadrul auditurilor interne efectuate de auditori interni (dacă societatea are sisteme de management în vigoare) sau de specialiști din departamentul de analiză intern. Procedura și calendarul auditurilor sunt stabilite prin documentul de reglementare relevant. Eficacitatea activităților companiei este evaluată pe baza rezultatelor diagnosticelor organizaționale, precum și a datelor de monitorizare privind indicatorii de performanță a procesului de afaceri.

Practica arată că, la momentul începerii lucrărilor de descriere și optimizare a proceselor de afaceri, companiile au deja un pachet mare de documentație de reglementare (în special tipic pentru companiile care au sisteme de management în vigoare). Este adesea imposibil să transferați unele dintre documentele din acest pachet într-un sistem de modelare a afacerii pentru generația viitoare în mod automat, din cauza costurilor mari de timp și forță de muncă. Pentru a sincroniza documentele existente cu noile versiuni ale proceselor companiei, la etapa de descriere a procesului, este necesar să le analizăm relevanța. După acordul asupra versiunii finale a modelului de afaceri, documentația existentă este complet actualizată și legată de noile versiuni ale proceselor de afaceri.

În loc de concluzie

Rezumând cele de mai sus, aș dori să observ că, la fel ca în orice chestiune complexă, atunci când îmbunătățim performanța companiei, este important să înțelegem cu exactitate motivele inițierii proiectului și să folosiți cele mai bune metode și instrumente în proiect. Sperăm că acest articol va elimina multe întrebări care apar managerilor și va facilita decizia de a începe schimbări. Suntem siguri că rezultatul nu vă va face să așteptați!

Modelul SIPOC este utilizat în Six Sigma și managementul calității pentru a defini limitele proiectului și procesele de revizuire de sus. Datorită detaliilor noastre de sarcini, acest model a funcționat perfect la altitudini mai mici. Voi reveni la câteva concluzii despre „înălțimea” revizuirii procesului de mai jos.

Acest model poate servi ca furnizor de material pentru formalizarea proceselor de afaceri în notații general acceptate. În multe cazuri, acest model poate descrie complet procesele companiei, dacă respectați metodologia, în acest caz, modelul poate sta la baza specificațiilor tehnice pentru modificări sau implementarea configurațiilor standard 1C;

Acest model are argumente pro și contra, așa că nu susțin adoptarea universală, dar cred că o perspectivă alternativă este întotdeauna utilă. Inclusiv pe mine. Scrie ce crezi in comentarii.

Înainte de a începe

Esența ideii de formalizare a procesului folosind metoda SIPOC este că:

1. Acordăm o atenție deosebită „scării” procesului sau, așa cum o numesc și „înălțimea punctului de vedere”.
2. „Desfășuram” procesul ca o minge, pornind de la consumatorii rezultatului final al procesului, terminând cu inițiatorul acestuia. Nu invers!
3. Acordăm o atenție deosebită „joncțiunilor” etapelor procesului.
4. Acordăm o atenție deosebită lizibilității hărții procesului.

Destul de ciudat, dar în ciuda faptului că aceste puncte sunt evidente, aproape toate hărțile de proces pe care le-am întâlnit în viața mea au încălcat cel puțin două dintre aceste patru puncte. Dacă acest articol vă ajută să înțelegeți aceste puncte fundamentale, atunci voi considera că mi-am atins scopul, indiferent de notația pe care o folosiți.

Ce este SIPOC

Deci SIPOC este un acronim pentru cuvinte englezești Furnizor (furnizor), Intrare (intrare), Proces (proces), Ieșire (ieșire), Client (client) . Acest model vă permite să descrieți procesele în termeni de succesiune de acțiuni, mișcarea informațiilor/produselor/serviciilor între etapele procesului, precum și relațiile care apar ca urmare a procesului dintre diverșii participanți. Modelul vă permite să urmăriți logica de afaceri a unui proces, cu un nivel de abstractizare ridicat, dar ușor de gestionat.

Imediat un exemplu clar de descriere a procesului. Noțiunile de bază le puteți vedea aici.

(S) Horns and Hooves LLC -> (I) Cerințe de sistem informațional -> (P) Formalizarea cerințelor -> (O) Specificații tehnice -> (C) 1C: Francizat

Citim de la stânga la dreapta: Clientul exprimă cerințele pentru sistemul informatic, care sunt formalizate, rezultând o specificație tehnică pentru 1C: Francizat.

Afișează vizual:

Acum să ne dăm seama ce este și pentru ce este.

S - Furnizor (furnizor). În exemplul nostru, aceasta este o organizație. Acest rol poate fi orice element al procesului care asigură intrarea procesului cu unele informații, documente, materiale, produse, bunuri, servicii etc. În general, acesta este un furnizor de orice, orice este implicat în mod necesar în proces. .

I - Intrare. În exemplul nostru, acestea sunt cerințele pentru sistemul informațional. Aceste cerințe pot fi sub formă e-mail, descrise oral în timpul negocierilor sau înregistrate în interviurile anterioare. Tot ceea ce este necesar pentru proces este descris aici. Pentru această descriere se aplică cerințe, motiv pentru care acronimul SIPOC poate fi văzut în unele surse ca SIRPORC. Aceste cerințe, după cum indică acronimul, se aplică atât pentru intrare, cât și pentru ieșire.

De obicei, nu afișăm vizual cerințele de intrare sau de ieșire decât dacă condițiile o cer (nu am întâlnit niciodată acest lucru în practica noastră, dar orice este posibil). Dar descriem aceste cerințe în anexa la afișarea vizuală a procesului de afaceri. Acest lucru este dictat de inconvenientul emergent de utilizare a cardurilor SIPOC pentru utilizarea ulterioară în documentația de proiect, din cauza volumului lor în creștere. Dar pentru a consolida vizual tehnica în capul nostru, o vom desena astfel:

Cerințele pentru obiectele incluse în proces pot fi orice condiții care sunt necesare pentru execuția cu succes a procesului. Săgeata este direcționată de la proces către furnizor, deoarece furnizorul este cel care trebuie să respecte cerințele. Aceasta poate fi calitatea măsurabilă sau cantitatea materialelor, dacă aceasta este producție, sau poate fi cerința „disponibilității analizei SMART în scopul implementării unui sistem informațional”, dacă acesta este un pre-proiect etc.

P - Proces. Aici descriem procesul care va avea loc. În exemplul nostru, aceasta este formalizarea cerințelor. De obicei, acest bloc descrie cine este responsabil pentru proces, eventual rolul lor. Este descris procesul de producere a ceea ce va fi rezultatul. Desenez o imagine doar pentru a oferi o reprezentare vizuală a procesului.

De obicei, oferim această descriere în anexa la o afișare vizuală a procesului de afaceri. [Ignorați săgețile diagonale, desenez în timp ce scriu articolul]

O - Ieșire. Aici descriem ce ar fi trebuit să rezulte din etapa anterioară. În exemplul nostru, aceasta este o sarcină tehnică. Specificațiile tehnice ca „ieșire” din proces au propriile cerințe, care sunt formulate de client. De exemplu, 1C: Francizatul are un standard pentru proiectarea specificațiilor tehnice ” este descris de noi în anexă Dar pentru a o remedia vizual, să terminăm desenul:

C - Client. În exemplul nostru, acesta este 1C:Franchisee, care primește o sarcină tehnică ca urmare a formalizării cerințelor.

Acesta este un exemplu foarte simplificat. Este necesar doar să treceți peste partea de sus și să vedeți imaginea în ansamblu.

Subtilități

Aceasta este o descriere a procesului dintr-o vedere de ochi de pasăre. Desigur, procesul în sine este mult mai complicat. Deci, mai întâi, să începem cu capacitățile de granularitate din cadrul procesului.

Dacă avem mai mulți furnizori de obiecte „incoming” sau mai multe obiecte „incoming” în sine, atunci acestea pot fi afișate astfel:

Același lucru este valabil și pentru obiectele „ieșite” și clienții:

Acum, dacă ne imaginăm că avem nevoie de mai multe detalii în procese și cerințe, atunci desenul va deveni din ce în ce mai puțin lizibil. Pe care, de altfel, vrem să-l evităm.

Nivelul nostru de detaliu este determinat empiric individual cu fiecare client.

Pentru a menține lizibilitatea procesului, începem să împărțim procesul în etape. Fiecare etapă este o copie a modelului SIPOC cu propriile intrări și ieșiri. De exemplu, un pre-proiect poate fi împărțit în două sau mai multe etape, în funcție de detaliul solicitat. Le voi desena pe primele două.

Dacă te uiți cu atenție la aceste două etape, vei observa că primele trei elemente ale celei de-a doua etape „Consultant-Protocoale-CIO” dublează ultimele trei elemente ale primei etape. Acestea sunt joncțiunile etapelor procesului. Vom reveni la ei mai târziu.

Dar cum rămâne cu procesele ciclice? Dar procesele paralele? Dar ramurile?

Voi răspunde la toate întrebările în ordine.

Procesele ciclice sunt întotdeauna considerate de la o „înălțime” care permite ca procesul ciclic să fie definit ca o etapă unitară separată. De exemplu, în ultima figură, vedem că protocoalele sunt transmise CIO pentru aprobare. Știm că aprobarea poate dura mult timp, deoarece... cineva a uitat ceva sau, dimpotrivă, și-a amintit ceva și protocoalele vor merge înainte și înapoi până când se primește „ieșirea” procesului - protocoale semnate. Dacă un proces ciclic conține blocuri fundamental importante pentru automatizare, atunci o iterație a unui astfel de ciclu este descrisă de un card SIPOC separat.

Procesele paralele, dacă situația o permite, sunt descrise prin carduri SIPOC separate. Dacă relațiile proceselor paralele în timp sunt complexe, atunci SIPOC este folosit doar pentru a descrie procese, relațiile proceselor în timp sunt descrise de alte instrumente. Acest lucru depășește aplicarea cardurilor SIPOC.

Acum despre ramuri. Dacă un proces conține ramuri, atunci hărțile SIPOC descriu etapele procesului înainte și după ramuri. În acest sens, SIPOC nu este deloc un instrument convenabil. Dacă există o mulțime de ramuri, atunci aceasta înseamnă că fie a fost selectată „scara” greșită, fie că este necesar să folosiți alte instrumente.

Pe de o parte, înțeleg că SIPOC are avantajele și dezavantajele sale. Pe de altă parte, experiența automatizării diferitelor procese arată că procesele cele mai corecte, stabile și de lucru la același nivel (dacă procesele sunt la niveluri diferite, atunci sunt desenate pe hărți diferite) sunt aproape întotdeauna liniare și, în mod ideal, tind spre o lista de verificare. Procesele complexe fie au fost schițate de o companie de consultanță, fie sunt rodul imaginației pe tema „cum ar putea fi”. Este rar, dar se întâmplă ca procesul să fie cu adevărat complex și să nu existe cu adevărat altă cale. De îndată ce întâlnim procese complexe, ne punem în prealabil întrebarea că, cel mai probabil, procesul nu este construit optim sau este descris incorect. Cel mai adesea acest lucru se întâmplă atunci când cineva dorește să descrie totul dintr-o dată pe o singură bucată de hârtie, deși una foarte mare.

Acesta este foarte asemănător cu procesul de programare. Folosim un nivel de detaliu în proceduri și funcții care ne permite să navigăm cu ușurință. Imaginați-vă ce s-ar întâmpla dacă 1C ar avea un singur modul care ar fi responsabil pentru tot și nu ar exista proceduri și funcții care să mărească nivelul de abstractizare al algoritmului.

Există diferite niveluri de management și niveluri diferite de scară corespunzătoare.

Pe această hartă nu vedem soldați, echipamente sau unități. „Înălțimea” revizuirii nu permite. Dacă luăm controlul operațional ca analogi: ramuri, cicluri etc., atunci nu vom vedea aceste roți dințate de la o asemenea distanță. De fapt, ei nu aparțin aici; această hartă este un instrument de planificare strategică și tactică. Managementul operațional necesită utilizarea altor instrumente de vizualizare.

Nu poți vedea totul în detaliu în același timp. Trebuie să existe cărți diferite Pentru puncte diferite recenzie. Dacă această cerință este îndeplinită, atunci aproape toate procesele care corespund în detaliu „înălțimii” revizuirii pot fi descrise de modelul SIPOC. De aici am tras la un moment dat următoarea concluzie: dacă procesul este descris printr-o metodăSIPOC, atunci „înălțimea” vederii de ansamblu a procesului corespunde nivelului de detaliu. Aceasta poate părea o declarație controversată. Sper că dacă greșesc, camarazi mai competenți mă vor corecta în comentarii. Sunt mereu gata să mă perfecționez. Dar până acum nu am reușit să experimentăm opusul experimental.

Cum se desenează o hartă a procesului?

Acum, după ce am examinat metodologia de descriere a proceselor în sine, trebuie să învățăm cum să o desenăm.

În primul rând, trebuie să stabilim nivelul de detaliu. După cum am scris mai sus, determinăm nivelul de detaliu să fie corect atunci când este evidențiat un proces liniar. „Înălțimea” revizuirii nu trebuie să fie mai mică decât nivelul operațiunilor necesare contabilității. Aceste. Nu are sens să descriem procesul la nivelul „interpretului a luat un stilou și a început să scrie”, deoarece Aceste informații nu sunt reflectate în contabilitate în niciun fel.

Când un consultant vine la un interviu pentru sondajul de proces, el aderă la următoarele recomandări.

Dacă citim procesul de la stânga la dreapta de sus în jos, atunci începem să desenăm procesul de la dreapta la stânga de jos în sus! Adică:

Client: Mai întâi determinăm cine va fi consumatorul rezultatelor procesului. Acestea pot fi alte departamente, posturi specifice, eventual contractori externi.

Proces: Apoi descriem procesul în sine, ca o secvență de acțiuni și persoana responsabilă pentru execuția acestei etape.

Intrare: Descriem ceea ce este necesar pentru a finaliza această etapă și cerințele pentru aceasta.

Furnizor: Descriem cine va furniza procesului componentele necesare.

Am descris etapa cea mai de jos rezultată a procesului. Și apoi începem să desfășurăm mingea, urcând o treaptă. Acesta este modul în care toate etapele sunt descrise secvenţial.

Acum, dacă vă amintiți, puțin mai sus am scris despre joncțiunile etapelor procesului. Le-a venit rândul. De regulă, în timpul examinării (acest lucru este tipic pentru etapa de examinare în general) sunt dezvăluite diferite nuanțe. Dintr-o dată se dovedește că era nevoie de un document pentru a finaliza o etapă de proces, dar se dovedește că nu a existat niciodată și pasul de proces a fost efectuat înainte fără a lua în considerare acest document. Mai mult, pentru că documentul nu a existat niciodată, nu este clar cine ar trebui să-l furnizeze pentru etapa de proces. Sau se dovedește că la un moment dat este emisă o „ieșire”, care se dovedește a nu fi de folos nimănui, adică. când revizuim procesul mai târziu și vedem „clienți” care consumă „ieșiri” și apoi nu participă în altă parte, atunci este foarte posibil ca ceva să se facă în zadar. Nu este întotdeauna cazul, de exemplu, rezultatul poate fi un formular tipărit, care mai târziu merge la departamentul de contabilitate, dar în cadrul automatizării, contabilitatea nu este prezentă. Pentru a descrie procesul, o astfel de „ieșire” va fi inutilă, dar în limitele limitărilor procesului este acceptabilă. În orice caz, nu strică niciodată să verifici.

Aceste joncțiuni conduc uneori la extinderea cerințelor. De exemplu, într-o zi, în timp ce examinăm procesele unui client, am întrebat despre unele interfețe. S-a dovedit că era necesar să se emită acte sumare și facturi în baza contractului, iar contabilul a compilat totul manual. Nu existau cerințe inițiale pentru acest circuit, dar identificând acest punct în timpul procesului de inspecție tocmai în etapa de analiză a îmbinărilor și a necesității acestora, am elaborat un concept de soluție, l-am propus conducerii clientului și am primit un buget suplimentar pentru acest circuit. .

În urma unor astfel de interviuri, consultantul întocmește procese, întocmește protocoale de anchetă de proces, le coordonează și le transmite, împreună cu înregistrările audio ale interviului, managerului său pentru analize ulterioare.

Nu bonusuri explicite

Metodologia SIPOC, fiind un instrument simplu, vă permite să primiți bonusuri care nu sunt în totalitate evidente. Puteți, cu pricepere, să utilizați acest instrument în diferite situații.

Cardurile SIPOC în sine sunt ușor de citit și ușor de înțeles de factorii de decizie. Acest lucru vă permite să creați sondaje de „vânzare”. S-a întâlnit adesea pe proiecte medii și mari că decidentul nu știa să citească notațiile din seria IDEFx. În acest caz, le-am tradus la un nivel mai înțeles, dacă se poate, pentru că uneori erau prostii de-a dreptul. Dacă lucrăm cu departamentul IT, atunci suntem de acord cu ei cu privire la descrieri suplimentare în documentele de proiect, dacă nu se pronunță „împotrivă”, atunci continuăm să aderăm la notația SIPOC; Dar se întâmplă să fie necesare alte notații, de obicei IDEF0 și/sau IDEF1, acest lucru se întâmplă foarte rar. Până acum, nu am auzit un argument semnificativ în favoarea acestor notații, în afară de faptul că acesta este un standard familiar și nu au văzut niciodată SIPOC. Cu excepția unui proiect în care era necesar să se automatizeze procesul de direcționare a unui client către departamente în funcție de ce cumpără, în ce volum etc., erau foarte multe sucursale. De fapt, aceasta este automatizarea managementului operațional complex, cardurile SIPOC nu au locul acolo.

Un alt bonus este abilitatea de a determina „înălțimea” revizuirii unui proces. Adesea comunicând cu șefii diferitelor structuri, deja în conversație, pe baza semnelor indirecte, devine clar că „înălțimea” revizuirii procesului nu este aleasă corect. Și numai din această cauză, managementul în companie este practic nivel zero. În acest caz, apelez, într-un fel, la consultanță. Vă ajut să înțelegeți înălțimea revizuirii și etapele proceselor. De regulă, acest lucru vă permite să obțineți un contact mai apropiat pentru comunicare ulterioară și să creșteți nivelul de încredere ca expert. În ciuda descrierii lungi, toate acestea se pot întâmpla într-un singur prânz de afaceri.

Ei bine, probabil ultimul lucru pe care aș vrea să-ți spun. Uneori, clienții fie nu au fondurile pentru o examinare, fie pur și simplu nu înțeleg pentru ce plătesc de fapt și, ca urmare, devin lacomi. În acest caz, le ofer o opțiune în care completează și detaliază singuri procesele. Se dovedește a fi o consultanță atât de superficială, care uneori duce la proiecte. Acest lucru se întâmplă în corespondență, unde le trimit brief-uri gata făcute, iar ei le completează. Ne sunăm reciproc când apar întrebări. Această abordare vă permite să nu întrerupeți relația, să mențineți un dialog și în același timp să nu pierdeți timpul dacă clientul este avid de bani, se află într-o situație de economisire forțată sau pur și simplu nu înțelege pentru ce să plătească consultanții. După ce a gustat amărăciunea muncii de consultanță, fie produce un rezultat cu care să înceapă să lucreze, fie sare, calificându-se ca client nețintă, fie cumpără o examinare normală. În orice caz, cu această abordare rămânem într-o poziție puternică. În primul caz, am ajutat fără să ne pierdem timpul, care ne va fi creditat ulterior. În cel de-al doilea caz, am economisit mult timp și nervi în acțiunile nețintă. Și în al treilea am câștigat bani din sondaj.

Suma tuturor factorilor: simplitatea metodei, ușurința de învățare și oportunități ample pentru consultanta, acestea sunt toate avantajele care ne fac sa folosim metoda iar si iar. Până în prezent, nu am întâlnit încă o astfel de combinație de utilitate pentru examinare și îmbunătățirea calității comunicării cu clienții în orice metodă. Din nou, repet, colegi, împărtășiți experiențele voastre, mă bucur să învăț.

În timp ce pregăteam acest material, am decis să caut ce era în RuNet pe această temă, destul de mult. Dar acest lucru vă va permite să vă extindeți înțelegerea asupra acestui subiect:

Yandex.pictures conține o grămadă de exemple de carduri SIPOC

6 Sigma, producție slabă...

... și poate asta e tot.

Este atașat un exemplu de bucată dintr-o specificație tehnică reală, care a inclus o mică hartă a procesului și un apendice la aceasta. Acest lucru este pentru claritate, cum îl folosim în proiecte reale.

P.S. După cum am scris deja, am decis să încep un buletin informativ. Lista de corespondență este momentan în modul de repaus. Nu sunt încă mulți abonați, dar sunt deja destul de mulți abonați. Acum sunt deja 143 de persoane și încă 9 nu și-au confirmat abonamentul (verificați-vă dosarul Spam, uneori scrisoarea de confirmare ajunge acolo). Sunt doar 15 zile de la existența newsletter-ului, care mă inspiră cu adevărat. În viitorul apropiat voi desfășura un mic training online gratuit. Nu sunt un antrenor profesionist și acesta este mai degrabă un hobby, dar cred că va fi de interes pentru trăgătorii liberi și șefii de organizații implicați în automatizări bazate pe 1c. Toate elementele tehnice ale instruirii sunt în curs de pregătire. Dacă ți-a plăcut acest material, te poți abona la newsletter. Intenționez să continui publicarea pe IS; lista de corespondență va include materiale care nu se potrivesc cu formatul IS (de exemplu, nu mi-am dat seama cum să desfășor cursuri aici).

Când compania este mică și toată lumea îi cunoaște pe toată lumea (până la aproximativ 30 de persoane), nu sunt necesare procese de afaceri formalizate, în teorie. Când compania este mare, separată geografic sau sarcinile nu sunt banale, cantitatea de haos începe să crească rapid. Trebuie să luptăm cu asta. De exemplu, am decis să implementăm procese de afaceri în momentul în care am încetat să mai recunoaștem fețele unora dintre proprii angajați.

Prima întrebare rezonabilă pe care vreau să o pun este de ce este nevoie de această „birocrație”. Răspunsul este simplu: practic este ca o refactorizare. La exterior totul este la fel, dar la interior este deja logic, funcționează clar și te poți dezvolta rapid mai departe.

Un exemplu de proces din anii 1900

Este obișnuit? Nu. Este intuitiv? Nu. Profitabil? Da, dacă costurile de renovare și recalificare a lucrătorilor sunt mai mici decât profitul așteptat.

La fel este și implementarea proceselor de afaceri: trebuie să înțelegeți care este intrarea, care ar trebui să fie rezultatul și cum să o realizați în mod optim. Dacă costul cercetării și schimbării companiei este mai mic decât profitul așteptat din aceasta, trebuie făcut.

Cronologia luptei împotriva haosului

1. Suntem patru, toată lumea înțelege totul.
2. Apar două magazine diferite: reguli pentru acceptarea e-mailului și reguli pentru răspunsurile obligatorii la aceasta sunt deja necesare.
3. În orașe apar reprezentanțe. Începe colectarea sistematică a informațiilor instrucțiuni interne, sfaturi și alte lucruri menite să ajute situatii diferite: în esență o experiență pozitivă și colecții de greble moștenite.
4. Interacțiunile pe site devin mai complicate. Dezvoltatorii creează un sistem de urmărire și bilete.
5. Suntem atât de mulți încât aceleași întrebări ni se pun de mai mult de trei ori. Un blog corporativ privat este creat pentru a putea fi la curent cu totul, pentru a raporta rapid problemele și pentru a schimba mecanica procesului.
6. Se angajează o echipă de specialiști care planifică procesele de afaceri din cadrul companiei, întocmesc instrucțiuni precise și o organigramă. În esență, există un proces de descriere a proceselor existente și de optimizare a acestora acolo unde este necesar.
7. Toată această bucurie este adaptată situației.

Sunt necesare procese dacă o echipă de 10 persoane?

Exemplul 1: simplu, dar dureros de familiar - o caracteristică a clientului.

1. Întâlnire între client și manager pentru stabilirea sarcinii.
2. Coordonarea criteriilor de acceptare a sarcinilor.
3. Șeful departamentului întocmește specificațiile tehnice pentru dezvoltator.
4. Termenii de referință sau reperele sunt convenite cu clientul.
5. Dezvoltarea este în curs.
6. Șeful departamentului conduce recepția.
7. Managerul livrează proiectul clientului.

• Nimeni, cu excepția managerului tău, nu poate stabili sarcini pentru tine (nici măcar CEO-ul).
• Nu lucrezi niciodată fără termeni de referință clari.
• Nu vezi clientul. Nici măcar nu-l vezi pe manager dacă vrei cu adevărat.
• Un client care se răzgândește brusc cu o idee nouă în ultima zi de dezvoltare este o problemă a managerului.
• Sunteți responsabil pentru greșeli doar față de managerul dumneavoastră (și el față de client).
• Lucrezi nu pentru „oboseală”, ci pentru rezultate. Adică dacă dezvoltarea a fost finalizată într-o oră, asta nu înseamnă că vei primi mai puțin decât dacă s-a făcut într-o lună.

Exemplul 2, acum din practica Mosigra
Introducere: există un birou nebun pentru 50 de persoane și structurat clar magazine cu amănuntul. Să presupunem că un vânzător cu amănuntul are nevoie de un raft nou pentru a-l înlocui pe cel care tocmai s-a stricat. Iată ce face în vechea schemă:

1. Contactează punctul superior și raportează problema.
2. Managerul punctului contactează coordonatorul regional și raportează problema.
3. Coordonatorul bate la șeful departamentului de administrație și raportează problema.
4. Șeful departamentului de administrare atribuie o sarcină unui lucrător general.
5. Un om de mână aprobă un buget de la supervizorul său pentru un raft nou.
6. Pe masă se pune o factură pe care directorul financiar să o semneze.
7. Vine a doua zi.
8. Muncitorul instalează în sfârșit un nou raft.

Acum aceeași situație arată astfel:

1. Vânzătorul contactează AXO și raportează problema.
2. Ofițerul de management administrativ ia o decizie cu privire la oportunitatea utilizării fondurilor.
3. Un muncitor instalează un raft nou.

Dacă AHO emite o factură care depășește planul departamentului lor, se generează o alertă pentru management, unde există două butoane: „dați lyuley” și „permite”. Puteți apăsa pe ambele dacă doriți. Esența mecanicii: calea este mai scurtă și mai rapidă, dar se menține controlul deplin. Fără pași suplimentari.

Metrici

Este deja mai dificil de evaluat munca cumpărătorului: dar construirea unui proces de afaceri face posibilă înțelegerea exactă a ceea ce s-a întâmplat cu produsul, cum exact a devenit și cât de eficient este.

Shoals

Când sectoizii aterizează

• El apelează la oricine este responsabil pentru această problemă (cel mai probabil fără a-și distrage atenția managerului).
• Dacă situația se repetă, se creează un proces de reguli pentru a gestiona astfel de cazuri.

Cum se implementează toate acestea în companie?

1. În primul rând, analistul vorbește cu managerul și înțelege problema. Se întâmplă ca procesele să fie introduse pentru spectacol, astfel încât mai târziu să fie mai profitabil să vinzi afacerea unui străin, uneori este pentru show-off, iar alteori este pentru afaceri. Ultimul caz este cel mai interesant și mai complex.
2. Este prezentată o factură care provoacă disonanță cognitivă. În acest moment, trebuie să conveniți asupra condițiilor astfel încât plata să fie efectuată atunci când indicatori specifici cresc. Aproximativ vorbind, au început să primească cu 20% mai mult profit ca urmare a implementării - plata.
3. Apoi, analistul parcurge întreaga companie și pune multe, multe întrebări despre cum funcționează.
4. Apoi fiecare angajat primește un chestionar prin care îi cere să-și indice sarcinile curente (este nevoie de o jumătate de oră pentru a-l completa).
5. Analistul se gândește mult și întocmește o organigramă de interacțiune, din care cresc procesele și organigrama companiei.
6. Compania se reorganizează pentru a se adapta la noi procese.
7. Esența schimbărilor este comunicată angajaților. Dacă angajații sunt mai în vârstă, le este greu să înțeleagă, dar o fac imediat. Dacă sunt tineri, înțeleg perfect, dar se schimbă încet.
8. Bug-urile sunt corectate. Structura se schimbă pe măsură ce compania și procesele acesteia se schimbă.

Termenele limită

De ce altfel trebuie să implementăm astfel de lucruri?

• Pentru a controla fluxul de lucru, nu pierde sarcini și a vedea cine face ce anume.
• Pentru fiecare articol din companie, apare o anumită persoană responsabilă (fiecare problemă are un nume de familie).
• Nu explicați unei persoane noi de fiecare dată, de exemplu, cum să vă înregistrați pentru plecare etc.
• Este mai eficient să scalați fără a explica întreaga esență a vieții fiecărui angajat dintr-un alt oraș.
• Acceptă rapid oameni noi.

Rezumat: argumente pro și contra

• Mai puțin haos, mai multă ordine
• Apar descrieri clare de post
• Există o organigramă care optimizează procesele
• Procesele IT sunt strâns legate de cele reale și devine posibilă automatizarea multor lucruri.

• Procedura durează mult și necesită mulți bani: de exemplu, începerea ei în perioada de vârf sezonier al vânzărilor nu este cea mai bună idee.
• Un consultant nu este un magician. El nu rezolvă problemele, ci sugerează soluții standard(care sunt și în cărți) și ajută la rafinarea lor pentru companie. Aceste soluții standard sunt implementate cu participarea directă a conducerii.
• Va trebui să muncești mult și din greu, atât în ​​construirea proceselor, cât și în implementarea lor.
• În cele din urmă, acest lucru este costisitor pentru companie, așa că trebuie să înțelegeți foarte clar ce vor oferi exact toate acestea.

UPD. Mi-au amintit într-un mesaj personal că, pentru a construi procese de afaceri, trebuie să formulați obiective strategice și chiar o misiune (în într-un mod bun acest cuvânt). Da, altfel nu va fi clar ce să faci, unde să faci și cum să faci: ai nevoie de un fel de ADN sau modus operandi al companiei.