Când un om a sfâșiat lumea, el a încetat să ridice efectul nu numai al legilor divine, ci și al oamenilor.

Lumea în care trăim este o colecție interconectată de sisteme naturale și artificiale.

Sistem - un set de elemente care sunt interconectate și interacționează între ele, care formează un singur întreg, care are proprietăți care nu sunt inerente elementelor sale constitutive, luate separat.

Sistemele pot fi complexe (de exemplu, planetele din sistemul solar), complexitate medie ( nava spatiala, aeroport), și poate fi super complex (sisteme de interacțiuni moleculare în organismele vii.

Orez. 1 Sistem aeroportuar: flotă de aeronave și servicii la sol

La întrebarea „Este organizația (întreprinderea) un sistem?” toti raspund afirmativ. Da, organizația este un obiect destul de complex care funcționează ca un singur organism, motiv pentru care este considerată a priori ca un sistem. Da, există o mulțime de probleme în organizație în diverse domenii: de la planificarea financiară până la colectarea gunoiului și toate sunt legate într-o oarecare măsură.

În rezolvarea acestor probleme sunt implicați lucrători de diferite specialități, care văd organizația doar în cadrul profesiei lor. Și chiar și un director care este responsabil pentru absolut totul nu poate acoperi toate aspectele organizației pe care o conduce. El o vede în primul rând ca pe un obiect management organizatoric, și încredințează alte aspecte ale activității adjuncților săi, care, la rândul lor, au în subordine manageri responsabili de un domeniu separat de activitate etc. Acest lucru ne permite să spunem că organizația are o mare varietate de sisteme.

Elementele sistemului

Deci, dacă o organizație este un sistem, atunci este un set de elemente interdependente. Care sunt elementele unei organizații? Muncitori, mașini, calculatoare... Dar clădirile, stingătoarele și drumurile de pe teritoriul complexului industrial? Și aici ne putem „îneca” pur și simplu în elemente enumerate.

Sistemul este ca o cutie neagră

Să încercăm să privim organizația din cealaltă parte. Imaginează-ți ca pe o cutie neagră. Dar atunci apare o întrebare. Ochii cui (din punct de vedere al cui ne vom uita la organizatie? Putem aduna toate cunostintele noastre, si sa indicam ca urmare a activitatii produsele, serviciile, taxele platite, gunoaiele scoase, poluarea mediului, numarul de cazuri castigate in tribunal, etc.

Dar de ce să evidențiem un astfel de mega-sistem? De ce trebuie să reflectăm toate acestea în sistem? Ce problema rezolvam? „Noi” – cine este: economiști, avocați, manageri, pompieri?
Să revenim la punctul de plecare: de ce am început să analizăm organizația? Care este problema? Siguranța la incendiu nu este asigurată? Calitate slabă a produsului? Cheltuieli mari pentru întreținerea organizației? Rezultate de referință dezamăgitoare?

Alegerea unui sistem este întotdeauna subiectivă. În același timp, este important să cunoașteți și să utilizați următoarele recomandări practice:
. Este necesar să decidem din punctul de vedere al cui evidențiem sistemul;
. Încercați să o prezentați sub forma unei cutii negre, acordând atenție, în primul rând, la rezultatele țintă (rezultatele muncii);
. Determinați care sunt elementele și conexiunile sistemului alocat.

2. Cum se analizează o întreprindere dacă o întreprindere este un sistem?

Întrucât o întreprindere este un sistem, analiza de sistem ar trebui utilizată ca parte a studiului (analiza activităților) unei întreprinderi.

Etapele analizei sistemului

În studiul oricărei probleme a sistemului, pot fi remarcate etapele principale:

1) stabilirea scopului studiului;

2) evidențierea problemei (sistemului): evidențiați principalul, esențial, aruncând nesemnificativul, nesemnificativul;

3) descriere: a exprima într-o singură limbă (nivel de formalizare) fenomene și factori de natură eterogenă;

4) stabilirea criteriilor: să se determine ce este „bun” și „rău” pentru evaluarea informațiilor primite și compararea alternativelor;

5) idealizare (modelare conceptuală): introduceți o idealizare rațională a problemei, simplificați-o până la o limită acceptabilă;

7) compoziție (sinteză): combină părți într-un întreg fără a pierde proprietățile părților;

8) soluție: găsiți o soluție la problemă.

SADT Metodologia de analiză structurală pentru cercetarea sistemului de procese de afaceri al organizației

Au fost dezvoltate o serie de metodologii și instrumente aferente pentru analiza sistemului. Metodologia de analiză structurală SADT este utilizată pe scară largă în practică.

Metodologia SADT (Structured Analysis and Design Technique) pentru analiza și proiectarea structurale este o metodologie concepută special pentru descrierea și analiza sistemelor artificiale care se încadrează în categoria de complexitate medie.

Metodologia de analiză structurală și proiectare a fost aplicată cu succes pentru a descrie un număr mare de sisteme artificiale dintr-o gamă largă de domenii: bancar, rafinare a petrolului, producție industrială, sisteme de ghidare a rachetelor, management logistic, metodologie de planificare etc.

Analiza structurală este un studiu care constă în construirea unui model de sistem într-o formă generală mărită, urmată de descompunerea acestuia (downscaling) sub formă de blocuri funcționale interconectate. Descompunerea se realizează la nivelul necesar de detaliu.

Modele și modelare descriptivă

Descrierea unui sistem în termeni de SADT se numește model. Un model este o reprezentare idealizată care descrie sistemul cât mai precis posibil. Scopul principal al construirii unui model este de a defini și documenta aspectele de funcționare a sistemului pentru a înțelege cum funcționează sistemul acum și cum va funcționa în viitor. Acestea. modelul ar trebui să ne ajute să obținem răspunsuri la un set de întrebări. Dacă modelul nu răspunde la toate întrebările sau răspunsurile sale nu sunt suficient de precise, atunci spunem că modelul nu și-a atins scopul.

M este un model al unui sistem S dacă M poate fi folosit pentru a răspunde întrebărilor despre S cu acuratețe A.

Un model al unui sistem suficient de complex este o familie de submodele consistente care descriu sistemul din diferite puncte de vedere. La modelare, pot fi utilizate diferite limbaje de modelare (notații).

Orez. 2 O familie de submodele consistente ale sistemului studiat, descrise prin diferite limbaje de modelare

Notația este un set de simboluri (obiecte) și reguli pentru aplicarea lor.

Notația constă dintr-un set de obiecte grafice (simboluri: imagini matematice, grafice), un set de obiecte negrafice (text) și anumite relații între aceste obiecte.

3. Metodologia analizei structurale SADT

Pentru ca orice metodologie să funcționeze, principiile ei trebuie respectate întocmai.

Principiile de bază ale metodologiei SADT

Principii de bază ale metodologiei de analiză structurală:

1) Definirea scopului modelării;

2) Determinarea limitelor modelului (modelul stabilește exact ce este și ce nu face obiectul modelării);

3) Stabilirea unui singur punct de vedere

NOTĂ. Pentru a crea un model consistent al atelierului de mașini, puteți lua punctul de vedere atât al maistrului, cât și al mecanicului sau al controlorului. Cu toate acestea, niciunul dintre modelele rezultate nu vă va permite să scrieți un manual de instruire pentru întregul personal al magazinului. Doar din poziția șefului magazinului se pot vedea toate tipurile de lucrări efectuate în magazin. Din punctul său de vedere este posibil să se urmărească interrelațiile dintre responsabilitățile diferiților angajați.

4) Formarea modelului sistemului studiat ca ierarhie de diagrame interconectate (descompunere succesivă). Partea de sus a acestei structuri arborescente este cea mai generală descriere a sistemului, iar baza sa sunt descrierile (diagramele) cele mai detaliate (vezi Fig. 2).

Standardul IDEF0 este unul dintre standardele metodologiei SADT

Metodologia SADT și dezvoltarea acesteia - standardele IDEF - sunt utilizate pe scară largă în lume de o mare varietate de companii din diverse domenii de activitate.
Cel mai comun standard IDEF0 este o metodă de modelare structural-funcțională care descrie procesele de afaceri ca un sistem ierarhic de funcții interconectate.

Fig.3 Specificarea laturilor blocului în standardul IDEF0

Semnificația diagramei prezentate în figura 3 este următoarea: ca urmare a procesului, „intrarea” sub influența „controlului” este transformată într-o „ieșire” prin „mecanism” (performer).

Ieșirile unui bloc pot fi intrări, sau comenzi sau mecanisme (executoare) pentru altele. Interrelațiile blocurilor între ele și cu mediul extern sunt reflectate de arcuri de interfață. Arcurile de interfață sunt reprezentate de săgeți, a căror orientare reflectă direcția fluxurilor de obiecte (materiale, financiare, informaționale).

Etapele construirii unui sistem de procese de afaceri în standardul IDEF0 (notație)

Construirea unui model de proces în notația IDEF0 începe cu construirea descriere generala proces și interacțiunea acestuia cu mediul. Acest model este reprezentat ca o cutie neagră și se numește diagramă de nivel zero (sau diagramă de context).

Diagrama de context ar trebui să arate
. scopul modelării (de exemplu: dezvoltarea unui nou proces, reducerea timpului de execuție a procesului etc.);
. punct de vedere (director de organizație, specialist IT, specialist financiar etc.).

Fig.4 Diagrama contextuală în standardul IDEF0

Diagramele nivelurilor următoare detaliază procesul superior până la nivelul la care primesc răspunsuri la întrebările puse. Numărul de niveluri de descompunere nu este limitat de nimic, cu excepția oportunității și bunului simț.
Destul de des, mecanismele (resursele) nu sunt afișate pe diagramele nivelurilor superioare, dacă aceasta nu este cu adevărat o informație necesară. Acest lucru se face pentru a nu „supraîncărca” modelul.

Toate obiectele diagramei trebuie să aibă descrieri text.

Construirea unei descompunere este un proces multivariat și creativ. Dacă există un specialist care va oferi o altă opțiune de descompunere, atunci se pot folosi diagrame FEO (doar pentru expunere - doar pentru imagine).
În diagramele FEO, atenția este concentrată pe interacțiunile input-output, ceea ce face posibilă evaluarea fezabilității transformărilor sau verificarea compoziției fluxurilor interne (materiale, informaționale) generate de proces.

4. Unde să utilizați sistemul de procese de afaceri?

bazat pe Comindware Business Application Platform

Un sistem cuprinzător de management al proceselor de afaceri Low-code (BPMS): modelarea în notație BPMN 2.0, automatizarea proceselor, managementul cazurilor reprezintă o bază de încredere pentru transformarea digitală a unei întreprinderi.

Mai mult decât modelare și performanță

Platforma Comindware Business Application oferă un set complet de instrumente pentru modelarea, executarea, optimizarea proceselor de afaceri ale unei organizații, care sunt tipice sistemelor BPM tradiționale și nu numai. În plus, compania primește o serie de avantaje tipice pentru sistemele de clasă iBPMS (Intelligent BPM Suite) și platformele Low-code:

• Instrumente online convenabile pentru gestionarea proceselor de afaceri. Modelare, execuție, analiza procesului, managementul sarcinilor, proiectarea arhitecturii de procese de întreprindere, integrarea BPMS cu sisteme terțe.
• Suport pentru executarea sarcinilor creative. Soluțiile BPM bazate pe platforme de la Comindware nu sunt concentrate pe procese de afaceri precum BPMS tradiționale, lăsând loc pentru munca creativă (cazuri/sarcini).
• Managementul proceselor în mâinile oamenilor de afaceri (Low-code). Centrul de greutate pentru dezvoltarea și ajustarea ulterioară a aplicațiilor de afaceri este transferat de la programatori la analiști.

Specificul implementării tuturor instrumentelor principale de management al proceselor în platforma Comindware Low-code și o serie de beneficii unice de afaceri disting Comindware Business Application Platform de BPMS tradițional.

Setul de instrumente BPM pentru gestionarea și
optimizarea proceselor de afaceri

Digitalizarea profundă și distribuția sa în întreaga afacere — conditie necesara succesul afacerilor moderne. O tehnică de management numită BPM (Business Process Management) care include metodologie și software ajută afacerile să se dezvolte în această direcție. O afacere care practică tehnica managementului proceselor este construită ca un set de procese de afaceri end-to-end, care ajută la eliminarea barierelor funcționale din companie și crește radical eficiența tuturor departamentelor. Suportul tehnologic pentru metodologia BPM îl reprezintă sistemele de management al proceselor de afaceri (BPMS).

Comindware Business Application Platform include un set complet de instrumente de management al proceselor de afaceri incluse în software-ul de clasă BPMS. Fiecare instrument inclus în platforma Low-code de la Comindware este implementat ținând cont de cerințele actuale ale afacerii pentru flexibilitate atât în ​​procesele de afaceri principale, cât și în cele auxiliare ale întreprinderii.

Modelarea proceselor de afaceri

Modelul grafic al procesului de afaceri este componenta principală a managementului procesului de afaceri și demonstrează relația dintre toate elementele procesului din cadrul unei organizații sau exploatații. O astfel de vedere ajută la concentrarea asupra informațiilor vizate și semnificative pentru rezolvarea problemelor de optimizare a proceselor de afaceri.

Platforma Comindware oferă instrumente flexibile și ușor de utilizat pentru modelarea proceselor de afaceri, chiar și pentru cei care nu sunt profesioniști în BPM. Mai mult, dezvoltarea formularelor, personalizarea interfețelor și configurarea integrărilor de bază sunt realizate și de analist într-un browser web și nu necesită abilități de programare. Analistul de afaceri creează o diagramă de proces, definește participanții, descrie setul și ordinea acțiunilor lor. Modelele grafice construite sunt conforme cu BPMN 2.0, standardul global actual pentru BPM.

Modelarea arhitecturii de proces

Succesul managementului de proces al unei companii depinde în mare măsură de capacitatea organizației de a prioritiza corect optimizarea proceselor, concentrându-se în primul rând pe capacitățile cheie ale afacerii. Capacitatea de afaceri este ansamblul de procese, oameni și tehnologii care creează valoare în conformitate cu obiectivele strategice ale companiei. Cu alte cuvinte, o capacitate de afaceri este un element care descrie „ce” este capabilă să facă o companie, iar procesele de afaceri, la rândul lor, descriu „cum” o companie își implementează capacitățile. Modelul de capabilități de afaceri vizualizează întreaga gamă de capabilități ale unei anumite afaceri, în timp ce arhitectura de proces ajută la vizualizarea interdependenței proceselor.

Comindware Business Application Platform oferă capacitatea de a construi rapid un model de capabilități de afaceri și arhitectură de proces, de a vizualiza relația dintre procese, de a le lega de obiective specifice. Diagrama capacității de afaceri este actualizată în timpul optimizării, ceea ce ajută la analiza situației de sus în jos și la planificarea eficientă a schimbărilor viitoare.

Automatizarea unui proces de afaceri presupune parcurgerea automată a pașilor acestuia și notificarea utilizatorilor sistemului cu privire la sarcinile și acțiunile cerute acestora la etapa curentă a procesului. În funcție de setările selectate, procesul de afaceri poate fi pornit manual sau automat în funcție de un program, o solicitare primită sau o condiție. Cu drepturile de acces corespunzătoare, utilizatorul poate primi informații despre etapele anterioare și următoare ale procesului și poate evalua vizual stadiul finalizării acestuia.

Funcționalitatea BPMS a platformei Comindware se bazează pe un „motor” de proces care:

• Cereri de trasee
• Automatizează atribuirea sarcinilor către utilizatori
• Apelează sisteme și servicii externe
• Acceptă cereri de la sisteme externe
• Colectează datele necesare, le prelucrează
• Oferă acces la date în contextul unui proces de execuție

Sistemul Comindware BPM asigură execuția procesului de complexitatea și nivelul necesar de descompunere într-un singur sistem.

Monitorizarea proceselor de afaceri

Monitorizarea procesului de afaceri al întreprinderii este unul dintre instrumentele BPM care ajută persoana responsabilă să identifice „blocurile” în cursul execuției procesului de afaceri și să răspundă situațiilor critice prin ajustarea schemei de proces sau a acțiunilor angajaților. Pentru a rezolva cu succes problemele de monitorizare, este esențial să aveți acces efectiv la statisticile procesului și capacitatea de a afișa datele într-un format convenabil.

În timpul execuției proceselor de afaceri, Comindware Business Application Platform colectează statistici detaliate despre metricile și indicatorii acestora. O reprezentare vizuală a acestor date simplifică controlul execuției procesului, identificarea punctelor de optimizare și accelerare. Datele statistice sunt, de asemenea, o sursă de informații pentru reinginiere și optimizare a proceselor complexe de afaceri ale companiei, adoptare decizii de managementși ajustări ale arhitecturii procesului.

Optimizarea proceselor de afaceri

Optimizarea proceselor de afaceri presupune o gamă largă de activități care vizează îmbunătățirea eficienței operațiunilor companiei și îmbunătățirea calității implementării capacităților și serviciilor de afaceri ale întreprinderii. Optimizarea proceselor de afaceri, spre deosebire de reinginerie, se realizează în mod continuu, de regulă, ea acoperă o zonă destul de îngustă la nivelul capabilităților de afaceri sau al funcțiilor organizației.

Platforma de aplicații Comindware Business vă ajută să identificați potențialele oportunități de optimizare și vă permite să vă testați ipotezele față de procesele de afaceri reale. O imagine informativă a oportunităților de optimizare este dată de arhitectura de proces a întreprinderii, împreună cu datele statistice din monitorizarea proceselor de afaceri. Puteți optimiza procese specifice și puteți lega interacțiunea lor între ele. Pentru a optimiza un proces de afaceri, este suficient să faceți modificări modelului său grafic din browser fără a întrerupe execuția proceselor care rulează deja în BPMS.

Managementul sarcinilor

O condiție importantă pentru o implementare nedureroasă și de succes a unei abordări prin proces a managementului întreprinderii este furnizarea de instrumente simple și convenabile de gestionare a sarcinilor pentru angajații obișnuiți ai companiei, iar platforma low-code a Comindware le oferă.

Oricât de complicată este conectarea proceselor de afaceri, proiectelor și cazurilor din companie, angajatul își vede sarcinile într-o singură interfață accesibilă din browser, sau direct în MS Outlook, cu setarea corespunzătoare a integrării în casete. Acest lucru ajută la planificarea timpului, prioritizarea și gestionarea sarcinilor mai eficient. Managerul vede sarcinile unui anumit angajat și, de asemenea, poate obține un rezumat al tuturor proceselor, proiectelor, cazurilor în care este implicată o anumită persoană, chiar dacă alte departamente sau divizii sunt responsabile pentru acestea.

Integrare cu sisteme terțe

Comutarea angajaților între mai multe sisteme încetinește semnificativ munca și deseori face imposibilă automatizarea proceselor de afaceri. Sarcina unui sistem BPM este de a crea un nivel dedicat de gestionare a proceselor care este situat deasupra altor tehnologii, integrat cu sistemele de informații vechi (ERP, CRM etc.) și vă permite să implementați procese de afaceri end-to-end și să eliminați nevoia pentru a comuta între mai multe sisteme.

Platforma de aplicații Comindware Business oferă o integrare extinsă cu alte sisteme. Integrarea prin protocolul OData este configurată cu un „mouse”, pentru alte protocoale a fost creat un API deschis bazat pe standardul Web Services. O altă posibilitate de integrare este prin roboți RPA.

Suport pentru executarea sarcinilor creative

În lumea modernă, din ce în ce mai mult, artiștii executanți care lucrează conform reglementărilor aprobate sunt înlocuiți de lucrători ai cunoștințelor, pentru care procesele fixe tradiționale nu sunt potrivite. În plus, există adesea excepții în activitatea companiilor/instituțiilor care nu intră în domeniul de aplicare al proceselor de afaceri descrise. În aceste cazuri, sunt necesare forme de lucru mai flexibile și mai dinamice, pe care le oferă managementul adaptiv de caz (Adaptive Case Management/case management). Un caz este un proces care „se desfășoară în timp”: este planificat doar primul pas și, pe baza rezultatelor sale, se ia o decizie asupra altora ulterioare, spre deosebire de procesele de afaceri în care toți pașii sunt predeterminați.

Comindware Business Application Platform include suport pentru cazuri și oferă un spațiu unic atât pentru lucrul cu șablon, cât și pentru planificarea creativă din mers.

Managementul cazurilor (ACM)

ACM este o abordare destul de tânără a gestionării sarcinilor creative, procesul de rezolvare care este greu de oficializat sau nu trebuie reglementat. Platforma de aplicații de afaceri Comindware a fost proiectată și construită în acest moment dezvoltare activă Abordarea ACM și suportul pentru managementul cazurilor au fost inițial incluse în funcționalitatea de bază a platformei. Prin încorporarea suportului atât pentru cazuri, cât și pentru procesele de afaceri în funcționalitatea platformei, aceste controale se îmbină și se îmbină perfect unele cu altele. Nu există nicio barieră de nepătruns între fluxurile de lucru și cazurile tradiționale - atât procesele de afaceri, cât și cazurile generează sarcini care sunt gestionate în același mod. Diferă doar felul în care apar sarcinile: în cazul unui proces de afaceri, acestea sunt create automat conform schemei de proces, în cazul unui caz, angajatul autorizat decide singur ce să facă în fiecare etapă și cui să delege subsarcini. .

Migrarea de la cazuri la procesele de afaceri

„Cele mai bune practici” de management al proceselor de afaceri funcționează cel mai bine atunci când sunt trecute prin prisma experienței lor - date din istoria companiei în sine. Platforma de aplicații de afaceri Comindware minimizează ciclul de la o idee la un proces de afaceri funcțional.

Platforma low-code vă permite să încercați rapid, în format de cazuri, în practică reală diverse abordări de organizare a procesului de procesare a cererilor sau sarcinilor non-standard. Statisticile colectate în timpul procesării vă vor ajuta să alegeți cea mai bună opțiune. Gestionarea recurentă a excepțiilor colectează statistici și cele mai bune practici pentru gestionarea unor scenarii specifice. Această experiență poate fi transpusă cu ușurință într-un proces organizat și executabil prin migrarea de la cazuri la procese. În plus, cazurile și procesele de afaceri sunt strâns legate în cadrul platformei. Deci, un caz poate apela un proces și invers, iar toate sarcinile generate de ele sunt reflectate în lista de sarcini end-to-end, precum și în modelul integrat de capabilități de afaceri.

Low-code: managementul proceselor de afaceri în mâinile oamenilor de afaceri

Principalul beneficiu al automatizării afacerii este reducerea costurilor de operare. Transformarea digitală reduce timpul de răspuns al afacerii la schimbare nevoi reale clienților, ceea ce presupune adesea nu aprofundarea automatizării, ci formarea de noi modele de afaceri. Întreprinderile sunt din ce în ce mai interesate să permită utilizatorilor de afaceri să participe activ la îmbunătățirea proceselor de afaceri și să creeze ei înșiși aplicații de afaceri.

Platforma Comindware Business Application acceptă conceptul de Low-code la maximum, cu un minim de codare și un maxim de dezvoltare vizuală. Platforma de la Comindware rezolvă problema principală a digitalizării - accelerarea ciclului de la o nevoie de afaceri la un proces de afaceri funcțional.

Dezvoltarea browserului

Pentru a asigura ritmul necesar de inovare, multe companii revin la practica dezvoltării propriilor soluții IT, dar, bineînțeles, la un nou nivel. Acum există o cerere pentru instrumente vizuale de dezvoltare rapidă pentru crearea și executarea aplicațiilor de afaceri într-un singur mediu, disponibile de oriunde în lume, iar platforma Low-code oferă astfel de instrumente de dezvoltare la maximum.

Pentru a începe, este suficient să obțineți un cont cu drepturi de utilizator, analist și/sau dezvoltator în sistemul BPM - nu este nevoie să instalați software pe computer. Setarea drepturilor de acces la date, documente, funcționalitatea sistemului BPM, inclusiv crearea și exportul de rapoarte, editarea formularelor, se realizează și în browser folosind editorul online.

Actualizați fără întrerupere

În timpul funcționării sistemului, obiectele de afaceri și procesele de afaceri se dezvoltă, devin mai complexe, capătă noi atribute. În BPMS tradiționale care utilizează baze de date relaționale (DB-uri), efectuarea de modificări la procesele de afaceri necesită reconfigurarea bazei de date de către profesioniștii IT, blocând accesul utilizatorilor la sistem în timp ce modificările sunt transferate în mediul de producție. Această abordare necesită multe resurse și timp și nu oferă viteza necesară pentru a face modificări. Platforma de aplicații de afaceri Comindware utilizează o bază de date grafică și oferă o abordare diferită, dinamică, pentru a face modificări proceselor de afaceri și logicii aplicațiilor de afaceri.

În platforma Comindware Low-code, orice modificări pot fi făcute frecvent și fără durere, fără a implica programatori și fără a bloca accesul utilizatorilor la program. Acest lucru asigură capacitatea de a răspunde rapid la cerințele în continuă schimbare pentru aplicațiile de afaceri implementate în BPMS.

Implementarea unui sistem BPM

Sistemele BPM sunt concepute pentru a automatiza managementul întreprinderii și a îmbunătăți eficiența acesteia. Structura BPMS include un set de instrumente pentru modelarea și executarea proceselor, monitorizarea, analizarea și optimizarea proceselor de afaceri. Unele sisteme prezentate pe piața BPM din Rusia includ în plus module pentru dezvoltarea formularelor, interacțiune socialăși alte sarcini.

Există multe abordări ale implementării și fiecare organizație o alege pe cea potrivită pe baza stadiului actual de dezvoltare a întreprinderii, a strategiei de dezvoltare ulterioară, precum și a clasei de software selectat. Principalele abordări ale implementării unui sistem BPM bazat pe platforma Low-code:

• Evolutiv. Compania achiziționează licențe pentru platformă, creează o soluție BPM pentru sarcinile sale, automatizează procesele de afaceri și dezvoltă sistemul folosind angajații companiei. În etapa de implementare, ei comandă adesea un demo de la furnizor cu un prototip al sistemului BPM pentru o adaptare evolutivă independentă ulterioară la nevoile afacerii.
• Revoluţionar. Pentru a simplifica un proiect de implementare BPM, o organizație angajează adesea un expert BPM. El efectuează o analiză preliminară a proceselor companiei, formează angajații și supraveghează organizarea muncii privind implementarea sistemului BPM și automatizare.
• Integrare. Adesea, sistemele BPMS sunt implementate într-un sistem IT existent al întreprinderii. Nivelul ridicat de integrare a tuturor soluțiilor IT utilizate este un factor decisiv de succes. În acest caz, este logic să folosiți serviciile unei companii integratoare din rândul partenerilor Comindware. Experții vă vor ajuta să profitați la maximum de fiecare instrument din structura IT a companiei dumneavoastră.

Indiferent de abordarea aleasă pentru implementare, munca ulterioară cu sistemul de management al proceselor de afaceri bazat pe Platforma de aplicații de afaceri Comindware se bazează pe o schemă simplă de acțiuni:

• Un analist de afaceri, un expert BPM sau un utilizator avansat de afaceri creează un prototip de soluție. Programatorii sunt implicați doar pentru a crea o parte specifică a logicii de afaceri, procesarea datelor și integrarea cu alte sisteme.

În condițiile moderne, afacerile aplică în mod activ o abordare procesuală pentru organizarea muncii. Dar există încă o problemă de înțelegere - ce este managementul proceselor de afaceri și cum să utilizați corect BPM.

Definiția EABPM (Asociația Europeană BPM) a acestui termen este următoarea:

Managementul proceselor de afaceri (BPM) este o abordare sistematică pentru reflectarea, proiectarea, executarea, documentarea, măsurarea, monitorizarea și controlul atât a proceselor automate, cât și a celor neautomatizate, pentru a atinge obiectivele companiei și strategiile de afaceri. BPM îmbrățișează definirea, îmbunătățirea, inovarea și întreținerea conștientă, incluzivă și din ce în ce mai tehnologică a proceselor end-to-end. Datorită acestui management sistematic și conștient al procesului, companiile obțin rezultate mai bune mai rapid și mai flexibil.

Găsesc această definiție mai confuză decât o adevărată înțelegere a BPM, mai ales pentru persoanele care nu au studiat subiectul în profunzime.

În munca mea, folosesc în mod constant managementul grafic al proceselor de afaceri și notațiile BPMN. Consider acest instrument foarte convenabil, mă ajută nu doar în dezvoltarea soluțiilor de afaceri, ci și în justificarea acestora. La urma urmei, așa cum am spus de multe ori, o imagine valorează cât o mie de cuvinte. O persoană gândește în imagini și îi este mult mai ușor să-și imagineze un fel de activitate cu ajutorul unei imagini (diagrame).

Permiteți-mi să vă reamintesc, de asemenea, că nu este prima dată când ridic acest subiect. Am vorbit mult despre procesele de afaceri în articole precum „Ce este un proces de afaceri și o descriere a unui proces de afaceri” sau „O scurtă descriere a BPMN cu un exemplu”.

Dar întrebările rămân, ele mi se pun adesea atât de cititorii de articole, cât și de clienții mei. In plus, multa confuzie in intelegerea esentei o fac articolele de marketing si termenii legati de acest domeniu de activitate. Cum dezvoltatorii sisteme software, iar consultanții de afaceri care folosesc constant aceste instrumente în munca lor au reușit să introducă o mulțime de concepte exclusiv de marketing în domeniul managementului proceselor de afaceri. Pe de o parte, acest proces este inevitabil în orice domeniu comercial. Pe de altă parte, BPM nu este deja cea mai ușoară metodologie pentru un nespecialist. Și marketingul adaugă și mai multă confuzie.

Prin urmare, am decis să dau definiția mea detaliată a ceea ce este managementul proceselor de afaceri. Și sper că pot ajuta la înțelegerea principalelor probleme legate de utilizarea BPM.

Cum a apărut BPM?

Orice afacere noua poate fi comparat cu un copil. Fiecare companie creată de la zero trece printr-o perioadă de formare și învățare. Este necesar să se organizeze interacțiunea angajaților și departamentelor, să se creeze mecanisme de transfer de cunoștințe etc. Și indiferent cât de mare va fi această companie - într-o afacere mică, toate aceste probleme sunt la fel de importante ca și într-o organizație mare cu un număr mare de sucursale.

În același timp, umanitatea nu stă pe loc. Și atât în ​​domeniul predării copiilor, cât și în cel al organizării unei afaceri, apar noi instrumente mai flexibile, mai comode, mai intuitive, ceea ce este deosebit de important pentru oamenii care fac primii pași în orice domeniu.

Dacă ne întoarcem la înregistrări vechi și încercăm să studiem particularitățile organizării muncii atât în ​​întreprinderile sovietice, cât și în companiile occidentale, de exemplu, Ford, vom vedea în mare parte instrucțiuni text uscate, greu de citit, legate în principal de funcționalitatea. abordare:

1. Descrierea postului
2. Descrierea postului unui angajat
3. Cerințe de siguranță etc.

Toate acestea, după cum mulți își amintesc, sunt extrem de greu de perceput, iar o parte semnificativă din astfel de instrucțiuni adunau praf pe rafturi, adesea nefiind citite de nimeni, cu excepția creatorului. Și experiența și cerințele au fost transferate de la un angajat cu experiență la un novice.

Dar ce se întâmplă dacă este nevoie să se schimbe rapid modul în care funcționează întreaga organizație? Și dacă automatizarea este introdusă în același timp? Răspunsul la aceste solicitări a fost apariția BPM.

Am scris deja despre ce este un proces de afaceri („Ce este un proces de afaceri și o descriere a unui proces de afaceri”) și, prin urmare, nu voi repeta prevederile principale și definiția procesului de afaceri în sine. Să aruncăm o privire mai atentă asupra conceptului de management al proceselor de afaceri.

Despre managementul proceselor de afaceri în cuvinte simple

Managementul proceselor de afaceri înseamnă că reglementați, descrieți și schimbați procesele de afaceri. Vă schimbați, nu vă îmbunătățiți, pentru că puteți îmbunătăți și înrăutăți procesul de afaceri. Spre deosebire de o mașină unealtă sau de o mașină, nu este posibil să se controleze direct prin intermediul directivelor sau prin apăsarea unui buton de către colectiv. Dar putem stabili succesiunea de acțiuni pe care echipa le va efectua atunci când rezolvă o anumită problemă. Acesta este ceea ce se numește BPM.

Definitie de la mine:

Managementul proceselor de afaceri (BPM) este managementul activităților (atât automate, cât și neautomatizate) într-o echipă prin procese de afaceri.

Pentru a gestiona orice proces de afaceri, trebuie să:

1. Descrieți procesele de afaceri în sine.
2. Implementați procesul de afaceri descris în activitatea echipei
3. Numiți oameni responsabili pentru procesele de afaceri, așa-numiții deținători de stive sau proprietari de procese de afaceri.

Este important de înțeles că un proces de afaceri poate fi realizat atât de o persoană, cât și parțial automatizat. În mod similar, atât o persoană, cât și un program (execuția automată a operațiunilor și controlul automatizat) pot fi stack-holder.

În același timp, este necesară gestionarea unui mediu extrem de eterogen. Procesele de afaceri diferite necesită o abordare și acțiuni diferite ale angajaților, instrumente de automatizare diferite. Și toate acestea trebuie să poată fi descrise separat și apoi combinate într-un sistem comun.

Este necesar să pornim de la înțelegere: abordarea procesuală este managementul întregului prin managementul părților.

Și pentru a evita confuzia în terminologie, voi explica:

• BPM este o metodologie. acestea. un set de principii de bază și abordări ale construcției notațiilor și organizării în sine a muncii folosind procese de afaceri.
• BPMN este o notație (limbaj) în care sunt construite notații, inclusiv cele executabile.
• BPMS - sistem de execuție IT, construit după anumite reguli specificate în metodologie

Dacă facem o analogie cu știința, atunci BPM este, în primul rând, o abordare, un fel de viziune asupra lumii. BPMN sunt metode și algoritmi pentru rezolvarea unor probleme specifice. De exemplu, dovezi pentru teoreme sau un set de metode pentru crearea unui proiect pentru furnizarea de energie electrică unui obiect (producție, clădire de apartamente). Și, la rândul lor, BPMS sunt soluții de aplicație gata făcute care pot fi „pornite” și vor funcționa deja. Pentru matematică, acestea sunt soluții gata făcute la probleme de importanță practică. Pentru fizică - implementarea directă a cablajului și conexiunii obiectelor. Pentru sfera IT - un cod de program gata făcut.

Procese de afaceri executabile și neexecutabile

Am scris deja în articolele anterioare că notațiile proceselor de afaceri pot fi executabile și neexecutabile. Primele sunt destinate automatizării, cele din urmă studierii muncii companiei și îmbunătățirii eficienței interacțiunii în echipă.

Acestea. folosim principiile și tehnicile BPM pentru a crea notații. În același timp, folosim regulile pentru scrierea BPMS. Pentru a crea o notație neexecutabilă, în principiu, puteți folosi chiar și o foaie de hârtie de desen și un creion. Principalul lucru este să respectați cu strictețe toate regulile.

Notația executabilă necesită un mediu IT specific - BPMS. În același timp, recomand efectuarea chiar și a celor neexecutabile în BPMN, deoarece aici mediul însuși ajută la identificarea posibile greșeli, contradicții, ceea ce crește alfabetizarea și acuratețea descrierii procesului de afaceri.

Diferențele dintre proces și abordări funcționale

Un alt fapt important care vă va ajuta să înțelegeți ce este cu adevărat „managementul proceselor de afaceri”. Am aflat deja că managementul este crearea unei anumite secvențe de acțiuni ale angajaților. Acestea. ca urmare, fiecare sistem automatizat funcționează într-un anumit mod. Și o persoană este obligată, conform instrucțiunilor, să efectueze și acțiunile specificate de instrucțiuni.

De asemenea, trebuie să știe:

Pentru planificare strategicași evaluând activitatea companiei „în ansamblu”, este mai bine să folosiți modelarea funcțională și notațiile (de exemplu, IDF0). Am scris despre asta în detaliu în articolul „Introducere în notația IDEF0 și un exemplu de utilizare”. Aici puteți începe de la rezultatul dorit și puteți construi o secvență de funcții cutie neagră necesare pentru a-l atinge.

Pentru a gestiona succesiunea de acțiuni și pentru a optimiza ordinea. ceea ce se întâmplă în fiecare etapă de lucru, precum și îmbunătățirea interacțiunii dintre diferitele „cutii negre”, este necesară o abordare a procesului BPM. Aici studiați acțiunile în sine, urmăriți viteza și complexitatea obținerii rezultatelor, le optimizați și le standardizați.

Dacă faceți modificări în procesul de afaceri, atunci începeți întotdeauna nu de la întreg, ci de la o parte. Acestea. modificați algoritmul programului și/sau ajustați fișa postului pentru un angajat care îndeplinește anumite funcții. Ca urmare, unul dintre elementele procesului de afaceri se modifică și, ca urmare, procesul de afaceri în ansamblu.

Trebuie sa intelegi:

Crearea unei descrieri a procesului de afaceri începe „ca un întreg”, după care fiecare proces este împărțit în sub-procese și detaliat până la o anumită limită.

Schimbarea unui proces de afaceri, dimpotrivă, începe de la nivelurile „inferioare” - detaliu maxim. Și de la detalii - la întreg - se fac toate modificările necesare.

Dacă abordarea funcțională este obiectele foarte importante la intrare și la ieșire. În funcția „cutie neagră” în sine, au loc anumite procesări ale obiectelor pentru a obține rezultatul dorit. Și aici orientarea principală este „ce anume vrem să obținem”, adică. o abordare mai strategică a managementului afacerilor.

La abordarea procesuala primim un răspuns la întrebarea „cum este cel mai bine să facem asta”, adică. Ne concentrăm pe managementul tactic, operațional. Prin urmare, aici, atunci când se schimbă elemente individuale între „intrare și ieșire”, întregul proces se schimbă.

De asemenea, este important să determinați nivelul optim atunci când detaliați: nu prea „în general”, dar să nu detaliați un proces amplu până la acțiunile fiecărui angajat. Am văzut odată o descriere a proceselor de afaceri postată pe o hârtie Whatman de doi metri. Dar cu cât procesul este mai complex și mai detaliat, cu atât mai dificil va fi perceput „ca un întreg” și, ca urmare, va fi mai dificil de înțeles și îmbunătățit.

Din aceste motive, atunci când se lucrează cu procese de afaceri, se utilizează o descompunere pe mai multe niveluri, de ex. detalierea fiecărei „cutii negre” este separată într-un proces separat. Și din același motiv, abordarea procesului nu este folosită pentru planificarea strategică; pentru aceasta, repet, se folosește modelarea funcțională.

Descrierea lucrului cu BPM

Pentru o mai bună înțelegere a ce este BPM (Business Process Management), voi da un exemplu de succesiune de acțiuni ale unui analist de afaceri în cadrul acestei metodologii:

Sondaj de oameni (angajați ai companiei). Înțelegerea modului în care se lucrează în fiecare caz.

Documentarea procesului de afaceri pe baza datelor primite. În această etapă, analistul primește o descriere a procesului de afaceri „ca atare”.

Studierea procesului de afaceri rezultat din punct de vedere al punctelor slabe și al oportunităților de optimizare:

Documentele sunt create pe baza unei scheme optimizate gata făcute (după cum este necesar): descrierea postului, sunt implementate manuale de utilizare, precum și, dacă este necesar, soluții automatizate.

După implementare, pe baza notării, se monitorizează procesul de afaceri, se identifică eventualele inconsecvențe și se studiază cauzele acestora.

Dacă este necesar, se fac modificări ale schemei pe baza deficiențelor identificate sau a modificărilor în activitatea companiei asociate cu factori externi.

Ciclul de viață al procesului în BPM

După cum se poate observa din secvența descrisă mai sus, fiecare proces de afaceri trece printr-un anumit ciclu de la creare până la implementare. Apoi pentru o anumită perioadă de timp funcționează „ca atare”. După aceea, practica arată anumite neajunsuri și neajunsuri, analistul studiază raportarea și, la rândul său, găsește câteva „puncte slabe”. Procesul este în curs de modernizare.

Acest ciclu poate fi repetat de un număr infinit de ori. Orice afacere, orice organizație nu este un monolit înghețat, ci un organism în curs de dezvoltare într-un mediu în continuă schimbare. Caracteristicile legislative se schimbă, concurenții vin și pleacă de pe piață, apar noi instrumente de automatizare etc.

Regula principală a unui analist de afaceri: atunci când optimizați un proces, trebuie să vă puteți opri la timp. Și aici este necesar să se analizeze clar complexitatea (costul) modificărilor și creșterea eficienței (beneficiului) ca urmare.

Avantaje și dezavantaje ale BPM

Beneficiile utilizării BPM includ:

• Capacitatea de a maximiza detaliile acțiunilor oamenilor și sistemelor necesare pentru a obține rezultatul.
• Notațiile grafice sunt vizuale, ceea ce vă permite să înțelegeți caracteristicile proceselor din companie și să vedeți punctele slabe ale acestora.
• Notațiile sunt grozave ca instrucțiuni pentru interpret, care va primi o secvență clară și fără ambiguitate de acțiuni. În același timp, va fi proiectat grafic - în cel mai convenabil mod pentru percepția umană.
• Atunci când se utilizează abordarea procesului, rezultatul procesului va fi standardizat și va îndeplini așteptările. Acest lucru va reduce impactul factorului uman asupra nivelului de serviciu sau a performanței oricăror alte tipuri de muncă.
• Metodologia BPM este bine dezvoltată și standardizată datorită BPMN. În același timp, instrumentele (notații BPMN) sunt intuitive chiar și pentru persoanele care nu au studiat deloc managementul proceselor de afaceri. Pe de altă parte, prezența standardelor și regulilor vă permite să evitați erorile în timpul dezvoltării și să creați notații executabile în sistemul BPMS (elemente gata de automatizare a afacerii).

Contra BPM, așa cum se întâmplă adesea, sunt în același loc cu avantajele:

• Nivelul ridicat de detaliu al proceselor interferează cu percepția activității afacerii pentru planificarea strategică.
• Oamenii care dezvoltă modelul de proces au o responsabilitate foarte mare. Orice greșeală poate duce la rezultate triste. De exemplu, atunci când se dezvoltă un model funcțional, există date de intrare, un rezultat de ieșire, instrumente pe care compania le oferă executantului și interpretului însuși. Atâta timp cât executantul produce rezultatul așteptat la ieșire, în cadrul funcției, el poate acționa la propria discreție, alegând cea mai bună metodă pentru atingerea scopului. Odată cu abordarea procesuală, executantul este privat de „libertatea de manevră”. El are o secvență de acțiuni clar definită, ținând cont de toate condițiile posibile. Și nu are dreptul să acționeze altfel, chiar dacă rezultatul se dovedește a fi diferit de cel așteptat.
• Procesul de afaceri este static și practic nu este supus ajustărilor „din interior”. Interpretul primește o secvență clară de acțiuni și nu mai poate lua inițiativa. Drept urmare, executanții vor repeta orice greșeală din când în când până când aceasta este corectată în procesul de afaceri în sine.

Ce companii sunt potrivite pentru BPM

Abordarea procesului este ideală pentru companiile de stat. Aici este importantă îmbunătățirea nivelului de servicii și a calității muncii, în timp ce standardizarea serviciului este de asemenea importantă. LA companie de stat clienții nu se așteaptă la niciun bonus sau inițiative speciale. Dar serviciul trebuie efectuat de la și până la nivelul corespunzător.

În companiile comerciale, abordarea procesului este bună pentru standardizarea muncii, vă va permite să „trageți” nivelul de serviciu la anumite standarde. Pe de o parte, acesta este un mare plus. Pe de altă parte, este și un minus, deoarece inițiativa și angajații talentați, cu toată dorința lor, nu vor putea să se dovedească și să aducă mai multe beneficii și profit. Abordarea procesului este tocmai stabilitatea și un anumit caracter static. Prin urmare, atunci când îl utilizați, trebuie să înțelegeți clar unde vi se potrivește această opțiune de lucru și unde este mai bine să oferiți oamenilor mai multă libertate.

Pentru ca procesul de afaceri să fie benefic și să nu fie dăunător, se recomandă colectarea comentariilor și erorilor de la participanții la procesul de afaceri. Nu este nevoie să presupunem că BPM este adevărul suprem.

Am vorbit deja despre cum să gestionezi o afacere folosind procesele de afaceri mai detaliat în articolele anterioare și voi vorbi de mai multe ori. Aici am încercat să explic cât mai simplu posibil diferențele dintre termenii BPM, BPMS, BPMN și să descriu însuși conceptul de „managementul proceselor de afaceri”. Fără aceste cunoștințe de bază, este imposibil să înțelegem abordarea procesului.

Intrebari si raspunsuri

Care este diferența dintre modelarea funcțională și modelarea proceselor?

Cu o abordare funcțională, considerăm acțiunile oamenilor și ale sistemelor automate ca o „cutie neagră”. Și abordăm modelarea din punct de vedere - etapele atingerii scopului, precum și resursele necesare pentru aceasta. Cu modelarea proceselor, studiem succesiunea de acțiuni ale angajaților și sistemelor în fiecare etapă pentru a le optimiza și a crește eficiența.

Ce concepte sunt incluse în BPMN?

În primul rând, acesta este sistemul BPMN în sine, precum și o descriere a notațiilor BPMS. Am scris despre ele în acest articol și în detaliu - în articolele anterioare (vezi link-uri recomandate la sfârșitul publicației). În plus, nu cu mult timp în urmă, au apărut noi concepte - DMN și CMMN. Nu mă voi opri asupra lor acum. Voi încerca să descriu concepte noi și caracteristicile lor în publicațiile viitoare.

De ce avem nevoie de atâtea complexități și abordări diferite în construirea notațiilor?

Managementul proceselor de afaceri și metodologia BPM în sine sunt necesare, printre altele, pentru managementul direct al echipelor mari. Pentru aceasta, sunt necesare notații, descrieri ale proceselor de afaceri și o gamă largă de instrumente.

Cum să începi cu BPM?

Învață limbajul de notație BPMN și încearcă să-l folosești în munca ta. Cel mai important, nu vă fie frică să începeți. Veți înțelege că notațiile simple sunt mult mai ușor de construit în practică decât pare. Și pas cu pas vei putea învăța metodologia, bazându-te pe instrumente grafice BPM simple și ușor de înțeles.

BPM poate fi folosit pentru sisteme umane?

Poate sa. Această abordare este destinată, în primul rând, nu automatizării (există instrumente în sfera IT), ci organizării muncii unei companii sau a oricărei echipe. Aici pot fi luate în considerare domeniile de lucru care utilizează sisteme automatizate. Și numai procesele dintr-o echipă pot fi luate în considerare și, în plus, oricare - de la echipe de construcție sau producție până la echipe de creație dintr-un teatru sau o societate filarmonică. Principalul lucru este să descrii în mod clar modul în care se desfășoară procesul care te interesează, precum și cum vrei să-l schimbi.

Adnotare: Principii de creare a unui sistem informatic. Reproiectarea proceselor de afaceri. Afișarea și modelarea proceselor. Asigurarea procesului de analiză și proiectare a SI cu capacitățile tehnologiilor CASE. Implementarea sistemelor informatice.

4. Dezvoltarea și implementarea sistemului informațional

4.1. Principii de creare a unui sistem informatic

Mulți utilizatori de hardware și software de computer s-au confruntat în mod repetat cu o situație în care software-ul care funcționează bine pe un computer nu funcționează pe altul cu același dispozitiv. Sau blocurile de sistem ale unui dispozitiv de calcul nu se potrivesc în hardware-ul altuia. Sau sistemul informatic al altei companii refuza cu incapatanare sa prelucreze datele pe care le-ati pregatit in sistemul informatic de la locul de munca. Această problemă se numește problema compatibilității dispozitivelor de calcul, telecomunicații și informații.

Dezvoltarea sistemelor și mijloacelor de tehnologie informatică, implementarea lor extinsă în toate domeniile științei, tehnologiei, serviciilor și vieții de zi cu zi au condus la necesitatea combinării dispozitivelor de calcul specifice și a sistemelor informatice implementate pe baza acestora într-un singur sistem informatic-informatic ( ICS) și medii. În același timp, dezvoltatorii IVS s-au confruntat cu o serie de probleme.

De exemplu, eterogenitatea mijloacelor tehnice ale tehnologiei informatice în ceea ce privește organizarea procesului de calcul, arhitectura, sistemul de comandă, capacitatea procesorului și magistrala de date etc., a impus crearea de interfețe fizice care, de regulă, implementează compatibilitate reciprocă. a dispozitivelor. Odată cu creșterea numărului de tipuri de dispozitive integrate, complexitatea organizării unei interfețe fizice între ele a crescut semnificativ. Eterogenitatea mediilor programabile implementate în dispozitive și sisteme de calcul specifice, în ceea ce privește varietatea sistemelor de operare, diferențele de adâncime de biți și alte caracteristici, a condus la crearea de interfețe software între dispozitive și sisteme. În același timp, trebuie remarcat faptul că nu a fost întotdeauna posibil să se realizeze compatibilitatea deplină a produselor software dezvoltate pentru un anumit mediu software într-un alt mediu. Eterogenitatea interfețelor de comunicație din sistemul „om-calculator” a necesitat coordonarea constantă a software-ului și hardware-ului și recalificarea personalului.

Principiul „deschiderii” a sistemului informatic

Rezolvarea problemelor de interoperabilitate a condus la dezvoltarea unui număr mare de standarde și acorduri internaționale în domeniul tehnologiei informației și dezvoltării sistemelor informaționale. Conceptul de sisteme deschise a devenit un concept fundamental.

Termenul „sistem deschis” astăzi poate fi definit ca „un set cuprinzător și consistent de standarde internaționale de tehnologie a informației și profiluri de standarde funcționale care specifică interfețe, servicii și formate suport pentru a permite interoperabilitatea și mobilitatea aplicațiilor software, a datelor și a personalului”.

Această definiție, formulată de experți de la IEEE (Institute of Electrical and Electronic Engineers), unifică conținutul mediului pe care un sistem deschis îl oferă pentru utilizare pe scară largă. OASIS (Organizația pentru Avansarea Standardelor de Informații Structurate) este în prezent punctul focal general recunoscut pentru dezvoltarea și armonizarea standardelor sistemelor deschise.

Proprietățile generale ale sistemelor informatice deschise pot fi formulate după cum urmează:

• extensibilitate / scalabilitate: asigurarea posibilității de a adăuga noi funcții IS sau de a schimba unele dintre cele existente, rămânând neschimbate părțile funcționale rămase ale IS;
• mobilitate/portabilitate: asigurarea posibilității de transfer de programe, date la upgrade sau înlocuire a platformelor hardware IS și posibilitatea de a lucra cu acestea pentru specialiștii care folosesc IT, fără recalificarea acestora la schimbarea IS;
• interacțiune: capacitatea de a interacționa cu alte SI (mijloacele tehnice pe care este implementat sistemul informațional sunt unite printr-o rețea sau rețele diferite niveluri: de la local la global);
• standardizare: SI sunt proiectate și dezvoltate pe baza standardelor și propunerilor internaționale agreate, implementarea deschiderii se realizează pe baza standardelor (profilurilor) funcționale în domeniul tehnologiei informației;
• uşurinţă în utilizare: a dezvoltat interfeţe unificate în procesele de interacţiune în sistemul „om-maşină”, permiţând utilizatorului să lucreze fără pregătire specială „computer”.

O nouă privire asupra sistemelor deschise este determinată de faptul că aceste caracteristici sunt considerate împreună, ca fiind interconectate și sunt implementate într-un complex, ceea ce este destul de natural, deoarece toate proprietățile de mai sus se completează reciproc. Numai în ansamblu posibilitățile sistemelor deschise permit rezolvarea problemelor de proiectare, dezvoltare și implementare a sistemelor informaționale moderne.

Structura mediului de sistem informatic

Structura generalizată a oricărui IS poate fi reprezentată prin două părți care interacționează:

• partea funcțională, inclusiv programele de aplicație care implementează funcțiile zonei de aplicații;
• mediu sau parte de sistem care asigură execuția programelor de aplicație.

Două grupuri de probleme de standardizare sunt strâns legate de această diviziune:

• standarde pentru interfețele dintre programele de aplicație și mediul IS, interfața programului de aplicație (Application Program Interface - API);
• standarde pentru interfețele de interacțiune între IS-ul însuși și mediul său extern (External Environment Interface - EEI).

Aceste două grupuri de interfețe definesc specificațiile descriere externă Mediul SI - arhitectura, din punctul de vedere al utilizatorului final, designer SI, programator de aplicatii care dezvolta partile functionale ale SI.

Specificațiile interfețelor externe ale mediului IS și, după cum se va vedea mai jos, specificațiile interfețelor de interacțiune între componentele mediului însuși, sunt descrieri precise ale tuturor funcțiilor, serviciilor și formatelor necesare unei anumite interfețe. Setul de astfel de descrieri constituie modelul de referință al sistemelor deschise (Reference Open System Model).

Acest model a fost folosit de peste 20 de ani și este definit de System Network Architecture (SNA) propusă de IBM în 1974. Se bazează pe împărțirea mediului de calcul în șapte niveluri, a căror interacțiune este descrisă de standardele relevante, și asigură conectarea nivelurilor, indiferent de construcția nivelului în fiecare implementare specifică (Fig. 4.1). Principalul avantaj al acestui model este o descriere detaliată a conexiunilor din mediu în ceea ce privește dispozitivele tehnice și interacțiunile de comunicare. Totuși, nu ține cont de relație, ținând cont de mobilitatea aplicației software.

Orez. 4.1.

Modelul de referință pentru mediul sistemelor deschise (OSE/RM) definește împărțirea oricărui sistem informațional în aplicații (programe de aplicație și pachete software) și mediul în care operează aceste aplicații. Interfețele standardizate (API) sunt definite între aplicații și mediu și sunt o parte necesară a profilurilor oricărui sistem deschis. În plus, în profilurile IS pot fi definite interfețe unificate pentru interacțiunea părților funcționale între ele și interfețe pentru interacțiunea între componentele mediului IS.

Mai multe detalii despre aplicarea tehnologiei și modelele de sisteme deschise vor fi discutate în „lectura 18”.

Model de creare a sistemului informatic

Este important din punct de vedere metodologic, alături de modelele considerate ale mediului SI, să se propună un model de creare a unui SI care să aibă aceleași aspecte ale grupurilor funcționale de componente (utilizatori, funcții, date, comunicații). Această abordare va oferi un proces end-to-end de proiectare și întreținere în toate etapele operațiunii SI și posibilitatea unei alegeri rezonabile de standarde pentru dezvoltarea sistemelor și documentarea proiectelor.

O companie este o structură ontologică (conceptuală) complexă, constând dintr-un anumit set de entități și relații (Fig. 4.2).

Orez. 4.2.

Interacțiunile dintre elementele sale, determinate de logica afacerii și consacrate într-un set de reguli de afaceri, sunt activitățile companiei. Sistemul informatic „reflectează” logica și regulile, organizează și transformă fluxurile de informații, automatizează procesele de lucru cu date și informații și vizualizează rezultatele sub forma unor seturi de formulare de raportare. Prin urmare, pentru început, ar trebui să creați un model de afaceri al întreprinderii, care este o reflectare a întreprinderii și a sistemului său de management al informațiilor.

La crearea unui model, se formează un „limbaj de comunicare” pentru managerii companiei, consultanți, dezvoltatori și viitorii utilizatori, ceea ce permite dezvoltarea unei idei comune despre CE și CUM ar trebui să facă un sistem de management al întreprinderii (sistem de management corporativ). Un astfel de model de afaceri este un rezultat tangibil, cu ajutorul căruia este posibil să se precizeze obiectivele implementării IP cât mai mult posibil și să se determine următorii parametri ai proiectului:

• principalele obiective de afaceri care pot fi atinse prin automatizarea proceselor;
• lista site-urilor și secvența de implementare a modulelor IS;
• nevoia reală de volume de software și hardware achiziționate;
• estimări reale ale momentului de desfășurare și lansare a IMS;
• utilizatorii cheie ai SI și o listă actualizată a membrilor echipei de implementare;
• gradul de conformitate a aplicației software pe care l-ați ales cu specificul afacerii companiei dumneavoastră.

Modelul se bazează întotdeauna pe obiectivele de afaceri ale întreprinderii, care determină complet compoziția tuturor componentelor de bază ale modelului:

• funcții de afaceri care descriu CE face afacerea;
• procesele principale, auxiliare și de management care descriu CUM întreprinderea își îndeplinește funcțiile de afaceri;
• structura organizatorica si functionala care determina UNDE sunt efectuate functiile si procesele de afaceri;
• faze care determină CÂND (în ce secvență) trebuie implementate anumite funcții de afaceri;
• rolurile care definesc OMS îndeplinește funcții de afaceri și OMS este „proprietarul” proceselor de afaceri;
• reguli care definesc relația și interacțiunea dintre toate CE, CUM, UNDE, CÂND și CINE.

După construirea unui model de afaceri (sau în paralel cu acesta), puteți începe să formați un model pentru proiectarea, implementarea și implementarea IS-ului în sine (Fig. 4.3).

Orez. 4.3.

Experiența creării și utilizării SI „personalizate” ne permite să distingem condiționat următoarele etape principale ale ciclului lor de viață:

• determinarea cerințelor pentru sistem și analiza acestora - determinarea ce ar trebui să facă sistemul;
• proiectare - determinarea modului în care sistemul va face ceea ce ar trebui să facă; proiectarea este, în primul rând, specificarea subsistemelor, componentelor funcționale și modalităților de interacțiune a acestora în sistem;
• dezvoltare - crearea de componente funcționale și subsisteme individuale, conectarea subsistemelor într-un singur întreg;
• testare - verificarea conformității funcționale a sistemului cu indicatorii determinați în etapa de analiză;
• implementare - instalarea si punerea in functiune a sistemului;
• funcționare - un proces regulat de funcționare în conformitate cu principalele scopuri și obiective ale SI;
• suport - asigurarea functionarii regulate a sistemului la intreprinderea clientului.

Definirea cerințelor de sistem și analiza este primul pas în crearea unui SI, la care cerințele clienților sunt specificate, agreate, formalizate și documentate. De fapt, în această etapă, se dă un răspuns la întrebarea: „La ce este destinat sistemul informațional și ce ar trebui să facă?”. Aici se află cheia succesului întregului proiect.

Scopul analizei de sistem este de a transforma cunoștințele generale, vagi despre domeniul original (cerințele clienților) în definiții și specificații precise pentru dezvoltatori, precum și de a genera o descriere funcțională a sistemului. În această etapă, sunt definite și specificate următoarele:

• condițiile externe și interne ale sistemului;
• structură funcțională sisteme;
• distribuția funcțiilor între o persoană și un sistem, interfețe;
• cerințe pentru componentele tehnice, informatice și software ale sistemului,
• cerințe de calitate și siguranță;
• alcătuirea documentației tehnice și de utilizare;
• conditii de implementare si functionare.

Dezvoltarea specificațiilor de mai sus la crearea unui IS menit să automatizeze procesele de management, în cazul general, parcurge patru etape.

Prima etapă de analiză - analiza structurală a întreprinderii - începe cu un studiu al modului în care este organizat sistemul de management al întreprinderii, cu o cercetare a structurii funcționale și informaționale a sistemului de management, determinând consumatorii existenți și potențiali de informații.

Pe baza rezultatelor sondajului, analistul din prima etapă construiește un model logic generalizat al domeniului inițial, reflectând structura funcțională a acestuia, caracteristicile activității principale și spațiul informațional în care se desfășoară această activitate (Fig. 4.4). ). Pe acest material, analistul construiește un model funcțional „As is” (As Is).

A doua etapă de lucru, la care sunt implicați în mod necesar reprezentanți interesați ai clientului și, dacă este necesar, experți independenți, constă în analiza modelului „Așa cum este”, identificarea deficiențelor și blocajelor acestuia și determinarea modalităților de îmbunătățire a sistemului de management. pe baza criteriilor de calitate identificate.

A treia etapă de analiză, care conține elemente de proiectare, este crearea unui model logic generalizat îmbunătățit care afișează un domeniu reorganizat sau o parte a acesteia care este supusă automatizării - modelul As To Be.

Procesul (etapa a patra) se încheie cu elaborarea „Hărții automatizării”, care este un model de arie tematică reorganizată, pe care sunt indicate în mod necesar „limitele automatizării”.

În cele mai multe cazuri, modelul „Așa cum este” este îmbunătățit de către analistul de sistem prin eliminarea inconsecvențelor și blocajele evidente, iar varianta de model obținută în acest fel este considerată în continuare ca un model preliminar „Așa cum ar trebui să fie”, care este completat ulterior în conformitate cu cu strategia de dezvoltare a întreprinderii (Fig. .4.5).

Orez. 4.5.

La etapa de analiză a cerințelor pentru sistemul de proiectat se introduc următoarele:

• clase de utilizatori și diagrame de tranzacții comerciale corespunzătoare;
• modele (diagrame) proceselor de activitate aplicate și liste corespunzătoare de sarcini funcționale SI;
• clasele de obiecte ale disciplinei și diagramele entitate-relație corespunzătoare care reflectă modelul informațional al acestei discipline;
• topologia locației unităților și utilizatorilor deserviți de acest IS;
• parametrii de protecție a datelor, informațiilor și a sistemului însuși.

Documentul principal care reflectă rezultatele muncii din prima etapă de creare a unui SI este termenii de referință pentru proiect (dezvoltare), care conține, pe lângă definițiile și specificațiile de mai sus, și informații despre ordinea în care sistemul se creează, informații despre resursele alocate, termene de realizare a etapelor individuale de lucru, proceduri organizatorice și măsuri de acceptare a etapelor, protecția informațiilor despre proiect etc.

Următoarea etapă este proiectarea. În condiții reale, proiectarea este o căutare, modelare a unei metode de dezvoltare care satisface cerințele funcționalității sistemului prin intermediul tehnologiilor disponibile, ținând cont de condițiile și restricțiile inițiale date. Proiectarea sistemelor informatice începe întotdeauna cu definirea scopului proiectului. Sarcina principală a oricărui proiect de succes este de a se asigura că în momentul lansării sistemului și pe toată perioada de funcționare a acestuia este posibil să se furnizeze:

• funcționalitatea necesară a sistemului și gradul de adaptare la condițiile în schimbare ale funcționării acestuia;
• necesar debitului sistem și timpul minim de răspuns al sistemului la o solicitare;
• funcționarea fără probleme a sistemului în modul necesar, disponibilitatea și disponibilitatea sistemului pentru a procesa cererile utilizatorilor;
• ușurința în operare și întreținere a sistemului;
• securitatea datelor necesare și drepturile de acces ale utilizatorilor.

Performanța și fiabilitatea sunt principalii factori care determină eficacitatea sistemului. Designul bun este baza unui sistem de înaltă performanță.

Proiectarea sistemelor informatice acoperă trei domenii principale:

• proiectarea structurilor de date care vor fi implementate în baza de date;
• proiectarea de programe, formulare de ecran, rapoarte care vor asigura executarea interogărilor de date;
• proiectarea unui mediu sau tehnologie specifică, și anume: topologia rețelei, configurația hardware, arhitectura utilizată, procesarea paralelă, prelucrarea distribuită a datelor etc.

Pe baza rezultatelor analizei sistemului, în faza de proiectare preliminară se elaborează următoarele:

• proiect de implementare software și hardware, proiect de interfețe utilizator și tehnologii de lucru de utilizator în sistem;
• arhitectura sistemului distribuit și specificațiile rețelei de telecomunicații;
• modele (diagrame) ale fluxurilor de date;
• diagrame bloc funcționale ale aplicației și software-ului de sistem (cel din urmă - în conformitate cu modelele acceptate ale mediului IS și profilurile standardelor).

Etapa preliminară de proiectare poate implica prototiparea unor piese care sunt importante din punctul de vedere al utilizatorului pentru a verifica conformitatea acestora cu cerințele într-un stadiu incipient de dezvoltare.

În etapa de proiectare detaliată sunt dezvoltate:

• complexe de programe SI functionale si un proiect de implementare a mediului SI;
• structuri de date, instrumente de gestionare a bazelor de date;
• adresele de rețea, protocoalele de telecomunicații și alte componente ale mediului de schimb de informații incluse în IS proiectat;
• reguli de restricționare a accesului utilizatorilor și mijloace de implementare a acestora.

Etapa de implementare a SI prevede dezvoltarea și testarea componentelor și testarea completă a sistemului.

Etapa de operare și întreținere prevede monitorizarea funcționării SI, efectuarea modificărilor necesare la baza de informații în cursul lucrărilor curente și modernizarea funcțiilor IS de către specialiști aplicați folosind instrumente încorporate în sistem.

Etapele de dezvoltare, testare, implementare, operare și întreținere a SI sunt unite prin termenul - implementare. Implementarea SI este un proces cu mai multe aspecte extrem de complex, realizat pe baza unor seturi (profiluri) de standarde, specificații și acorduri internaționale armonizate. Această practică este o garanție că sistemul informațional creat va fi implementat ca un „sistem deschis”. Cu alte cuvinte, un astfel de IS va fi scalabil, mobil, portabil, va avea interfețe prietenoase etc.

Ciclul de viață al unui IS este format în conformitate cu principiul designului de sus în jos și, de regulă, este de natură spirală-iterativă. Etapele implementate, începând de la cele mai timpurii, se repetă ciclic în funcție de modificările cerințelor și condițiilor externe, introducerea de restricții suplimentare etc. La fiecare etapă a ciclului de viață, se generează un anumit set de soluții tehnice și documente, în timp ce documentele și soluțiile sunt inițiale pentru fiecare etapă parcursă în pasul precedent. Ciclul de viață al unui IS se încheie atunci când software-ul și suportul tehnic încetează.

4.2. Reinginiere a proceselor de afaceri

Introducerea tehnologiilor informaționale și a sistemelor informaționale implementate pe baza acestora în activitățile zilnice ale unei întreprinderi îi conferă acesteia avantaje tactice și pe termen lung în afaceri. Dorința managementului de a utiliza IT poate rămâne doar bună intenție dacă nu respectă cerințele și regulile stabilite pentru dezvoltarea, proiectarea și implementarea IT. Mai sus, am vorbit despre cerințele de bază pentru standardizarea obiectelor și a sarcinilor funcționale, fără de care sistemul implementat nu va fi un sistem deschis, ceea ce va duce ulterior la numeroase probleme în implementarea și funcționarea sa.

Urmărirea cerințelor standardelor în dezvoltarea SI duce automat la faptul că întreprinderea în sine - mediul extern pentru IS - îndeplinește și cerințele necesare: definirea și standardizarea claselor de utilizatori și obiecte, topologia datelor și fluxurilor de lucru. , arhitectura subsistemelor moștenite și dezvoltate, starea proceselor de afaceri etc.

Un proces de afaceri este un sistem de activități consistente, intenționate și reglementate în care, printr-o acțiune de control și cu ajutorul anumitor resurse pentru un anumit timp, intrările procesului sunt convertite în ieșiri - în rezultate care sunt valoroase pentru consumator și aduce profit producătorului.

Un proces standard de afaceri la nivelul întregii întreprinderi este implementat ca o rețea de procese principale, auxiliare, de suport și de management (Fig. 4.6).

Orez. 4.6.

În același timp, împărțirea în procese principale și auxiliare depinde într-o anumită măsură de domeniul și direcția întreprinderii: pentru o companie de producție, de exemplu, activitatea departamentului juridic este auxiliară, iar pentru o lege sau consultanță fermă este cea principală. Identificarea procesului este condiție prealabilă, fără implementarea căreia informatizarea activității este imposibilă.

Managerii de întreprindere care decid să implementeze IT ar trebui să înțeleagă cu fermitate că începerea lucrărilor la proiectarea unui sistem informațional presupune cel mai adesea o reinginerire obligatorie a proceselor de afaceri! Reingineria este un set de tehnici și recomandări, dintre care trebuie să le alegi pe cele care se potrivesc cel mai bine obiectivelor tale.

Reingineria proceselor de afaceri este un set de metode și acțiuni care servesc la reproiectarea proceselor în conformitate cu condițiile schimbate ale mediului extern și intern și/sau obiectivelor de afaceri.

Există mai multe reguli de bază care ar trebui urmate în procesul de reinginerie:

• dezvoltarea de proceduri coerente pas cu pas pentru reproiectarea procesului;
• utilizarea în proiectarea limbilor standard și a notațiilor;
• prezența unor indicatori euristici și pragmatici care vă permit să evaluați sau să măsurați gradul de conformitate a procesului reproiectat sau a funcționalității cu obiectivele specificate;
• abordarea soluționării unor probleme particulare și a totalității acestora ar trebui să fie sistemică;
• chiar și o mică îmbunătățire ar trebui să dea un efect pozitiv rapid.

Reproiectarea proceselor și funcțiilor de afaceri începe cu o revizuire a obiectivelor întreprinderii, structurii acesteia, analiza nevoilor utilizatorilor interni și a pieței, produselor și serviciilor produse (Fig. 4.7).

Orez. 4.7.

Reprogramarea scopurilor și obiectivelor implică revizuirea politicii întreprinderii și răspunsul la următoarele întrebări:

• Ce noi provocări ne prezintă schimbările condițiilor de afaceri?
• Ce reprezintă compania acum și ce ne dorim de la ea în viitor?
• Ce fel de clienți servim, cum le îndeplinim cerințele și așteptările și ce trebuie făcut pentru a atrage alții noi?
• Ce indicatori determină eficacitatea întreprinderii, productivitatea muncii și calitatea produsului, este această definiție completă și adecvată?
• Ce tehnologii și mijloace informaționale ne vor ajuta în acest sens?

Pentru a răspunde la aceste întrebări cheie, este necesar, în primul rând, să se efectueze o descriere detaliată a arhitecturii de afaceri a întreprinderii, a logicii sale de afaceri, să se construiască un model funcțional al interacțiunii proceselor, resurselor și personalului de afaceri și să-l reflecte în Arhitectura IS, conținutul modulelor subsistemului informațional și vizualizarea formelor de prezentare a informațiilor. De asemenea, este necesar să existe metode și instrumente pentru reorganizarea proceselor, rezolvarea problemelor aplicate și gestionarea unui proiect de reinginerie (Fig. 4.8). Descrierea arhitecturii de afaceri a întreprinderii permite:

Orez. 4.8.

• construiți o diagramă a principalelor fluxuri de date, munca, mișcarea finanțelor și documentelor;
• să înțeleagă modul în care informațiile sunt distribuite între departamente și cine este utilizatorul final într-un anumit proces de afaceri;
• descrie interacțiunea proceselor și modulelor sistemului informațional;
• determinarea importanței critice a tipurilor de informații pentru niveluri specifice de management al întreprinderii;
• identifica structurile și conexiunile duplicate.

Rezultatul acestei descrieri este:

• harta rețelei de proces actualizată;
• o matrice de interconexiuni între procese și departamente implicate în aceste procese;
• informații despre ce sisteme de automatizare există, ce operațiuni sunt utilizate, unde și ce date sunt utilizate, ce sisteme de automatizare și informatizare trebuie dezvoltate;
• diagrame funcționale ale fluxurilor de date (Data Flow), lucrări (Work Flow), fluxurilor financiare (Cash Flow), fluxurilor de acțiuni manageriale (Control Flow) și workflow (Doc Flow).

Modelul funcțional va ajuta la realizarea unor specificații precise ale tuturor operațiunilor, procedurilor și relațiilor dintre acestea. Un astfel de model, dacă este construit corect, oferă o descriere cuprinzătoare a unui proces de funcționare și a tuturor fluxurilor de informații în cadrul acestuia. Acest model descrie starea „Așa cum este” (Așa cum este). Pe baza rezultatelor analizei modalităților posibile de îmbunătățire, dintr-un model real, trebuie să treceți la un model care caracterizează îmbunătățirile - modelul As To Be, opțiunea este „Cum ar trebui să fie” (Fig. 4.9) .

Orez. 4.9.

Modelarea funcțională este o problemă destul de serioasă, completitudinea și conformitatea modelului construit depind atât de instrumentele de modelare, cât și de calificările specialiștilor care efectuează această modelare.

Reingineria proceselor de afaceri este un proiect complex și cu mai multe fațete care necesită o planificare atentă și detalii. Tabelul 4.1 prezintă principalele etape ale reingineriei.

Tabelul 4.1. Principalele etape ale reingineriei

Etapă	Evenimente
Planificare și începere	Identificarea principalelor motive ale reformei la întreprindere și evaluarea consecințelor refuzului unei astfel de reforme
	Dezvăluind procese critice care necesită reinginerie
	Identificarea unor persoane similare în rândul conducerii și crearea unui grup de lucru de reprezentanți ai administrației
	Asigurarea suportului managerial pentru proiect
	Pregătirea unui plan de proiect: definirea domeniului de aplicare, stabilirea obiectivelor măsurabile, alegerea unei metodologii, întocmirea unui program detaliat
	Coordonarea obiectivelor și domeniului proiectului cu managementul
	Formarea grupului de reinginerie
	Selectarea consultanților sau experților externi
	Organizarea unei întâlniri introductive
	Comunicarea obiectivelor proiectului managerilor de nivel inferior; informarea inițială a întregii organizații
	Training de grup de reinginerie
	Întocmirea planului și începerea lucrărilor
Cercetare	Studiu analitic al experienței companiilor cu procese similare
	Sondajul clienților și grupurilor de control pentru a identifica cerințele actuale și viitoare
	Sondajul angajaților și managerilor pentru identificarea problemelor; brainstorming
	Căutând în literatura de specialitate și în presă date despre tendințele industriei și experiențele altor oameni
	Decor documente detaliate privind procesele inițiale și colectarea datelor operaționale; identificarea deficiențelor
	Prezentare generală a modificărilor și a opțiunilor tehnologice
	Ancheta proprietarilor și reprezentanților conducerii
	Participarea la cluburi și seminarii
	Colectarea datelor de la experți și consultanți externi
Proiecta	Brainstorming și dezvoltarea de idei inovatoare; exerciții de gândire creativă pentru a „da jos orbiile”
	Scenarii „Dacă?” și aplicarea „modelelor de succes” ale altor companii
	Crearea cu ajutorul specialiștilor a 3-5 modele; dezvoltarea de modele complexe în care se adună cele mai bune din fiecare dintre cele anterioare
	Crearea unei imagini a procesului ideal
	Definirea noilor modele de proces și reprezentarea lor grafică
	Dezvoltarea unui model organizațional combinat cu un nou proces
	Definirea cerinţelor tehnologice; alegerea platformei pentru noi procese
	Separarea măsurilor pe termen scurt și pe termen lung
Afirmație	Analiza cost-beneficiu; calculul randamentului capitalului
	Evaluarea impactului asupra clienților și angajaților; evaluarea impactului asupra competitivității
	Pregătirea unei cărți albe pentru conducerea superioară
	Desfășurarea de ședințe de revizuire pentru familiarizarea și aprobarea detaliilor proiectului de către comitetul de organizare și conducerea superioară
Implementarea	Finalizarea dezvoltării detaliate a proceselor și modelelor organizaționale; definirea noilor responsabilităţi ale locului de muncă
	Dezvoltarea sistemelor de suport
	Implementarea optiunilor preliminare si a testelor initiale
	Familiarizarea angajaților cu noua opțiune; elaborarea și implementarea unui plan de reformă
	Elaborarea unui plan etapizat; implementare ca atare
	Elaborarea unui plan de instruire; instruirea angajaților cu privire la noi procese și sisteme
Activitati de urmarire	Dezvoltarea măsurilor de evaluare periodică; definirea rezultatului noului proces; implementarea unui program de îmbunătățire continuă pentru noul proces
	Depunerea raportului final către comitetul de organizare și administrație

4.3. Maparea proceselor și modelarea

Până în prezent, trei metodologii principale de modelare funcțională (și instrumentele lor însoțitoare) au devenit larg răspândite: IDEF (Integrated DEFinition), UML (Unified Modeling Language) și ARIS (Arhitectura Sistemelor Informaționale Integrate). Pentru fiecare dintre ele, există anumite produse software care, pe lângă dezvoltare, vă permit să efectuați transformări și operațiuni pentru lucrul ulterioar cu modelele rezultate. Metodologiile IDEF și produsul software BPWin, care conține metodologiile IDEF0, IDEF3, DFD (Data Flow Diagrams) și ERWin (IDEF1x) de la Computer Associates, sunt cele mai utilizate astăzi.

Istoria metodologiei IDEF începe în anii 1970 cu metodologia SADT (Structured Analysis and Design Technique) dezvoltată de Douglas Ross (Softtech INC). Inițial, SADT a fost folosit de Departamentul de Apărare al SUA pentru modelarea practică a proceselor, ca parte a programului ICAM (Integrated Computer Aided Manufacturing). Cerința principală în dezvoltarea familiei de metodologii luate în considerare a fost posibilitatea unui schimb eficient de informații între toți specialiștii participanți la programul ICAM (Icam DEFinition). Ulterior, această metodologie a fost transformată în standardul IDEF0 (Function Modeling, FIPS No. 183). Familia IDEF include deja menționate IDEF3 (Process Description Capture) și IDEF1x (Data Modeling, FIPS nr. 184).

După ce standardele au fost publicate, acestea au fost aplicate cu succes în diverse domenii de afaceri, dovedindu-se a fi un instrument eficient pentru analizarea, proiectarea și afișarea proceselor de afaceri (apropo, este utilizat activ și în structurile guvernamentale interne, de exemplu, în stat oficiu fiscal). Mai mult, apariția ideilor principale ale conceptului acum popular de „Business Process Reengineering” (Business Process Reengineering - BPR) este asociată cu utilizarea pe scară largă a IDEF (și a metodologiei anterioare SADT).

Procesul de informare este un proces durabil (o secvență de lucru și acțiuni cu date și informații) legat de susținerea activităților de producție și economice ale companiei și este de obicei axat pe serviciul de informare pentru crearea de valoare nouă. Un proces de afaceri include o ierarhie de acțiuni funcționale interconectate care implementează unul (sau mai multe) obiective de afaceri ale companiei și reflectă rezultatele în sistemul informațional, de exemplu, suport informațional pentru gestionarea și analiza rezultatelor produsului sau suportul resurselor pentru ieșirea produsului. (produse aici înseamnă bunuri, servicii, decizii, documente).

Lucrul folosind metoda IDEF începe cu stabilirea scopului modelării. Experiența mondială arată că erorile în stabilirea obiectivelor duc în medie la 50% din eșecurile în procesul de modelare. Formularea scopului orientează inițial munca într-o direcție dată și, prin urmare, limitează gama de întrebări pentru analiză. Munca practicaîncepe cu definirea contextului (Context, Context Diagram), adică nivelul superior al sistemului, în cazul nostru, întreprinderea. După formularea scopului, este necesară conturarea zonei de modelare (Scope), care va determina ulterior direcțiile generale de mișcare și adâncimea detaliului (Descompunere). De fapt, metodologia IDEF în sine definește obiecte standardizate pentru operare și afișare. De exemplu, acestea includ o funcție (Activitate), un arc de interfață (Săgeată), o notă (Notă), precum și modul în care sunt localizate și interpretate (Semantică).

În ultima vreme piata ruseasca a apărut produsul software Business Studio, care este special conceput pentru a funcționa cu metode IDEF și are o interfață intuitivă și prietenoasă (User-friendly Interface).

Orez. 4.10.

Notația și metodologia IDEF0 se bazează pe conceptul de „bloc”, adică un dreptunghi care exprimă o anumită funcție de business (Fig. 4.10). În conformitate cu standardul, funcția trebuie exprimată printr-un turnover verbal.În IDEF0, rolurile laturilor dreptunghiului (sensuri funcționale) sunt diferite: partea de sus are semnificația „control”, cea din stânga - „input ", cel din dreapta - "ieșire", cel de jos - "mecanism de execuție".

Al doilea element al metodologiei și al notației este „fluxul”, denumit în standard „arcul de interfață”. Acesta este un element care descrie datele, controlul informal sau orice altceva care afectează funcția reprezentată de casetă. Fluxurile sunt desemnate printr-o frază nominală.

În funcție de ce parte a blocului este direcționat fluxul, acesta, respectiv, se numește „intrare”, „ieșire”, „control”. Elementul iconic care reprezintă fluxul este o săgeată. Un flux poate fi interpretat ca o reprezentare a unui obiect, care se referă atât la un obiect informațional, cât și la un obiect fizic real.

Un factor important este că „sursa” și „receptorul” fluxurilor (adică începutul și sfârșitul săgeții) pot fi de obicei numai blocuri. În acest caz, doar partea de ieșire a blocului poate fi sursă, receptorul poate fi oricare dintre cele trei rămase. Dacă este necesar să se sublinieze natura externă a fluxului, atunci se poate aplica metoda „tunelului” - ascunderea sau apariția arcului de interfață din „tunel”.

Și, în sfârșit, „al treilea pilon” al metodologiei IDEF0 este principiul descompunerii funcționale a blocurilor, care este o interpretare model a situației practice în care orice acțiune (mai ales la fel de complexă ca un proces de afaceri) poate fi descompusă (descompusă) în operațiuni mai simple (acțiuni, funcții de afaceri). Sau, cu alte cuvinte, acțiunea poate fi reprezentată ca o colecție de funcții elementare.

Un exemplu de model funcțional al procesului de expediere și livrare a produselor este prezentat în fig. 4.11.

Gradul de formalizare a descrierii proceselor de afaceri poate fi diferit în funcție de sarcinile care se rezolvă. Pentru descriere procesele informaţionale a fost dezvoltat un limbaj specializat BPEL (Business Process Execution Language). BPEL se bazează pe XML pentru o descriere formală a proceselor de afaceri și a protocoalelor pentru interacțiunea lor între ele. BPEL extinde modelul de interacțiune a serviciilor Web pentru a include suport pentru tranzacții.

În prezent, se dezvoltă în mod activ metodologia BPMS (Business Process Management System) - o clasă de software pentru gestionarea proceselor de afaceri și a reglementărilor administrative. (Sunt folosiți și termenii sistem BPM și pur și simplu BPM.) Utilizarea BPMS vă permite să vă organizați interacțiune eficientăîntre manageri și profesioniști IT, este mai bine să folosiți subsistemele existente și să accelerați dezvoltarea altora noi.

Principalele funcții ale BPMS sunt modelarea, execuția și monitorizarea proceselor de afaceri. Pe baza datelor de monitorizare, întreprinderile identifică blocajele și își îmbunătățesc procesele de afaceri. Bucla de control este închisă atunci când procesele de afaceri modificate sunt puse rapid în funcțiune cu ajutorul BPMS.

Metodele moderne de proiectare și dezvoltare a software-ului IS încearcă pe deplin să se concentreze pe posibilitatea unor schimbări automate prompte. Cel mai dificil a fost procesul de standardizare a limbajului BPEL pentru a unifica utilizarea acelorași constructe de către software de la diferiți producători. IBM și Microsoft au definit două limbi destul de similare: WSFL (Web Services Flow Language) și, respectiv, Xlang.

Creșterea popularității BPML și mișcarea deschisă a BPMS către utilizatori au determinat Intalio Inc., IBM și Microsoft să fuzioneze aceste limbi în noua limbă BPEL4WS. În aprilie 2003, BEA Systems Corporation, IBM, Microsoft, SAP și Siebel Systems au transmis BPEL4WS versiunea 1.1 la OASIS pentru standardizare de către Comitetul Tehnic BPEL pentru Servicii Web. Deși BPEL4WS a apărut în versiunile 1.0 și 1.1, comitetul tehnic WS-BPEL OASIS a votat pe 14 septembrie 2004 denumirea specificației WS-BPEL 2.0. Această modificare a fost făcută pentru a alinia BPEL cu alte standarde de servicii Web care încep cu „WS-” ca parte a „Convenției de denumire”.

Active Endpoints, Adobe, BEA, IBM, Oracle și SAP au publicat specificațiile de consens BPEL4 People și WS-HumanTask, care descriu modul în care interacțiunea procesului cu oamenii poate fi implementată în sistem și notațiile BPEL. Ar trebui să adauge semantică la BPEL sub formă de WS-HumanTask și diverse alte completări.

4.4. Asigurarea procesului de analiză și proiectare a SI cu capacitățile tehnologiilor CASE

Termenul CASE (Computer Aided Software/System Engineering) este utilizat în prezent într-un sens foarte larg. Sensul inițial al termenului CASE, limitat la problemele de automatizare a dezvoltării doar a software-ului (software), a căpătat acum un nou sens, acoperind procesul de dezvoltare a SI complex în ansamblu.

Acum, termenul CASE-tools se referă la instrumente software care sprijină procesele de creare și întreținere a SI, inclusiv analiza și formularea cerințelor, proiectarea software-ului aplicației (aplicații) și baze de date, generarea de cod, testare, documentare, asigurare a calității, management al configurației și managementul proiectelor, precum și alte procese. Astfel, instrumentele moderne CASE, împreună cu software-ul de sistem și mijloace tehnice sprijin dintr-un mediu complet de dezvoltare IS.

Apariția tehnologiei CASE și a instrumentelor CASE a fost precedată de cercetări în domeniul metodologiei de programare. Programarea a dobândit caracteristicile unei abordări sistematice cu dezvoltarea și implementarea limbajelor nivel inalt, metode de programare structurală și modulară, instrumente de modelare vizuală și proiectare bazate pe UML (Unified Modeling Language), instrumente pentru suportul acestora, limbaje formale și informale pentru descrierea cerințelor și specificațiilor sistemului etc. În plus, astfel de factori precum:

• formarea analiștilor și programatorilor receptivi la conceptele de programare modulară și structurată;
• introducerea pe scară largă și creșterea constantă a performanței computerului, care a făcut posibilă utilizarea instrumentelor grafice eficiente și automatizarea majorității etapelor de proiectare;
• introducerea tehnologiei de rețea, care a făcut posibilă combinarea eforturilor interpreților individuali într-un singur proces de proiectare prin utilizarea unei baze de date partajate care conține informațiile necesare despre proiect.

Tehnologia CASE este o metodologie de proiectare IS, precum și un set de instrumente care vă permit să modelați vizual domeniul subiectului, să analizați acest model în toate etapele dezvoltării și întreținerii SI și să dezvoltați aplicații în conformitate cu nevoile de informații ale utilizatorilor. Majoritatea instrumentelor CASE existente se bazează pe metodologiile de analiză și proiectare structurală (în mare parte) sau orientate pe obiecte, folosind specificații sub formă de diagrame sau texte pentru a descrie cerințele externe, relațiile dintre modelele de sistem, dinamica comportamentului sistemului și arhitectura software. [Vendrov A. M , www.citforum. ru/database/case/index.shtml].

Instrumentele CASE vă permit să creați nu numai un produs care este aproape gata de utilizare, ci și să asigurați procesul „corect” al dezvoltării acestuia. Scopul principal al tehnologiei este de a separa proiectarea software-ului de codificarea, asamblarea, testarea acestuia și de a „ascunde” cât mai mult posibil de viitorii utilizatori toate detaliile dezvoltării și exploatării software-ului. În același timp, eficiența muncii proiectantului este crescută semnificativ: timpul de dezvoltare este redus, numărul erorilor software este redus, modulele software pot fi utilizate în următoarele dezvoltări.

Majoritatea instrumentelor CASE se bazează pe metodologia/metoda/notația/structura/paradigma instrumentului.

Metodologia stabilește linii directoare pentru evaluarea și selectarea unui proiect de dezvoltare software, etapele și succesiunea de lucru, reguli de aplicare a anumitor metode.

Metodă - o procedură sistematică sau o tehnologie pentru generarea de descrieri ale componentelor software (de exemplu, o descriere a fluxurilor și a structurilor de date).

Notațiile sunt menite să descrie sistemul în ansamblu, elementele sale: grafice, diagrame, tabele, diagrame bloc, algoritmi, limbaje formale și limbaje de programare.

Structurile sunt un mijloc de implementare a analizei structurale și de construire a structurii unui anumit sistem.

Instrumente - instrumente tehnologice și software pentru sprijinirea și îmbunătățirea metodelor.

Tehnologiile CASE au următoarele avantaje principale care le permit să fie utilizate pe scară largă în dezvoltarea sistemelor informaționale:

• accelerarea procesului de proiectare și dezvoltare colectivă;
• permite pentru Pe termen scurt creați un prototip al sistemului comandat cu proprietățile specificate;
• eliberați dezvoltatorul de munca de rutină, lăsând timp pentru creativitate;
• asigura eficienta si calitatea software-ului dezvoltat prin automatizarea controlului intregului proces de dezvoltare;
• sprijină întreținerea și dezvoltarea sistemului la un nivel înalt.

Trebuie remarcat faptul că, în ciuda tuturor posibilităților potențiale ale instrumentelor CASE, există destul de multe exemple de implementare nereușită a acestora, în urma cărora instrumentele CASE devin software de „raft” (Shelfware).

În acest sens, trebuie avute în vedere următoarele:

• Instrumentele CASE nu dau neapărat un efect imediat, acesta poate fi obținut doar după ceva timp;
• costurile reale de implementare a instrumentelor CASE sunt de obicei mult mai mari decât costurile de achiziție a acestora;
• Instrumentele CASE oferă oportunități pentru beneficii semnificative numai după finalizarea cu succes a procesului lor de implementare, instruirea eficientă a utilizatorilor și utilizarea regulată.

De asemenea, puteți enumera următorii factori care complică determinarea posibilului efect al utilizării instrumentelor CASE:

• o mare varietate de calitate și capabilități ale instrumentelor CASE;
• timp relativ scurt de utilizare a instrumentelor CASE în diverse organizatiiși lipsa de experiență în aplicarea acestora;
• o mare varietate în practica de implementare a diferitelor organizații;
• lipsa unor metrici și date detaliate pentru proiectele deja finalizate și în derulare;
• o gamă largă de domenii ale proiectului;
• grad diferit de integrare a instrumentelor CASE în diferite proiecte.

Unii analiști consideră că beneficiul real al utilizării anumitor tipuri de instrumente CASE poate fi obținut doar după unul sau doi ani de experiență. Alții cred că impactul poate apărea de fapt în faza operațională a ciclului de viață al CI, când îmbunătățirile tehnologice pot duce la costuri de operare mai mici.

În cele ce urmează sunt enumerate principalele tipuri și secvența de lucru recomandate la construirea modelelor logice ale domeniului subiectului în cadrul tehnologiei CASE pentru analiza unui sistem de management al întreprinderii.

1. Efectuarea unui studiu funcțional și informațional al sistemului de management (activități administrative și manageriale) al întreprinderii (Fig. 4.2):
   • determinarea structurii organizatorice a întreprinderii;
   • determinarea structurii funcționale a întreprinderii;
   • determinarea listei de funcții țintă ale elementelor structurale (divizii și funcționari);
   • determinarea sferei și ordinii de examinare a elementelor structurale ale sistemului de management în conformitate cu funcțiile țintă formulate;
   • examinarea activităților elementelor structurale identificate;
   • realizarea unei diagrame FD a sistemului de control indicând elementele structurale și funcțiile, a cărei implementare va fi modelată la nivel de DFD.
2. Dezvoltarea modelelor de activitate pentru elementele structurale și sistemul de management în ansamblu:
   • selectarea unui set de obiecte externe care au un impact semnificativ asupra activității unui element structural;
   • specificarea fluxurilor de informații de intrare și de ieșire;
   • identificarea principalelor procese care determină activitatea unui element structural și asigură implementarea funcțiilor țintă a acestuia;
   • precizarea fluxurilor de informații între principalele procese de activitate, clarificarea legăturilor dintre procese și obiectele externe;
   • evaluarea volumelor, intensității și a altor caracteristici necesare ale fluxurilor de informații;
   • dezvoltarea unei ierarhii de diagrame de flux de date care formează un model funcțional al activității unui element structural;
   • combinând modelele DFD ale elementelor structurale într-un singur model al sistemului de management al întreprinderii.
3. Dezvoltarea modelelor informaționale ale elementelor structurale și a unui model al spațiului informațional al sistemului de control:
   • definirea entităților model și a atributelor acestora;
   • efectuarea de analize de atribute și optimizare a entităților;
   • identificarea relațiilor dintre entități și definirea tipurilor de relații;
   • analiza si optimizarea modelului informatic;
   • combinarea modelelor informaţionale într-un singur model al spaţiului informaţional.
4. Elaborarea de propuneri de automatizare a sistemului de management al întreprinderii:
   • determinarea limitelor automatizării - întocmirea unei liste de elemente structurale automatizate, împărțind procesele activității principale în automate, automatizate și manuale;
   • alcătuirea unei liste de subsisteme și stații de lucru logice (stații de lucru automate), stabilirea modalităților de interacțiune a acestora;
   • elaborarea de propuneri privind succesiunea de proiectare și implementare a subsistemelor și stațiilor de lucru logice individuale care fac parte din SI;
   • dezvoltarea cerințelor pentru mijloacele de suport tehnic de bază al SI;
   • dezvoltarea cerințelor pentru software-ul IS de bază.

Modelul logic care reflectă activitățile sistemului de management al întreprinderii și spațiul informațional în care se desfășoară această activitate este un „instantaneu” al stării de lucruri (structura funcțională, rolurile funcționarilor, interacțiunea între departamente, tehnologiile acceptate de procesare a informațiilor de management, procese automatizate şi neautomatizate etc. .) la momentul examinării. Acest model vă permite să înțelegeți ce face întreprinderea și cum funcționează ea din punct de vedere al analizei sistemului, să formulați propuneri de îmbunătățire a situației.

Dezvoltarea unui model logic al domeniului de studiu, transformarea sa consecventă într-un model țintă IS, va permite integrarea propunerilor promițătoare din partea conducerii și a angajaților de conducere ai întreprinderii, experți și analiști de sistem și formarea unei viziuni a unui nou, reorganizat și activitatea automatizată a întreprinderii (Fig. 4.12).

Orez. 4.12.

Modelul construit este un rezultat complet din următoarele motive.

1. Include un model al tehnologiei existente neautomatizate adoptată de întreprindere. O analiză formală a acestui model vă permite să identificați blocajele în managementul întreprinderii și să formulați recomandări pentru îmbunătățirea acestuia (indiferent dacă se așteaptă o dezvoltare ulterioară). sistem automatizat sau nu).
2. Este independent și separabil de dezvoltatori specifici, nu necesită întreținere și poate fi transferat fără durere altora. Mai mult, dacă dintr-un motiv oarecare întreprinderea nu este pregătită să implementeze proiectul la un moment dat, modelul poate fi „raft” până când este necesar.
3. Permite formarea eficientă a noilor angajați în domenii specifice ale întreprinderii, deoarece tehnologiile relevante sunt conținute în model.
4. Poate fi folosit pentru pre-modelare. direcții promițătoare activitățile întreprinderii pentru a identifica noi fluxuri de date, procese care interacționează și elemente structurale.
5. Asigură diseminarea experienței acumulate în alte întreprinderi, face posibilă unificarea structurilor administrative și manageriale și activitate financiară aceste intreprinderi.

Modelul nu este doar o implementare a etapelor inițiale de lucru și baza pentru formarea specificațiilor tehnice pentru etapele sale ulterioare. Este un rezultat independent de mare importanță practică, deoarece permite utilizarea în continuare a tehnologiilor CASE pentru proiectarea și dezvoltarea reală a SI.

Paradigm Plus - modelarea aplicațiilor și generarea codului obiect;

Rational Rose - modelarea proceselor de afaceri și a componentelor aplicației

Rational Suite AnalystStudio - un pachet pentru analisti de date;

Oracle Designer (inclus în Oracle9i Developer Suite) este un instrument extrem de funcțional pentru proiectarea sistemelor software și a bazelor de date care implementează tehnologia CASE și metodologia proprie Oracle - CDM. Permite echipei de dezvoltare să finalizeze proiectul, de la analiza procesului de afaceri prin modelare până la generarea de cod și obținerea unui prototip și apoi a produsului final. Un instrument CASE complex, este logic să îl utilizați atunci când vizați linia de produse Oracle.

Cel mai puternic dintre aceste pachete software este pachetul Rational Rose (RR) de la IBM-Rational, cu ajutorul căruia puteți proiecta și menține întregul ciclu de viață al dezvoltării unui produs software (Fig. 4.15 Fig. 4.16. Menținerea ciclului de viață al unui software). produs cu RR

4.5. Implementarea sistemelor informatice

Introducerea SI corporativă, dezvoltată independent sau achiziționată de la un furnizor, este adesea însoțită de o întrerupere (reproiectare) a proceselor de afaceri existente în întreprindere. Trebuie să le reconstruiți pentru a îndeplini cerințele standardelor și logica sistemului implementat. Observăm imediat că introducerea IP rezolvă o serie de probleme manageriale și tehnice, dar naște probleme asociate cu factorul uman.

Introducerea unui sistem informatic, de regulă, facilitează foarte mult managementul unei întreprinderi, optimizează fluxurile de informații interne și externe și elimină blocajele în management. Totuși, după ce sistemul a fost instalat cu succes, „roda” în funcțiune și și-a demonstrat eficacitatea, unii angajați manifestă o reticență de a folosi IS în munca lor. Ca urmare a reinginerării, devine clar că unii angajați dublează în mare măsură munca altora sau nu sunt deloc necesari. În plus, introducerea CIS este însoțită de formare obligatorie, dar, așa cum se arată experiență rusă Nu sunt atât de mulți care doresc să se recalifice. Spărgerea vechilor abilități și insuflarea altora noi este un proces lung și dificil!

Trebuie să se înțeleagă clar că IP corporativă este concepută pentru a simplifica managementul organizației, a îmbunătăți procesele, a consolida controlul și a oferi beneficii competitive. Numai din acest punct de vedere este posibil să se evalueze beneficiile implementării sale.

Urmând această logică, devine clar că, deși SI-ul corporativ este în general menit să ofere tuturor utilizatorilor informațiile necesare, gestionarea dezvoltării și implementării CIS este apanajul conducerii de vârf a companiei! Înțeleg managerii asta?

Și aici trebuie să se confrunte cu stereotipuri tenace. „De ce am nevoie de un sistem de întreprindere dacă întreprinderea merge bine oricum?” „De ce să spargi ceva dacă totul funcționează?”. Dar de cele mai multe ori nu trebuie spart. În prima etapă, este necesar doar să se oficializeze și să se transfere în mod competent și corect procesele identificate în cadrul cărora întreprinderea trăiește către IS-ul corporativ. O astfel de formalizare nu va face decât să perfecționeze, să șlefuiască descoperirile de marketing și producție de succes, să optimizeze procesul de management și control și să permită efectuarea unor schimbări specifice în viitor.

Introducerea unui nou IS este un proces complex, care durează de la câteva luni pentru SI mici până la câțiva ani pentru SI ale companiilor mari distribuite cu o gamă largă de produse și un număr mare de furnizori. Succesul proiectului pentru dezvoltarea (achiziția) și implementarea SI depinde în mare măsură de disponibilitatea întreprinderii de a conduce proiectul, de interesul și voința personală a conducerii, de un program real de acțiune, de disponibilitatea resurselor, de personal instruit. , și capacitatea de a depăși rezistența la toate nivelurile organizației existente.

Până în prezent, a fost dezvoltat un set standard de metode pentru implementarea IP. Regula principală este de a efectua fazele obligatorii în succesiune și de a nu sări peste niciuna dintre ele.

Următorii factori sunt critici pentru implementare:

• disponibilitatea obiectivelor de proiect clar definite și a cerințelor IP;
• disponibilitatea unei strategii pentru implementarea și utilizarea IP;
• efectuarea unui studiu înainte de proiect al întreprinderii și construirea modelelor „Așa cum este” și „Așa cum va fi”;
• planificarea muncii, resursele și controlul asupra implementării planului de implementare;
• participarea managementului superior la implementarea sistemului;
• efectuarea lucrărilor de implementare a SI de către specialiști în integrarea sistemelor împreună cu specialiști ai întreprinderii;
• monitorizarea periodică a calității muncii prestate;
• obținerea rapidă a rezultatelor pozitive cel puțin în parte din modulele IS implementate sau în procesul de funcționare de probă a acestuia.

Înainte de a începe dezvoltarea unui proiect de implementare, trebuie să:

• formalizează pe cât posibil obiectivele proiectului de implementare a PI;
• estimați costurile și elementele de cheltuieli minime necesare;
• stabiliți o prioritate ridicată pentru proiectul de implementare față de alte proiecte în derulare;
• acordați managerului de proiect cât mai multă autoritate;
• desfășoară activități educaționale în masă cu personalul întreprinderii pentru a aduce tuturor importanța și necesitatea schimbărilor viitoare;
• dezvolta aranjamente organizatorice pentru aplicarea noilor tehnologii informatice;
• distribuie responsabilitatea personală pentru toate etapele implementării și operațiunii de probă.

De asemenea, este necesar să se definească arii funcționale implementarea modulelor sistemului informatic:

• management organizațional;
• suport organizatoric si administrativ;
• managementul proceselor de afaceri;
• management, planificare, financiar și contabilitate;
• managementul personalului;
• managementul documentatiei;
• managementul logisticii;
• gestionarea relatiilor cu clientii si mediul extern.

În plus față de cele enumerate mai sus, este necesar să se stabilească cerințe tehnologice pentru implementarea SI:

• platformă de sistem: implementare și adaptare soluție gata de la producător sau dezvoltare personalizată conform termeni de referinta client.
• integrabilitate: datele sunt stocate și prelucrate într-un singur spațiu de informare - aceasta le asigură completitatea, consistența, fiabilitatea și reutilizarea; sistemul poate include tehnologii și aplicații nou dezvoltate și deja utilizate.
• adaptabilitate: sistemul este configurat în conformitate cu cerințele clientului și cu caracteristicile câmpului de informații al clientului.
• distribuție: sistemul poate funcționa eficient în divizii și sucursale ale întreprinderii îndepărtate geografic.
• scalabilitate: sistemul poate fi implementat ca un cadru care conține module de bază și completat în conformitate cu cerințele unui mediu extern și intern în schimbare.

Principalele faze ale implementării sistemului informațional

Etapa „Lucrări preliminare la pregătirea proiectului de implementare a PI”. În timpul studiului pre-proiect al întreprinderii (Fig. 4.1.4), se colectează informații detaliate despre organizarea structurală a organizației, relațiile funcționale, sistemul de management, despre principalele procese de afaceri, despre fluxurile din cadrul întreprinderii (Control Flow, Doc Flow, Data Flow, Work Flow, Cash Flow) necesare pentru a construi modelele adecvate și a selecta obiecte pentru automatizare. Sunt estimate termenii, resursele, tipurile și volumele de muncă, gama și costul software-ului, hardware-ului și telecomunicațiilor, costul pregătirii personalului etc.

Faza „Pregătirea proiectului”. După finalizarea primei faze, se realizează planificarea preliminară și formarea procedurilor de lansare a proiectului:

• formarea de proiecte și grupuri de experți;
• repartizarea puterilor și responsabilităților;
• determinarea cerințelor organizatorice și tehnice pentru procesul de implementare;
• clarificarea specificațiilor și a așteptărilor clienților;
• instruirea grupului de implementare, format din specialiști din întreprinderea clientului.

Ultima este foarte punct important din anumite motive, este adesea omis atunci când se elaborează un plan de implementare. Dar succesul întregului proiect depinde în mare măsură de el! După începerea finanțării, proiectul se consideră lansat spre execuție.

Faza „Studiu conceptual al proiectului”. În această fază:

• se formează și se aprobă un design conceptual;
• se realizează o înțelegere neechivocă obligatorie a intențiilor tuturor participanților la proiect cu privire la SI implementat;
• se clarifică și se concretizează scopurile și obiectivele proiectului;
• se determină dimensiunile prototipului de sistem;
• se agreează planul de lucru consolidat, succesiunea etapelor și condițiile pentru funcționarea de probă, planificarea, indicatorii financiari și de raportare.

În același timp, toate aceste acțiuni sunt în mod necesar documentate, agreate și aprobate de toate părțile interesate și responsabile.

Faza „Implementarea proiectului”. În timpul lucrărilor principale de implementare, mediul de sistem este creat, instalat și configurat, sunt determinate procedurile de administrare a sistemului și sunt instalate principalele sisteme și aplicații software și hardware. Sistemul stabilește structurile organizatorice și de personal, precum și structurile organizatorice și funcționale ale întreprinderii folosind astfel de unități organizatorice ca ramură, departament, departament, grup de lucru etc.

Problemele de securitate sistemică ale funcționării sistemului în modul multi-utilizator sunt în curs de rezolvare. Sunt create aplicații, șabloane, rapoarte, forme de acces client, sunt distribuite puterile utilizatorului. Toate sistemele sunt testate în „modul de luptă” cu participarea tuturor părților interesate. După încheierea fazei de implementare, proiectul de implementare se consideră finalizat. Sistemul informatic este pus în funcțiune.

Conducerea unei afaceri este un amestec de ruletă și șah. De la ruletă apar evenimente pe care antreprenorul nu le poate influența, iar de la șah, nesfârșite analize și previziuni ale situației. Și tocmai analiza activităților întreprinderii trebuie să plătească managerul Atentie speciala. Una dintre componentele analizei este managementul proceselor de afaceri.

Principalele obiective ale managementului proceselor de afaceri

Pentru a răspunde la toate întrebările despre management, mai întâi trebuie să decideți ce procese de afaceri sunt într-o întreprindere. În esență, acesta este un set de sarcini și acțiuni conexe care duc direct sau indirect la rezultatul principal - obținerea de profit. Aproape totul, până la organizarea serviciului de curățenie, poate fi atribuit acestei categorii.

Acum că definițiile sunt îndepărtate, trebuie să luăm în considerare următorul aspect: ce implică managementul proceselor de afaceri. Această lucrare analitică poate fi împărțită în trei părți majore:

1. Modelarea proceselor;
2. Creare;
3. Îmbunătăţire.

În timpul fazei de simulare, prima sarcină va fi delimitarea activităților. Fiecare departament specific trebuie să își îndeplinească propriile sarcini, a căror listă trebuie să fie clar indicată pentru șefii diviziilor structurale. În această etapă se decide ce compoziție va funcționa pentru rezolvarea unei anumite probleme.

Etapa de creație este întotdeauna cea mai scumpă. Aici are loc crearea și implementarea acelor idei, asupra cărora este îndreptată prima etapă. Cea mai importantă etapă este compararea situației reale cu ceea ce era planificat. Aducerea realității cât mai aproape de situația „ideală” care este descrisă pe hârtie.

Cea mai dificilă și importantă lucrare începe în etapa de îmbunătățire. Desigur, poți sta pe loc, demonstrându-ți mecanismele bine unse an de an. Dar concurenții continuă să avanseze și, pentru a rămâne cu un pas înainte, trebuie să vă îmbunătățiți constant. Pentru a face acest lucru, va trebui să alocați un grup de specialiști și unul responsabil pentru acest domeniu. După găsirea unei metode de optimizare, aceasta va trebui implementată și apoi monitorizată pentru implementarea corectă. Și ciclul trebuie să se repete.

La o anumită etapă a dezvoltării organizației, pentru îmbunătățirea ciclică, va fi necesară o infuzie de „sânge tânăr”. Angajații care vă vor ajuta să aruncați o privire nouă asupra lumii familiare din cadrul companiei. De aceea este necesar fie extinderea personalului, fie selectarea analiștilor pentru post alături de angajați cu experiență, tineri care să privească tot ce se întâmplă cu alți ochi.

Metode moderne de îmbunătățire a proceselor de afaceri

Pentru a îmbunătăți procesele de afaceri, sunt utilizate diverse metode. În același timp, cercetătorii identifică cinci dintre cele mai relevante:

• Luare rapidă a deciziilor;
• Inginerie;
• Reinginerie;
• Reproiectarea unui anumit proces;
• Benchmarking.

Să vorbim mai detaliat despre fiecare dintre metode. Acestea sunt aranjate în funcție de impactul asupra companiei.

Luare rapidă a deciziilor

Această tehnică poate fi redusă la sintagma „Brainstorming”. Un grup de analiști își propune să îmbunătățească performanța unui anumit proces pentru o perioadă scurtă de timp - până la 90 de zile. De obicei, este nevoie de o întâlnire, care durează 1-2 zile lucrătoare, pentru a veni cu o metodă de lucru. Conducerea poate fie să aprobe o astfel de decizie, fie să o respingă. Unul dintre avantaje este luarea promptă a deciziilor.

Minus - soluția doar a problemelor locale. Cel mai adesea, nu cauza în sine este tratată, ci doar consecințele acesteia. Această metodă este potrivită pentru organizațiile conservatoare care nu doresc să schimbe nimic în mod semnificativ.

Benchmarking

În esență, aceasta este o analiză a proceselor altor organizații care sunt luate ca referință și găsirea motivelor discrepanței cu compania actuală. Acesta este, sarcina principalăîn acest caz, căutați o companie de referință, înțelegeți cum funcționează procesele sale, cum diferă de ale noastre și încercați să recreați aceleași condiții. Există multe plusuri, dar unul minus și semnificativ este posibilitatea de a transfera probleme. Nu există niciun plan de lucru elaborat de-a lungul anilor.

Reproiectarea procesului

Una dintre cele mai interesante și importante moduri de a gestiona. Se aplică acelor procese care nu au devenit încă învechite, dar nu mai pot îndeplini pe deplin funcțiile care le sunt atribuite din cauza schimbărilor în situația pieței sau a nevoilor consumatorilor. Poate fi folosit în multe domenii ale companiei. Îndeplinește sarcini specifice, dar, cu toate acestea, nu face decât să întărească situația actuală și nu poate schimba radical structura organizației.

Inginerie

Cel mai controversat mod de îmbunătățire a companiei. Există o mulțime de controverse în jurul lui și mulți experți nu pot determina ce include exact. Dar, în sens general, acesta este încă designul companiei „de la zero”. Un mod complet nou de a privi lucrurile, care vă permite să setați vectorul de dezvoltare, să creați toate procesele și să rezolvați noi probleme. Această metodă este potrivită numai pentru companiile noi.

Reinginerie

La fel ca metoda anterioară, presupune ceva global. Dar, în ciuda acestui fapt, se potrivește marilor corporații care doresc să regândească vectorul dezvoltării lor. metoda revolutionara, care vă permite să vă schimbați dramatic, făcând un salt uriaș înainte. A fost creat pentru a schimba complet toate tradițiile și normele care au fost stabilite în organizație. Distrugerea a ceea ce nu este în pas cu vremurile și „reconstruirea din cenușă” este esența reinginerării.

Reproiectarea procesului

Una dintre cele mai interesante și importante moduri de a gestiona. Se aplică acelor procese care nu au devenit încă învechite, dar nu mai pot îndeplini pe deplin funcțiile care le sunt atribuite din cauza schimbărilor în situația pieței sau a nevoilor consumatorilor.

Relevanța procesului de îmbunătățire

De mult a fost clar că o organizație fără dezvoltare nu poate fi competitivă. Și nu doar o companie nouă trebuie să se gândească la cum să intre pe piață, dar corporațiile veterane sunt pur și simplu obligate să cheltuiască averi de mai multe miliarde de dolari pentru îmbunătățirea constantă a tuturor proceselor lor de afaceri.

Pentru o companie nouă, îmbunătățirea este o modalitate excelentă de a te face cunoscut. La urma urmei, ceva care se schimbă constant, urmând piața, urmează invariabil valul de popularitate.

Un alt lucru este că nu este întotdeauna posibil să-ți creezi propriul stil în astfel de cazuri. De aceea este necesar să se păstreze o linie fină între schimbările nesfârșite și fidelitatea față de tradiții.

Companiile mari, in schimb, trebuie neaparat sa isi analizeze activitatile. Cu o cantitate mare de resurse, puteți pierde unele detalii și, din cauza neatenției, nu veți primi profit. Analiza constantă face posibil să se determine ce funcționează cel mai bine și ce nu, să rezolve rapid problemele emergente și să te simți liber în fața concurenței constante.

Indiferent de dimensiunea companiei, îmbunătățirea continuă a proceselor de afaceri este cheia dezvoltării de succes și a profitului continuu.

Programe de lucru pentru îmbunătățirea proceselor de afaceri

În era robotizării puternice, monitorizarea și analiza pot fi obținute de mașini. Mai jos este primele 3 cele mai multe programe interesante pentru a îmbunătăți procesele de afaceri:

Aris Express

Un program destul de simplu și de înțeles pentru modelarea proceselor unei organizații. Simplifică implementarea diferitelor sisteme, vă permite să controlați execuția proceselor, precum și să optimizați costul acestora. Prezentat în limba rusă. Există o tehnologie de limbă rusă. A sustine.

studio de afaceri

Mai mult program global pentru a dezvolta și implementa strategia. Versiunea plătită vă permite să implementați atât controlul asupra execuției tuturor proceselor, cât și sarcini mai mici, cum ar fi personalul. Va ajuta la distribuirea tuturor documentației necesare între angajați. Programul de la producătorul rus.

Managerul Fox

Un program la scară largă care vă permite să creați complet un model de procese de afaceri într-o întreprindere. Generează raportări în timp real și oferă utilizatorului diverse soluții. Diferă prin simplitate, funcționalitate și accesibilitate. Există o versiune în rusă.

Există multe programe precum IBM Business Modeler, elma și altele care vă permit, de asemenea, să efectuați sarcini similare. Dar nu sunt atât de simple, iar munca va necesita specialiști care au desfășurat anterior activități în aceste programe.

În general, pentru cei care doresc să se perfecționeze constant, să fie activi și competitivi, doar calea îmbunătățirii continue este potrivită. Și modul de implementare depinde de conducerea și angajații companiei.

In contact cu