Verslo modeliavimo įrankiai ir jo taikymo ypatybės. Šiuolaikinių verslo procesų modeliavimo įrankių analizė Verslo procesų modeliavimo įrankiai

Medžiagą paruošė bendrovės „Abis Soft“ specialistai

Kaip padaryti pasirinkimą

Prieš pradėdami rinktis programinės įrangos produktą, turite atsakyti į tris pagrindinius klausimus:

1. Ką reikia aprašyti?

2. Kiek reikia apibūdinti?

3. Kaip bus stebimas našumas?

Atsakydami į pirmąjį klausimą, turėtumėte nustatyti, kurias valdymo sistemos sritis aprašysite, ar būtinas išsamus visos sistemos aprašymas.

Atsakymas į antrąjį klausimą turėtų parodyti, ar valdymo sistema bus aprašyta konkrečiam verslui, skyriui ar visai organizacijai.

Trečiasis klausimas nustatys apribojimus, kuriuos galima nustatyti programinės įrangos produktui, kad ateityje būtų galima jį integruoti į vykdomąją sistemą.

Gavę atsakymus į šiuos klausimus, galite žymiai susiaurinti galimų spektrą programinės įrangos produktai.

  • Galimybė dirbti su keliais vartotojais,
  • Rezultatų pateikimo metodai,
  • Sąsaja ir ergonomika,
  • Prieiga prie dokumentų ir techninės pagalbos,
  • Aparatūra ir programinė įranga,
  • Kaina.

Neapsimesdami galutine tiesa, apžvalgos autoriai siūlo keletą variantų, kaip įvertinti peržiūrimus produktus.

1. Jei įmonė jau sukūrė strategiją ir ją reikia kontroliuoti, tada iš straipsnyje aptartų užsienio produktų sprendimas geriausiai tinka šiam tikslui „Hyperion Performance Scorecard“ pateikė „Oracle“.

2. Jei pagrindinis dėmesys skiriamas verslo procesams įmonėje, tuomet įmonės produktas yra optimalus. IBM - „IBM WebSphere Business Modeler“.

(Reikėtų paaiškinti, kad programinės įrangos pasirinkimas iš gamintojų, tokių kaip IBM, Oracle, SAP, nulemtas pasirinkimo ERP-atitinkamo gamintojo sistemos. Jų verslo modeliavimo programinė įranga yra sudėtingų produktų posistemės.)

3. Iš rusiškų produktų patartina naudoti INTALEV: Įmonių navigatorius jei norite apibūdinti visą įmonę (holdingą) kaip visumą, o ne tik vieną verslo vienetą (padalinį ar filialą).

Informacija buvo gauta iš gamintojų atstovų Rusijos Federacijos teritorijoje arba iš oficialių gamintojų svetainių.

„ARIS Business Performance Edition“.

Įdiegta naudojant sistemą „IBM Rational ClearCase“

Verslo procesų modeliavimas yra veiksminga priemonė ieškant būdų optimizuoti įmonės veiklą, leidžianti nustatyti, kaip įmonė veikia kaip visuma ir kaip veikla organizuojama kiekvienoje darbo vietoje. Verslo proceso modelio (aprašymo) kūrimo metodika (žymėjimas) suprantama kaip visuma būdų, kuriais realaus pasaulio objektai ir jų tarpusavio ryšiai pateikiami modelio forma. Kiekvienam objektui ir nuorodoms būdingi keli parametrai arba atributai, atspindintys tam tikras realaus objekto savybes (objekto numeris, pavadinimas, aprašymas, vykdymo trukmė (funkcijoms), kaina ir kt.).

Verslo procesų aprašymas atliekamas tolesnei jų analizei ir pertvarkymui. Reorganizavimo tikslas gali būti informacinės sistemos įdiegimas, išlaidų mažinimas, klientų aptarnavimo kokybės gerinimas, darbo ir darbo instrukcijų kūrimas ir kt., O išsamus procesų aprašymas pats savaime nėra vertingas.

Perprojektavimas verslo procesai (angl. Business business reengineering) yra esminis verslo procesų permąstymas ir radikalus pertvarkymas siekiant maksimalaus gamybos, ekonominės ir finansinės bei ekonominės veiklos efektyvumo, įformintas atitinkamų organizacinių ir administracinių bei norminius dokumentus... Verslo inžinerija susideda iš verslo procesų modeliavimo (modelio kūrimo „kaip yra“, jo analizės, modelio „kaip turėtų būti“) ir perėjimo į „kaip reikia“ būsenos plano sukūrimo ir įgyvendinimo.

Daugelis šiuolaikinių verslo procesų modeliavimo metodikų yra pagrįstos SADT metodika (struktūrinė analizė ir projektavimo technika), IDEF standartų šeima („Icam DEFinition“, kur „Icam“ reiškia integruotą kompiuterinę gamybą) ir algoritminės kalbos.

Pagrindinės verslo procesų modeliavimo ir analizės metodikos rūšys:

Verslo procesų modeliavimas ( Verslo procesų modeliavimas). Plačiausiai naudojama verslo procesų aprašymo metodika yra IDEF0 standartas. Modeliai, pažymėti IDEF0, yra skirti aukšto lygio įmonės verslo aprašymui funkciniu aspektu.

Darbo eigos aprašymas ( Darbo eigos modeliavimas). IDEF3 standartas skirtas aprašyti darbo eigą ir yra artimas algoritminiams blokinių diagramų sudarymo metodams.

Duomenų srautų aprašymas ( Duomenų srauto modeliavimas). DFD žymėjimas ( Duomenų srauto schema), leidžia atspindėti proceso metu atliktų darbų seką ir tarp šių darbų sklandančius informacijos srautus.

Kitos metodikos.


Norint gauti pridėtinę produkto ar paslaugos vertę, galima išskirti šias procesų klases:

Pagrindiniai verslo procesai (pvz., Produktų rinkodara, gamyba, tiekimas ir aptarnavimas).

Verslo procesų palaikymas neprideda gaminiui pridėtinės vertės, bet padidina jo vertę (pavyzdžiui, finansinė operacijų parama, personalas, teisinė parama, administravimas, saugumas, komponentų tiekimas, remontas ir Priežiūra ir tt).

Verslo procesų valdymas.

Verslo modelis yra formalizuotas (grafinis, lentelinis, tekstinis, simbolinis) verslo procesų aprašymas. Pagrindinė verslo modelių taikymo sritis yra verslo procesų pertvarkymas.

Verslo procesų modeliavimo tikslai paprastai formuluojami taip:

Suteikti supratimą apie organizacijos struktūrą ir joje vykstančių procesų dinamiką;

Suteikti supratimą apie esamas organizacijos problemas ir jų sprendimo galimybes;

Užtikrinti, kad klientai, vartotojai ir kūrėjai vienodai suprastų organizacijos tikslus ir uždavinius;

Sukurti pagrindą programinės įrangos, kuri automatizuoja organizacijos verslo procesus, formavimui (reikalavimai programinei įrangai formuojami verslo modelio pagrindu).

Svarbus verslo procesų modelio elementas yra verslo taisykles arba domeno taisyklės. Įprastos verslo taisyklės įmonių politika ir valstybės įstatymai. Verslo taisyklės paprastai yra suformuluotos konkrečiame dokumente ir gali atsispindėti modeliuose.

Skilimas bendrąja prasme tai yra metodas, leidžiantis vienos didelės problemos sprendimą pakeisti mažesnių užduočių sprendimu, padalijant objektą į jo sudedamąsias dalis pagal nurodytą kriterijų. Praktiškai skaidymas naudojamas verslo modeliams tobulinti.

Verslo procesų aprašymo etapai:

Aprašymo tikslų nustatymas.

Aplinkos aprašymas, verslo proceso įėjimų ir išėjimų apibrėžimas, IDEF0 diagramų sudarymas.

Funkcinės struktūros aprašymas (proceso veiksmai), IDEF3 diagramų konstravimas.

Proceso srautų (materialinių, informacinių, finansinių) aprašymas, DFD diagramų sudarymas.

Organizuojant proceso organizacinę struktūrą (padaliniai, dalyviai, atsakingi).

IDEF0

Modelį sudaro diagramos, teksto fragmentai ir žodynėlis, susieti vienas su kitu. Diagramos yra pagrindiniai modelio komponentai, visos juose esančios funkcijos ir sąsajos pateikiamos kaip blokai ir lankai.

Ryšys tarp lanko ir bloko lemia sąsajos tipą:

Valdymo informacija patenka į bloką viršuje.

Įvesties informacija patenka į kairėje esantį bloką.

Rezultatai pateikiami dešinėje esančiame bloke.

Mechanizmas (žmogaus ar automatizuota sistema), kuri atlieka operaciją, įeina į bloką iš apačios.

Kiekvieną modelio komponentą galima išskaidyti (išsamiau iššifruoti) kitoje diagramoje. Rekomenduojama nutraukti modeliavimą, kai modelio detalumas atitinka jo paskirtį. Bendras modelio lygių skaičius neturėtų viršyti 5-6.

Diagramavimas prasideda vaizduojant visą sistemą kaip vieną bloką ir lankus, vaizduojančius sąsajas su funkcijomis, esančiomis už sistemos ribų. Tada blokas, vaizduojantis sistemą kaip vieną vienetą, yra išsamiai aprašytas kitoje diagramoje, naudojant kelis blokus, sujungtus sąsajos lankais. Kiekviena išsami schema yra bloko skilimas iš ankstesnio lygio diagramos. Kiekviename skaidymo etape ankstesnio lygio diagrama vadinama pagrindine diagrama.

Tokiose diagramose nei seka, nei laikas nėra aiškiai nurodyti. Metodas turi nemažai trūkumų: suvokimo sudėtingumas (daug lankų diagramose ir daugybė skilimo lygių), sunkumas susieti kelis procesus.

IDEF3

Šis metodas skirtas imituoti veiksmų seka ir tarpusavio priklausomybės procesuose. IDEF3 modeliai gali būti naudojami norint ištirti IDEF0 funkcijų blokus, kuriuose nėra skilimo diagramų.

Rodomos IDEF3 diagramos veiksmas stačiakampio pavidalu. Veiksmai įvardijami naudojant veiksmažodžius ar žodinius daiktavardžius, kiekvienam veiksmui priskiriamas unikalus identifikavimo numeris (prieš veiksmo numerį paprastai nurodomas jo pirminio numeris, pavyzdžiui, 1.1.).

Visos IDEF3 nuorodos yra vienkryptės ir tvarkomos iš kairės į dešinę.

IDEF3 nuorodų tipai:

Laikina pirmenybė, paprasta rodyklė. Prieš pradedant galutinį veiksmą, pradinis veiksmas turi būti baigtas.

Objekto srautas, dvipusė rodyklė. Pradinio veiksmo rezultatas yra galutinio veiksmo įvestis. Prieš pradedant galutinį veiksmą, pradinis veiksmas turi būti baigtas. Srautinių nuorodų pavadinimai turėtų aiškiai identifikuoti objektą, kuris yra perduodamas naudojant juos.

Neaiškūs santykiai, brūkšninė rodyklė.

Užbaigus vieną veiksmą galima pradėti vykdyti kelis kitus veiksmus vienu metu arba, priešingai, tam tikram veiksmui gali prireikti atlikti kelis kitus veiksmus prieš pradedant vykdyti (proceso šakojimas).

Proceso išsišakojimas atsispindi naudojant specialius blokus:

- „Ir“, užblokuokite & ženklu.

- „Išskirtinis ARBA“ („vienas iš“), blokuoti su X ženklu.

- „ARBA“, užblokuokite su O ženklu.

Jei veiksmai „IR“, „ARBA“ turi būti atliekami sinchroniškai, tai rodo dvi dvigubos vertikalios linijos bloko viduje, asinchroniškai - viena.
IDEF3 metodas leidžia jums išskaidyti veiklą kelis kartus, taip dokumentuojant alternatyvius proceso srautus viename modelyje.

DFD

Šio pristatymo tikslas yra parodyti, kaip vyksta kiekvienas procesas transformuoja jų indėlis duomenis savaitgalį. Jis gali atspindėti ne tik informaciją, bet ir medžiagų srautus. Be to, kaip ir kituose modeliuose, palaikomas irimas.

Pagrindiniai duomenų srautų diagramų komponentai yra šie:

Išoriniai subjektai (materialus objektas arba individualus kurie yra informacijos šaltinis ar gavėjas, pavyzdžiui, klientai, darbuotojai, tiekėjai, klientai, sandėlis);

Sistemos ir posistemiai (pavyzdžiui, posistemis darbui su asmenimis);

Procesai (įvesties duomenų srautų pavertimas išvestimi pagal tam tikrą algoritmą; fiziškai tai gali būti, pavyzdžiui, organizacinis vienetas (departamentas), apdorojantis įvesties dokumentus ir ataskaitų išdavimą, programa, aparatinės įrangos įdiegtas loginis įrenginys ir kt.) .);

Duomenų saugojimo įrenginiai (abstraktūs informacijos saugojimo įrenginiai);

Duomenų srautai (rodyklės diagramoje).

Kiekvienoje diagramoje būtina įdėti nuo 3 (mažiau nėra prasmės) iki 7 (daugiau - nesuvokiama) procesų, neperkraunant diagramų detalėmis, kurios šiame lygmenyje yra nereikšmingos.

Pirmasis žingsnis kuriant DFD hierarchiją yra kontekstinių diagramų kūrimas. Paprastai, projektuojant palyginti paprastas sistemas, sukuriama vieno konteksto diagrama su žvaigždės topologija, kurios centre yra vadinamasis pagrindinis procesas, prijungtas prie kriauklių ir informacijos šaltinių. Sudėtingoms sistemoms (dešimt ar daugiau išorinių objektų, paskirstytas sistemos pobūdis ir daugiafunkciškumas) sukuriama kontekstinių diagramų hierarchija. Tuo pačiu metu aukščiausio lygio kontekstinėje diagramoje yra ne vienas pagrindinis procesas, o posistemių rinkinys, sujungtas duomenų srautais.

Kiekvienas DFD procesas gali būti išsamiai aprašytas naudojant DFD arba (jei procesas yra elementarus) specifikaciją. Specifikacijos yra procesų atliekamų užduočių algoritmų aprašymai. Specifikacijos kalbos gali būti įvairios - nuo struktūrizuotos natūralios kalbos arba pseudokodo iki vizualinio modeliavimo kalbų.

Verslo procesų modeliavime duomenų srautų diagramos (DFD) naudojamos AS-IS ir AS-TO-BE modeliams kurti, taip atspindint esamą ir siūlomą organizacijos verslo procesų struktūrą.

ARIS

Šiuo metu pastebima įvairių modeliavimo metodų integravimo tendencija, kuri pasireiškia integruotų modeliavimo priemonių kūrimu. Vienas iš šių įrankių yra programinės įrangos produktas, vadinamas ARIS (Integruotų informacinių sistemų architektūra), sukurtas Vokietijos bendrovės IDS Scheer.

ARIS palaiko keturių tipų modelius (ir daugybę kiekvieno tipo modelių), atspindinčius skirtingus tiriamos sistemos aspektus:

Organizacijos modeliai, atspindintys sistemos struktūrą - organizacinių vienetų, pareigų ir konkrečių asmenų hierarchiją, ryšius tarp jų, taip pat struktūrinių padalinių teritorinį susiejimą;

Funkciniai modeliai, turintys tikslų hierarchiją, su kuria susiduria valdymo aparatas, ir funkcijų medžių rinkinys, būtinas tikslams pasiekti;

Informaciniai modeliai, atspindintys informacijos struktūrą, reikalingą visam sistemos funkcijų rinkiniui įgyvendinti;

Valdymo modeliai, atspindintys integruotą požiūrį į verslo procesų diegimą sistemoje.

Norint sukurti išvardytus modelių tipus, naudojami tiek patentuoti ARIS modeliavimo metodai, tiek įvairūs gerai žinomi modeliavimo metodai ir kalbos, ypač UML. Modeliavimo procesą galite pradėti naudodami bet kurį modelio tipą.

Pagrindinis ARIS verslo modelis yra eEPC (išplėstinė įvykiu pagrįsta proceso grandinė). ARIS eEPC žymėjimas yra IDEF3 žymėjimo pratęsimas. Verslo procesas eEPC žymėjime yra nuosekliai atliekamų darbų (procedūrų, funkcijų) srautas, išdėstytas jų vykdymo tvarka. EEPC vizualiai neatspindi tikrosios procedūros trukmės.

Norint gauti informacijos apie tikrąją procesų trukmę, būtina naudoti kitas aprašymo priemones, pavyzdžiui, MS Project.

ARIS modeliai yra diagramos, kurių elementai yra įvairūs objektai- „funkcijos“, „įvykiai“, „ struktūriniai vienetai"," dokumentai "ir tt Tarp tam tikrų tipų objektų galima įdiegti jungtys tam tikrų tipų („vykdo“, „priima sprendimą“, „turi būti informuotas apie rezultatus“ ir pan.). Kiekvienas objektas atitinka tam tikrą atributų rinkinį, kuris leidžia įvesti Papildoma informacija apie konkretų objektą.

Pagrindiniai eEPC žymėjimo objektai:

Funkcija. Naudojamas apibūdinti įmonės padalinių / darbuotojų funkcijas (procedūras, darbus). Kiekvieną funkciją turi sukelti įvykis ir ji turi baigtis įvykiu; kiekvienoje funkcijoje negali būti daugiau nei viena rodyklė, „pradedanti“ funkcijos vykdymą, ir iš daugiau nei vienos rodyklės, apibūdinančios funkcijos vykdymo pabaigą.

Įvykis. Tarnauja aprašant tikrus įvykius, turinčius įtakos funkcijų vykdymui.

Organizacinis vienetas. Pavyzdžiui, vadovybė ar skyrius.

Dokumentas. Atspindi tikras žiniasklaidos priemones, tokias kaip popieriniai dokumentai.

Taikoma sistema.

Informacijos sankaupa. Apibūdina objektų rinkinį ir tarpusavio santykius.

Bendravimas tarp objektų. Santykių tarp objektų tipas, pavyzdžiui, tam tikro įvykio funkcijos vykdymo aktyvinimas.

Loginis operatorius. Operatorius „AND“, „OR“ arba išskirtinis „OR“ leidžia apibūdinti proceso išsišakojimą.

Jei, kuriant modelį eEPC, nurodoma tik procedūrų seka, nesirūpinant dėl ​​kontrolės dokumentų ir informacijos atspindžio, gauti modeliai turės mažą vertę analizės ir tolesnio naudojimo požiūriu.

Norėdami išsaugoti modelius ARIS, naudojama objekto DBVS ir kiekvienam projektui sukuriama nauja duomenų bazė. Pateikiamos įvairios duomenų bazės administravimo funkcijos, pavyzdžiui, prieigos kontrolė. Duomenų bazė yra hierarchinė modelių saugykla.

Modelio kūrimo darbus turėtų reglamentuoti griežtos ir didelės apimties modeliavimo sutartys (standartai), ARIS palaiko metodinių filtrų mechanizmą, leidžiantį vartotojui naudoti tik tam tikrą schemų ir objektų rinkinį. Tokiems susitarimams parengti reikia daug laiko ir aukštos kvalifikacijos specialistų. Jei projektas, kuriame naudojama ARIS, pradedamas išsamiai neišsiaiškinus tokių sutarčių, tikimybė sukurti verslo procesų modelius, neatsakančius į pateiktus klausimus, yra labai didelė.

Dabar, bendrai išaiškinus bendras funkcines užduotis, kurias išsprendė nagrinėjamos priemonės, būtina palyginti šių priemonių teikiamas galimybes.

Tolesnėje analizėje bus atsižvelgiama tik į ARIS ToolSet (toliau-ARIS), BP-Win-Erwin (toliau BP-Win) ir ORG-Master (toliau-ORG-Master) programų ypatybes. „Rational Rose“ programa daugiausia skirta grynai programinės įrangos, o ne organizacinių sistemų kūrimui, siekiant supaprastinti pateikimą, neįtrauksime į svarstymą, ypač todėl, kad pagrindinė UML metodika dabar įdiegta ARIS).

Verslo sistemų modeliavimo įrankių funkcionalumas

Lyginant įvairias verslo sistemų modeliavimo priemones, patartina atsižvelgti į jų ypatybes pagal šias funkcinių galimybių grupes:

  • verslo sistemų modelių kūrimo įrankiai;
  • modelių analizės įrankiai;
  • imituojamų sistemų optimizavimo priemonės pagal jų modelius;
  • parama tipiškų modelių bibliotekoms;
  • taisyklių ir dokumentų registravimas;
  • parama duomenų bazių modelių ir programinės įrangos kūrimui;
  • integracija su kitais programinės įrangos produktais (CASE įrankiai, ERP sistemos, taikomosios programos).
  • bendras verslo procesų organizavimas ir organizacinių padalinių (atlikėjų) sąveikos tvarka,
  • atsakomybės už atskirų funkcijų įgyvendinimą ir sistemos išteklių naudojimą paskirstymas,
  • organizacinių saitų, atlikėjų ir instrumentinių išteklių įkėlimas į sistemą,
  • pagrindiniai imituotos sistemos laiko ir išlaidų parametrai,
  • sistemoje vykstančių procesų išteklių aprūpinimo reikalavimai.

Analizė bendras verslo procesų organizavimas ir organizacinių padalinių sąveikos tvarka sistemoje atliekamas tiesiogiai tiriant sukonstruotus verslo procesų modelius. Kokybinė analizė taip pat leidžia jums juos atpažinti vaidmuo, kuris tam tikromis sąlygomis gali būti pašalintas iš proceso. Kurioje modelio matomumas ir galimybė atsekti sistemoje esančius ryšius tampa nepaprastai svarbi.

Žemiau pateikiamos pastabos dėl modelių aiškumo. Tačiau čia taip pat reikėtų pažymėti, kad svarbus modelio reikalavimas yra jo analizės galimybė prieš ją visiškai statant. Iš tiesų, jei sistemoje galima nustatyti sąsajas (taip pat ir jų nebuvimą) tik sukūrus visą jos modelį, tai pasirodo labai nepatogu pradiniuose darbo etapuose, kai pateikiama informacija apie vykstančių procesų ypatybes. sistemoje vis dar gali iš dalies nebūti arba ji gali būti netiksli.

Čia „ORG-Master“ yra palankioje padėtyje, nes jame esančių verslo procesų modelis nėra sukurtas tiesiogiai IDEF diagramos pavidalu. Ši diagrama gali būti automatiškai sugeneruota sukūrus ir užpildžius modelį sudarančius klasifikatorius (verslo funkcijas, organizacinius vienetus, išteklius ir kt.) Ir nustačius visas būtinas prognozes (išteklių, atlikėjų, įrankių, taisyklių ir faktinių ryšių santykiai) verslo operacijos). Taigi, dar prieš gaunant pilną (ar dalinį) verslo proceso modelį, pagrindiniai modeliuotą procesą lemiantys santykiai jau yra nustatyti ir gali būti analizuojami.

Priešingai šiam požiūriui, ARIS ir BP-Win verslo procesų modeliai yra kuriami tiesiogiai, o esami santykiai tarp proceso komponentų turi būti paruošti analizei atlikus atitinkamas procedūras.

Taigi, pavyzdžiui, sukūrus verslo proceso modelį „BP-Win“, naudojant „ERwin“ sukuriamas atskiras duomenų modelis, kuriame nustatomos sąsajos tarp sistemos komponentų (duomenų modelio objektai pagal metodiką). Tada šie modeliai susiejami mechanizmu, kuris iš esmės yra panašus į ORG-Master naudojamą projekcijos konstrukcijos mechanizmą (žr. 1 priedą. „ORG-Master“ programinės įrangos modelio komponentai ir metodinis kompleksas).

Atsižvelgiant į tai, antroji iš svarstomų modelio analizės galimybių: atsakomybės už atskirų funkcijų įgyvendinimą ir sistemos išteklių naudojimo pasiskirstymo analizė, pasirodo automatiškai įgyvendinamas kuriant verslo proceso modelį ORG-Master sistemoje. Iš tiesų, organizacinio ryšio - Funkcijos ir funkcijos - ištekliai projekcijos, nurodytos kuriant verslo procesų modelius „ORG -Master“, tiesiogiai parodo asmenis, atsakingus už tam tikrą darbo ar išteklių sritį (ir leidžia bet kokį jų derinį) išanalizuota). Be to, „ORG-Master“ leidžia eksportuoti matricos projekcijas į „MS Excel“, kur jų pagrindu sudaromos organizacinės analizės diagramos.

ARIS ir BP-Win šiuo tikslu būtina arba rankiniu būdu atsekti visus ryšius verslo procesų diagramose (ir duomenų modeliuose BP-Win), arba specialiai sudaryti atitinkamus sąrašus ar ataskaitas.

Klausimas apie atlikėjų ir instrumentinių išteklių įkėlimą į sistemą, taip pat apskaičiuoti pagrindinius imituotos sistemos laiko parametrus, gali būti nuspręsta remiantis kiekybiniais duomenimis apie jų vykdomų funkcijų sudėtingumą (ar tiesiog trukmę). Norint išspręsti šią problemą, būtina vienaip ar kitaip įvesti tokius duomenis į sistemą, taip pat numatyti priemones apibendrinamiems įvertinimams gauti. Parama IDEF3 metodikai (naudojant BP-Win), ABC metodai ARIS ir BP-Win, taip pat modeliavimo įrankiai ARIS (ir iš dalies BP-Win) numato kai kuriuos šių įvertinimų apdorojimo būdus. Kalbant apie faktinius pradinius duomenis, juos nustato vartotojas, todėl jis yra atsakingas už galutinį rezultatą.

Tačiau norint gauti pakankamai reprezentatyvių įvertinimų naudojant statistinį (modeliavimo / įvykio) modeliavimą (ir, be to, naudojant ABC metodus, laikant laiką kaip išteklių), pakrauti sistemos komponentus, trukdo šie veiksniai.

Šiuolaikiniai bet kurio proceso analizės metodai ( darbo eiga) padalinkite jo įgyvendinimo laiką iš tikrųjų į operacijų vykdymo laikotarpį ir jų rezultatų perdavimo laiką. Tuo pačiu metu biuro procesuose ar paslaugos teikimo procesuose faktinis darbas vidutiniškai trunka apie 10% laiko, o likęs laikas skiriamas fiziniam užduoties rezultato judėjimui (tam reikia sutarties teksto, kurį reikia dar kartą nuplauti, pasirašymas) ir laukdamas eilės, kol kitas vykdytojas ras laiko tęsti procesą. Todėl metodai, pagrįsti paprastu operacijų laiko apibendrinimu šiuo metu, paprastai nesuteikia tikslaus proceso laiko parametrų vaizdavimo.

Galite pabandyti gauti tinkamesnius rezultatus, imituodami sistemos elgesį. Tačiau paslaugų vėlavimo metu reikia arba padaryti labai apytiksles prielaidas apie jų paskirstymo įstatymą laiku, arba atlikti gana brangias ir daug darbo reikalaujančias laiko procedūras ir vėlesnį statistinį apdorojimą. Tuo pačiu metu gautų rezultatų patikimumas nebus per didelis arba reikės didelių papildomų išlaidų. Todėl atrodo protinga manyti, kad: „modeliavimo sąnaudos bet kokiai informacijai gauti neturėtų viršyti jos naudojimo rezultatų vertės (išlaidų). Be to, visada reikia prisiminti apie Pareto įstatymą, iš kurio, atsižvelgiant į nagrinėjamą problemą, matyti, kad 20% modeliavimo pastangų suteikia 80% efekto.

Todėl, mūsų požiūriu, prieš pereinant prie sudėtingų ir daug laiko reikalaujančių ir daug išteklių reikalaujančių modeliavimo metodų, susijusių su kiekybiniais laiko ir sąnaudų parametrų įvertinimais, verta sutelkti dėmesį į tai, kad būtų pasiektas akivaizdesnių verslo rezultatų įgyvendinimo poveikis modeliavimas. Patartina kiekybinį optimizavimą atlikti atsižvelgiant į realaus gyvenimo procesų matavimus ir analizę.

„ORG -Master“ turi funkcinį ABC analizės įrankių analogą - biudžeto sudarymo vedlį, kuris sukuria paprastą biudžeto sudarymo sistemą. Vienas iš šios sistemos darbo rezultatų yra kiekybinis verslo procesų įgyvendinimo išlaidų (veiklos biudžetų) įvertinimas, kurio vertė bent jau yra palyginama su duomenimis, gautais naudojant ABC išlaidų apskaičiavimo pagalbines priemones.

Be to, „ORG-Master“ šeimai taip pat priklauso „Time-Master“ programinės įrangos paketas, kurio vienas iš komponentų, užtikrinantis procesų valdymą (darbo eigą), leidžia jų vykdymo metu kaupti statistiką, kurioje pateikiami įvertinimai analizei būtinų procesų laiko parametrus.

  • Verslo sistemų optimizavimo įrankiai (verslo procesai) be modelių analizės galimybių suteikia: valdymo įrankį.
  • įvairių alternatyvų kūrimas;
  • planavimas;
  • pasirinkti geriausią veiksmų būdą;
  • išteklių paskirstymas;
  • prioritetų nustatymas.

Paprastai išvardytų funkcijų įgyvendinimas yra susijęs su specialių gana sudėtingų ar sudėtingų algoritmų naudojimu optimizavimo problemoms spręsti. Į ARIS sistemą įtraukta daug tokių galimybių. Tačiau apskritai jų įgyvendinimas neatrodo tinkamas iki patobulinus verslo procesą, pasiekus jo restruktūrizavimo rezultatus naudojant paprastesnius metodus.

Parama bendroms modelių bibliotekoms leidžia panaudoti anksčiau sukurtus pokyčius kuriant naujus modelius. Ši galimybė suteikiama visose trijose svarstomose priemonėse. Visų pirma, „ORG-Master“ palaiko tiek išsamius įmonių orientacinius verslo modelius, gautus įgyvendinant realius projektus Rusijos įmonėse, tiek „bibliotekų“ klasifikatorius, apibūdinančius tipišką atskirų veiklos aspektų organizavimą.

Dekoras, pagal pagamintus modelius, įmonės nuostatai atrodo labai svarbi galimybė užtikrinti verslo sistemos dokumentinio aprašymo vientisumą ir nuoseklumą. Šio komponento svarbą verslo modeliavimo priemonėms galima suprasti pažvelgus į reglamentus kaip į įmonės valdymo įrankį. Iš tiesų, jei įmonė yra stabili, tai reiškia, kad jos verslo procesai yra gerai sutepti ir gali būti beveik formaliai reglamentuojami. Vidinė kultūra, kuri turi būti tokioje įmonėje, leis prireikus greitai atstatyti verslo procesų sistemą ar parametrus, keičiant atitinkamų padalinių ir atlikėjų darbo reglamentą.

Dokumentų ir taisyklių, reglamentuojančių visus įmonės veiklos aspektus, buvimas yra viena iš pagrindinių reguliarumo, sistemos valdymas... Anot jos, gerai organizuotame versle apie 80% valdymo sprendimų priimama pagal iš anksto nustatytas procedūras, o tik likusi dalis, susijusi su nestandartinėmis situacijomis ir įvairiomis naujovėmis, remiasi darbuotojų kūrybiškumu ir didvyriškumu.

Įmonės (įmonės) organizaciją, kuria siekiama tam tikrų tikslų, šiuolaikiniu lygiu reguliuoja toks standartinis pagrindinių organizacinių dokumentų rinkinys:

  • nuostata dėl organizacinės ir funkcinės struktūros, atspindinčios įmonėje esančių įmonių sudėtį ir funkcijas bei jų pasiskirstymą įmonėje;
  • nuostatas dėl įmonės politikos (apskaita, investicijos ir kt.);
  • nuostatas dėl pagrindinių verslo posistemių organizavimo ir įmonės valdymo, įskaitant išsamų funkcijų aprašymą pagal verslo sritis;
  • dokumentuotos procedūros - verslo procesų aprašymai tokia forma, kuri leidžia tiek pristatyti procesą pašaliniam stebėtojui, tiek vadovautis šiuo dokumentu proceso operacijų vykdytojams;
  • ir galiausiai, tradicinės „padalijimo sąlygos“ ir pareigybių aprašymus»Personalas su funkcinių pareigų sąrašais, atsakomybės rūšimis, darbuotojų teisėmis ir įgaliojimais.

Be to, turėtų būti įmanoma sukurti specialias ataskaitų formas, skirtas dokumentams kurti įvairiose funkcinėse srityse: Įgaliojimai apie įmonės valdymo informacinę sistemą, kokybės vadovą (žr., pavyzdžiui, 3 priedą) ir kitus specialius dokumentus pagal ISO9000 standartą ir kt.

Visa informacija, leidžianti sugeneruoti šiuos dokumentus, turi būti pateikiama nuoseklios ir nuoseklios sistemos pavidalu visame įmonės (įmonės) verslo modelyje. Be to, daugelis sukurtų dokumentų turi kuo labiau atitikti visuotinai priimtus Rusijos standartus (akivaizdu, kad ARIS ir BP-Win sistemos mažiausiai atitinka paskutinį reikalavimą).

„ORG-Master“ aplinkoje tokie teiginiai ir nurodymai generuojami automatiškai kaip tekstinės procedūrų aprašymų formos, vaizduojamos atitinkamais klasifikatoriais ir ryšių projekcijomis tarp jų. Grafinės formos (įvairios skaitmenys ir proceso diagramos) puikiai papildo šiuos dokumentus.

ARIS aplinkoje pareigybių ir procesų aprašymai yra pagrįsti įvykių procesų schemomis ir iš esmės įvairius tekstinius dokumentus galima bandyti sukonstruoti analizuojant proceso modelius ir organizacijos struktūras. Nors iš esmės vaizdas yra priešingas - sistema daugiausia orientuota į grafikos kūrimą, o dokumentų -reglamentų kūrimo funkcija yra aiškiai pagalbinė ir dėl to nėra išplėtota.

„BP-Win“ nėra numatyta tiesioginė galimybė gauti įvairių taisyklių.

Santykiuose projekto dokumentacija galima apsvarstyti dvi puses: verslo procesų aprašymą ir informacinės sistemos, skirtos verslo procesams palaikyti, aprašymą tolesniam jo vystymui. Pirmąjį iš jų praktiškai vienodai suteikia kiekviena nagrinėjama aplinka, nes yra galimybė sukurti įvairias ataskaitų formas pagal sukonstruotus verslo procesų modelius.

Kalbant apie informacinės sistemos kūrimo dokumentaciją, tradicines galimybes suteikia aplinka „BP-Win / ERwin“, kuri iš tikrųjų buvo sukurta tam.

ARIS galimybės yra maždaug panašios: pirmosiose duomenų modelio versijose subjekto santykių schema buvo aprašyta, vėlesnėse-UML kalba. Tačiau „ARISToolset“ siūlo pažangesnes kūrimo funkcijas Informacinės sistemos.

„ORG -Master“ galimybės leidžia jums visiškai atstovauti duomenų struktūroms, būtinoms organizuoti informacijos palaikymą modeliuojamiems verslo procesams, naudojant savo universalias priemones - klasifikatorius ir projekcijas. Tačiau nėra jokių formalumų, tokių kaip ER diagramos naujausios versijos galima vizualizuoti DFD standarte. Be to, tapo įmanoma atspindėti funkcinių blokų sąveiką IDEF0 diagramose ne tik tiesiogiai perduodant dokumentus ir failus, bet ir per bendras duomenų bazes!

Parama duomenų bazių modelių ir programinės įrangos kūrimui paprastai nurodo tokių įrankių galimybes kaip CASE ar panašius įrankius, skirtus konfigūruoti įmonės valdymo informacines sistemas (pavyzdžiui, ERP klasės sistemas). Toks palaikymas gali suteikti šias funkcijas:

  • informacijos valdymo sistemų architektūros analizė ir projektavimas,
  • duomenų bazių ir failų projektavimas,
  • programavimas (programų kodų generavimas),
  • parama ir pertvarkymas,
  • projektų valdymas.

Klausimai informacinių sistemų architektūros analizė ir projektavimas paprastai užbaigiami apibrėžiant sistemos reikalavimus ir susijusias specifikacijas. Šis etapas, sistemingai vertinant projektavimą, turėtų tiesiogiai remtis verslo sistemų modeliais ir iš tikrųjų juos išsamiai aprašyti. Todėl čia galioja visi aukščiau išvardyti svarstymai, susiję su sistemų modelių konstravimu, analize ir optimizavimu, taip pat taisyklių ir dokumentų projektavimu.

Duomenų bazės ir failų dizainas(koncepcinis ir vidinis lygiai), duomenų modelių transformacija, failų formatų aprašymas yra išsamiausias nagrinėjamose priemonėse, palaikomas tik „BP-Win“ (ERwin), nes ši aplinka yra specialiai sukurta tokioms problemoms spręsti.

ARIS aplinkoje tokia galimybė numatyta „ARIS Toolset“ pakete projekto specifikacijos ir duomenų bazės parametrų apibrėžimo lygiu.

„ORG-Master“ aplinkoje sukurtas metodas daro prielaidą (nors nebūtinai), kad informacines sistemas, kurios jau turi duomenų bazes, galima naudoti modeliuojamose verslo sistemose. Tokiu atveju jų nereikia pertvarkyti, nebent reikia pakeisti sistemą. Tačiau nesant informacinių sistemų, „ORG-Master“ sukuria koncepcinio duomenų modelio ir duomenų failų struktūrų pagrindą. Šią sistemą vaizduoja verslo procesų modeliuose naudojamų informacijos objektų ir dokumentų sudėties ir santykių aprašymai.

Programų kodų generavimas programoms ar sistemos įrankiams ARIS ir ORG-Master sistemos neteikiamos, nes jos yra verslo sistemų projektavimo įrankiai, o ne programinė įranga. Tam tikru mastu ši funkcija įdiegta tik „BP-Win“.

Techninė priežiūra ir inžinerija... Šios funkcijos paprastai įgyvendinamos dokumentuojant, analizuojant programas, restruktūrizuojant ir pertvarkant programas. Aukščiau pateiktos pastabos dėl dokumentacijos priemonių yra visiškai taikomos šioje diskusijoje.

Funkcijos projektų valdymas duomenų bazių kūrimas ir programinės įrangos įrankiai yra specialiai skirti programinės įrangos produktams kurti. Tokia forma jie įgyvendinami „BP-Win“. Projektų valdymas „ORG-Master“ šeimoje visiškai palaiko „Time-Master“ programinės įrangos paketą. (Nors, griežtai tariant, šios funkcijos nebūtinos nagrinėjamai įrankių klasei).

Integracija su kitais programinės įrangos produktais reiškia nagrinėjamos priemonės taikymo srities išplėtimą ir gali būti vykdoma kuriant suderinamus programinės įrangos įrankius (pvz., „Platinum Technologies“) arba naudojant kitų kūrėjų programinę įrangą (trečiųjų šalių programinė įranga).

Integravimas su trečiųjų šalių programinės įrangos produktais atliekamas vienu iš šių tikslų:

  • naudojant integruoto produkto funkcionalumą, kad išplėstumėte savo produkto apimtį,
  • leidžiantį jūsų produktą įtraukti į trečiosios šalies produktą,
  • universali, tam tikru ar kitu laipsniu, sąsaja jūsų produktui, jei konkreti trečioji šalis nėra žinoma iš anksto.

Funkcinio dėmesio požiūriu, integracija su:

  • CASE reiškia,
  • ERP sistemos,
  • taikomosios programos.

ARIS turi sąsajas su kai kuriais CASE įrankiais, taip pat yra modelio kūrimo įrankis, skirtas tiesiogiai pritaikyti tokias įmonių valdymo sistemas, pirmiausia SAP R / 3. Kaip minėta aukščiau, sistema remiasi savo žymėjimais, atstovaujančiais verslo procesus, todėl ji naudoja įmontuotus modeliavimo įrankius ir įrankį išlaidų analizė, kurių rezultatus vis dėlto galima eksportuoti į „MS Excel“ formatus.

„ORG-Master“ ir „BP-Win“ sistemos palaiko žymėjimo sistemą IDEF0, apibūdinančią vaizduojamus verslo procesus. Iš esmės tai yra tam tikras ryšys tarp šių įrankių ir ryšio su kitais programinės įrangos produktais, naudojant šią metodiką. Tačiau, neatsižvelgiant į IDEF0 žymėjimo „amžiaus“ klausimus, reikia pažymėti, kad vidinis duomenų atvaizdavimas kiekvienoje sistemoje yra skirtingas, o standartinė sąsaja, tokia kaip „lizdai“ ar klasės IDEF0 sistemai, nėra nurodyta. Tačiau yra standartizuotas failo formatas IDEF diagramoms pavaizduoti. Todėl, nors su jo pagalba padaryti aprašymai nėra labai patogūs tiek žmonėms, tiek kompiuteriams, juos galima naudoti kaip modelių mainų priemonę, jei yra atitinkamų šio formato keitiklių. Toks keitiklis pateikiamas šiose „ORG-Master“ versijose.

„BP-Win“ palaiko metodikas IDEF0, DFD ir IDEF3 ir integruojamas su šiais programinės įrangos produktais (dažniausiai to paties gamintojo):

  • „ERwin“ duomenų modeliavimo įrankis („Platinum Technology“),
  • projektų valdymo ir saugojimo sistema „ModelMart“ („Platinum Technology“),
  • specializuotas ataskaitų generatorius RPTwin modeliui („Platinum Technology“),
  • modeliavimo sistema BPSimulator (System Modeling Corporation),
  • sąnaudų analizės įrankis „EasyABC“ („ABC Technologies“).

(* „Platinum Technology“ - nuo 1999 m. Įstojo į „Computer Associates“)

„ORG-Master“ iš pradžių yra organizacinė klasių sistema, orientuota į verslo procesų ir struktūrų modeliavimo ir projektavimo problemų sprendimą bei organizacinių sprendimų palaikymą. Tai suteikia galimybę integruotis su savo kūrėjų paketais („BIG-SPB Software“), orientuota į įvairių funkcinių užduočių sprendimą. Jei reikia, „ORG-Master“ sistemoje MS Office aplinkoje automatiškai sukuriamos paprastos vykdomosios informacijos sistemos:

  • Biudžeto sudarymo sistema (tai paprasta sistema valdymo apskaita, įmonės pelningumo ir mokumo valdymas).
  • Rinkodaros sistema (kaupianti operatyvinę kiekybinę informaciją apie įmonės rinką, taip pat integruojama su savo CRM sistema, skirta palaikyti ryšius su klientais).

Šių programų įtraukimas į įmonės veiklą leidžia greitai įsisavinti šiuolaikinius valdymo metodus, o tai labai palengvina perėjimą prie sudėtingesnių vykdomųjų sistemų.

Galima (ir buvo išbandyta projektuose) duomenų sąsaja naudojant mainų failus, kuriant integruotas informacines sistemas su įmonių partnerių vykdomosiomis ir analitinėmis programomis: 1C, A&T: Soft, Intalev, Comtech +, INEK ir kt. taip pat su sudėtingomis valdymo sistemomis įmonės ištekliai (pavyzdžiui, IPS gamyba).

Naujoje versijoje taip pat numatyti mechanizmai, kaip eksportuoti verslo procesų aprašymus į programinės įrangos paketą „Time-Master“, kuris sujungia tokių sistemų kaip „Project Management“, „WorkFlow“ ir „Personal Information System“ savybes ir yra sukurtas remiantis interneto / intraneto technologijomis.

Skilties santrauka:

Pagrindinės lyginamų priemonių funkcinės galimybės pateiktos 2 lentelėje, kur funkcijų ar savybių įgyvendinimo laipsnio įvertinimai nurodyti penkių balų skalėje.

Kaip matyti iš 2 lentelės, tiesioginis įvertinimų sumavimas suteikia apie ± 4%sklaidą. Šis skirtumas yra pačių įvertinimų klaida. Be to, pačios priemonės, kurios skiriasi savo funkcine orientacija, buvo panašiai įvertintos dėl to, kad skirtingos stiprybės ir trūkumai skirtingos priemonės, apskaičiuojamos tiesiogiai, kompensuoja viena kitą.

Tačiau aptariant funkcines galimybes buvo pabrėžta, kad tiesiogiai sprendžiant verslo inžinerijos problemas atskiros funkcinių galimybių grupės turi skirtingas reikšmes. Šį faktą atspindi koeficientai, užrašyti 2 lentelės stulpelyje „Svoris“. Atsižvelgiant į šį veiksnį, matyti, kad Bendras įvertinimas kompleksas ORG-Master šiek tiek lenkia ARIS.

Bet vėlgi, tai gali būti skirtingo produkto naudojimo ir prioritetų rezultatas. Pavyzdžiui, dėl mažesnio esamų priemonių, skirtų kiekybinei modelių analizei (modeliavimo ir įvykių modeliavimo), svarbos įvertinimo, taip pat dėl ​​optimizavimo priemonių, kurios vis dėlto yra menkai atstovaujamos visose svarstomose sistemose. Tuo pačiu metu labai vertinamos savidokumentuojančių modelių savybės arba įvairių modeliavimo aspektų pateikimo universalumas.

Apskritai, vertinant ir renkantis modeliavimo priemonę, rekomenduojama savarankiškai nuspręsti, kurie iš sistemos įrankių yra svarbiausi sprendžiant konkrečią jos taikymo problemą, ir atitinkamai numesti „svorius“.

Be to, 2 priede pateikiama formalizavimo standartų ir įrankių, skirtų tam tikriems modeliams, naudojamiems nagrinėjamose sistemose, konstravimui ir (arba) analizei, apžvalga.

Straipsnis skirtas įmonių vadovams ir aukščiausio lygio vadovams, kurie rimtai ketina kurti įmonės valdymo sistemą, ketina savarankiškai arba dalyvaujant trečiųjų šalių specialistams sukurti ir įdiegti įmonės valdymo sistemą, pagrįstą procesiniu metodu. Svarstomi praktiniai dizaino aspektai, pateikiami pavyzdžiai ir rekomendacijos.

Atsižvelgiant į tai, kad įmonės ir organizacijos, kurių pavyzdys aptariamas straipsnyje, tęsiasi sėkmingas darbas rinkoje konkretūs kūrinio pavadinimai, pavadinimai ir kita informacija yra paslėpta arba pakeičiama tais, kurie artimi straipsnio prasmei ir tikslams. Nepaisant to, autoriai dėkingi savo darbuotojams už pagalbą ruošiant medžiagą.

Norėčiau pradėti straipsnį nuo to, kad autoriai jokiu būdu neapsimetinėja, kad jų darbas suvokiamas kaip baigtas pamokašia tema. Šiuose puslapiuose atsispindi dalis autorių patirties praktiškai įgyvendinant procesinio metodo taikymą valdymo sistemų veikimui klientų įmonėse.

Kam to reikia

Ir ne tik kam - bet ir kada, ir už ką. Kontrolės sistemos projektavimas yra rimta ir didelio masto užduotis, reikalaujanti didelių investicijų į įmonės išteklius ir ne visada duodanti efektą atitinkantį poveikį. Todėl prieš pradedant šį darbą verta bent jau užduoti klausimą apie jo tikslingumą. Taigi, tai visiškai akivaizdu individualus verslininkas, kuris yra viršininkas ir pavaldinys viename asmenyje, nereikia įforminti jo veiklos, jei tai susiję tik su juo vienu. Smulkaus verslo lyderiai taip pat gana sėkmingai atlieka žodinius nurodymus, įformindami tik būtiniausius santykius su pavaldiniais, pavyzdžiui, samdydami ir atleisdami, arba tuos, kurie reikalingi „išorės“ ataskaitoms. Priežastis aiški: kiekvienos užduoties vykdytojas visada matomas, darbo eiga aiški ir akivaizdi, nėra sudėtingų technologinių grandinių ir darbuotojų priklausomybės vienas nuo kito. Didelės įmonės (iš šimtų darbuotojų) neleidžia vadovui sekti visų vykdomo darbo detalių - ir ką didesnė įmonė, juo labiau tai, kas jame vyksta, direktoriui tampa paslaptimi. Turime suskirstyti dideles komandas į skyrius, paskirti įvairių lygių vadovus ir paskirstyti atsakomybę už atskiras viso darbo dalis. Kitaip tariant, sukurkite valdymo sistemą.

Taigi pirmasis kriterijus aiškus - dydis. Įmonėje, kuriai reikia įformintos valdymo sistemos, dirba ne mažiau kaip 50 žmonių. Tačiau ne kiekviena įmonė užsiima valdymo sistemos projektavimu ar jos modernizavimu - yra patenkinta esama sistema. Pabandykime nustatyti, kokiose situacijose verta užsiimti tokia veikla.

● Naujai įsteigta įmonė... Pavyzdžiui, statoma nauja gamykla. Labai palanki situacija kurti nuo pat pradžių, nuo nulio, ideali valdymo struktūra. Tokioje sistemoje nebus jokių tradicijų ir įpročių - gerų ar blogų - ir iš pradžių ji bus orientuota į statomos įmonės savininko lūkesčius.

● Auganti įmonė. Kažkaip nepastebimai jūsų įmonė pereina iš smulkaus verslo į vidutinį, į didelį ... Padidėjęs produktų ir paslaugų asortimentas, padidėjęs darbuotojų skaičius neišvengiamai lemia valdymo sistemos pasikeitimą, įgaliojimų delegavimas, atsakomybės sričių paskirstymas ... Buvusi bendraminčių komanda aiškiai suskirstyta į viršininkus ir pavaldinius. Ten, kur anksčiau buvo bendradarbiaujama, vyksta vidinė konkurencija. Dėl to formuojama nauja valdymo sistema, ir tik nuo galvos priklauso, ar ji bus veiksminga, ar ne. Sukūrus valdymo sistemą, pagrįstą geriausia praktika, galima išvengti pagrindinio valdymo krizės augimo skausmo.

● Poreikis gerinti konkurencingumą ir efektyvumą. Nesvarbu, ar įmonė yra natūrali monopolistė, ar veikia labai konkurencingoje rinkoje - anksčiau ar vėliau atsiranda poreikis sumažinti produktų ar paslaugų savikainą, pagerinti paslaugų kokybę ir sutrumpinti naujų produktų pristatymo laiką. į rinką. Jei vis dar įmanoma sumažinti gamybos sąnaudas šiandien, pasirenkant geriausius tiekėjus, perkant moderni įranga, tobulinant technologijas, tada rytoj šios galimybės bus išnaudotos, ir reikės rasti vidinių išteklių. Kitų pasiekimas konkurencinių pranašumųįmanoma tik optimizavus įmonės valdymo sistemą.

● Sertifikavimo poreikis pagal tarptautinius standartus. Nepriklausomai nuo priežasčių, sukėlusių šį poreikį, jo įgyvendinti neįmanoma nepakeitus ir neįforminus valdymo sistemos.

● Ketinama įdiegti automatizuotą valdymo sistemą. Faktas yra tas, kad automatinės valdymo sistemos įsigijimas ir įdiegimas ne visada duoda teigiamų rezultatų. Tokių sistemų diegimo specialistai, nepriklausomai nuo jų orientacijos į produktą, sutaria dėl vieno: „neįmanoma automatizuoti netvarkos“. Tobuliausia valdymo sistema neveiks be aiškaus atsakomybės paskirstymo tarp joje dirbančių darbuotojų. Ir net jei yra aiški valdymo sistema, prieš investuojant daug išteklių į automatinės valdymo sistemos įsigijimą ir diegimą verta apsvarstyti, ar esama sistema turi kokių nors trūkumų, kurių nereikėtų ištaisyti griežtoje kompiuterinėje logikoje.

● Noras padidinti verslo vertę. Kai kuriais atvejais verslo procesai gali būti vienas iš pagrindinių įmonės turtų. Pavyzdys - įmonės, veikiančios paslaugų rinkoje. Potencialiam investuotojui griežtos veiklos taisyklės žymiai sumažina riziką prarasti investicijas net ir masinio atleidimo atveju.

Žinoma, gali būti ir kitų priežasčių - arba priežasčių, dėl kurių reikia sukurti valdymo sistemą, rinkinio. Svarbiausia, kad priimant sprendimą nereikėtų pamiršti paprasta tiesa: "Jei tai veikia, neremontuokite!" (Rašydami straipsnį autoriai turėjo tam tikrų nesutarimų aiškindami šią patarlę. Mes sustojome ties šiuo paaiškinimu: tai, kas šiandien puikiai veikia, rytoj gali tapti problema.

Keletas pavyzdžių iš gyvenimo

Apsvarstykite keletą įmonių, kurioms verslo procesų modeliavimas tapo suprantamu poreikiu. Pavyzdžiai paimti iš realaus gyvenimo, atitinkamus pranešimus spaudai galima peržiūrėti internete, tačiau šiame straipsnyje autoriai bandė sukurti apibendrintą iliustratyvų vaizdą. Todėl jei jums atrodė koks nors pavyzdys, susijęs su konkrečia įmone, tai yra grynas atsitiktinumas.

IT įmonė yra tipiška vidutinio verslo įmonė. Pagrindinės veiklos kryptys:

● Verslo automatizavimo įrankių pardavimas - nuo buhalterinės ir biuro programinės įrangos pardavimo iki visapusiškų automatinių valdymo sistemų

● Verslo automatizavimo priemonių diegimas

● Sistemos integravimas

● Kliento specialistų mokymo ir sertifikavimo paslaugos

● savo programinės įrangos gamyba ir pardavimas.

Tipiškas pavyzdys, kai kiekis virsta kokybe. Augant įmonės autoritetui, didėjant klientų skaičiui, plėtėsi siūlomų prekių ir paslaugų spektras. Padidėjo darbuotojų specializacija - ir jų skaičius augo. Pradėjo atsirasti skyriai, skirti spręsti įvairias problemas, pagalbiniai skyriai, kiekviename projekte pradėjo dalyvauti daug darbuotojų. Žinoma, vadovybė nebegalėjo kontroliuoti visų veiklos klausimų, atsirado būtinybė organizuoti veiksmingą darbuotojų ir padalinių tarpusavio sąveiką.

Kitas pavyzdys. Didelis laikymas. Anksčiau, sovietų valdymo laikais, tokios įmonės buvo vadinamos miesto formavimu - nes, be mineralų kasybos ir perdirbimo, įmonė vykdė socialines ir buitines užduotis, jos balanse buvo vaikų darželiai, ligoninės, stovyklavietės, valgyklos. taip pat remonto, energetikos, transporto ir kitas pagalbines paslaugas ... Dėl restruktūrizavimo pasikeitė ne tik gamyklos, aplink kurią buvo pastatytas visas miestas, savininkai, bet ir reikėjo radikaliai pakeisti įmonės struktūrą. Taigi, pavyzdžiui, parduotuvių remonto paslaugos buvo sujungtos į vieną didelę atskirą gamybą, o dešimtys vienodų valgyklų įgijo didesnę nepriklausomybę, prisitaikė prie konkrečių sąlygų ir pradėjo uždirbti. Akivaizdu, kad toks ūkis turėtų būti valdomas kitaip nei anksčiau. Kontrolės sistemos projektavimas šiuo atveju nėra kaprizas, bet gyvybiškai būtina.

Kitas pavyzdys. Natūralus monopolistas. Visos Rusijos tiekėjas - vėl iš sovietinių laikų. Įmonės užduotys yra nustatytos vyriausybės lygmeniu. Visų pirma viena iš užduočių buvo įdiegti kokybės vadybos sistemą. Analizuojant problemą, buvo nustatytas poreikis pereiti nuo funkcinio verslo modelio prie modelio, sukurto verslo procesų pagrindu, o tai savo ruožtu turėjo sukurti naują valdymo sistemą.

Skirtingi pavyzdžiai, skirtingi tikslai ir požiūriai į problemų sprendimą. Tačiau visos įmonės turi vieną bendrą bruožą - poreikį sukurti ir įdiegti verslo valdymo sistema, pagrįstą verslo procesais.

Kur pradėti?

Tradicinis požiūris apima tam tikros būsenos aprašymą „kaip buvo“, paiešką kliūtis ir sistemos pakeitimas, kuris vėliau laikomas „pataisytu, kas buvo“. Paprasta ir efektyvi technika ne visai apleistiems atvejams. Tačiau nepakankamas dėmesys tam, ko reikia, yra rimtas šio požiūrio trūkumas, ypač kai dabartinis savininko tikslas yra toli nuo to, ką daro įmonė. Strategijos kūrimas ir įforminimas padeda pasiekti teisingą kryptį. Strategijos, įformintos naudojant strateginį žemėlapį, pavyzdys - 1 pav.

1 paveikslas.

Žemėlapio kūrimas pradedamas aiškinantis savininko tikslą. Ko jis tikisi iš savo įmonės? Pateiktame pavyzdyje tikslas yra paprastas ir aiškus - padidinti verslo vertę ilgame laikotarpyje ir padidinti pelną per trumpą laiką. Galimi ir kiti tikslai - pavyzdžiui, investicijų patrauklumo didinimas. Pagrindinė sąlyga yra tikslo pasiekiamumas, jo aiškus ir aiškus apibrėžimas (pavyzdžiui: „Aš noriu sugebėti parduoti šį verslą už 10 milijonų “). Paprastai tikslai nustatomi dialogu tarp savininko ir verslo analitikų bei aukščiausių įmonės vadovų, kurių užduotis yra pateikti ne itin aiškius norus konkretiems skaičiams ir faktams, kuriuos pageidautina pasiekti per tam tikrą laikotarpį. laikas. Šiuose susitikimuose taip pat aprašomi pagrindinio tikslo pasiekimo būdai. Mūsų pavyzdyje aukščiausią tikslą - prekės ženklo vertės didinimą - galima suskirstyti į du papildomus tikslus - didelė įmonės prekės ženklo vertė ir įmonės prekių ženklai- taip nusprendė analitikai, tyrinėdami įmonės veiklą. Žemesni lygiai parodo, kaip šias vertes galima padidinti. Gautame žemėlapyje aiškiai išdėstytos pagrindinės kryptys, kuriomis reikia veikti siekiant pagrindinio savininko nurodyto tikslo.

Ir dabar galite veikti pagal aukščiau pateiktą šabloną. Strateginis žemėlapis parodo, kuriuos papildomus tikslus reikia pasiekti, kad būtų pasiektas aukščiausias tikslas. Turėdama šį atskaitos tašką, grandinė „tokia, kokia buvo“ - „tokia, kokia bus“, turi prasmę ir nukreipia valdymo sistemos dizainą sprendžiant strateginę problemą. Kiekvienas esamos valdymo sistemos elementas gali arba negali turėti įtakos bet kurio strateginio žemėlapio tikslo pasiekimui. Akivaizdu, kad pertvarkymas reikalingas tik tiems, kuriems svarbu pasiekti strateginis tikslas elementai.

Kokie elementai yra analizuojami? Visų pirma, įmonės siūlomų prekių ir paslaugų asortimentas. Sudaromas registras - visas šių pasiūlymų paketas - ir analizuojamas. Ar viskas, ką gaminame, yra pelninga, naudinga ir padeda siekti pagrindinių tikslų? Ar turėtume plėsti savo asortimentą? Ar man reikia jį sumažinti dėl nuostolingų prekių ar paslaugų? Ar nepelningos prekės ar paslaugos gali būti pelningos (o pelningos - itin pelningos?). Rengiamas perspektyvus produktų ir paslaugų paketas, kuriam bus atliekamas verslo procesų modeliavimas. Produktų analizei galite, pavyzdžiui, naudoti „Boston Consulting Group“ matricą (2 pav.).

2 pav.

Taikant straipsnio temą, verslo procesų dizainas yra aktualiausias „žvaigždėms“ (įskaitant potencialias) ir „grynoms karvėms“.

Ne visada būtina atlikti verslo procesų analizę „kaip yra“. Kompetentingi verslo analitikai (arba patyrę vadovai) paprastai sugeba pasiūlyti verslo procesus „teisingu būdu“. Tačiau yra situacijų, kai niekas negali pasakyti „kaip turėtų būti“, pavyzdžiui, visiškai naujo tipo verslas arba įmonė, turinti daug sudėtingų padalinių sąveikos, kuriems reikia padidinti savo darbo efektyvumą. Jo darbą galima optimizuoti tik nuodugniai analizuojant esamus verslo procesus. Tuo pat metu labai tikėtina, kad analizė parodys, kad intuityviai sukurti ryšiai ir sąveika yra optimalūs, o efektyvumo reikėtų ieškoti kitur. Nepaisant to, verslo procesų schemos sudarymas bus naudingas įmonei, nes tai suteikia galimybių įforminti veiklą ir taip pat paruošia dirvą bet kokių verslo pokyčių atveju.

Analizės trūkumas „kaip buvo“ turėtų būti siejamas su naujos, tik sukurtos įmonės valdymo sistemos kūrimo ypatumais. Valdymo sistema iš pradžių sukurta siekiant strateginių įmonės tikslų.

Dalyvių komanda

"Kadrai yra viskas!" Šis šūkis, kaip niekur kitur, yra aktualus tobulinant valdymo sistemą. Norint išspręsti šią problemą, neįmanoma tiesiog samdyti profesionalių atlikėjų, kurie padarys viską už jus. Atsakingas pagrindinių įmonės darbuotojų dalyvavimas yra būtina šios problemos sprendimo sąlyga. Kita vertus, išorės specialistų kvietimas, nors ir pageidautinas, nėra būtinas - jei jūsų darbuotojai prisiima visas būtinas funkcijas. Pabandykime apibūdinti šias funkcijas ir surinkti oficialią atlikėjų komandą, taip pat nurodyti profesinių įgūdžių svarbą kiekvienam.

Strategas. Jis taip pat yra projektų vadovas. Šio žmogaus užduotis projekte yra savininko lūkesčius paversti jų įgyvendinimo strategija, koordinuoti kitų dalyvių veiksmus ir spręsti konfliktus tais atvejais, kai reikalinga visos situacijos vizija. Strategas, jei taikomas karinėms asociacijoms, turi atstovauti visą mūšio vaizdą - tai yra, turi būti atlikti gynybiniai veiksmai. Kai kuriuose sektoriuose - įžeidžiamuose, kituose - kavalerija tam tikru momentu turi iššokti iš pasalų, kad užtikrintų proveržį, tankai naudojasi šiais laimėjimais, kad prasiveržtų į užpakalį ir nugalėtų priešą ... Jam nerūpi, kokia forma susidarys tankai įsikelti - tai vietinė taktinė užduotis. Jam nerūpi, kokiu transportu bus gabenami šaudmenys - juos tiesiog reikia pristatyti reikiamu kiekiu. Tuo pačiu metu, jei tiekimo skyrius ir tankų brigados vadas negali susitarti dėl sviedinių pristatymo skaičiaus ir laiko, strategas, žinodamas bendrą sistemos veikimo logiką, turi išspręsti tarnybų konfliktą, vadovaudamasis savo nuomonę apie būtiną pusiausvyrą. Vienas iš realiausių kandidatų į šią funkciją yra generalinis direktorius (tačiau taip pat atsitinka, kad generalinis direktorius yra „vestuvių generolas“ arba yra per daug užimtas ir gali patikėti stratego funkciją pavaduotojui ar išorės konsultantui). Priklausomai nuo patirties, darbo krūvio, specialių žinių prieinamumo, jam gali padėti tiek pavaduotojai, tiek išorės konsultantai (pavyzdžiui, projekto vadovas ar koordinatorius iš vykdytojo pusės). Tačiau galutinius sprendimus priima šis vienintelis asmuo, o kartais ir įmonės savininkas.

Verslo analitikai. Patyrę strategijos ir verslo procesų konsultantai, turintys įgūdžių kuriant, analizuojant ir optimizuojant. Pageidautina pakviesti specialistus, įgijusius specialų išsilavinimą ir turinčius realios ir patirties sėkmingų projektų... Tačiau, vadovaudamiesi esamomis bendromis rekomendacijomis ir savo sveiku protu, aukščiausi įmonės vadovai gali atlikti šias funkcijas bent jau vidutiniu lygiu. Iš tiesų finansų direktorius, vyriausiasis inžinierius, pavaduotojas plėtrai ir kiti budintys vadovai privalo mokėti analizuoti strateginius ir taktinius savo veiklos aspektus. Profesionalų verslo analitiką nuo jų išskiria jo darbo patirtis kitose įmonėse, gebėjimas peržengti įprastas sąvokas ir žinios apie rekomendacijas, kurios akivaizdžiai duoda teigiamų rezultatų. Kaip tokių rekomendacijų pavyzdį galima paminėti: kur įmanoma, proceso lygiagretumą, naudojant automatizavimą, kuo mažesnį įvairių padalinių atliekamų verslo procesų skaičių.

Žemo lygio verslo procesų dizaineriai. Kad suprastume - kas yra šie žmonės, pažvelkime į užduotį nagrinėjamos užduoties požiūriu. Dėl smulkus verslas paprastai išskiriami 7–8 aukščiausio lygio verslo procesai (pavyzdžiui, gamyba, pardavimas, tiekimas, personalo atgaminimas ir kt.). Kiekvienas iš jų yra suskirstytas į 7–8 mažesnius papildomus procesus - išsamesnius (pavyzdžiui, „produktų gamyba“ gali apimti dalių gamybą, gaminių surinkimą, kokybės kontrolę), tai yra, mes turime apie penkiasdešimt verslo procesų. Didelėse įmonėse, kaip taisyklė, būtinas tolesnis padalijimas - dar vienas ar du lygiai. (3 pav.)

3 pav. Vidutinės įmonės verslo procesų padalijimo pavyzdys. Dideliems, pridėkite vieną ar du aukštus žemyn ...

Pavyzdžiui, vienas vidutinio dydžio įmonės žmogiškųjų išteklių vadovas atlieka savo funkcijas viename verslo procese, kuris tiesiog vadinamas „įdarbinimu“. Atsižvelgiant į tai, kad jis beveik visus darbus atlieka savarankiškai, šiam darbui nereikia rašyti jokių nuostatų. Kitas dalykas - didelės įmonės personalo skyrius, kuriame yra įvairių funkcijų padalijimas tarp darbuotojų. „Įdarbinimo“ procesą šiuo atveju jau sudaro dešimtys kitų paprasti veiksmai atlieka skirtingi žmonės - ir būtent jų sąveiką reikia apibūdinti žemesnio lygio verslo procesais. Galutinis verslo procesų padalijimo lygis yra verslo operacija - procesas, kurį visiškai vykdo ir kontroliuoja vienas personalo padalinys. Ir labai didelėms įmonėms tūkstančiai verslo procesų yra gana realūs. Dabar padarykime įsivaizduojamą verslo procesų vaizdo projekciją į įmonės padalinių diagramą. Akivaizdu, kad kai kurie verslo procesai visiškai tilps viename skyriuje. Taip pat bus procesai, už kuriuos atsakingi du ar daugiau padalinių (tam tikru ar kitu laipsniu). Ir nemaloniausios situacijos yra tos, kuriose atsakomybė už verslo proceso vykdymą ne kartą perkeliama iš vieno skyriaus į kitą (žvelgiant į priekį, tarkime, kad, jei įmanoma, rekomenduojama vengti tokių verslo procesų). 4 paveiksle schematiškai pavaizduoti fiktyvios produktų gamybos įmonės verslo procesai. Kai kurie verslo procesai, pavaizduoti juodomis rodyklėmis, vyksta padaliniuose. Kita dalis - mėlynos rodyklės - juda iš vieno įrenginio į kitą. Galiausiai, trečioji dalis yra procesas, kuriame dalyvauja keli skyriai. Raudona punktyrinė linija.

Ryžiai. 4. Priklausymas verslo procesams. Juodos rodyklės rodo padalinių vidinių verslo procesų eigą, spalvos rodyklės - aukštesnio lygio procesus.

Kam geriausiai patikėti modeliuoti žemo lygio verslo procesą, už kurį visiškai (arba beveik visiškai) atsakingas vienas skyrius? (Kam turėtų būti patikėta suformuoti tankų būrį, kad būtų įvykdytas proveržis?) Atsakymas pats rodo - tai yra padalinio vadovas (arba tokio lygio išorės konsultantas, dirbantis su padalinio vadovu). Bet būtų bent neapdairu planuoti raitelių, tankistų ir atsargų sąveiką vieno iš šių padalinių vadovui - rizika „užsitraukti antklodę ant savęs“ yra per didelė. Todėl verslo procesų modeliavimas aukštesniais lygmenimis, procesai, turintys daug ryšių tarp dirbtuvių ir padalinių, turėtų būti vykdomas tiesiogiai stratego, kaip asmens, suinteresuoto visos įmonės sėkme, o ne atskiro padalinio. Minimalūs reikalavimai projektuotojams yra tokie patys kaip darbo pareigasįvardinti darbuotojai. Pasamdžius talentus iš išorės, galima šiek tiek palengvinti vadovų naštą, o patirtis ir profesiniai įgūdžiai gali pagreitinti darbą.

Atlikėjai. Jie taip pat yra žemo lygio verslo procesų ekspertai ir ... jūrų kiaulytės. Neužtenka parengti teoriškai teisingą sąveikos schemą. Norėdami laimėti, turite tai įgyvendinti praktiškai. Tai yra, pristatyti jį paprastiems atlikėjams ir pasiekti jo vykdymą. Idealus variantas - iš vieno darbuotojo, atliekančio tą patį darbą, išrinkti vieną ar du aktyviausius ir pajėgiausius darbuotojus ir patikėti jiems dirbti nauju būdu - iki sistemos derinimo. Kitas variantas yra laipsniškas perėjimas nuo kai kurių senų procesų prie naujų, juos pakeičiančių. Tačiau iš tikrųjų tai ne visada būna. Santykių sistema (ypač jei ji nebuvo optimizuota) gali būti tokia sudėtinga, kad bandymuose turės dalyvauti daug dalyvių. Tam tikrą analogiją galima padaryti naudojant automatizuotos informacinės sistemos diegimo pavyzdį. Retas atvejis, kai atskirus senosios sistemos skyrius galima pakeisti naujais sprendimais. Dažniausiai darbuotojai kurį laiką turi lygiagrečiai saugoti įrašus senose ir naujose sistemose. Šiems komandos nariams išorės paslaugų teikimas neįmanomas. Tačiau išorės konsultantai gali žymiai paspartinti įgyvendinimą, priskirdami specialistus mokyti ir konsultuoti įmonės darbuotojus bei stebėti procesų teisingumą.

Klausimas: Ar komanda, susidedanti tik iš įmonės darbuotojų, neįtraukdama išorės specialistų, pasitelkdama tam tikrus metodus ir sveiką protą, gali sukurti ir įdiegti naują valdymo sistemą - nuo Strateginio žemėlapio iki išsamių verslo procesų, reglamentų ir pan.?

Atsakymas: Nėra aiškių metodų, kaip teisingai sudaryti verslo procesus „nuo ir iki“, tačiau yra rekomendacijų ir orientacinių modelių. Remdamasis savo ir kitų patirtimi, stiprus vadovas bent jau sugeba sukurti operacinę sistemą. Tačiau norint išspausti maksimalų sistemos efektyvumą, be puikios (ir, pageidautina, plačios) patirties, reikia nemažai talentų. Šiuo atveju įmonė turi realią galimybę „patekti į dešimtuką“. Norint tapti neginčijamu savo verslo lyderiu, įmonei reikės puikios komandos, kuriai vadovauja atitinkamas vadovas, pagalbos.

Tikrasis dizainas ...

Kaip minėta anksčiau, nėra vienos metodikos verslo procesams plėtoti. Šiame skyriuje mes stengsimės apsvarstyti keletą pagrindinių punktų, į kuriuos reikėtų sutelkti dėmesį ir kurie neturėtų būti mūsų dėmesio.

Aukščiausio lygio verslo procesų išsamumas ir harmonija. Šio kriterijaus svarba prilygsta paties verslo svarbai. Vadas pirmiausia turi laimėti mūšį savo mintimis, įsivaizduodamas, kaip įvykiai turėtų vystytis mūšio lauke - kitaip neverta net artintis prie priešo. Priklausomai nuo įmonės dydžio, reikia patikrinti dviejų ar trijų lygių vientisumą ir nuoseklumą.

Pastangų sutelkimas siekiant strateginių tikslų. Verslo procesai, kurie neturi jokios įtakos pagrindiniai rodikliai yra kuriami paskutiniai arba visai neišvystyti. Atlikime paprasčiausią skaičiavimą: įmonei, kuri turi tris verslo procesų lygius (t. Y. Ne itin didelę vieningą įmonę), turime 7–8 aukštesnio lygio procesus, kurių kiekvienas yra padalintas į 7–8 BP antrasis lygis, tas pats padalijimo principas lieka žemiau ... Dėl to jau trečiame lygmenyje turime daugiau nei 350 verslo procesų. Vidutiniškai kiekvieną verslo procesą sudaro keliolika operacijų, o tai sudaro keturis tūkstančius įmonės operacijų. Ir tai tik šiek tiek! Siūlau savarankiškai apskaičiuoti geometrinę progresiją į ketvirtą ir penktą lygius. Žinoma, tik tokiems monstrams kaip „Gazprom“ ar „RAO UES“ reikalingas penktas detalumo lygis, tačiau net ir ketvirto lygio operacijų skaičius nėra mažas. Idealiu atveju kiekvieną procesą, kiekvieną operaciją reikia optimizuoti, reguliuoti ir peržiūrėti bent kartą per metus arba keičiantis išorinėms sąlygoms. Atsižvelgdami į operacijų skaičių, mes suprantame, kad idealas, kaip įprasta, yra nepasiekiamas, o jo siekimas lems tik nepagrįstą išteklių perteklių. Turite priimti liūdną, bet teisingą sprendimą - paėmę strateginį žemėlapį, suprojektuokite tik tuos verslo procesus, kurie atitinka jame nurodytus tikslus. Ir jei vidinės teritorijos valymas neturi įtakos jokiems strateginio žemėlapio tikslams ar daliniams tikslams, neturi įtakos jokiam BSC rodikliui, leiskite tai reguliuoti patiems valytojams. Bent jau kol galiausiai išsiaiškinome gamybą, pardavimą ir tiekimą ...

Detalumas turi atitikti mūsų poreikius. Viena iš priežasčių, kodėl nereikėtų leisti pernelyg detalių, yra išdėstyta aukščiau - nepagrįstas darbo apimties padidėjimas. Kitas primena seną šimtakojo palyginimą - jei paprasti natūralūs veiksmai darbuotojui aprašomi per daug detaliai, tuomet jų įgyvendinimas gali tapti neveiksmingas. Pagrindinis kriterijus šiuo atveju yra paprastas - jei buvo pasiektas aiškus pareigų pasiskirstymas tarp darbuotojų ir nustatyti pagrindiniai operacijų atlikimo principai, tuomet tolesnis detalizavimas nėra būtinas. Pakanka nurodyti, kad, pavyzdžiui, gavęs prašymą, darbuotojas turi atsispausdinti atitinkamą sąskaitą faktūrą ir nustatyti vykdymo laiką - nenurodydamas, kokiais klavišų deriniais reikia judėti langeliuose, išsaugoti ir atspausdinti failą.

Projektuodami nepamirškite nustatyti pagrindinių verslo proceso parametrų (5 pav.).

5 pav. Pagrindiniai verslo proceso parametrai

Tai apima, pavyzdžiui, pristatymo laiką ir išlaidas. Projektavimas daugeliu atvejų yra tik viena iš valdymo sistemos pertvarkymo užduočių. Anksčiau ar vėliau atsiras noras optimizuoti - tada šie skaičiai pravers. Tačiau, kai optimizavimas neįtrauktas į artimiausius planus, galite jį atidėti ... jei nesijaudinate, kad gali užtrukti kelias valandas ar dienas, kol darbuotojai atspausdins sąskaitą faktūrą.

Proceso probleminio pobūdžio ir svarbos įvertinimas. Tai taip pat leidžia suprasti, kurie procesai turėtų būti suprojektuoti iš karto, o kurie gali palaukti. Tarp pagrindinių kriterijų čia galima laikyti: 1) kritiškumą verslui. Tai yra, kiek neteisingas proceso vykdymas gali pakenkti įmonei - padidinti išlaidas, prarasti klientą, atidėti svarbaus sprendimo priėmimą ... 2) Proceso kartojimo dažnis (retai, dažnai) , reguliariai). 3) atsakomybės perkėlimų skaičius per vieną procesą, pavyzdžiui, iš skyriaus į skyrių. Tokie procesai yra potencialiai pavojingi ir sukelia daug problemų.

Visų trijų kategorijų lyderiai yra aiškūs projektavimo ir optimizavimo kandidatai.

6 pav. Proceso metodo iliustracija

Reikėtų pažymėti, kad šie du metodai retai pastebimi ryškioje formoje. Taigi, didelės įmonės personalo skyrius beveik visada aprūpina jį visų padalinių poreikiams, tuo pačiu metu labai skirtingų produktų gamyba labai dažnai organizuojama atskirose įmonės dalyse. Taigi užduotis nustatyti, kuris metodas taikomas konkrečioje įmonėje (ir kuris iš tikrųjų turėtų būti įgyvendintas), turėtų būti išspręstas vienas iš pirmųjų atliekant projektą. Galų gale, kuo labiau įmonė linkusi į funkcinę struktūrą, tuo labiau supainioti verslo procesai ir atsakingesnė bei sunkesnė jų projektavimo užduotis. Rekomendacija pereiti prie procesų valdymo ne visada yra tinkama - juk, pavyzdžiui, šiuo atveju visi ištekliai turės būti suskirstyti į skyrius, o tai neįmanoma, atsižvelgiant į unikalius išteklius (pavyzdžiui, energijos pastotę), ir gali pasirodyti ekonomiškai nenaudingas. Kitas pavyzdys-dešimties žmonių takelažo dirbtuvės, galinčios perkelti 2–3 tonas sveriančią mašiną. Jei ši dirbtuvė bus išsibarsčiusi į penkias brigadas skirtinguose padaliniuose, tada tokios mašinos kartu perkelti bus neįmanoma. Kiekviename skyriuje turėsite išlaikyti dešimties žmonių komandą - ir tai nėra faktas, kad jie bus nuolat apkrauti darbu.

Atsižvelkite į neišvengiamą įmonės darbuotojų pasipriešinimą viskam, kas vienaip ar kitaip sunaikins esamą santykių sistemą. Taigi, takelažo skyriaus vadovas vargu ar bus patenkintas paaukštinimu meistrui ir ieškos visų įmanomų būdų, kaip sabotuoti tokio sprendimo priėmimą. Darbuotojai perdės savo darbo svarbą ir sieks sumažinti kitų padalinių darbo svarbą. Departamentų vadovai nutrauks pelningus verslo procesus ir visais įmanomais būdais paneigs atsakomybę už būtiną indėlį į „kitų žmonių“ procesus. Nors, žinoma, labai stipriai priklauso nuo konkrečių atlikėjų (kurie dažniausiai visiškai nesidomi jokiais pokyčiais, net jei jie žada kažką labai gero ateityje) priklausomybės nuo naujovių skatinimo, nes efektyvumo požiūriu, reiškia galimybę padaryti daugiau už savo darbdavį už tuos pačius pinigus).

Ko galų gale tikimės

Galutinis projekto rezultatas turėtų būti įmonė, veikianti pagal naują schemą. Vienas iš svarbiausių galutinio dizaino produktų yra būtinas ir pakankamas norminių dokumentų rinkinys.

Verslo procesų taisyklės (bent jau pagrindinės), standartinės dokumentų formos, tiek išorės, tiek vidaus, padalinių nuostatos, pareigybių aprašymai, personalo stalasįmonės - tai yra jo minimalus sąrašas. Ne mažiau svarbu yra sistemos diegimas, reglamentų įgyvendinimas praktikoje. Tik tada galime pasakyti, kad pastangos ir ištekliai kuriant projektą nebuvo švaistomi veltui. Gerai, jei įgyvendinimą pavyks padalyti į mažus etapus ir skyrius (pavyzdžiui, pirmiausia pirkimo skyrius, paskui sandėliavimo patalpos Be to, kad tai leis išlaikyti patikimą naujovių diegimo proceso kontrolę, kiekviena maža sėkmė taps geru tolesnio darbo paskatinimo veiksniu. Tiesa, įgyvendinimą suskirstyti į atskiras nepriklausomas dalis toli gražu ne visada įmanoma. Net jei naujoji sistema visiškai vengia atsakomybės pasidalijimo tarp padalinių, jei naujų verslo procesų struktūra yra griežtai linijinė ir paprasta, net ir tada būtinybė „skristi“ (kas leis sustabdyti pelningą įmonę?) naujas procesas veikia dešimtis senų, kuriuos savo ruožtu pakeičia dešimtys „naujų“, kurių kiekvienas ... (ir toliau, palaipsniui). Todėl daugeliu atvejų įgyvendinimo metu komanda yra priversta kurį laiką dirbti pagal seną sistemą, lygiagrečiai imituojant naują veiklą (dauguma jūsų darbuotojų yra raštingi žmonės ir puikiai supranta, kad ilgą laiką jie turės tai padaryti dvigubas darbas tik tam, kad galutinė jų apkrova padidėtų, palyginti su originalia - taigi ir atsparumas naujovėms). Labiausiai apleistais atvejais paaiškėja, kad lengviau pastatyti naują gamyklą netoliese, kad būtų įdiegta valdymo sistema (būtent tai turite padaryti, pavyzdžiui, „AvtoVAZ“, kur absurdai, paveldėti iš sovietinių laikų, padauginti iš tų įgyta restruktūrizavimo proceso metu, sukūrė aplinką, kurioje beveik kiekvienas darbuotojas priešinasi naujovėms.). Galiausiai, dar vienas natūralus dizaino rezultatas - įdiegta automatizuota įmonės valdymo sistema. Jau seniai įrodyta, kad automatika pagerina darbo efektyvumą. Automatika suteikia ypač pastebimą efektą įmonėse, kuriose yra aiški ir racionali valdymo sistema, visi verslo procesai yra reguliuojami. Ir atvirkščiai - automatizuoti valdymą be išankstinio projektavimo reiškia pasmerkti ACS įgyvendinimą žlugimui (ar jau minėjome, kad neįmanoma neterminuotai automatizuoti atsitiktinai atsirandančių santykių?). Esant griežtai verslo procesų sistemai, bus galima priartėti prie automatinių valdymo sistemų diegimo maksimalaus efektyvumo požiūriu. Dabar jau gana realu pirmiausia automatizuoti pačias svarbiausias darbo sritis, iš to gaunant ar sutaupius pinigus - kitą svarbiausią ... Tai galite padaryti su laipsniškumu, kurį leidžia ištekliai arba reikalauja išorinė situacija.

Išteklių poreikių įvertinimas

Jei anksčiau dalyvavote tokioje veikloje, tuomet jau įsivaizduojate, kaip jūsų einamoji sąskaita bus kuriama lengviau, kiek darbuotojų laikinai neteksite kaip visaverčių kovos vienetų (ir kiek jų neteksite). Toliau pateikti argumentai labiau tikėtini tiems, kurie planuoja pradėti tokį darbą pirmą kartą - juk tai pavojinga tiek pervertinti, tiek nuvertinti būsimų nuostolių mastą. Pervertintas sudėtingumo įvertinimas gali lemti viso projekto atsisakymą (kartu su viltimi tapti pramonės lyderiu) arba nepagrįstai dideles sumas pagal sutartį su rangovu. Neįvertintas įvertinimas lems tai, kad tam tikru momentu nebus pakankamai išteklių ir projektas bus atsisakytas - tai vėlgi reiškia prarastus pinigus. Laikas yra toks pat svarbus - ir dėl tų pačių priežasčių. Praktika rodo, kad vidutinės įmonės - nuo 500 iki 1000 žmonių - per vienerius metus sukuria ir diegia naują valdymo sistemą. Įmonėms, kuriose dirba 10 000 darbuotojų, prireiks maždaug 2–3 metų. Tačiau, atsižvelgiant į situacijos sudėtingumą, įgyvendinimo laikas gali padidėti du ar tris kartus.

Iš žmogiškųjų išteklių poreikio galima daryti prielaidą, kad visą šį laikotarpį sudarys 3–4 žmonių nuolatinė komanda (strategas, analitikai) ir poreikį prireikus įtraukti įmonės darbuotojus, - padalinių vadovus ir paprastus vykdytojus. Viršininkai dalyvaus maždaug vieną ar du mėnesius grynojo laiko per visą projektavimo ir įgyvendinimo ciklą, paprasti atlikėjai - mažiau, nuo 2 savaičių iki mėnesio. Atsižvelgiant į šį laiką, jūsų specialistų kaina gali būti įvertinta. Išoriniai konsultantai yra brangūs. Specialisto paslaugos gali kainuoti nuo 1,5 iki 25 tūkstančių rublių už valandą darbo.

Šiek tiek apie sėkmės garantijas. Mes jau sakėme, kad pats kurdamas valdymo sistemą patyręs ir sveiko proto vadovas, padedamas savo pavaduotojų komandos, turi geras galimybes atlikti šį darbą neįtraukdamas išorės konsultantų - nors, žinoma, tokia komanda pirmą kartą nepasiekite idealaus rezultato. Profesionaliai komandai - ir kuriai garsesnei (ir brangesnei) konsultacinei įmonei pakviesite - yra daugiau galimybių - tuo arčiau būsite ideali jūsų veiklos valdymo sistema. Gerai žinoma įmonė, kaip taisyklė, vertina savo reputaciją, jos specialistai išankstinio projekto tyrimo metu gali padaryti išvadą apie būsimo darbo efektyvumą-arba jie gali atsisakyti, jei dėl kokių nors priežasčių pavyks dizainas negarantuojamas. Neseniai atsirado kitas požiūris - įgyvendinimo metu pagrindinis konsultantas yra samdomas kliento įmonės kaip aukščiausio lygio vadovas - direktorius ar pavaduotojas. Žinoma, konsultacinės įmonės reputacija turi būti labai aukšta, tačiau galite būti tikri, kad gausite rezultatą Aukštos kokybės, pastebimai taupant nervines ląsteles. Mažai žinoma įmonė gali būti pigesnė, tačiau rezultatas toli gražu nėra garantuotas.

Klausimas: Ar įmanoma sumažinti valdymo sistemos projektavimo išlaidas?

Atsakymas: tai įmanoma ir būtina. Išteklių poreikio mažinimo būdas yra specializuotų programinės įrangos produktų naudojimas.

● Pirmoji priežastis, kodėl dizaino automatizavimas yra tikrai naudingas, yra galimybė išsaugoti ir redaguoti kiekvieną žingsnį. Esami, sukurti ir išsaugoti verslo procesai leidžia daug lengviau modeliuoti esamus procesus-redaguoti yra lengviau nei kurti iš naujo.

● Antroji priežastis yra efektyvumo pagrindų supratimas. Dažnai pasikartojantys procesai yra labai svarbūs bendrai bylos eigai - juk, nepaisant jų paprastumo ir įprastumo, jų indėlis į visas darbo sąnaudas yra labai didelis. Kuriant verslo procesus, yra daug šablonų, pasikartojančių veiksmų, kurie, kada rankų darbo užims liūto dalį viso kūrimo laiko. Žinoma, CTRL-C-CTRL-V metodų naudojimas labai palengvina darbą WORD ar Excel įvedant juos, tačiau specializuota programinė įranga suteikia dar patogesnę dizaino aplinką.

● Trečioji priežastis yra visų objektų - nuo padalinių ir darbuotojų iki įvairių lygių procesų ir strateginių tikslų - tarpusavio ryšys. Gerai sukonstruotoje sistemoje viskas turėtų būti taikoma vienai strateginei tikslų sistemai. Specializuota programinė įranga užtikrina tokį sujungimą, padeda išvengti erzinančių klaidingų skaičiavimų dėl neatsargumo įvedant informaciją.

● Ketvirta priežastis - optimizavimo galimybė. Net jei šiandien nėra programos, galinčios savarankiškai sukurti optimalią verslo proceso versiją (kitaip vadovų ir verslo analitikų poreikis išnyktų savaime, kompiuteris yra pigesnis), bet imituoja šimtus kiekvieno tūkstančio verslo procesų ciklų. dešimtimis jų sąveikos variantų ... Išbandykite naudodami „Excel“! Ir šiuo atveju jūs negalite išsiversti be statistinio apdorojimo - juk sistema veiks realiame pasaulyje, kur viskas vyksta.

● Penkta (ir daugeliui svarbiausia) priežastis yra rezultato išvesties automatizavimas. Net ir pati puikiausia valdymo sistema liks tik projektu, kol verslo procesai nepavers nuostatais ir pareigybių aprašymais. Sistema, galinti automatiškai sugeneruoti visus šiuos šimtus ir tūkstančius norminių dokumentų ir netgi atnešti juos kiekvienam darbuotojui, sutaupys vadovui labai daug jo labai brangaus laiko. Žinoma, taisydama verslo procesus (ir tiesiog primygtinai rekomenduojama bent kartą per metus tikrinti jų gyvybingumą), automatizuota sistema nepamirš visų pakeitimų paveiktų dokumentų pakeitimų - ir vėl atneš naujas žaidimo taisykles. darbuotojams. Turime nepamiršti, kad automatiškai sugeneruotos taisyklės yra nuoseklios ir nuoseklios (jei, žinoma, verslo procesai yra suplanuoti teisingai), o darbuotojai nebegalės pasinaudoti jūsų vidaus teisės aktų „skylėmis“.

● Šeštoji priežastis. Tai gana svarbu pradedantiesiems dizaineriams. Specializuotos programinės įrangos instrukcija savaime yra verslo procesų modeliavimo pagrindų konstatavimas. Dirbdamas pagal programinėje įrangoje aprašytą modelį, pradedantysis nepadarys jokių erzinančių klaidų, sistema neleis praleisti jokių svarbių veiksmų ar veiksmų, dėl kurių žymiai padidėja dizaino sėkmės tikimybė.

  • Išgauti holistinį organizacijos gyvenimo vaizdą, susitarti dėl skirtingų požiūrių į nuolat besivystantį ir besikeičiantį verslą.
  • Užtikrinti tarpusavio supratimą visuose organizacijos lygmenyse, panaikinti atotrūkį tarp vadovaujančių ir vykdančių šalių.
  • Užtikrinti gamybos sąnaudų sumažėjimą ir kokybės bei paslaugų lygio padidėjimą.

Verslo modeliavimo procese pereinama nuo sąvokos „ką“ reikia padaryti prie „kaip“. Modeliavimo rezultatas turėtų būti dokumentas, leidžiantis kūrėjų komandai aiškiai suprasti projekto ribas, taip pat kliento programinę ir techninę įrangą. Gauti duomenys atsispindi projekto specifikacijoje, kurią gali sudaryti šie skyriai:

  • pagrindinių programos duomenų subjektų aprašymas;
  • oficialus programos specifikacijos aprašymas;
  • verslo logika ir verslo taisyklės;
  • funkciniai reikalavimai;
  • nefunkciniai reikalavimai;
  • paraiškos formos / puslapio šablonai;
  • balsavimas arba santrumpų sąrašas;
  • pagalbinės schemos.

Verslo modeliavimo įrankiai ir jų raida

Verslo modeliams kurti naudojamos informacinių sistemų projektavimo priemonės ir atitinkamos aprašymo kalbos (garsiausia iš jų yra UML - Unified Modeling Language). Pasitelkus tokias kalbas, kuriami grafiniai modeliai ir diagramos, demonstruojančios organizacijos verslo procesų struktūrą, žmonių sąveikos organizavimą ir būtinus pokyčius, siekiant pagerinti visos organizacijos veiklą. Verslo modeliavimo įrankiai nuolat tobulėja. Iš pradžių tokių įrankių pagalba buvo galima apibūdinti tik įmonės verslo funkcijas (darbą) ir duomenų judėjimą jų vykdymo procese. Tuo pačiu metu, jei atliekant skirtingų tipų darbus buvo naudojama ta pati verslo funkcija, buvo sunku suprasti, ar tai reiškia tą pačią verslo funkciją, ar kitą. Nesugebėjimas aiškiai apibrėžti verslo procesų hierarchijos (pavyzdžiui, „vertės grandinė“, „verslo procesas“, „papildomas procesas“, „darbas“, „funkcija“) sukėlė problemų naudojant tokius aprašymus. Patys aprašymai buvo tik nuotraukų rinkinys. Vėliau pradėjo atsirasti įrankiai, leidžiantys apibūdinti organizaciją ne tik iš verslo funkcijų pusės, bet ir iš kitų pusių. Taigi tapo įmanoma sukurti atskiras atspindinčias diagramas organizacinė struktūraįmonės, duomenų srautai organizacijoje, verslo funkcijų, sudarančių vieną verslo procesą, vykdymo seka, galimybė naudoti loginius simbolius ir pan. Dėl nuolat didėjančių reikalavimų verslo modeliavimo įrankiams, vis daugiau diagramų atrodytų apibūdinantys įvairius organizacijos veiklos aspektus, todėl modelio kūrimas tapo vis sunkesnis. Šiuo atžvilgiu kitas svarbus verslo modeliavimo priemonių kūrimo etapas yra susijęs su idėja naudoti vieną objektų saugyklą (saugyklą) ir idėją apie galimą pakartotinį objektų panaudojimą skirtingose ​​diagramose. Kad ir kokia priemonė būtų pasirinkta, būtina užtikrinti vietinių informacinių sistemų tarpusavio sąveiką. Šiandien moderniausias ir kartu visuotinai priimtas verslo procesų valdymo organizavimo standartas yra BPEL (Business Process Execution Language). Remdamiesi šiuo produktu, galite sukurti vieną integravimo platformą visoms naudojamoms programoms. Sumodeliavus procesus, vienas iš modeliavimo įrankių naudoja specialius vertėjus, kad modelis būtų pristatytas į BPEL.

Verslo modeliavimo ir jo rezultatų pavyzdžiai

  • Sumažinti išlaidas. Verslo modelis padės suprasti, kur galima išvengti nereikalingų išlaidų ir kaip optimizuoti išteklių naudojimą. Remiantis verslo modeliu, atliekama funkcinių sąnaudų analizė, siekiant apskaičiuoti produkto ar paslaugos kainą, ir sukurta biudžeto valdymo sistema, leidžianti kontroliuoti įmonės išlaidas.
  • Padidėjęs efektyvumas. Galimybė sumažinti adaptacijos ir personalo mokymo išlaidas. Reguliavimo dokumentacija, pagrįsta parengtu verslo modeliu, atitinka esamą organizacijos padėtį, paskirsto atsakomybę, kuria hierarchinę karjeros augimo sistemą.
  • Įtakos sferos išplėtimas, tinklo plėtra, filialų organizavimas. Esant verslo modeliui, sumažės išlaidos ir bus galima apibūdinti naujų įmonės filialų išdėstymo struktūrą.
  • Investicijų tinkamumas. Naudojant verslo modeliavimą, galima pakankamai tiksliai nustatyti kapitalo investicijų sumą, sumažinti riziką ir finansinius nuostolius naujo projekto pradžios etape.
  • EDMS įgyvendinimas. Įmonės verslo modelis standartizuoja įmonės dokumentų sudėtį ir nustato dokumentų judėjimo kelius.
  • ERP, SCM, CRM ar kitų programinės įrangos sistemų automatizavimas ir diegimas. Remiantis verslo modeliu, galima suformuluoti aukštesnius sistemos kokybės reikalavimus ir pasirinkti optimalų kainos ir funkcionalumo atžvilgiu sprendimą.
  • Kokybės vadybos sistemos sertifikavimas. Sukūrus įmonės verslo modelį, galima žymiai sutrumpinti kokybės valdymo sistemos kūrimo, diegimo ir sertifikavimo laiką bei išlaidas ir gauti rinkinį reikalingi dokumentai kad sertifikavimas būtų sėkmingas, sumažinkite kokybės valdymo sistemos išlaikymo išlaidas.

Verslo modeliavimo ypatybės

Verslo modelio sukūrimas, įgyvendinimas ir palaikymas yra brangus investicinis projektas. Ir kaip ir bet kuris projektas, prieš verslo modelio sukūrimą turėtų būti atlikta jo įgyvendinimo galimybių ir galimybių analizė. Dideliems projektams reikalingi galingi verslo modeliavimo įrankiai su gerai išvystytomis funkcijomis: galimybė saugoti informaciją vienoje saugykloje, komandinis darbas su modeliavimo projektu ir tikrinimas, ar sukurtas modelis yra vientisas, pusiau automatinis diagramų generavimas, integracija su kita programine įranga, analizė ir modelio dokumentacija - mažų projektų atveju dėl išlaidų būtų protingiau naudoti mažiau galingus įrankius. Veiklos analizei, esamos struktūros kūrimui pirmiausia turėtų būti sukurtas tinkamas verslo modelis. Tai yra, iš pradžių teorija, o tik po jos įgyvendinimo.

Sprendimai

Šiandien yra daug programinės įrangos produktų, skirtų apibūdinti organizacijos architektūrą. Remiantis analitinės bendrovės „Gartner“ ataskaitomis, šio segmento lyderiams galima priskirti šias įmones.

Panašūs leidiniai