Lõputöö: Äriprotsesside modelleerimine tarkvaraarendusettevõtte näitel. Äriprotsessid organisatsioonis: näited ja kirjeldus Äriprotsessi kirjelduse näide

Selles artiklis tahan rääkida äri modelleerimise põhiprintsiipidest, selles valdkonnas kasutatavatest lähenemisviisidest ning mille alusel luuakse modelleerimiskeeled ja tähistused.

Olen juba kirjutanud IDEF0 abil modelleerimisest (IDEF0 tähistuse tutvustus ja kasutusnäide), lao töö korraldamisest ja tööst klientidega müügivihjest tehinguni (CRM juurutamine. Müügivihje registreerimisest tehingu sulgemiseni. Juhtum ja selgitused), Bizagi süsteemi kohta ( Bizagi. Näide). Ja kõikjal kasutasin näidete ja praktiliste lahenduste selgitamisel äriprotsesside tähistust.

Ühest küljest ei tekita ärimudelite kirjeldamisel diagrammide kasutamine selguse huvides kellelgi küsimusi. See on tõesti väga mugav. Teisest küljest on paljud ärimehed ja isegi minu kolleegid hämmingus, miks on äriprotsesside arendamiseks vaja spetsiaalseid märgendeid ja reegleid, sest intuitiivse diagrammi saate lihtsalt joonistada mis tahes graafilises redaktoris (visio) või muude mugavate tööriistade abil.

Tahan rääkida sellest, miks on standardimine nii oluline ja millistel juhtudel seda või teist lähenemist kasutatakse.

Põhilised lähenemised

Tänapäeval on ärimudelite arendamiseks palju erinevaid tööriistu, mis kasutavad erinevaid modelleerimiskeeli, nii standardseid kui ka oma. Kuid kõiki neid saab vastavalt tööpõhimõttele kombineerida kolmeks peamiseks lähenemisviisiks:
  • Funktsionaalne;
  • Protsess;
  • Vaimne (vaimsete kaartide kasutamine).
Tegelikult on muidugi ka teisi lähenemisi, neid on palju, nagu ka modelleerimiskeeli. Kuid need on enamasti hübriidlahendused, mis ühendavad ülaltoodud lähenemisviise. Lisaks on protsess ja funktsionaalsed mudelid vähemalt läänes juba standardiks saanud. Ja siin muutuvad nad üha laiemaks. Tahan nendest põhisuundadest täpsemalt rääkida.

Funktsionaalne modelleerimine käsitleb äritegevust funktsioonina (lat. functio – vahendustasu, täitmine) ehk teisisõnu “musta kasti”. Funktsionaalses mudelis ei ole funktsioonil ajajada, vaid ainult sisenemis- ja väljumispunkt. Funktsionaalne modelleerimine aitab vaadata ärimudelit tulemuslikkuse vaatenurgast, s.t. Modelleerimisel lähtume sellest, mis meil on sisendis ja mida tahame saada väljundis.

Näiteks ettevõte arendab oma äri jaoks mingit CRM-süsteemi. Funktsionaalse lähenemise kasutamisel modelleerimisel ütleb valitud töökeskkond ise, millest alustada. Sisendpunktiks on “siseneva kliendi huvi või müügivihje”, väljumispunktiks on soovitud tulemus: “püsikliendi ostmine ja hankimine”, “püsikliendi hankimine”, “potentsiaalse kliendi kohta maksimaalse info saamine” jne.

Seega on funktsionaalses mudelis algselt teada sisenemispunkt ja soovitud tulemus ning tegevuste jada on arendusobjekt. Samas võimaldab funktsionaalsete mudelite kasutamine “mustade kastidena” iga etappi vastavalt vajadusele täpsustada. Ja kogu modelleerimistöö on suunatud eesmärgi saavutamiseks optimaalse lahenduse leidmisele.

Oma ideede ja lahenduste demonstreerimiseks saate kasutada ka funktsionaalseid mudeleid. See on ka väga mugav, sest demonstratsiooni käigus saab liikuda üldisest detaili juurde, eraldades ja lagundades funktsioone vastavalt vajadusele. Kuid te lagundate täpselt funktsioonid ja jagades ühe funktsiooni mitmeks, ei saa te protsessi kirjeldust.

Mõned inimesed ajavad segamini protsessikirjelduse ja funktsionaalse mudeli. Näiteks Business Studio süsteemis nimetatakse funktsiooni protsessiks, kuigi see pole täiesti tõsi. Siiski on funktsioonide kirjeldus ja protsessi lähenemine mõnevõrra erinevad asjad. Ja ma isiklikult usun, et funktsionaalne modelleerimine on IDEFO tähistuses optimaalselt rakendatud. Ise kasutan seda seda tüüpi töödel ja soovitan ka kõigile.

IDEFO-ga töötamise reeglite kohta saate lisateavet, lugedes minu artiklit: IDEF0 tähistusega alustamine ja kasutusnäide.

Protsessi modelleerimine (äriprotsesside modelleerimine)

Räägin protsesside modelleerimisest BPMN-i tähistuse kui ühest enamlevinud protsesside modelleerimise standardist. Nagu öeldud, olen täiesti nõus, et modelleerimiskeeli ja erinevaid süsteeme on palju. Ja igaüks saab kasutada seda, mis talle mugavam on. Kuid siiski on BPMN protsesside modelleerimisel juba väljakujunenud standard ja seetõttu võtan selle kirjelduses aluseks.

Ärimudeli seisukohalt on protsess sündmuste ja toimingute jada, millel on algus ja lõpp.

See on peamine erinevus protsessi modelleerimise ja funktsionaalse modelleerimise vahel. Funktsionaalne modelleerimine vaatleb ärimudelit sisendi ja väljundi (saadaolevad ressursid ja soovitud tulemus) seisukohast. Ja protsessipõhine põhineb teatud piirides toimingute jadal, BPMN-i puhul on see sündmuse algus ja lõpp.

Kõik protsessid saab kuni ülesande tasandil detailideni jaotada (detailselt) alamprotsessideks, s.t. toimingud, mille täpsem kirjeldamine on võimatu. Protsess on teatud toimingute jada, mis tuleb teatud tulemuse saavutamiseks läbi viia. Tuleb märkida, et ärimudelis kui protsessis ei pruugi tulemus olla ilmne, erinevalt funktsionaalsest mudelist.

Põhimõtteline erinevus protsesside modelleerimise ja funktsionaalse modelleerimise vahel seisneb selles, et protsesside modelleerimisega ei pöörata põhitähelepanu sellele, mida me tahame saada, vaid sellele, mida on vaja tulemuse saamiseks teha, s.t. mitte selle või teise tegevuse tulemused, vaid tegevuste jada ise.

Näiteks BPWIN-is või Business Studios toimub iga funktsiooni üksikasjaliku kirjeldamise protsessis üleminek funktsionaalselt lähenemiselt protsessipõhisele lähenemisele. Need. üldiselt vaatleme mudelit võimaluste ja soovitud tulemuse seisukohalt ning iga funktsiooni puhul lahenduste juurde liikudes praktiseeritakse siin juba selgelt protsessilähenemist, s.t. samm-sammult toimingute algoritm tulemuste saavutamiseks.

Kujutage ette, et funktsionaalses mudelis on "must kast" - funktsioon "Aktsepteeri tellimus". Ja lagunemisel ei käsitle me seda enam funktsioonina, vaid protsessina ning tegevuste jada tellimuse vastuvõtmisel on juba protsessikäsitlus.

On veel üks väga oluline erinevus. Funktsionaalset mudelit ei saa kasutada ühegi süsteemi juurutamisel, ainult projekteerimisel. Ja protsessilähenemine võimaldab luua käivitatavaid mudeleid, st. tegevuste jada kirjeldused, mida saame hiljem tõlkida mingisse keskkonda, et luua protsessipõhisel lähenemisviisil põhinev ettevõtte koostöösüsteem.

Mentaalsete mudelite loomisel läheneb spetsialist modelleerimisele mitte kui protsessile või funktsioonide kogumile, vaid kui teatud omavahel seotud mõistete kogumile. Selguse huvides toon näite - kontseptsiooni "Hankemenetlus" mõttelise kaardi (vt joonist).

Seda lähenemise versiooni kasutatakse eelkõige enda jaoks. Vabas vormis skeemi joonistamine aitab oma teadmisi struktureerida, nii-öelda vabas vormis saadud infot “sortida”. Samuti aitavad sellised mentaalsed kaardid leida lahendust, mida hiljem vastavalt vajadusele mingi protsessi või funktsionaalse lähenemise rangete reeglite raames ellu viia.

Samuti saate mentaalsete kaartide abil näidata klientidele nii olemasolevat olukorda kui ka võimalusi probleemi lahendamiseks. Mõttekaardid aitavad teil visualiseerida, milliseid meetodeid saab kasutada, ja visualiseerida erinevaid ideid.

Selliste vaimsete kaartide kasutamise eelised on ilmsed:

  • Te ei pea oskama mingeid erikeeli;
  • Skeemi loomisel puuduvad ranged raamistikud ega piirangud;
  • Vaimne kaart on enamikul juhtudel intuitiivne;
  • Selliste diagrammide loomine on lihtne.
Lähenemisviisi puuduseks on väljakujunenud lähenemisviisi ja standardiseeritud metoodika puudumine. Kui funktsionaalsetes ja protsessilistes tähistustes on mõningane varieeruvus, kuid see on siiski piiratud modelleerimiskeelte range raamistikuga, siis luuakse mentaalseid kaarte mis tahes kujul. Ja isegi nende loomise spetsiaalsed programmid ei piira peaaegu inimest modelleerimisprotsessis. Need. teatud tarkvaratootes võidakse kasutusele võtta mõned reeglid, kuid standard puudub.

Sellest tulenevalt eeldab mudeli ja selles sisalduvate ideede mõistmine selle arendaja (analüütiku) kohalolekut ja kommentaare.

Muidugi on väga lihtsaid kaarte, mida saab lugeda intuitiivselt ilma lisakommentaarideta. Aga standardite puudumisel jääb alati võimalus, et ka sel juhul pidas autor midagi muud silmas või kuskil ebapiisavalt detailselt oma skeemi. Need. on erineva näidu võimalus. Kuid äri ei ole filosoofia. Hoolimata kogu äriprotsesside kirjeldamise spekulatiivsusest ja lähenemisviiside mitmekesisusest, on üheselt mõistetavad otsused siin väga olulised.

Ärimudelite metoodika ja keeled

Väga sageli tekib isegi erialakirjanduses segadus, kui inimesed ajavad segamini ärianalüüsi metoodika mõisted ja ärimudelite keelte kirjeldused.

Metoodika on põhimõtete ja standardite süsteem ärimudelite kirjeldamiseks ja nende hilisemaks analüüsiks. Kuigi ärimudelite keel pole midagi muud kui tööriist ärimudelite arendamiseks.

See viitab võrdlusele programmeerimisega üldiselt ja konkreetse programmeerimiskeele kasutamisega. Programmeerimine hõlmab algoritmi koostamist, sobiva programmeerimiskeele valimist ja programmi algoritmi rakendamist konkreetses keeles. Ja näiteks C++ keeles programmeerimine on juba ilmselgelt piiratud teatud raamistikuga, kuna teatud keele vahenditega saab lahendada vaid selgelt piiratud hulga probleeme ja samal ajal isegi kui probleem saab lahendada C++ tööriistade abil, pole üldse vajalik, milline see keel konkreetsel juhul optimaalne on. Üldiselt arvan, et enamik inimesi mõistab mõistete "programmeerimine" ja "konkreetses keeles programmeerimine" erinevust isegi ilma selliste selgitusteta.

Ärimudeli arenduskeelte ja süsteemide kujundamise keelte erinevus

Seal on terve perekond süsteemidisaini keeli, mis on pealiskaudselt sarnased ärimudelite keeltega, näiteks Ares Studios, terve UML-i keelte perekond ja teised, mida kasutatakse IT-süsteemide kujundamisel.

Peamine erinevus nende keelte ja äriprotsesside arendamise keelte vahel seisneb nende eesmärgis. Kui IT-süsteemide disainikeeled arvestavad äriprotsesse nende automatiseerimise ja IT-süsteemides juurutamise võimaluse seisukohast, siis ärimudelite keeled lähtuvad tegevuste järjestusest ärilisest vaatenurgast, sealhulgas mõlema tööst. IT-süsteemid ja töötajad ning kaupade liikumine jne.

Sellest tulenevalt pole süsteemikujunduskeeltel elemente, mis aitaksid täielikult kirjeldada osakondade, töötajate tegevust, nendevahelist suhtlust, tööd tarnijatega, suhtlemist klientidega jne. Selle keelerühma tööriistad aitavad teil automatiseerida äriprotsesse, mida saab automatiseerida. Ja kõik muu jääb näiteks mõne dekodeerimiseta “funktsioonina” kulisside taha.

Samas katavad äriprotsesside arenduskeeled võimalikult palju ettevõtte tööd kui sellist, kuid alati ei ole võimalik neis piisavalt detailselt kirjeldada teatud automatiseerimise ja süsteemide algoritmiseerimise nüansse.

Ärimudeli arendamise eelised

Ja veel, miks kasutada ärimudelite keeli, mis seavad ranged piirangud ja nõuavad modelleerimisel rangelt määratletud reeglite järgimist? Lõppude lõpuks saate vaimset lähenemist kasutades alati "joonistada diagrammi" graafilises redaktoris või isegi paberile ning modelleerimiskeelte õppimine pole üldse vajalik.

Tegelikult on standardid ja reeglid tohutu pluss:

  1. Modelleerimiskeeled aitavad edastada teavet võimalikult tõhusalt. Standardimine hõlbustab arusaamist.
  2. Mudeli väljatöötamise kiirus suureneb oluliselt. Keeled sisaldavad kõiki vajalikke tööriistu ja graafilisi plokke valmis kujul. Te ei pea "joonistama" ega oma terminoloogiat välja mõtlema. Tööriistad on juba valmis ja töö selle raames on oluliselt kiirenenud. Muidugi peate keelt õppima. Kuid selle ühekordne õppimine on palju kiirem, kui iga kord oma märgete komplekti välja mõelda ja selgitada.
  3. Võimalike vigade arv väheneb. Süsteemi elemendid ise pakuvad juba võimalike ja vajalike toimingute loendit. Ja käivitatavate või mittekäivitatavate mudelite loomisel, kuid reeglite ranges raamistikus, saate alati kontrollida ärimudeli toimimist käivitatavas keskkonnas ja teha silumist, nagu programmeerimisel.

Ärimudelite rakendamine praktikas

Isiklikult leian, et ärimudelite abil tuleks lahendada kõik probleemid, mis on seotud probleemide ja kitsaskohtade väljaselgitamise, ettevõtte optimeerimise ja moderniseerimisega jne. Ärikonsultandina koostan oma klientidega töötades peaaegu alati mudeleid ettevõtte või selle allüksuste toimimisest. See annab selge ülevaate kõigist tööetappidest ja võimaldab teil selles küsimuses vältida "tühje kohti".

Lisaks aitavad visuaalsed ärimudelite diagrammid mul klientidega suhelda. Minu projektid on sageli keerulised ning mõistmiseks ei piisa lihtsast tekstist või suulisest sõnast, samas kui visuaalsete ärimudelite kasutamine vähendab kliendi aega minu ettepanekute lugemiseks ja mõistmiseks ning praktiliselt välistab vastastikuse mõistmise probleemid selles küsimuses. Ja kui veel paar aastat tagasi seisin silmitsi klientide hämmeldusega, siis nüüd kasutatakse võimalust kirjeldada “sõnaga” ilma visuaalsete ja mugavate diagrammideta üliharva.

Ja mis tahes tööetapi automatiseerimisel või projektipõhisel lähenemisel põhineva automatiseeritud ärijuhtimissüsteemi loomisel saab ühes või teises modelleerimiskeeles teostatud kvaliteetne ärimudel tehniliste spetsialistide valmis juhendiks. .

Mugavus, mitmekülgsus, tajumise lihtsus – need on põhjused, miks ärisfääri inimesed liiguvad üha enam verbaalsetelt kirjeldustelt äri modelleerimise poole. Ja valmiskeelte kasutamine võimaldab teil mudelitega kiiresti töötada, vältida vigu ja teha ka muudatusi ilma probleemideta.

Samuti valmistan hetkel ette avaldamiseks raamatut ja veebikursust, milles kirjeldan üksikasjalikult enda nägemust protsessikäsitlusest ettevõtlusele ning ka enda praktilisi kogemusi funktsionaalse ja protsesside modelleerimise vallas. Igaüks saab tellida teateid uue raamatu ilmumise ja muude uudiste kohta

UDC 65:519.86 E.M. Mihhailova SGGA, Novosibirsk

ETTEVÕTETE ÄRIPROTSESSIDE MODELLEERIMINE

Ye.M. Mihhailova

Siberi Riiklik Geodeesia Akadeemia (SSGA) 10 Plakhotnogo Ul., Novosibirsk, 630108, Venemaa Föderatsioon

ETTEVÕTETE ÄRIPROTSESSIDE MODELLEERIMINE

Töödes uuritakse kaasaegsete ettevõtete äriprotsesside modelleerimise teoreetilisi ja metodoloogilisi aluseid. Seda tüüpi modelleerimine on osutunud oluliseks ettevõtte tegevuse efektiivsuse tõstmisel. Rõhutatakse nii äriprotsesside modelleerimise eeliseid kui ka selle kaudu lahendatavaid probleeme ning äriprotsesside kirjeldamise etappe. Erilist tähelepanu pööratakse modelleerimisel kasutatavate tehnikate omadustele.

Selles artiklis käsitletakse kaasaegsetes ettevõtetes äriprotsesside modelleerimise teoreetilisi ja metoodilisi aluseid. Välja tuuakse äriprotsesside modelleerimise olulisus organisatsioonide efektiivsuse tõstmisel, tuuakse välja selle peamised eelised, lahendatavad ülesanded ning äriprotsesside kirjeldamise etapid. Erilist tähelepanu pööratakse äriprotsesside modelleerimisel kasutatavate metoodikate omadustele.

Kaasaegsed ettevõtted on sunnitud oma tegevust pidevalt täiustama. See eeldab uute tehnoloogiate ja äritegevuse meetodite väljatöötamist, tegevuse lõpptulemuste kvaliteedi parandamist ja loomulikult uute, tõhusamate meetodite kasutuselevõttu ettevõtete tegevuse juhtimiseks ja korraldamiseks. Sellega seoses on äriprotsesside modelleerimine tõhus vahend ettevõtte majandustegevuse parandamise võimaluste leidmiseks.

Äriprotsesside modelleerimine on meetod, mis võimaldab hinnata ettevõtte jooksvat tegevust seoses selle toimimisele, juhtimisele, efektiivsusele, lõpptulemustele ja klientide rahulolule esitatavate nõuetega.

Äriprotsesside modelleerimine võimaldab mitte ainult kindlaks teha, kuidas ettevõte tervikuna toimib, kuidas see suhtleb väliste organisatsioonide, klientide ja tarnijatega, vaid ka seda, kuidas tegevust igal töökohal korraldatakse. Äriprotsesside modelleerimine on tõhus vahend ettevõtte tegevuse optimeerimise võimaluste leidmiseks, vahend ettevõtte ümberkorraldamise erinevates etappides tekkivate riskide prognoosimiseks ja minimeerimiseks. See meetod võimaldab anda kuluhinnangu iga üksiku protsessi ja organisatsiooni kõigi äriprotsesside kohta kokku.

Äriprotsess on loogiline, järjestikune, omavahel seotud tegevuste kogum, mis kulutab tootja ressursse, loob väärtust ja toodab tarbija jaoks tulemusi. Peamiste põhjuste hulgas, mis ajendavad organisatsiooni äriprotsesse optimeerima, on vajadus vähendada kulusid või tootmistsükli kestust, tarbijate ja riigi poolt kehtestatud nõuded, kvaliteedijuhtimise programmide juurutamine, ettevõtete ühinemised, organisatsioonisisesed vastuolud jne. .

Ettevõtte äriprotsesside modelleerimine avab muid võimalusi, mis pole vähem olulised. Nagu juba mainitud, võimaldab mudel anda eelnevalt hinnangu erinevatest vaatenurkadest. Ettevõtte jaoks on esmased nõuded selle toimimisele, juhtimisele, efektiivsusele, tegevuse lõpptulemusele ja klientide rahulolu tasemele. Sellist ettevõtte äriprotsesside analüüsi nimetatakse äriprotsesside auditiks. Tööstusettevõttes saab seda teha perioodiliselt kogu tootmistsükli jooksul. Äriprotsesside auditi üldine eesmärk on saada operatiivteavet ettevõtte kõigi äriprotsesside jooksvate tegevuste kohta. Äriprotsessi audit viiakse läbi pärast ettevõtte mudeli loomist ja kirjeldamist.

Ärimudel on äriprotsesside formaliseeritud (graafiline, tabel, tekst, sümboolne) kirjeldus.

Äriprotsesside modelleerimise eesmärgid on tavaliselt sõnastatud järgmiselt:

1) anda arusaam organisatsiooni struktuurist ja selles toimuvate protsesside dünaamikast;

2) anda arusaam organisatsiooni aktuaalsetest probleemidest ja nende lahendamise võimalustest;

3) Veenduge, et klientidel, kasutajatel ja arendajatel on organisatsiooni eesmärkidest ja eesmärkidest ühesugune arusaam;

4) luua alus nõuete kujundamiseks organisatsiooni äriprotsesse automatiseerivale tarkvarale (tarkvaranõuded kujunevad ärimudeli alusel).

Äriprotsesside modelleerimisel on oluline mõista äriprotsessi olemust ja tüüpi, millesse see kuulub. Seoses toote või teenuse lisandväärtuse saamisega võib eristada järgmisi protsesside klasse:

1. Põhilised äriprotsessid (näiteks toodete turundus, tootmine, tarnimine ja teenindus).

2. Äriprotsesside toetamine ei anna tootele lisaväärtust, vaid suurendab selle maksumust (näiteks tegevuste rahaline toetamine, personalitoetus, juriidiline tugi, haldus, turvalisus, komponentide tarnimine, remont ja hooldus jne).

3. Ärijuhtimise protsessid.

Ärimudelite peamine rakendusvaldkond on äriprotsesside ümberkujundamine. Äriprotsesside ümberkorraldamine on äriprotsesside põhimõtteline ümbermõtestamine ja radikaalne ümberkujundamine, et saavutada tootmise, majandus- ja finants-majanduslike tegevuste maksimaalne efektiivsus, mis on vormistatud asjakohaste organisatsiooniliste, haldus- ja regulatiivsete dokumentidega.

Äritehnoloogia koosneb äriprotsesside modelleerimisest (mudeli “nagu on” väljatöötamine, selle analüüs, “nagu peab” mudeli väljatöötamine) ning “nagu peab” olekusse ülemineku plaani väljatöötamisest ja elluviimisest. Ümbertöötamise eesmärk võib olla infosüsteemi juurutamine, kulude vähendamine, klienditeeninduse kvaliteedi tõstmine, töö- ja tööjuhendite loomine jms ning protsesside detailne kirjeldamine iseenesest ei ole väärtuslik.

Iga äriprotsesside modelleerimismeetodi kõige olulisemad mõisted on objekti ja ühenduse mõisted. Iga mudelobjekt peegeldab mõnda nn domeeni (organisatsiooni) reaalset objekti, inimesi, dokumente, masinaid ja seadmeid, tarkvara jne. Reeglina luuakse ühe meetodi raames reaalse maailma erinevaid entiteete kajastavaid mudelobjekte. ka erinev. Seosed on mõeldud kirjeldama objektide omavahelisi suhteid. Sellised seosed võivad hõlmata järgmist: täitmise järjestus ajas, suhtlus teabevoo kaudu, kasutamine teise objekti poolt jne.

Iga objekti ja seoseid iseloomustavad mitmed parameetrid või, nagu öeldakse, atribuudid, mis peegeldavad reaalse objekti teatud omadusi. Atribuutide koosseis sõltub mudeli abil kuvatava tegeliku organisatsiooniobjekti tüübist. Atribuudid võivad olla sellised omadused nagu objekti number, nimi, kirjeldus, täitmise kestus (funktsioonide jaoks), maksumus jne. Praktikas toimub organisatsioonimudelite loomisel mudeliobjektide atribuutide kirjeldamine spetsiaalsete äriprotsesside modelleerimise tööriistade abil. See võimaldab muuta lihtsa äriprotsessi “kirjelduse” keerukamaks “mudeliks”, mille alusel tehakse teatud arvutused, protsessi analüüs ja hindamine.

Äriprotsesside kirjeldamisel eristatakse järgmisi etappe:

1. Kirjelduse eesmärgi määramine.

2. Keskkonna kirjeldamine, äriprotsessi sisendite ja väljundite määramine, IDEFO diagrammide koostamine.

3. Funktsionaalse struktuuri kirjeldus (protsessitoimingud), IDEF3 diagrammide konstrueerimine.

4. Protsessi voogude (materjal, informatsioon, finants) kirjeldus, DFD diagrammide koostamine.

5. Protsessi organisatsioonilise struktuuri ülesehitamine (osakonnad, osalejad, vastutajad).

Praegu kasutatakse äriprotsesside kirjeldamiseks, modelleerimiseks ja analüüsimiseks mitut tüüpi metoodikat. Kõige tavalisemad tüübid hõlmavad järgmisi meetodeid:

1. Äriprotsesside modelleerimise metoodikad (äriprotsesside modelleerimine)

Kõige laialdasemalt kasutatav äriprotsesside kirjeldamise metoodika on USA standard IDEF0. Alates selle väljatöötamisest ei ole standardit oluliselt muudetud. Hetkel on IDEF0 metoodika arendamine seotud seda toetavate tööriistade - äriprotsesside modelleerimiseks mõeldud tarkvaratoodete (näiteks BPWin 4.0, ProCap, IDEF0/EM Tool jne) täiustamisega. IDEF0 metoodika annab analüütikule rohkelt võimalusi kirjeldada organisatsiooni äri tipptasemel rõhuasetusega protsesside juhtimisel. Märkus võimaldab protsessimudelis kajastada erinevat tüüpi tagasisidet – infot, juhtimist, materiaalsete ressursside liikumist. IDEF0 tähistusega mudelid on mõeldud ettevõtte äritegevuse kõrgetasemeliseks kirjeldamiseks. Nende peamine eelis on oskus kirjeldada organisatsiooni protsesside juhtimist.

2. Töövoogude kirjeldamise metoodikad (Work Flow Modeling)

Protsesside kirjeldamise tähtsuselt teine ​​metoodika on IDEF3.

mõeldud kirjeldama tööprotsesse või teisisõnu töövooge. IDEF3 standard on lähedane protsessiskeemide koostamise algoritmilistele meetoditele ja vooskeemide koostamise standardtööriistadele. IDEF3 metoodika aluseks on protsessimudelite konstrueerimine ajas järjestikku sooritatava töö (funktsioonide, operatsioonide) põhimõttel.

3. Andmevoogude kirjeldamise metoodikad (andmevoo modelleerimine)

Teine praktikas aktiivselt kasutatav metoodikate rühm on DFD (Data Flow Diagramming) tähistused, mis on mõeldud andmevoogude kirjeldamiseks. Need võimaldavad kajastada protsessi käigus tehtavate tööde järjestust ja nende tööde vahel ringlevat infovoogu. Lisaks annab DFD märge võimaluse kirjeldada dokumentide liikumist (töövoogu) ja materiaalseid ressursse (näiteks materjalide liikumist ühelt töölt teisele). DFD metoodikat saab tõhusalt kasutada protsesside kirjeldamiseks organisatsiooni juhtimise protsessikäsitluse juurutamisel, kuna see võimaldab minimeerida äriprotsesside kirjeldamise subjektiivsust. DFD-s protsessiskeemi abil selgitatakse välja peamised andmevood, mis on oluline järgnevaks andmestruktuuri mudelite loomiseks ja organisatsiooni infosüsteemi nõuete väljatöötamiseks.

Erinevad tarkvarafirmad pakuvad ka muid metoodikaid.

Olemasolevate metoodikate lühikirjelduse lõpetuseks tuleb märkida, et ettevõtte äriprotsesse saab kujutada standardsete vooskeemide abil, mis sisuliselt põhinevad GOEBZ-i tähistuse ideoloogial, kuid sisaldavad samas mõningaid. täiendavad spetsiaalsed graafilised objektid. Nende objektide kasutamine võimaldab muuta protsesside vooskeemid esinejatele visuaalsemaks ja arusaadavamaks.

Seetõttu on mõnikord keeruline kindlaks teha sisemiste vastuolude allikat, funktsioonide mõningast ebakõla või ettevõtte äriprotsesside optimaalset tööjada. Selles aspektis võimaldab konstrueeritud mudel mitte ainult probleemi tuvastada, vaid ka selgelt näidata tekkivate probleemide põhjuseid.

Samuti tuleb rõhutada, et ettevõtte äriprotsessi mudel on väliskeskkonnast eraldivõetuna või kõrgema taseme süsteemist eraldiseisev struktuur ja selles esile tõstetud elemendid. Selline saadud teave võimaldab teha fundamentaalset analüüsi ehk tuvastada vastuolusid kõrgema taseme süsteemiga (ettevõtte jaoks võib selleks olla rahvamajandusharu, territoriaalringkond vms). Selline analüüs võimaldab prognoosida ettevõtte väljavaateid, sealhulgas selle kriisi tõenäosust.

© E.M. Mihhailova, 2009


Annotatsioon

infomodelleerimise äri

See artikkel uurib PromTransInform LLC (edaspidi PTI) äriprotsesse.

Vaadati üle ja uuriti järgmist:

· ettevõtte üldised omadused;

Arvestati organisatsiooni tegevusliikidega, milliseid tooteid ta tutvustab ja milliseid teenuseid osutab, milliste organisatsioonidega (eelkõige suurematega) sõlmiti lepingud ja kuidas see mõjutab organisatsiooni tegevust.

· kirjeldatakse äriprotsesside kirjeldamise metoodikaid;

Peamiselt kasutatakse PTI-s ARIS metoodikat, mis võimaldab vaadelda organisatsiooni kõikidest vaatenurkadest ning võimaldab vaadelda organisatsiooni kasutades mudelite hierarhiat – üldistamisest kuni protseduuride ja funktsioonide ressursikeskkonna tasemeni.

· konstrueeriti ärimudelite diagrammid (ARIS-i märgetes kasutades CASE tööriista Microsoft Visio) “NAGU ON” (nagu on);

· leiti “pudelikael” ja eEPC mudeli näitel kujutati mudelit “NAGU ON” (nagu peab);

Antud kursusetöö “pudelikaelaks” on tööprotsessi kehv organiseeritus, mis tekib siis, kui kohustused pole ratsionaalselt jaotatud, mis aeglustab korralduse täitmist.

· kirjutati äriprotsessi modelleerimise ja dokumenteerimise leping;

· teostati protsessianalüüs.

Sissejuhatus

Töö eesmärgiks on modelleerida PromTransInform LLC äriprotsesse, tuvastada puudused konkreetsete osakondade tegevuses ning pakkuda välja võimalus nende kõrvaldamiseks.

Küsimus ettevõtte tegevuse parandamisest, leides ja kõrvaldades nn kitsaskohad töötajate töös, kasutades äriprotsesside modelleerimist, on aktuaalne igas arenevas ettevõttes.

Antud kursusetöö õppeobjektiks on PTI OÜ ja selle osakonnad, mille põhiteenuseks on tööstuslike raudteetranspordiettevõtete automatiseerimine.

Õppeaineks on osakondade ja peadirektorile alluvate osakondade töötajate suhtlus.

Töö eesmärgid: ARIS äriprotsesside modelleerimise metoodikaga töötamise oskuste koolitus, info kogumine ja ettevõtte äriprotsesside uurimine, protseduuride modelleerimine, ärimudeli diagrammide koostamine, modelleerimislepingu väljatöötamine ja äriprotsessi dokumenteerimine, protsessianalüüsi läbiviimine.

Töömeetodid. Töö viiakse läbi eesmärgiga täiendada ärimudeli diagrammide konstrueerimise oskusi ARIS-i tähistuses kasutades CASE tööriista Microsoft Visio PTI OJSC äriprotsesside näitel.

Selles töös kasutatakse lähteandmetena järgmist teavet:

· ettevõtte organisatsiooniline struktuur;

· ettevõtte omadused;

· projekteerimise korraldamine konsultatsiooniettevõtetes;

· teave kasutatavate PTI rakendussüsteemide kohta.

Tehtud töö ja kitsaskohtade kõrvaldamise tulemusena on oodata töötajate töö lihtsustumist ja kergendust, seega töömahukuse ja aruannete vigade vähenemist.

1. Integreeritud infosüsteemide ARIS arhitektuur kui äriprotsesside modelleerimise metoodika

ARIS (Architecture of Integrated Information Systems) metoodika arendajaks on 1984. aastal Saarbrückenis (Saarland, Saksamaa) professor August-Wilhelm Scheeri poolt asutatud IDS Scheer AG. ARIS metoodika on kaasaegne lähenemine organisatsiooni tegevuse struktureeritud kirjeldamisele ja selle esitlemisele omavahel seotud ja üksteist täiendavate graafiliste mudelite kujul, mida on lihtne mõista ja analüüsida.

ARISes kasutatavad mudelid on toodud joonisel 1.1.

Joonis 1.1 – ARISe mudelite klassifikatsioon

ARISe metoodikat kasutades loodud mudelid kajastavad olemasolevat olukorda erineva lähendusastmega. Kirjelduse detailsus sõltub selle projekti eesmärkidest, mille raames modelleerimine toimub. ARISe mudelite abil saab analüüsida ja arendada erinevaid lahendusi ettevõtte tegevuse ümberkorraldamiseks, sh juhtimisinfosüsteemi juurutamiseks ja kvaliteedijuhtimissüsteemide arendamiseks.

ARIS metoodika rakendab struktuurianalüüsi põhimõtteid ning võimaldab tuvastada ja mudelites kajastada organisatsiooni põhikomponente, käimasolevaid protsesse, toodetud ja tarbitavaid tooteid, kasutatud informatsiooni, samuti tuvastada nendevahelisi seoseid. Loodud mudelid esindavad dokumenteeritud teadmiste kogumit juhtimissüsteemi kohta, mis hõlmab organisatsiooni struktuuri, käimasolevaid protsesse, organisatsiooni ja turuüksuste vastastikust mõju, dokumentide koostist ja struktuuri, protsessi sammude järjestust, osakondade ja nende töötajate ametijuhendeid. . Erinevalt teistest lähenemistest hõlmab ARIS metoodika kogu teabe salvestamist ühte hoidlasse, mis tagab modelleerimis- ja analüüsiprotsessi terviklikkuse ja järjepidevuse ning võimaldab ka mudeli verifitseerimist.

ARIS-e metoodika põhineb integratsiooni kontseptsioonil, pakkudes protsessidele terviklikku vaadet ning esindab paljusid erinevaid metoodikaid, mis on kombineeritud ühtse süsteemse lähenemise raames. Nende hulgas on selliseid tuntud nagu:

eEPC diagramm (Extended Event Driven Process Chain – sündmuste protsessiahel)

· Cheni diagramm (ERM – olemi suhte mudel – olemi suhte mudel)

· UML keel (Unified Modeling Language – universaalne modelleerimiskeel)

· OMT tehnika (Object Modeling Technique – objektorienteeritud modelleerimise tehnika)

· BSC metoodika (Balanced Scorecard) Selle lähenemise eeliseks on see, et on võimalik kirjeldada protsesse ja nende keskkonda erinevatest, üksteist täiendavatest vaatenurkadest.

2. Olemasolevate äriprotsesside modelleerimise metoodikate eelised ja puudused

ARIS metoodika.

Eelised:

· oskus vaadelda objekti erinevatest vaatenurkadest; erinevad kirjeldustasemed süsteemide elutsükli kontseptsiooni toetamiseks; diferentseeritud vaade analüüsitavale objektile (organisatsioon, juhtimissüsteem jne);

· modelleerimismeetodite rohkus, mis peegeldab uuritava ainevaldkonna erinevaid aspekte, võimaldab modelleerida väga erinevaid süsteeme (organisatsioonilisi, majanduslikke, tehnoloogilisi ja muid);

· ühtne hoidla; kõik mudelid ja objektid luuakse ja salvestatakse ühtsesse projekti andmebaasi, mis tagab ainevaldkonna tervikliku ja tervikliku mudeli koostamise;

· modelleerimistulemuste korduva rakendamise võimalus; kogutud ettevõtteteadmised organisatsiooni tegevuse kõigist aspektidest võivad edaspidi olla aluseks erinevate projektide arendamiseks otse ARIS-keskkonnas ning liideste ja muude tööriistade abil.

Puudused:

· Mõnede protsesside puhul pole liigne formaliseerimine mitte ainult ebaefektiivne, vaid nende spetsiifilisuse tõttu isegi kahjulik. Näiteks võiks tuua need äritegevuse komponendid, mis on otseselt seotud selle tegevuse käigus tekkivate ettearvamatute probleemide loominguliste lahendustega.

· Toote kõrge hind.

SADT ( Struktureeritud analüüs ja disainitehnika) on struktuurianalüüsi ja disaini metoodika, mis integreerib modelleerimisprotsessi, projekti konfiguratsioonihalduse, täiendavate keeletööriistade kasutamise ja projektihalduse oma graafilise keelega. Modelleerimisprotsessi võib jagada mitmeks etapiks: ekspertide küsitlemine, diagrammide ja mudelite koostamine, dokumentatsiooni levitamine, mudelite adekvaatsuse hindamine ja edasiseks kasutamiseks vastuvõtmine. See protsess on hästi välja kujunenud, sest spetsialistid täidavad projekti arendamise käigus spetsiifilisi kohustusi ning raamatukoguhoidja tagab õigeaegse infovahetuse.

SADT tekkis 1960. aastate lõpus osana revolutsioonist, mille tõi kaasa struktureeritud programmeerimine. Kui enamik inimesi nägi vaeva tarkvara loomisega, siis vähesed püüdsid lahendada keerukamat probleemi – luua suuremahulisi süsteeme, mis hõlmaksid nii inimesi kui masinaid, aga ka tarkvara, mis sarnaneks telefonisides, tööstuses, valitsuses ja relvakontrollis kasutatavate süsteemidega. . Sel ajal hakkasid traditsiooniliselt suuremahuliste süsteemide loomisega tegelevad spetsialistid mõistma vajadust suurema korra järele. Seega otsustasid arendajad vormistada süsteemi loomise protsessi, jagades selle järgmisteks etappideks:

Analüüs – selle kindlaksmääramine, mida süsteem teeb

· Disain – allsüsteemide määratlemine ja nende koostoime

· Rakendamine - allsüsteemide arendamine eraldi

Integratsioon – alamsüsteemide ühendamine ühtseks tervikuks

· Testimine – süsteemi töö kontrollimine

· Paigaldamine – süsteemi kasutuselevõtt

· Töötamine -- süsteemi kasutamine

SADT meetod sobib kõige paremini tipptaseme mudelite kirjeldamiseks. Selle peamised eelised on järgmised:

· äriprotsessi kirjelduse täielikkus (kontrollid, info- ja materjalivood, tagasiside).

· Lagunemise keerukus

· Andme- ja infovoogude liitmise ja detailistamise võimalus (kaarede eraldamine ja liitmine)

· Rangete nõuete olemasolu, mis tagavad standardtüüpi mudeli saamise.

Protsessi on lihtne dokumenteerida

· Protsessi kirjeldamise lähenemisviisi vastavus ISO standardile

Samal ajal on SADT-l mitmeid puudusi:

· Tajumisraskused – diagrammil suur hulk kaarte.

· Suur hulk lagunemistasemeid

· Sama organisatsiooni erinevates mudelites esindatud mitme protsessi sidumise raskused.

IDEF0

Funktsionaalse modelleerimise metoodika. Visuaalset graafilist keelt IDEF0 kasutades näib uuritav süsteem arendajatele ja analüütikutele omavahel seotud funktsioonide (funktsionaalsete plokkide – IDEF0 terminites) kogumina. IDEF0 abil modelleerimine on reeglina mis tahes süsteemi uurimise esimene etapp.

IDEF0 peamised eelised on järgmised:

· äriprotsessi kirjelduse täielikkus (juhtimine, info- ja materjalivood, tagasiside);

· lagunemise keerukus (noolte ränne ja tunnelistumine);

· oskus andme- ja teabevoogusid koondada ja detaileerida (noolte eraldamine ja liitmine);

· rangete metoodiliste nõuete olemasolu, mis tagavad standardtüüpi protsessimudelite valmistamise;

· dokumenteerimisprotsesside lihtsus;

· IDEF0-s protsesside kirjeldamise lähenemisviisi vastavus ISO 9000:2000 standarditele.

Seega on IDEF0 üldeesmärk funktsioonide struktuuri ümberkorraldamine, mis parandab süsteemi jõudlust ja tõhusust.

IDEF3 (Integrated Definition Process Description Capture Method) metoodika töötati välja tööprotsesside (Work Flow) mugavamaks kirjeldamiseks, mille puhul on oluline kajastada protseduuride loogilist järjestust. Erinevalt IDEF0-st ei ole see tehnika standardiseeritud.

IDEF3 on struktuurne meetod, mis näitab põhjuse-tagajärje seoseid ja sündmusi. Samuti näitab see, kuidas töö on korraldatud ja millised kasutajad simuleeritud süsteemiga töötavad. IDEF3 kirjeldab iga protsessi stsenaariumi ja toimingute järjestust. Stsenaarium on objekti omaduste muutuste jada kirjeldus vaadeldava protsessi raames (näiteks detaili töökojas töötlemise etappide jada ja selle omaduste muutumise kirjeldus pärast läbimist läbi iga etapi). Iga stsenaariumi täitmisega kaasneb vastav dokumendivoog, mis koosneb kahest voost: protsessi ülesehitust ja järjekorda määratlevad dokumendid (tehnoloogilised juhised, standardite kirjeldused) ning selle rakendamise edenemist kajastavad dokumendid (eksamitulemused, defektiaruanded). ).

IDEF3 dokumentatsiooni- ja modelleerimistööriistad võimaldavad teil täita järgmisi ülesandeid:

· dokumenteerida olemasolevad andmed protsessitehnoloogia kohta;

· tuvastada ja analüüsida seotud dokumendivoogude mõjupunkte tehnoloogilise protsessi stsenaariumile;

· tuvastada olukorrad, kus on vaja otsust, mis mõjutab protsessi elutsüklit (näiteks lõpptoote tehnoloogiliste omaduste muutmine);

· hõlbustada optimaalsete otsuste vastuvõtmist tehnoloogiliste protsesside ümberkorraldamisel;

· töötada välja tehnoloogiliste protsesside simulatsioonimudelid “mis juhtub, kui...” põhimõttel.

IDEF3-l on otsene seos IDEF0 metoodikaga – iga funktsiooni saab IDEF3 abil esitada eraldi protsessina. Kuid IDEF3 funktsionaalne modelleerimine erineb IDEF0 ja DFD modelleerimisest selle poolest, et see peegeldab süsteemi funktsioone nende rakendamise ajas.

DFD (Data Flow Diagrams) metoodika – andmevoo diagrammid on infotöötlusprotsesside kujutamise viis. Tehnika autorid Gane ja Sarson töötasid selle välja IDEF0-st sõltumatult. Erinevalt IDEF0-st ei ole see tehnika standardiseeritud.

Erinevalt IDEF0 nooltest, mis kujutavad jäikaid seoseid, näitavad DFD (andmevoo) nooled, kuidas objektid (sh andmed) tegelikult ühest funktsioonist teise liiguvad. See andmevoo esitus tagab, et DFD mudel peegeldab süsteemi füüsilisi omadusi, nagu objekti liikumine, objekti salvestamine ja objekti levik.

DFD diagrammid võimaldavad mugavalt kirjeldada edastatavat teavet nii modelleeritava süsteemi osade vahel kui ka süsteemi ja välismaailma vahel. See kvaliteet määrab DFD-de rakendusala – nende abil luuakse organisatsiooni infovahetuse mudelid, näiteks dokumendivoo mudel. DFD-d kasutatakse laialdaselt ka ettevõtete infosüsteemide ehitamisel.

Unified Modeling Language (UML), ühtne modelleerimiskeel, on mittevaraline modelleerimis- ja spetsifikatsioonikeel, mis on mõeldud kasutamiseks tarkvaraarenduse valdkonnas. Kuid selle rakendusala ei piirdu ainult infosüsteemide modelleerimise valdkonnaga. Seda saab kasutada ka insenerisüsteemide, äriprotsesside ja organisatsiooniliste struktuuride modelleerimiseks. UML on keel, mida süsteemiinsenerid kasutavad keerukate teaberikaste objektisüsteemide täpsustamiseks, visualiseerimiseks, konstrueerimiseks ja dokumenteerimiseks.

UML-i eelised

· UML on objektorienteeritud, mille tulemusena on analüüsi ja disaini tulemuste kirjeldamise meetodid semantiliselt lähedased tänapäevaste objektorienteeritud keelte programmeerimismeetoditele;

· UML võimaldab kirjeldada süsteemi peaaegu kõigist võimalikest vaatenurkadest ja süsteemi käitumise erinevatest aspektidest;

· UML-diagramme on suhteliselt lihtne lugeda, kui olete selle süntaksiga üsna kiiresti tuttavaks saanud;

· UML laieneb ja võimaldab sisestada oma teksti- ja graafilisi stereotüüpe, mis soodustab selle kasutamist mitte ainult tarkvaratehnika valdkonnas;

· UML on laialt levinud ja areneb dünaamiliselt.

Puudused:

· Keele liiasus. UML-i kritiseeritakse sageli kui tarbetult suurt ja keerukat. See sisaldab palju üleliigseid või suures osas kasutamata diagramme ja konstruktsioone.

· Ebatäpne semantika. Kuna UML on defineeritud iseenda (abstraktne süntaks), OCL-i (formal validation constraint language) ja inglise keele (detailne semantika) kombinatsiooniga, ei ole sellel ametlike kirjeldustehnikatega täpselt määratletud keeltele omast piirangut. Mõnel juhul on UML-i, OCL-i ja inglise keele abstraktne süntaks omavahel vastuolus, mõnel juhul on need puudulikud. UML-i enda ebatäpsed kirjeldused mõjutavad nii kasutajaid kui ka tööriistade tarnijaid, mis põhjustab spetsifikatsioonide ainulaadsete tõlgenduste tõttu tööriistade kokkusobimatust.

· Probleemid õppimisel ja rakendamisel. Ülaltoodud probleemid muudavad UML-i õppimise ja juurutamise problemaatiliseks, eriti kui juhtkond sunnib ärianalüütikuid kasutama UML-i ilma eelnevate teadmisteta.

· Püüab olla kõigi jaoks kõik. UML on üldotstarbeline modelleerimiskeel, mis püüab saavutada ühilduvust kõigi võimalike arenduskeeltega. Konkreetse projekti kontekstis tuleb disainimeeskonnal konkreetse eesmärgi saavutamiseks valida kohaldatavad UML-i võimalused. Veelgi enam, viisid UML-i ulatuse piiramiseks konkreetses domeenis on läbi formalismi, mis pole täielikult sõnastatud ja mida võib kritiseerida.

3. Äriprotsessi valimine modelleerimiseks ja selle sisukas kirjeldamine

3.1. Ettevõtte üldised omadused

PromTransInform LLC tegeleb tööstuslike raudteetranspordiettevõtete automatiseerimisega integreeritud infohaldussüsteemi "Transpordi- ja logistikakompleks" tarkvara- ja riistvarakompleksi teabekomponentide juurutamise kaudu, projektide haldamisega spetsialiseeritud teabehaldussüsteemide juurutamiseks põhiliinis. raudteetransport, samuti projektide juhtimine Kasahstani Vabariigi territooriumil seadmete, raudtee automatiseerimise ja telemehaanika seadmete ja infosüsteemide juurutamiseks, pakub selles valdkonnas nõustamisteenuseid.

PromTransInform LLC põhitegevused on:

Raudteeettevõtete automatiseerimine, mis töötab selliste IT-toodetega nagu IAS “Transport Work”, IAS “Operating Costs”, IAS “Transport Assets”, IAS “Customer Interaction”, IAS “Logistikaefektiivsus”.

IAS TR riist- ja tarkvarakompleks on osa tarkvara- ja riistvaraplatvormist “PTI Framework .Net.2.1.”, millele on ehitatud integreeritud haldusinfosüsteem “Railway Complex” (IIMS “ZHDK”).

See kompleks on ettevõtte PromTransInform LLC spetsiaalne lahendus, mis põhineb Microsofti .NET-sarja IT-toodetel.

IAS TR kasutab olulisel määral sisseehitatud äriloogikat, mis tagab Kliendi raudteekompleksi automatiseeritud haldamise.

Info- ja analüütilise süsteemi “Transport Work” (edaspidi “IAS TR”) töötasid välja PromTransInform LLC (Novosibirsk) spetsialistid.

IAS TR juurutamise põhieesmärk on tootmise planeerimise ning mahtude ja kulude arvestuse juhtimise äriprotsesside terviklik automatiseerimine:

Transpordilogistika (transport); Postitatud http://www.site/

transpordi (logistika) töö;

Transport umbesPostitatud http://www.site/

klienditeenindus (transporditeenuste pakkumine);

Transpordikulud (töö maksumus Postitatud http://www.site/

ja teenuste tariifid);

Raudtee-ettevõtte transpordivarade käitamine juurdepääsuteel ja põhiliikluses.

See võtab arvesse tööstuse erinevusi raudtee-ettevõtete tootmises ja majandustegevuses (võrreldes tööstusettevõtete tegevusega)

PromTransInform LLC tegeleb ka transpordi- ja majandusnõustamisega (raudteetranspordi transpordiloogilised kompleksid, raudteetranspordi transpordikonsultatsioonid, raudteetranspordi majanduskonsultatsioonid, raudteetranspordi IT-konsultatsioonid, raudteetariifide metoodilised juhised) ja projektijuhtimisega raudteeettevõtetes ( infosüsteemide juurutamine raudteetranspordis, raudteetranspordi logistika äriprotsesside optimeerimine, raudteetranspordikompleksi tegevuskulude optimeerimine, projektijuhtimissüsteemide juurutamine).

PromTransInform LLC peamised partnerid ja kliendid on Kasahstani Vabariigi ja Venemaa raudteetööstuse tööstusraudteekompleksi ettevõtted.

PromTransInform LLC peamiseks metoodiliseks partneriks on Siberi Riiklik Transpordiülikool (Novosibirsk). Ettevõtte spetsialistidel on 6-aastane raudteetööstuse kogemus.

3.2 Uuringupiirkond

Uuritavaks objektiks võtame PromTransInform LLC, nimelt tööprotsessi organiseerimise protsessi. Seda ettevõtet uurides ja töötajatega vesteldes võib järeldada, et tööprotsessi korraldus on nõrk. Kitsaskoha täielikum kirjeldus ja selle kõrvaldamise võimalused on toodud jaotises Protsessi analüüs.

PromTransInform LLC organisatsiooniline struktuur (joonis 3.1):

Joonis 3.1 – PTI organisatsiooniline struktuur

3.3 Küsitluse läbiviimise kord

· Uuringu asukohaks on PromTransInform LLC maja, Krasny Prospekt tn., 220/5, kontor 326 (Siberi mess);

· Eksamimeetod - suuline vestlus PromTransInform LLC töötajatega, hankides vajaliku dokumentatsiooni elektroonilisel kujul.

4. Modelleerimine “NAGU ON” (nagu on), lähenemise kirjeldus. ARIS-i abil äriprotsessi kirjeldamiseks kasutatavate diagrammitüüpide valik ja põhjendus

Igal ettevõttel on struktuurid, reeglid ja dokumendid, mis on aluseks ettevõtte protseduuride tõrgeteta toimimisele ning mis peavad olema integreeritud uue kvaliteedijuhtimissüsteemiga. "As Is" analüüs hõlmab juurutava standardi uurimist, võttes arvesse ettevõtte spetsifikatsioone. Sellise analüüsi eesmärk on selgitada standardi nõudeid ja seda, mil määral need ettevõtte tegevuse konkreetseid aspekte mõjutavad. Samal etapil viiakse läbi ettevõttesiseselt kvaliteediga seotud dokumentide ja infosüsteemide inventuur.

PromTransInform LLC protsesside modelleerimiseks kasutame järgmisi diagramme:

· Organisatsiooniskeem - osakonna organisatsioonilise struktuuri kirjeldus.

· Teadmiste kaart – PTI töötajate teadmiste tüüpide kuvamine ja nende salvestusvormide struktureerimine, et määrata kindlaks nende võimed.

· Volituste kaart – töötaja volituste kirjeldus.

· Informatiivne kandeskeem - dokumentide kirjeldus osakonnas toimuvate protsesside kirjeldamise mugavuse huvides.

· Funktsioonipuu – osakonna poolt täidetavate funktsioonide jagamine tasemeteks osakonna tegevuste visuaalsemaks kujutamiseks.

· Funktsioonide jaotusskeem – funktsiooni ümbritsevate objektide kirjeldus keeruka funktsiooni visuaalseks esituseks.

· Kommunikatsioonidiagramm – organisatsiooniüksuste koostoimete esitus kirjeldamaks kogu tootmisprotsessi teostamist.

· Riskidiagramm – tegevusprotsessis tekkivate riskide kirjeldamiseks.

· Toote/teenuse puu – osakonna tegevuse tulemusena saadud toodete struktureerimiseks.

· Tehniliste ressursside mudel – kirjeldada osakonnas kasutatavaid tehnilisi ressursse.

· Lisandväärtuse aheldiagramm - osakonna protsesside kirjeldus, mis mõjutavad toimimise kvaliteeti. Kirjeldada PTI tegevuste liike, mis loovad toodetele lisakvaliteeti.

· Sündmustest juhitud protsesside ahelskeem – tegevuste kirjeldus äriprotsessi sees. Osakonna poolt läbiviidavate protsesside visuaalseks kujutamiseks.

5. Modelleerimislepingud

Modelleerimisprojekti eesmärk langeb kokku kursuseprojekti eesmärgiga ja on toodud sissejuhatuses. Alumises töös vaadeldakse mudeleid “NAGU ON” (nagu on) ja “NAGU ON” (nagu peab). Modelleerimismeetod on ülalt-alla.

Vaadeldakse modelleerimist järgmistel abstraktsioonitasemetel: standardsed äriprotsessid ja eksemplari äriprotsessid.

Mudeleid vaadeldakse seoses lähteandmetega: nõuete kirjeldus, volituste kirjeldus, ametijuhendid, ettevõtte teenused, töötajate funktsioonid.

ARIS-e metoodika sisaldab mitut tüüpi mudeleid, millest igaüks on määratud kindlale esitustüübile ja kirjeldustasemele. Töös kasutatakse äriprotsessi modelleerimiseks järgmist hierarhiat:

- tipptasemel protsessid, mis sisaldab diagramme Organisatsiooniskeem - PTI organisatsiooniline struktuur, Tehniliste ressursside mudel - Tehnilised ressursid, Toodete/teenuste puu - PTI tooted ja teenused

- alamprotsessid, mis sisaldavad teabekandja diagrammi – PTI dokumendid

- protsessi stsenaariumid, mis sisaldavad autoriseerimiskaardi diagrammi – Ärianalüütiku volitused

- protseduurid (operatsioonid), mis sisaldavad diagramme Sündmuspõhine protsessiahel, Teadmiste kaart - Ärianalüütiku teadmiste kaart, Funktsioonide jaotusskeem - Funktsioonikeskkond - IAS "Tranporditöö" moderniseerimise protsess kliendi jaoks, Lisandväärtuse ahelskeem - Protsessi protseduurid konkursil osalemisest.

Eelmises osas loetleti kursusetöös esitatavate diagrammide tüübid. Nende diagrammide elemente kirjeldatakse üksikasjalikult modelleerimiskokkuleppes.

5.1 Projekti terminite sõnastik

Modelleerimislepingus on määratletud projektis kasutatud järgmiste mõistete tõlgendus (tabel 5.1):

Tabel 5.1 – Sõnastik

Termin (vene)

Termin (inglise)

Definitsioon

Töötaja toimingud, mida tehakse teatud tingimuste (sündmuste) ilmnemisel ja mille eesmärk on soovitud tulemuse saavutamine.

Välis- või sisekeskkonna seisundi muutuste peegeldus, mis väljendub dokumentide komplektis, tehtud otsustes, teatud tähtaja saabudes jne. See on sooritatava toimingu tulemus, aga ka selle teostamise vajadus. või rohkem järgmistest toimingutest. Erinevalt funktsioonidest, mis peegeldavad aja jooksul toimuvat ja teatud kestusega protsessi, toimuvad sündmused ühel ajahetkel.

Äriprotsess

Äriprotsess

Seotud korratavate toimingute (funktsioonide) kogum, mis muudab lähtematerjali ja/või teabe lõpptooteks (teenuseks) vastavalt eelnevalt kehtestatud reeglitele.

Toode/teenus on inimtegevuse või tehnoloogilise protsessi tulemus. Toode võib olla nii materiaalne kui ka mittemateriaalne (teenus).

5.2 Sündmuspõhise protsessiahela (eEPC) skeem. Kasutatud objektid ja nende sümbolid on toodud tabelis 5.2.1.

Tabel 5.2.1 - kasutatud objektid

Objektitüüp vene keel (inglise)

Sihtotstarbeline kasutamine

Nimetamise reeglid

Sündmus

Äriprotsessi käigus toimuvate sündmuste kuvamine

Nimi algab objekti nimega, oleku või sündmusega, millega seoses see aset leidis

Teabesalvestusmeediumi kujutamine mittemateriaalsel kujul (nt magnetkettal või välkmällul)

Seda nimetatakse failinimeks või teabebaasi nimeks

Infokandja

Teabesalvestuskandja kujutamine materialiseeritud kujul (nt paberil)

Nimi peab sisaldama dokumendi nime

Funktsiooni eksemplar

Ärifunktsiooni eksemplari kirjeldus äriprotsessi täitmisahelas.

positsioon

Täielik ametinimetus

Sündmuspõhises protsessiahela diagrammis kasutatavad ühenduste tüübid on toodud tabelis 5.2.2.

Tabel 5.2.2 - ühenduste tüübid

Sideallika objekti tüüp

Suhtlustüüp vene keel (inglise)

Sihtotstarbeline kasutamine

Sidevastuvõtja objekti tüüp

Sündmus

Aktiveerib

Funktsioon

Funktsioon

loob

Mõeldud väljundis loodud sündmuse kirjeldamiseks

Sündmus

Funktsioon

Viib

Reegel

Reegel

Aktiveerib

Mõeldud funktsiooni kutsumiseks

Funktsioon

Reegel

Viib

Mõeldud hukkamise tulemuste kirjeldamiseks

Sündmus

Organisatsiooniüksus

Täidab

Funktsioon

positsioon

Täidab

Mõeldud funktsiooni täitva üksuse/isiku märkimiseks

Funktsioon

Infokandja

Funktsioon

Funktsioon

Infokandja

Rakendussüsteem

Toetab

Funktsioon

5.3 Organisatsiooni skeem

Tabel 5.3.1 – Kasutatud objektid

Organisatsiooni struktuuriskeemil kasutatud seoste tüübid on toodud tabelis 5.3.2.

Tabel 5.3.2 - ühenduste tüübid

5.4 Teadmiste struktuuriskeem

Teadmiste struktuuri diagrammil kasutatud objektide tüübid on toodud tabelis 5.4.1.

Tabel 5.4.1 – objektitüübid

Objektitüüp vene keel (inglise)

Vaikenimega sümbol (vene/inglise)

Sihtotstarbeline kasutamine

Nimetamise reeglid

Dokumenteeritud teadmised

Objekti kasutatakse ärifunktsiooni täitmiseks vajaliku formaliseeritud (dokumenteeritud) teadmiste hulga tuvastamiseks.

Teavet sisaldava dokumendi täisnimi

Teadmiste või oskuste esitus, mis töötajal peavad olema või mis on vajalikud äritegevuse edukaks täitmiseks.

Nõutava teadmiste hulga poolformaalne määratlus

positsioon

Organisatsiooni töötaja ametikoha esindamine.

Täielik ametinimetus

Teadmiste struktuuri diagrammil kasutatud seoste tüübid on toodud tabelis 5.4.2.

Tabel 5.4.2 - ühenduste tüübid

5.5 Infokandja diagramm

Diagrammil kasutatud objektide tüübid on toodud tabelis 5.5.1

Tabel 5.5.1 – Objektitüübid

Diagrammil kasutatud ühenduste tüübid on toodud tabelis 5.5.2.

Tabel 5.5.2 - ühenduste tüübid

5.6 Autoriseerimiskaart

Kasutatavate objektide tüübid on toodud tabelis 5.6.1.

Tabel 5.6.1 – objektitüübid

Ühenduste tüübid on toodud tabelis 5.6.2.

Tabel 5.6.2 - objektidevaheliste ühenduste tüübid

5.7 Funktsioonipuu

Kasutatavate objektide tüübid on toodud tabelis 5.7.1.

Tabel 5.7.1 – objektitüübid

Ühenduste tüübid on toodud tabelis 5.7.2.

Tabel 5.7.2 - ühenduste tüübid

5.8 Funktsioonide jaotusskeem

Kasutatavate objektide tüübid on toodud tabelis 5.8.1.

Tabel 5.8.1 - objektitüübid

Objektitüüp vene keel (inglise)

Vaikenimega sümbol (vene/inglise)

Sihtotstarbeline kasutamine

Nimetamise reeglid

Eesmärk

Protsessi eesmärgi kirjeldus

Nimetus algab tegevuse või protsessi tähistusega, mille olulised tunnused on nimes ära toodud hiljem.

Tegevusressurss

Kasutatud ressursside kujutamine

Nimi sisaldab ressursi nime

Rakendussüsteem

Kasutatud rakendussüsteemide tutvustus

Nimi sisaldab rakendussüsteemi eksemplari nime

positsioon

Organisatsiooni töötaja ametikoha esindamine.

Täielik ametinimetus

Kiri (post)

Kiri meili teel

Nimi sisaldab saadetud manustatud meili pealkirja

Infokandja

Infokandja esitlemine materiaalsel kujul

Nimi peab sisaldama kogu nime

Asukoht

Koht, kus objekt asub

Nimi peab sisaldama asukoha koordinaate

Ühenduste tüübid on toodud tabelis 5.8.2.

Tabel 5.8.2 - ühenduste tüübid

Sideallika objekti tüüp

Suhtlemistüüp

rus. (inglise)

Sihtotstarbeline kasutamine

Sidevastuvõtja objekti tüüp

Funktsioon

Toetab

Mõeldud funktsioonide alluvuse kirjeldamiseks

Eesmärk

positsioon

Kas IT vastutab

Mõeldud kirjeldama konkreetse töötaja panust mõne funktsiooni täitmisesse

Funktsioon

Infokandja

Pakub sisendit

Mõeldud funktsiooni dokumenteerimise kirjeldamiseks

Funktsioon

Funktsioon

Loob väljundi

Infokandja

Rakendussüsteem

Toetab

Mõeldud kirjeldama kasutatavat rakendussüsteemi

Funktsioon

Funktsioon

Hukatakse kell

Mõeldud kirjeldama, kus funktsioon täidetakse

Asukoht

5.9 Sideskeem

Objektitüübid on toodud tabelis 5.9.1.

Tabel 5.9.1 – Objektitüübid

Ühenduste tüübid on toodud tabelis 5.9.2.

Tabel 5.9.2 - ühenduste tüübid

5.10 Tehniliste ressursside mudel

Objektitüübid on toodud tabelis 5.10.1.

Tabel 5.10.1 - objektitüübid

Ühenduste tüübid on toodud tabelis 5.10.2

Tabel 5.10.2 - ühenduste tüübid

5.11 Toote/teenuse puu

Kasutatavate objektide tüübid on toodud tabelis 5.11.1.

Tabel 5.11.1 – objektitüübid

Ühenduste tüübid on toodud tabelis 5.11.2.

Tabel 5.11.2 - ühenduste tüübid

Kasutatavate objektide tüübid on toodud tabelis 5.12.1

5.12. Riski diagramm

Ühenduste tüübid on toodud tabelis 5.12.2.

Tabel 5.12.2 - ühenduste tüübid

5.13 Lisandväärtuse ahelskeem

Objektitüübid on toodud tabelis 5.13.1

Ühenduste tüübid on toodud tabelis 5.13.2

Tabel 5.13.2 - ühenduste tüübid

6. Ärimudeli diagrammid

6.1 Sündmuspõhine protsessiahel

Joonis 6.1.1 – Sündmuspõhine ahel kliendi rakenduse töötlemiseks (ARIS-i laiendatud sündmustepõhise protsessiahela diagrammi tähistuses)

6.2 PromTransInformi organisatsiooni skeem on toodud joonisel 6.2

Joonis 6.2 – PTI organisatsiooniline struktuur (ARIS-i organisatsiooniskeemi tähistuses)

6.3 Teadmiste kaart ja ärianalüütiku teadmusstruktuuri diagramm on toodud joonistel 6.3.1, 6.3.2, 6.3.3.

Joonis 6.3.1 – Ärianalüütikute teadmiste kaart (ARISe teadmiste kaardi diagrammi tähistuses)

Tabel 6.3.1 – Üksikasjad

Joonis 6.3.3 – Ärianalüütiku oskused (ARISe teadmusstruktuuri diagrammi tähistuses)

Joonis 6.3.4 – Ärianalüütiku teadmised (ARISe teadmusstruktuuri diagrammi tähistuses)

6.4 PTI teabekandjate diagramm on toodud joonisel 6.4

Joonis 6.4 – teabekandja diagramm (ARISi teabekandja diagrammi tähistuses)

6.5 Ärianalüütiku volituste kaart on näidatud joonisel 6.5

Joonis 6.5 – Ärianalüütiku asutus (ARIS-i autoriseerimiskaardi diagrammi tähistuses)

6.6 Tellimuse täitmise protsessi funktsioonipuu on näidatud joonisel 6.6

Joonis 6.6 - Tellimuse täitmise protsessi funktsioonipuu

6.7 Funktsioonikeskkonna diagramm on näidatud joonisel 6.7

Joonis 6.7. - Funktsioonikeskkond - IAS “Transporditöö” moderniseerimine kliendi jaoks (ARIS Funktsioonide jaotusskeemi märgetes)

6.8 Sideskeem on näidatud joonisel 6.8

Joonis 6.8 - Kommunikatsiooniskeem - Tulemuste ülekandmine osakondade vahel (ARIS-e sideskeemi tähistuses)

6.9 Tehnilise ressursi mudel on toodud joonisel 6.9

Joonis 6.9 - PTI tehnilised ressursid (ARISe tehniliste ressursside mudeli diagrammi tähistuses)

6.10 Toote/teenuse puu on näidatud joonisel 6.10

Joonis 6.9 – PTI tooted ja teenused (ARISE toote/teenuse puu diagrammil)

6.11 Riskidiagramm on näidatud joonisel 6.11

Joonis 6.9 – PTI riskidiagramm (ARIS-i riskidiagrammi tähistuses)

6.12 Konkursil osalemise protsessi lisakvaliteedi ahela skeem on toodud joonisel 6.12

Joonis 6.12 - Konkursil osalemise protsessi lisatud kvaliteediahela protseduur (ARIS-e lisandväärtusahela diagrammi tähistuses)

7. Äriprotsessi dokumenteerimine

Äriprotsesside juhtimisel seisab ettevõtte juhtkond silmitsi tõsiasjaga, et nende juhtimise keerukuse tase tõuseb järsult hallatavate objektide arvu ja organisatsiooniliste struktuuride koosmõju olulise suurenemise, samuti äritegevuse mitmekesistamise ja laienemise tõttu. geograafia ja/või tootevalik.

Selles kontekstis täidab ettevõtte tegevuse dokumenteerimine mitmeid olulisi funktsioone, nagu teadmusbaasi hoidmine ettevõtte erinevate teemavaldkondade kohta (protsessid, organisatsiooni struktuur, tooted, volitused jne), äriprotsesside läbipaistvuse suurendamine (analüüs) struktuuriüksuste vahelise suhtluse tõhusust, osaledes ots-otsani protsessis), valmistades ette organisatsiooni protsesse infosüsteemide juurutamiseks. Tegevuste dokumenteerimine võimaldab teil mõista, millised protsessid organisatsioonis toimuvad, kes nende eest vastutab, kas neile vastutavatele isikutele on antud piisavad volitused ja kas nendele protsessidele on tagatud piisavad vahendid (tehnilise teabe dokumenteerimine tabelis 7.1.1). .

Tabel 7.1.1 – PTI-uuringu tulemused

Ametinimetus

Kellele nad aru annavad?

Sissetulev teave

Väljuv teave

Ärianalüütik

Analüütika osakond

BP kirjutamine

Peadirektor

kliendi soovid, kliendi tarkvara uuringu andmed

Tehnilised näitajad, äriprotsessid

Programmeerija

Arendusosakond

Kodeerimistarkvara

Arendusosakonna juhataja

BP, kliendi soovid

Tarkvara (programmid)

Tester

Arendusosakond

Tarkvara testimine

Arendusosakonna juhataja

Valmis tarkvara

Tööprogramm

Peadirektor

PTI juht

Klientide leidmine ja nendega lepingute sõlmimine

kliendi soovid, sõlmitud leping kliendiga

Juhised tööjuhile

Direktor

PTI juht

Koostöö tegevjuhiga

Peadirektor

kliendi soovid, sõlmitud leping kliendiga

Peadirektori juhised

Arendaja

Arendusosakond

Tarkvaraarhitektuuri projekteerimine

Arendusosakonna juhataja

BP, kliendi soovid

Moodustunud arhitektuur

Veebiarendaja

Arendusosakond

Programm veebi jaoks kliendi ja serveri poolel, veebiserveri konfiguratsioon, paigutus

Arendusosakonna juhataja

BP, kliendi soovid

Seadistatud server, veebiserver

Arendusosakonna juhataja

Arendusosakond

Peadirektor

Ülesanne direktorilt

Juhised alluvatele

Protsesside ja nende omanike uuendatud loend on toodud tabelis 7.1.2.

Tabel 7.1.2 - protsesside ja nende omanike loend

Omanik

Saabuvad üksused ja ametnikud

Tootmine

Põhiline

Peadirektor, direktor

Tegevjuht, direktor

IT pakkumine

Põhiline

Arendusosakonna juhataja

Arendusosakond

Kvaliteedikontroll

Põhiline

Tester

Arendusosakond

Organisatsiooni juhtimine

Abistav

Tegevjuht, direktor

Peadirektor, direktor

Andmete salvestamine

Abistav

Ärianalüütik

Analüütika osakond

Kokku on osakonnas 5 protsessi. Neist 3 on peamised ja 2 abistavad.

Tootmisprotsessi dokumentatsioon on toodud tabelis 7.1.3. Seega ei sisalda väljunddokument protsessis ja selle mudelis vajalike muudatuste tegemisel neid käsitsi käsitluses esinevaid vigu struktuuriüksuste loogikas ja volituste jaotuses.

Näiteks kui protsessis ARIS-is tehakse muudatusi, peavad uued funktsioonid kajastuma vastaval BP-l, kus on märgitud vastutav osakond ja vastav kasutaja.

Selliste muudatuste käsitsi tegemine on vaevarikas ja pikk protsess, mis nõuab eraldi kontrolli, mis võtab palju aega ja ressursse. ARIS-is saab selliseid muudatusi teha mõne minuti jooksul ning uue dokumendi genereerimine toimub automaatselt.

Tabel 7.1.3 – Tootmisprotsess

Ametinimetus

Alajaotus

Sissetulev teave

Tingimuste kokkuleppimine kliendiga

Direktor

ülemused

Kliendi tingimused

Lepingu sõlmimine

Peadirektor

ülemused

Lähtetingimused

Töötajate teavitamine tellimusest

Direktor

ülemused

Automatiseerimistellimus (e-post)

Toiteallika kirjeldus ja dokumentatsioon

Ärianalüütik

Analüütika osakond

BP dokumentide komplekt

IS arhitektuuriline projekteerimine

Arendaja

Arendusosakond

Tehnoloogilised juhised, andmed kliendi andmearhitektuuri kohta, BP dokumentide komplekt, tarkvaranõuded

Tarkvara kodeerimine

Programmeerija või veebiprogrammeerija

Arendusosakond

BP dokumentide komplekt,

Tarkvara litsents

Tarkvara testimine

Tester

Arendusosakond

Kliendi IP

IS rakendamine

Arendaja

Arendusosakond

Järeldus IS-i rakendamise kohta

Muudatuste tegemine muutub äärmiselt lihtsaks ning regulatiivsete dokumentide vormistamine ei venita hetkeni, mil iga uus dokument enam tegelikkusele ei vasta.

8. Äriprotsesside analüüs

Protsessianalüüsi tuleks mõista laiemas tähenduses: see ei hõlma mitte ainult tööd graafiliste diagrammidega, vaid ka protsesside kohta kogu olemasoleva teabe analüüsi, nende näitajate mõõtmist, võrdlevat analüüsi jne. Seal on nii kvalitatiivne analüüs kui ka kvantitatiivne äriprotsesside analüüs . Alustame protsessi kvalitatiivse analüüsiga. Probleemsete piirkondade väljaselgitamine on protsessi kvalitatiivse analüüsi lihtsaim vahend. Selle analüüsimeetodi peamine eesmärk on määrata edasise põhjalikuma analüüsi suunad. Joonisel 8.1 on näidatud neli probleemset piirkonda.

Esimene neist on seotud töö planeerimisega, teine ​​- tellimuste täitmisega, kolmas - suhtlemisega klientidega, neljas - suhtlemisega personaliga. Iga probleemse valdkonna kohta esitatakse lühikesed probleemipüstitused.

Probleemsete kohtade väljaselgitamine toimub vaadeldavasse protsessi kaasatud juhtide ja töötajate intervjueerimise teel. Seega viidi joonise 8.1 näitel läbi PTI töötajate küsitlus. Iga protsessi viivad läbi kindlad osakonnad.

Joonis 8.1 – PTI probleemsed alad

Saadud protsessiskeem võib olla protsessi ümberkujundamise projekti elluviimisel arutelu- ja analüüsiobjektiks. Nii saab näiteks üksikasjalikumalt käsitleda teavet klientidega suhtlemise kohta: milline on töö järjekord, rollide määramise protsess, klientidega suhtlemise kord jne.

Just seda protsessi on diagrammil üksikasjalikult välja toodud (joonis 6.1.1).

Kuna sellel protsessil on probleeme, tuleb see ümber korraldada.

Enne moderniseerimist nägi protsess välja selline: pärast kliendiga lepingu sõlmimist andis PTI peadirektor projekti juhtimise üle projektijuhile (joonis 8.2).

Aga kui tekkis küsimusi, oli projektijuht sunnitud ühendust võtma peadirektoriga, et too helistaks kliendile ja täpsustaks kogu vajaliku info. See oli sageli äärmiselt ebamugav, kuna peadirektor oli pidevalt komandeeringus ja temaga polnud alati võimalik telefoni teel ühendust saada.

Seetõttu pidi projektijuht pidevalt ootama, et peadirektor infot täpsustaks.

Seetõttu ootavad töötajad edasisi juhiseid ja töö ei liigu.

Joonis 8.2 – Korralduse täitmise protseduur kuni kitsaskoha kõrvaldamiseni (ARIS-i laiendatud sündmustepõhise protsessiahela diagrammi tähistuses)

Nüüd näeb protsess välja selline: pärast kliendiga lepingu sõlmimist annab PTI peadirektor projekti juhtimise üle projektijuhile (joonis 8.3).

Ei edastata mitte ainult haldust, vaid ka kõiki andmeid klientide kohta (nende telefoninumbrid jne).

Nüüd ei pea enam peadirektorit ootama (ta saab rahulikult töötada, uusi lepinguid sõlmida) ning projektijuht teeb kõik tööd ise. Lisa A sisaldab ärianalüütiku ametijuhendit.

Joonis 8.3 - Tellimuse täitmise protseduur pärast kitsaskoha kõrvaldamist (ARIS-i laiendatud sündmustepõhise protsessiahela diagrammi tähistuses)

Nõuded KPI süsteemile:

Iga näitaja peab olema selgelt määratletud;

· näitajad ja standardid peavad olema saavutatavad: eesmärk peab olema realistlik, kuid samas stiimuliks;

· näitaja eest peavad vastutama need inimesed, keda hinnatakse;

· näitaja peab olema sisukas;

· näitajad võivad olla üldised kogu ettevõtte kohta, s.t ettevõtte eesmärgiga “seotud” ja iga divisjoni jaoks spetsiifilised, s.t. "seotud" üksuse eesmärkidega.

Analüüsime ajalisi viivitusi (kui kaua tellimus valmis enne ja pärast protsessi moderniseerimist) (tabel 8.1). Arvutused tehakse ühe tellimuse kohta.

Tabel 8.1 – Viivituse analüüs

Info täpsustamine kliendilt

BP kirjutamine

IC testimine

IS rakendamine

Eesmärgi saavutamise astme terviklik hindamine

Eesmärgi saavutamise taseme planeeritud terviklik hindamine

Moderniseerimise summaarne efektiivsus (KPI) on 63,13%. „Order Execution BP (eEPC)“ protsessimudeli analüüsiaruande tulemustel põhinevad BP analüüsi andmed on toodud tabelis 8.2.

Tabel 8.2 - „Order Execution BP (eEPC)“ protsessimudeli analüüsi tulemuste aruanne

Sarnased dokumendid

    Äriprotsesside klassifikatsioon, erinevad lähenemised nende modelleerimisele ja kvaliteediparameetrid. Äriprotsesside modelleerimissüsteemide metoodika ja funktsionaalsus. ARIS ja AllFusion Process Modeler 7 süsteemide võrdlev hindamine, nende eelised.

    lõputöö, lisatud 11.02.2011

    Tarbimislaenu väljastamise protsessi ärimudeli loomine. Krediidiprotsessi organisatsiooniline tugi. Äriprotsesside modelleerimine ja dokumenteerimine BPwin programmis. AS IS mudeli ehitus. Ettepanek äriprotsessi automatiseerimiseks.

    kursusetöö, lisatud 01.07.2012

    Organisatsiooni äriprotsessi põhjendus, skeem ja kirjeldus. Juhuslike suuruste jaotusseaduste tuvastamine. Modelleerimisalgoritmi väljatöötamine ja kirjeldamine simulatsioonimudelprogrammi realiseerimiseks. Arvutisimulatsiooniprogrammi väljatöötamine.

    kursusetöö, lisatud 28.07.2013

    Toidukaupade supermarketi "Big Lozhka" äriprotsesside infosüsteemi (IS) modelleerimine varases staadiumis (ettevõtte kontseptsiooni kujundamise faas), kasutades UML-i standardeid. IS-i modelleerimise stsenaarium, lähteandmed ja juhtimisstruktuur.

    kursusetöö, lisatud 16.09.2011

    Välis- ja sisekeskkonna analüüs, majandusnäitajad, ettevõte. Selle konkurentsivõime hindamine. Turu atraktiivsuse maatriksi koostamine. Tulude ja kulude prognoosiplaan. Äriprotsesside modelleerimine puhkemaja toimimiseks.

    kursusetöö, lisatud 18.03.2015

    Äriprotsesside modelleerimise omadused IDEF0 standardis ja nende efektiivsuse arvutamine. Käsitsi valmistatud seebi valmistamise protsessi ümberkujundamine, järgides materjalikulude eelarvet, säästes materjale ja täites kõiki kvaliteedinõudeid.

    kursusetöö, lisatud 17.07.2014

    Ettevõtte MegaFon äriprotsessi "Intsidentide haldamine" simulatsioonimudeli koostamine, et prognoosida IT-teenuste kogumaksumust juhtumite teenindamiseks. Modelleerimisalgoritmide väljatöötamine mudeli arvutiprogrammide realiseerimiseks.

    kursusetöö, lisatud 04.09.2012

    Ühtse korraldusmeetodi rakendamine äriprotsesside optimeerimiseks. Tarkvara Staffware Process Suit, selle töö olemus ja eelised. Prototüübirakenduse väljatöötamine ühtse vahemeetodi rakendamise automatiseerimiseks.

    lõputöö, lisatud 21.08.2016

    IT-nõustamise kontseptsioon ja olemus. Infonõustamise valdkonnale spetsialiseerunud ettevõtete tegevusalad. Ärimodelleerimise põhimõisted. Äriprotsesside klassifikatsioon. Põhjuse ja tagajärje probleemi analüüsi aruande omadused.

    test, lisatud 09.11.2012

    Äriprotsessi üldised omadused ning selle välis-, funktsionaal- ja objektmudelite konstrueerimine. Ressursside ja protsesside teostajate kirjeldus. Hindamine mõõdikute järgi, mis iseloomustavad klientide rahulolu astet. Optimeerimiseesmärkide määratlemine.

Vladimir Repin, Vitali Eliferov Peatükk raamatust “Protsessikäsitlus juhtimisele. Äriprotsesside modelleerimine"
Kirjastus "Mann, Ivanov ja Ferber"

Protsessianalüüsi tuleks mõista laiemas tähenduses: see hõlmab mitte ainult tööd graafiliste diagrammidega, vaid ka protsesside kohta kogu olemasoleva teabe analüüsi, nende näitajate mõõtmist, võrdlevat analüüsi jne.

Protsessianalüüsi tüüpide klassifikatsioon on näidatud joonisel fig. 1.

Riis. 1.Äriprotsesside analüüsi tüüpide klassifikatsioon

Protsesside subjektiivseks hindamiseks on mitmeid meetodeid. Paljuski on sellised meetodid välja töötatud äriprotsesside ümberkujundamise metoodika rajajate ja järgijate töödes, näiteks Hammer ja Champy, Robson ja Ullah jt. Lisaks saab kvalitatiivseks analüüsiks kasutada tuntud analüüsimeetodeid protsesside kohta: SWOT-analüüs, Bostoni maatriksi analüüs ja teised.

Graafilise protsessianalüüsi meetodid on vähem arenenud. Nende klassifikatsiooni meile teadaolevast kirjandusest ei leia. Sellega seoses pakume välja ja kaalume oma lihtsaimat graafilise protsessianalüüsi meetodite klassifikatsiooni.

Lisaks nendele meetoditele pakume protsesside kvantitatiivseks hindamiseks veel üht meetodit, mis põhineb protsessi vastavuse analüüsile selle organisatsiooni standardnõuetele. Kavandatav tüüpiliste protsessinõuete struktuur põhineb ISO 9000 standardite seeria nõuetel. Lisaks saab analüüsida protsessi vastavust seadustele ja määrustele.

Protsesside kvantitatiivse analüüsi meetodid on maailma praktikas põhjalikumalt välja töötatud. Enamik neist põhinevad protsesse puudutava statistilise teabe kogumisel, töötlemisel ja analüüsil. Tegelikult töötati välja statistilise protsessianalüüsi meetodid kvaliteedijuhtimissüsteemide rakendamisel kasutatavate vahenditena.

Praegu on laialt levinud kvantitatiivsed analüüsimeetodid nagu protsessi simulatsiooni modelleerimine ja ABC protsesside analüüs (tegevuskulude analüüs). Neid ei käsitleta raamatu raames, kuna nende praktika praktikas on seotud suurte kuludega ja organisatsioonide projektide pikkade teostusaegadega. Meie hinnangul on nende meetodite kasutamine organisatsioonides, kus puudub selge protsesside regulatsioon ja vahendid nende näitajate mõõtmiseks, sobimatu. Kuna enamik Venemaa ettevõtteid on täpselt sellises seisus, on simulatsioonimudelite ja ABC-analüüsi kasutamine nende jaoks ennatlik.

Protsessi SWOT-analüüs

Protsessi SWOT-analüüs hõlmab selle tugevate ja nõrkade külgede, parendusvõimaluste ja halvenemisohtude väljaselgitamist. Tabelis Joonisel 3.15 on toodud näide protsessi SWOT analüüsist.

Tabel 1. Protsessi SWOT-analüüsi näide

Tugevused Nõrkused
1. On juht – juht.
2. Kvaliteetne tooteprotsess.
3. Kvalifitseeritud personali olemasolu.
4. Kõrge automatiseerituse tase
1. Kliendid ei ole rahul toodete tarneajaga.
2. Funktsioonide osaline dubleerimine.
3. Puudub süsteem protsesside tulemuslikkuse näitajate mõõtmiseks.
4. Paljude esinejate kohta puuduvad ametijuhendid
Võimalused Ähvardused
1. Efektiivsuse tõstmine läbi CRM süsteemi juurutamise.
2. Vähendatud üldkulud.
3. Tellimuste täitmise aegade vähendamine läbi edasise automatiseerimise
1. Klientide kaotus pikkade tarneaegade tõttu.
2. Toote kvaliteedi langus.
3. Suur sõltuvus protsessi läbiviijate isiksustest

Protsessi SWOT-analüüsi saab läbi viia järgmiselt:

  • viia läbi organisatsiooni juhtide ja spetsialistide küsitlus;
  • töödelda küsitluse tulemusi, hinnates tähenduselt sarnaste vastuste arvu ja moodustades vastustele reitingu;
  • koostage protsessi SWOT-analüüsi tabel.

SWOT-analüüs on vahend protsessi kvalitatiivseks eelhindamiseks. Selle alusel saadud andmeid saab edaspidi kasutada protsessi madala efektiivsuse põhjuste väljaselgitamiseks ja seda iseloomustavate näitajate määramiseks.

Protsessi probleemide analüüs: probleemsete piirkondade tuvastamine

Probleemsete piirkondade väljaselgitamine on protsessi kvalitatiivse analüüsi lihtsaim vahend. Selle analüüsimeetodi peamine eesmärk on määrata edasise põhjalikuma analüüsi suunad. Probleemsete piirkondade tuvastamiseks tuleks koostada suuremahuline protsessiskeem, millel kuvatakse peamised täidetavate funktsioonide rühmad ja nende täitjad. Pärast seda peate diagrammil märkima probleemsed piirkonnad ja kirjeldama neid lühidalt. Joonisel fig. 2 on sellise protsessi diagrammi näide.

Probleemsete kohtade väljaselgitamine toimub vaadeldavasse protsessi kaasatud juhtide ja töötajate intervjueerimise teel. Niisiis, kasutades joonisel fig. 2 viidi läbi küsitlus RSU - ettevõtte remondi- ja ehitusosakonna - töötajate seas. Sellest tulenev seadmete remondiprotsess tipptasemel koosneb seitsmest funktsioonide rühmast. Igaüht neist teostavad kindlad üksused.

Joonisel fig. Joonisel 2 on näidatud neli probleemset piirkonda. Esimene neist on seotud seadmete ostmisega, teine ​​- töövõtjate kaasamisega, kolmas - remondi teostamisega, neljas - tehtud tööde ja seadmete eest tasumise teostamisega. Iga probleemse valdkonna kohta esitatakse lühikesed probleemipüstitused.

Riis. 2. Protsessi probleemsed valdkonnad

Saadud protsessiskeem võib olla protsessi ümberkujundamise projekti elluviimisel arutelu- ja analüüsiobjektiks. Nii võib näiteks üksikasjalikumalt käsitleda teavet probleemide esinemise kohta remonditööde tegemisel: milline on remonditööde tegemise kord, kuidas ja kes tarnib materjale ja varuosi, kuidas peetakse arvestust, kes on vastutab hinnangute kontrollimise eest, kes protsessi kiiresti juhib jne. Probleemsete kohtade esiletõstmine on seega vahend juhtide ja ekspertide tähelepanu koondamiseks protsessi teatud osadele.

Protsesside järjestamine subjektiivse hinnangu alusel

Protsesside järjestamine viiakse läbi projekti ettevalmistavas etapis, kui on vaja iseloomustada organisatsiooni iga suuremat protsessi ja otsustada, millist neist tuleks kõigepealt parandada. Lisateavet selle tehnika kohta saate lugeda.

Järjestusprotsesside jaoks on mitu lähenemisviisi. Vaatleme kõige lihtsamat meetodit. Esimeses etapis on vaja koostada organisatsiooni põhiprotsesside loetelu. Seejärel moodustatakse järgmine tabel (tabel 2):

Tabel 2. Organisatsiooni protsesside pingerida

Protsessi tähtsus/protsessi olek Kõrge efektiivsus Keskmine efektiivsus Madal efektiivsus
Väga oluline protsess Protsess 1 - 2. protsess
Oluline protsess Protsess 6 Protsess 3 -
Väike protsess Protsess 5 Protsess 7 4. protsess

Tabeli analüüs 2 näitab, et protsess 2 on organisatsiooni tegevuse jaoks väga oluline ja samal ajal kõige vähem efektiivne. Seega on kõigepealt vaja suunata jõupingutused protsessi analüüsimiseks ja ümberkorraldamiseks 2. Iga organisatsiooni jaoks tabel. 2 täidetakse erinevalt. Pealegi muutub aja jooksul protsesside asukoht tabeli lahtrites.

Tuleb märkida, et protsesside järjestamine sellise tabeli abil on väga subjektiivne. Pikaajalised projektid organisatsiooni tulemuslikkuse parandamiseks ei saa põhineda selliste analüüsimeetodite kasutamisel. Tavaliselt kasutatakse seda meetodit juhtide koolitusseminaride, koosolekute, ajurünnakute jms ürituste läbiviimisel, mille eesmärk on kvalitatiivsete näitajate alusel kiiresti analüüsida olukorda ettevõtte protsessidega.

Protsessi analüüs seoses tüüpiliste nõuetega

Iga organisatsioonilist protsessi saab analüüsida teatud nõuete täitmise seisukohast. Hetkel ei ole maailmas spetsiaalseid standardeid, mis reguleeriksid äriprotsessidele esitatavaid nõudeid (ISO/IEC 15504-2:2003). Allpool välja pakutud protsessi korraldamise nõuete struktuur töötati välja meie poolt, võttes arvesse ISO 9001 standardi nõudeid.

ISO 9000 standardite seerias soovitatakse kasutada PDCA (Plan-Do-Check-Act) tsüklit, et luua süsteem protsesside pidevaks täiustamiseks. Usume, et selle tsükli kasutamine on ka kohustuslik nõue, mida tuleb protsessidele rakendada.

Lisaks ülaltoodud nõuetele peab protsess sisaldama üldtuntud kõrvalekallete haldamise skeemi: "protsessi planeerimine - protsessi teostamine - arvestus - kontroll - otsuste tegemine."

Seega peaks tüüpiline protsess meie arvates vastama järgmistele nõuete rühmadele:

  • protsessi kõigi komponentide reguleerimine;
  • PDCA protsessi pideva täiustamise tsükli kasutamine.

Nõuded protsessi korraldamiseks, võttes arvesse ISO 9001 standardi soovitusi, on toodud tabelis. 3.

Tabel 3. Küsimustik protsesside analüüsiks seoses tüüpiliste nõuetega

Protsessianalüüsi läbiviimisel tuleb infot koguda vastavalt tabeli nõuetele. 3. Sellise töö tegemine võib olla asjakohane ettevõtte protsesside ümberkorraldamise projekti elluviimisel. Protsessi analüüsitakse PDCA tsükli olemasolu suhtes. Tuletage meelde, et protsessi ümber luuakse PDCA silmus, nagu on näidatud joonisel fig. 3. Protsessi pideva täiustamise tsükli funktsioonide eesmärk on näidatud tabelis. 4.

Riis. 3. PDCA tsükkel

Tabel 4. PDCA tsükkel protsessi jaoks

Protsessi tuleks analüüsida selle põhjal, kas on olemas dispersioonihaldustsükkel. See tsükkel sisaldab viit protsessifunktsioonide rühma, mille eesmärk on näidatud tabelis. 5.

Tabel 5. Juhtkontuuri funktsioonid

Juhtkontuuri funktsioon Kirjeldus
1 Planeerimine Funktsioonide rühm protsessi töö tehniliseks, majanduslikuks ja finantsplaneerimiseks
2 Täitmine Funktsioonide rühm protsessi läbiviimiseks (näited: dokumendi koostamine, toote valmistamine jne)
3 Raamatupidamine Funktsioonide rühm faktilise teabe salvestamiseks protsessi teostamise kohta
4 Kontrolli Funktsioonide rühm planeeritud tulemusnäitajate täitmise jälgimiseks võrreldes tegelike näitajatega
5 Otsuste tegemine Funktsioonide rühm juhtimisotsuste ettevalmistamiseks ja tegemiseks kavandatud tulemusnäitajatest kõrvalekallete andmete põhjal

Hälbe reguleerimise tsükli skeem on näidatud joonisel fig. 4.

Riis. 4. Hälvete juhtimise tsükkel

Kui analüüsi tulemusena selgub, et protsess rahuldab kõiki ülaltoodud kolme nõuete gruppi, siis võib protsessi korraldust lugeda rahuldavaks. Edasine töö sellise protsessi täiustamiseks hõlmab selle toimivuse analüüsimist ja parandamist.

Graafiliste protsessiskeemide visuaalne analüüs

Graafiliste protsessiskeemide visuaalsel analüüsil on mitmeid olulisi piiranguid. Fakt on see, et protsess on keeruline objekt, mida ei saa kirjeldada ühe graafilise diagrammi kujul. Iga graafiline protsessiskeem kuvab teavet vastavalt valitud kirjeldamisviisile (tähistusele). Kõik vead või puudused graafilise diagrammi moodustamisel põhjustavad tõhusa analüüsi võimatust. Näiteks unustas analüütik protsessi kirjeldamisel märkida mitu sissetulevat ja väljaminevat dokumenti. Visuaalne analüüs võib loomulikult näidata nende puudumist, kuid see teave ei anna midagi protsessi edasiseks täiustamiseks, kuna need dokumendid on olemas.

Teine rõhutatav aspekt on ideaalse protsessi tundmine. Protsessi graafilist diagrammi vaadates saab teatud järeldusi mõne vajaliku elemendi puudumise kohta teha ainult praktilise kogemuse ja parimate tööstuslahenduste teadmiste, teiste ettevõtete kogemuste ja standardnõuete põhjal. Sellise kogemusega ekspertide leidmine ja isegi protsessikirjelduste tähistuste tundmine on üsna keeruline. See asjaolu piirab ka visuaalse analüüsi tõhusust.

Olles teinud sissejuhatavad märkused, käsitleme graafiliste protsessiskeemide analüüsi peamisi lähenemisviise. Pange tähele, et kõiki alltoodud analüüse saab teha ilma graafilisi diagramme kasutamata.

Esiteks saab protsessi diagrammi analüüsida sisendite ja väljundite osas. Sisend/väljundanalüüs koosneb kahest osast:

  1. Sisendnõudluse analüüs/väljundnõudluse analüüs.
  2. Kasutamata väljundite analüüs.

Sisendvajaduse analüüs viiakse läbi järgmiselt. Protsessi iga funktsiooni uuritakse järjestikku ja analüüsitakse selle sisu. Määratakse selleks vajaliku teabe koosseis. Kontrollitakse, kas see teave on sissetulevates dokumentides. Kui üheski dokumendis vajalikku teavet ei ole, võib see tähendada, et funktsiooni täitmiseks vajalik dokument on puudu. Määratud algoritmi illustratsioon on näidatud joonisel fig. 5.

Riis. 5. Sisendite vajaduse tuvastamine

Analüüs viiakse läbi sarnaselt materiaalsete sisendite, personali ja infrastruktuuri kohta.

Ilmselgelt, kui protsessi mõnes osas leiame sisenddokumendis vea, on vaja määrata funktsioon, mille jaoks see väljund on. Selliste funktsioonide (protsesside) otsimine mudelskeemide abil on vaevalt võimalik. Lihtsam on intervjueerida vastavaid esinejaid ja leida vajaliku teabe tarnijaid. Järgmisena uurige välja, miks seda teavet ei dokumenteerita ega edastata selle saamisest huvitatud ametnikule. Seda illustreerib joonis fig. 6.

Riis. 6. Väljundite vajaduse tuvastamine

Kasutamata väljundi analüüs tähendab protsessi (funktsiooni) nende väljundite leidmist, mida teised protsessid (funktsioonid) ei kasuta. Praktika näitab, et ettevõtetes on päris palju dokumente, mis küll genereeritakse, kuid mida edaspidi kas ei kasutata või kasutatakse formaalselt. Viimane juhtum tähendab, et dokumendi saab ette valmistada, sihtkohta toimetada ja siis lihtsalt vastavasse kausta sattuda ja seal aastaid tolmu koguda. Sellised dokumendid võib julgelt liigitada kasutamata. Vähemalt tuleks neile tähelepanu pöörata ja võimalusel neist lahti saada.

Kasutamata väljundite leidmiseks looge järgmine tabel:

Tabel 6. Kasutamata protsessiväljundite leidmine

Kasutamata dokumentide tuvastamiseks on vaja kogu organisatsioonis järjepidevalt jälgida kogu dokumentide liikumise ahelat. Lähtepunktiks võetakse protsessifunktsioon, mille väljundis kõnealune dokument esimest korda ilmub. Järgmisena analüüsitakse järjestikku kõiki selle töötlemise, kasutamise ja salvestamisega seotud funktsioone. Praktikas, et mõista, kas dokumenti kasutatakse või mitte, tuleb kohtuda vastavate inimestega ja analüüsida nende tegevust. Kasutamata dokumentide tuvastamisel tuleb järjepidevalt üle vaadata kõik protsessi funktsioonid ja väljunddokumentatsioon.

Vaatleme protsessifunktsioonide graafilise analüüsi võimalusi. See võimaldab teil tuvastada:

  • vajalike funktsioonide puudumine;
  • mittevajalike funktsioonide olemasolu;
  • funktsioonide dubleerimine.

Vajalike funktsioonide puudumise analüüs viiakse läbi eksperdi teadmiste põhjal, kuidas protsess peaks olema korraldatud, et tagada selle tõhus toimimine. Sellise analüüsi näide on näidatud joonisel fig. 7.

Riis. 7. Protsessimudelis puudub nõutav funktsioon

Võite anda soovitusi selle kohta, millised funktsioonid peavad protsessis olema. IDEF0 tähistusega koostatud tipptaseme mudelite puhul on need planeerimise, arvestuse, kontrolli ja otsuste tegemise funktsioonid. IDEF3 (ARIS eEPC) formaadis koostatud madalama taseme mudelite puhul on mitmeid olulisi funktsioone, mida ei tohiks mudeli ehitamisel unustada:

  • juhtimisfunktsioonid: sissetuleva kontrolli, statistilise protsessi juhtimine;
  • eriolukordades täidetavad funktsioonid;
  • mittevastavate toodete töötlemise funktsioonid;
  • protsessi faktilise teabe salvestamise funktsioonid.

Vaatame juhtimisfunktsioone. Joonisel fig. Joonisel 8 on näide protsessist, mille käigus lisatakse täiendavalt kaks sellist funktsiooni. Esimene viib läbi valikulise sissetuleva kontrolli ja selle tulemused dokumenteeritakse - joonisel fig. Joonisel 8 on dokument “Sissetuleva kontrolli tulemused”. Funktsiooni täitmise tulemuste põhjal võib toimuda kaks alternatiivset sündmust: "Sisend ei vasta nõuetele" ja "Sisend vastab nõuetele". Esimesel juhul toimub üleminek funktsioonile "Protsessi omaniku otsuste tegemine". Seda tuleb kirjeldada kui eraldi juhtimisprotsessi. (Loomulikult on võimalik, et otsuse teeb protsessi elluviija.)

Riis. 8. Juhtimisfunktsioonide puudumine

Teine kontrollfunktsioon on oma olemuselt statistiline. Protsessi väljundeid kontrollitakse kohapeal. Kontrolli tulemused registreeritakse dokumendis “Statistilise kontrolli tulemused” ja neid tuleks edaspidi kasutada protsessi juhtimiseks.

Reeglina unustatakse protsesside kirjeldamisel sageli ära erinevad hädaolukorrad ja tegevused nende tekkimisel. Selliste protsessiskeemide väärtus väheneb oluliselt. Hädaolukorra kuvamise näide on näidatud joonisel fig. 9.

Riis. 9. Funktsiooni puudumine hädaolukordade lahendamiseks

Joonisel fig. 9 eeldatakse, et pärast protsessi esimese funktsiooni täitmist on võimalik hädaolukord. Seda tuleb töödelda. Selleks sisaldab protsess funktsiooni “Emergency Situation Processing”, kahte uut sündmust ning eksklusiivse ja tavalise “OR” loogilisi sümboleid.

Protsessiskeemidel võivad puududa funktsioonid mittevastavate toodetega töötamiseks (teenused, dokumendid). Joonisel fig. 10 on sellise protsessi näide. Faktilise teabe salvestamise funktsioonid on väga olulised, kuna võimaldavad koguda protsessi parameetrite kohta juhtimisinfot, mille abil saab seda analüüsida ja täiustada. Teoreetilisest vaatenurgast on vaja iga funktsiooni tulemused kirja panna. Praktikas on vaja koguda seda faktilist teavet, mille kasutamine on tulevikus soovitatav.

Riis. 10. Funktsiooni puudumine nõuetele mittevastavate toodete töötlemiseks

Toome lihtsaima näite protsessi täitmisparameetrite registreerimise puuduva funktsiooni kohta (vt joonis 11).

Riis. 11. Funktsiooni puudumine faktilise teabe salvestamiseks protsessi kohta

Graafilist protsessiskeemi tuleks kontrollida üleliigsete funktsioonide osas. See analüüs viiakse läbi järgmise algoritmi abil. Kõiki protsessi funktsioone vaadeldakse järjestikku ja analüüsitakse igaüht neist. Esitatakse küsimus: "Mis juhtub, kui jätame selle funktsiooni protsessist välja?" Võib esineda olukordi, kus see sisaldab funktsioone, mida pole vaja. Sa pead neist lahti saama.

Graafiliste protsessiskeemide analüüsi käsitleva alajaotuse lõpetuseks keskendume funktsioonide dubleerimise analüüsile. Sellise analüüsi näide on näidatud joonisel fig. 12.

Riis. 12. Protsessi funktsioonide dubleerimise analüüs

Joonisel fig. 12 näitab kahte erinevat protsessi. Neid saab läbi viia erinevates osakondades. Vaadeldakse kahte funktsiooni: "protsessifunktsioon 1" ja "protsessifunktsioon 2". Nende nimed võivad oluliselt erineda. Nende funktsioonide väljundid on samuti erinevad: “dokument 1” ja “dokument 2”. Kuidas dubleerimist tuvastada? Nende kahe funktsiooni väljundeid tuleks analüüsida järgmiselt.

  • igas dokumendis sisalduva teabe analüüs;
  • iga dokumendi tarbijate analüüs;
  • dokumentides sisalduva teabe alusel tehtud otsused.

Joonisel fig. Jooniselt 12 on näha, et mõlemad dokumendid sisaldavad sama "teavet A". See võib tähendada, et kõnealused funktsioonid dubleerivad üksteist täielikult või osaliselt. Vähemalt tasub neile suurt tähelepanu pöörata. Kuidas tuvastada funktsioonide dubleerimist praktikas? On ilmne, et protsesside funktsioone pole võimalik omavahel võrrelda. Kõigepealt on vaja koostada dubleerimises “kahtlustatavate” funktsioonide loend. Seda tüüpi teavet saab töötajate ja osakonnajuhatajatega tehtud intervjuudest.

Lisaks peaks üsna pikka aega protsessidega tegelenud analüütikul olema eelinfo funktsioonide võimaliku dubleerimise kohta.

Kokkuvõtteks märgime, et graafiliste protsessiskeemide analüüs peaks suuresti põhinema tervel mõistusel ja töökogemusel.

Protsessi näitajate mõõtmine ja analüüs

Protsessi näitajate mõõtmine ja analüüs on olulised vahendid protsesside täiustamise võimaluste leidmiseks. Nagu eespool mainitud, saab protsessi iseloomustada mitme näitajate rühmaga:

  • protsessi indikaatorid;
  • protsessi tootenäitajad;
  • töötlema klientide rahulolu näitajaid.

Protsessi indikaatoreid saab defineerida kui arvväärtusi, mis iseloomustavad protsessi enda kulgu ja sellega kaasnevaid kulusid (aeg, rahalised, ressursid, inimkulud jne). Näitajad võivad olla absoluutsed ja suhtelised (taandatuna teenuste mahule, hooajalistele kõikumistele, tariifide muutustele ja muudele välisteguritele, mis ei sõltu auditeeritava protsessi juhtimisest).

Toote (teenuse) näitajad on numbrilised väärtused, mis iseloomustavad toodet (teenust) protsessi tulemusena (teenuste absoluutne maht, teenuste maht võrreldes tellitu või nõutuga, vigade ja tõrgete arv teenuse osutamisel , pakutavate teenuste valik, osutatavate teenuste valik vastavalt vajadusele jne. d).

Protsessi klientide rahulolu näitajad on arvväärtused, mis iseloomustavad kliendi rahulolu astet protsessi tulemustega (väljund, teenindus jne). Sel juhul tuleb eristada tarbija rahulolu (sisemine ja väline) protsessi väljundiga ning lõpptarbija rahulolu saadud toote või teenusega.

Joonisel fig. 13 näitab protsessiindikaatorite lihtsaimat klassifikatsiooni.

Riis. 13. Protsessi näitajate klassifikatsioon

Me ei võta arvesse protsessi kvalitatiivseid hinnanguid, näiteks juhi hinnangut, et "protsess on halvasti juhitud", kuna nende näitajate põhjal on võimatu teha teadlikke juhtimisotsuseid.

Protsessi kvantitatiivsed näitajad jagasime kahte rühma: absoluutsed ja suhtelised. Absoluutnäitajate hulka kuuluvad: protsessi teostamise aeg, tehnilised näitajad, kulu- ja kvaliteedinäitajad. Suhtelisi näitajaid saab arvutada absoluutsete näitajate põhjal, moodustades nende vahel erinevaid seoseid.

Vaatame lähemalt protsessi absoluutseid tulemusnäitajaid.

Protsessi täitmise aja indikaatorid

Esimene indikaatorite rühm sisaldab protsessi täitmise aja indikaatoreid:

  • protsessi kui terviku keskmine täitmise aeg;
  • keskmine seisakuaeg;
  • üksikute protsessifunktsioonide keskmine täitmise aeg;
  • teised.

Protsessipõhise lähenemise rakendamise esimeses etapis tuleks arvesse võtta lihtsamaid näitajaid, näiteks protsessi kui terviku täitmisaega. Üksikasjalikumas analüüsis võite võtta arvesse selliseid näitajaid nagu seisakuaeg, üksikute protsessifunktsioonide täitmise aeg jne. Kuidas selliseid näitajaid mõõta? Selleks on vaja välja töötada ja juurutada süsteem üksikute protsessifunktsioonide täitmisaja registreerimiseks. Nendel töökohtadel, kus see on asjakohane, tuleb salvestada teave funktsiooni alustamise ja lõpetamise hetke kohta. Selleks saab kasutada erinevaid registreerimisvorme, näiteks saabuvate dokumentide laekumise logisid jne. Teistel töökohtadel saate kasutada standardseid keskmise valmimisaja hinnanguid. Lihtsaim viis seda teha on järgmine.

Arvutatakse funktsiooni poolt toodetud toodete maht (teenused, töödeldud dokumendid). Järgmisena jagatakse kogu tööaeg arvutatud toodete arvuga. Saame funktsiooni keskmise täitmisaja. Olukord on keerulisem, kui üks esineja täidab mitut funktsiooni. Sel juhul saate kasutada erinevaid kaalukoefitsiente, mis määravad erinevate ülesannete jaoks esineja tööaja jaotuse struktuuri.

Loomulikult ei ole protsessi ajanäitajate arvutamine, nagu teisedki, eesmärk omaette. See peaks andma teavet, mis võimaldab teha otsuseid protsessi parandamiseks. Lihtsaim, kuid väga oluline näide on kliendi taotluse töötlemisaja arvutamine.

Kui kliendid ei ole selle protsessi pikkusega rahul, jääb organisatsioon neist tõenäoliselt ilma.

Joonisel fig. Joonisel 14 on kujutatud skeem lihtsa lineaarse protsessi täitmisaja arvutamiseks.

Riis. 14. Protsessi aja arvutamise näide

Protsessi tehnilised näitajad

Tehnilised näitajad peaksid sisaldama neid näitajaid, mis iseloomustavad protsessi läbiviimise tehnoloogiat, kasutatavaid seadmeid, tarkvara, keskkonda jne. Ilmselt on tehnilised näitajad erinevate tööstusharude ettevõtete protsesside puhul erinevad. Samal ajal saab tuvastada mitu indikaatorit, mis on mõõdetavad mis tahes protsessi jaoks:

  • töökohtadel teostatavate protsessifunktsioonide arv;
  • protsessipersonali arv, sh juhid ja spetsialistid;
  • tehingute arv perioodi kohta;
  • automatiseeritud tööjaamade arv;
  • - teised.

Tehnilised näitajad peegeldavad suuresti organisatsiooni efektiivsust ja neid saab kasutada protsessi võrdleva analüüsi läbiviimisel konkureerivate organisatsioonide protsessidega. Reeglina näeb eriti silmatorkav välja sama tööstusharu kodumaiste ja välismaiste ettevõtete võrdlus. Näiteks selline personaliarvu võrdlus näitab, et sarnaste protsesside läbiviimiseks kasutavad arenenud riikide organisatsioonid kolm kuni viis korda vähem töötajaid kui kodumaised. Tuleb märkida, et protsesside tehniliste näitajate absoluutväärtuses võrdlemine on enamasti väheinformatiivne. Huvitavamaid andmeid analüüsiks annab mitme protsessi suhteliste näitajate arvutamine. Seda arutatakse hiljem.

Tehnilised näitajad on aluseks paljude spetsiifiliste protsessinäitajate arvutamisel, nagu toodang töötaja kohta, protsesside automatiseerituse aste jne. Tuleb meeles pidada, et oluline ei ole näitajate kogum ise, vaid võime teha otsuseid. selle aluseks protsessi täiustamiseks.

Protsessi kulunäitajad

Protsessikulu indikaatorid on üks olulisemaid näitajate rühmi. Kulunäitajad võib jagada mitmeks rühmaks:

  • kogu protsessi maksumus;
  • protsessi kulunäitajad:
    • esinejate tööjõukulud;
    • seadmete ja immateriaalse põhivara amortisatsioon;
    • soojus- ja energiakulud;
    • sidekulud;
    • teabe hankimise kulud;
    • esitajate kvalifikatsiooni tõstmise kulud;
    • teised;
  • protsessitoodete maksumuse näitajad:
    • tooraine ja materjalide maksumus;
    • tööjõukulud;
    • seadmete amortisatsioon;
    • muud kulud.

Peab ütlema, et protsessi kogumaksumuse korrektne arvutamine ja analüüs eeldab vastavate tehnikate kasutamist. Tänapäeval on protsessikäsitluse seisukohalt adekvaatseim ABC kuluanalüüsi tehnika. See põhineb:

  • organisatsiooni protsessides kasutatavate ressursside määramine;
  • protsessioperatsioonide määratlemine;
  • kulude jaotamise objektide määramine - protsessi väljundid (tooted, teenused, teave);
  • kvantitatiivse seose “ressursid – toimingud” ja “toimingud – valmistooted” näitajate määramine ja arvutamine;
  • ressursside maksumuse ülekandmine protsessi toimingute kuludesse;
  • tegevuskulude ülekandmine valmistoodete maksumusele.

ABC meetodi alusel saab arvutada protsessi maksumuse. Selle meetodi praktiline rakendamine on tehniliselt keeruline, pikk ja kulukas projekt. Enne selle teostamist peab iga organisatsioon analüüsima ABC-meetodi kasutamise otstarbekust. Meie arvates on protsessipõhise lähenemise juurutamise esimeses etapis organisatsioonis selle meetodi kasutamine kohatu.

Praktikas on protsessi kui terviku maksumust raske kindlaks määrata. Protsessi täiustamiseks on aga olulised mitte absoluutsed, vaid konkreetsed ja suhtelised näitajad ning nende muutumise dünaamika, mis kajastavad parenduste edenemist. Joonisel fig. Joonisel 15 on näide kulunäitajate muutustest protsessi täiustamisel.

Riis. 15. Kulunäitajate muutus koos protsessi täiustamisega

Iga protsessi analüüsimisel tuleks kindlaks määrata piiratud kogum kulunäitajaid, mis toimivad selle paranemise/ halvenemise näitajatena. Näiteks hõlmavad sellised näitajad:

  • palgafond (protsessi paranedes võib kaasneda personali vähenemine ja/või tööviljakuse tõus);
  • energiakulud (mitte protsessienergia, energiasääst);
  • remondi- ja hoolduskulud (seadmete parem ja õigeaegne hooldus toob kaasa remondi kogumaksumuse vähenemise);
  • kaotused abielust;
  • teised.

Kuidas süstematiseerida protsessi kulunäitajate valimise ülesannet? Soovitame teil hoolikalt analüüsida selle komponente ja iga komponendiga seotud kulusid. Riis. 16 illustreerib seda lähenemist.

Riis. 16. Protsessi kulunäitajate tuvastamine

Näitajate mõõtmiseks tuleb välja töötada sobivad meetodid, sealhulgas töökirjeldused, et koguda faktilist teavet protsessi kulude, selle töötlemise ja kasutamise kohta.

Protsessi kvaliteedinäitajad

Kvaliteedinäitajad on kõige olulisem protsessi iseloomustavate näitajate rühm. Mida tuleks mõista protsessi kvaliteedi all? Meie arvates on see tema võime rahuldada oma klientide vajadusi etteantud ulatuses minimaalsete ressursside kuluga. Pange tähele, et protsessi kvaliteedi määramise põhiaspektiks on kliendikesksus. Kunstlikult loodud protsesside kvaliteedinäitajad, mis on lahutatud kliendi vajadustest, ei saa olla tõelise täiustamise vahendiks.

Protsessi kvaliteedinäitajad hõlmavad järgmist:

  1. Protsessi toodete defekti määr.
  2. Protsessitoodete tagastamiste ja kaebuste arv.
  3. Klientidelt laekunud kaebuste ja kaebuste arv teenuse kvaliteedi kohta.
  4. Mittetäielike (spetsifikatsioonidele mittevastavate) saadetiste arv.
  5. Valmistoodete ohutus.
  6. Hädaolukordade arv, mis nõudsid tippjuhtkonna kiiret sekkumist.
  7. Protsessi võime kiiresti kohaneda muutuvate klientide nõudmistega.
  8. Protsessi võime säilitada oma parameetreid välistingimuste muutumisel (protsessi stabiilsus, minimaalsed kõikumised).
  9. Protsessi sõltumatus personali muutustest.
  10. Protsessi kontrollitavus.
  11. Protsessi paranemisvõime.

Näitajaid 1–6 on üsna lihtne mõõta. Vajalik on välja töötada meetodid asjakohase teabe kogumiseks ja töötlemiseks. Näitajad 7–10 on intuitiivsed, kuid nende praktiline mõõtmine on keeruline. Nende näitajate muutusi saate jälgida, analüüsides protsessitõrkeid, mis ilmnevad erinevates välistes ja sisemistes hädaolukordades. Selliste rikete põhjuste väljaselgitamine aitab tuvastada protsesside täiustamise valdkondi.

Tõhusalt toimiva protsessiindikaatorite süsteemi ülesehitamine nõuab palju aega ja vaeva. Iga ettevõte peab looma sellise süsteemi, võttes arvesse oma protsesside eripära. Tuleb märkida, et protsessiindikaatorite süsteem peaks arenema koos protsessiga: selle paranedes tuleks kasutada üha keerukamaid näitajaid.

Vaatleme protsessi suhtelisi tulemusnäitajaid. See rühm arvutatakse absoluutsete protsessinäitajate põhjal. Protsessi täiustamise eesmärgil kasutamise seisukohalt on need näitajad väga olulised.

Ajutine

Suhtelise täitmisaja näitajad hõlmavad järgmist:

  • "plaani/tegelikud" näitajad:
    • planeeritud protsessi täitmise aeg/tegelik protsessi täitmise aeg;
    • planeeritud funktsiooni täitmise aeg / tegelik funktsiooni täitmise aeg;
    • keskmine protsesside täitmise aeg / konkurendi keskmine protsesside täitmise aeg;
    • kliendi poolt nõutav teenindusaeg/tegelik klienditeeninduse aeg;
  • konkreetne:
    • protsessi teostamise aeg/protsessipersonali arv;
    • protsessi täitmise aeg / protsessi funktsioonide arv.

Maksumus

Suhteliste kulude näitajad hõlmavad järgmist:

  • "plaani/tegelikud" näitajad:
    • protsessi planeeritud maksumus/protsessi tegelik maksumus;
    • planeeritud ressursikulud/tegelikud ressursikulud;
    • planeeritud protsessikulude vähendamine/tegeliku protsessikulude vähendamine;
    • planeeritud remondikulud/tegelikud remondikulud.
  • võrdlus teise protsessiga:
    • protsessikulu/konkurendi protsessikulu;
    • protsessipersonali makse suurus/konkurendi protsessipersonali makse suurus;
  • konkreetne:
    • protsessi tasuvus = protsessi kasum/protsessi maksumus;
    • protsessi käibevara tasuvus = protsessi kasum / kasutatud käibevara maht;
    • toodang töötaja kohta = protsessi toodangu maht/töötajate arv;
    • protsessi kapitali tootlikkus = toodangu maht/põhivara väärtus;
    • protsessi käibevara käive = tulude summa/protsessi käibevarade keskmised jäägid;
    • üldkulude osa = üldkulude summa/protsessi maksumus.

Lisaks ülaltoodule saab määrata ja arvutada palju muid suhtelisi protsessikulude näitajaid ning kasutada tuleks finantsjuhtimise tehnikaid.

Tehniline

Suhtelised tehnilised näitajad hõlmavad järgmist:

  • "plaani/tegelikud" näitajad:
    • planeeritud seisakute arv/tegelik seisakute arv;
    • planeeritud tehingute arv/tegelik tehingute arv;
  • võrdlus teise protsessiga:
    • protsessipersonali arv/konkurendi protsessipersonali arv;
    • automatiseeritud protsessi tööjaamade arv/konkurendi automatiseeritud protsessi tööjaamade arv;
  • konkreetne:
    • personali koormuse määr = kogu tööaeg protsessi funktsioonide täitmiseks / kõigi töötajate kogu tööaeg;
    • automatiseerituse aste = automatiseeritud protsessi funktsioonide arv / protsessi funktsioonide koguarv;
    • kontoripinna suurus töötaja kohta;
    • personaalarvutite arv töötaja kohta.

Kvaliteedinäitajad

Protsessi kvaliteedi suhtelised näitajad on järgmised:

  • "plaani/tegelikud" näitajad:
    • planeeritud defektide määr/tegelik defektide määr;
    • planeeritud kaebuste arv/protsessi klientide kaebuste tegelik arv;
    • planeeritud toote tagastamiste arv/tegelik toote tagastamiste arv;
    • aruandeperioodi hädaolukordade arv/eelmise perioodi eriolukordade arv;
  • võrdlus teise protsessiga:
    • protsessitoodete defektsuse määr / konkurendi protsessitoodete defekti määr;
    • protsessikaebuste olemasolu/konkurendi protsessikaebuste olemasolu;
  • konkreetne:
    • kaebuste arv/klientide koguarv.

Organisatsioon peab teatud arenguetapis reguleerima oma põhilisi äriprotsesse, s.t. kirjeldada nende rakendamise edenemist kohalikes määrustes. Selline dokument nagu määrus hõlmab samm-sammult protsessi, millega töötatakse korraga mitmes osakonnas. Vaevalt, et sekretärile usaldatakse keeruka tootmisprotsessi regulatsioonide väljatöötamine, kontoritöö puhul aga üsna tõenäoline.

Käesolevas artiklis vaadeldakse eeskirju kui dokumendi liiki, selle ülesehitust ja põhiandmeid ning tuuakse ka näide koolieelse lasteasutuse ühe olulisema protsessi – dokumentide järgi ülesannete täitmise jälgimise – regulatsioonidest.

MÄÄRUSED DOKUMENDINA

Meie sõnastik

Määrused äriorganisatsioonis on organisatsiooniline ja haldusdokument, mis kirjeldab konkreetset äriprotsessi samm-sammult alates selle algusest kuni valmimiseni.

Eeskirjad on rangelt individuaalsed ja võivad kehtida ainult organisatsioonile, kes on need enda jaoks heaks kiitnud. Seega kasutatakse kontoritöö juhiste koostamisel tavaliselt GOST R 6.30-2003 “Ühtsed dokumentatsioonisüsteemid”. Organisatsiooni- ja haldusdokumentatsiooni ühtne süsteem. Nõuded dokumentide koostamisele" ja metoodilised soovitused GOST R 6.30-2003 rakendamiseks. Nende dokumentide põhjal koostatakse sisejuhised nii väikeses kaupluses kui ka föderaalse taseme JSC-s. Kuid näiteks ühes organisatsioonis kehtestatud sisedokumentide edastamise kord võib olla teisele täiesti sobimatu.

Olles tutvunud reglemendiga, peab osakonna uus töötaja mõistma, millised on tema ülesanded ja kiiresti protsessi kaasama.

Tavaliselt töötavad äriprotsesside regulatsioonid välja organisatsiooni kutsutud konsultatsioonifirma esindajad. Kuid nad ei saa seda teha ilma töötajate abita, kes neid protsesse iga päev läbi viivad.

Kui äriprotsessi (seda protsessi nimetatakse otsast lõpuni) on kaasatud mitu struktuuriüksust, võib üks määrus asendada pika sisemise kirjavahetuse. Ühe osakonna töötaja ei saa ju alluda teise osakonna juhile, miks peaks ta siis teatepulga kätte võtma ja mingeid toiminguid tegema ilma vahetu juhi korralduseta? Tavatingimustes peavad osakonnajuhatajad pidama kirjavahetust. Kui määrus on olemas, siis kaasatakse erinevate osakondade töötajad protsessi elluviimisse, ootamata juhiseid “ülalt”.

Millised protsessid on reguleeritavad?

Kõigi tööprotsesside jaoks eraldi regulatsioonide olemasolu on kahtlemata väga mugav. Sellel medalil on aga ka tagakülg, nimelt:

  • reguleerimine nõuab tõsiseid rahalisi investeeringuid: head konsultandid on kallid, nagu ka nende enda töötajate tööaeg;
  • igasugune protsess areneb pidevalt: tekivad uued tehnilised töötingimused, uued, erineva ettevalmistusega inimesed tulevad seda läbi viima ja täna koostatud protsessiskeem võib aasta pärast tundmatuseni muutuda. Seda tuleb ka jälgida, mis tähendab uusi kulusid;
  • lähenemine protsessi läbiviimisele, kus "samm kõrvale võrdub põgenemisega" ei julgusta töötajaid initsiatiivi näitama ja lõppkokkuvõttes ei suuda keegi protsessi paremini optimeerida kui need, kes sellega otseselt tegelevad;
  • Määruste rakendamine toob peaaegu garanteeritult kaasa töötajate, nii protsessis otseste osalejate kui ka arvukate „kaastundjate“ vastupanu. Vastupanu ületamine on regulatsioonide rakendamise terve etapp, mis nõuab nii aega kui ka materiaalseid ressursse.

Seega on standardprotsessid eeskätt reguleeritavad. Need viiakse alati organisatsioonis läbi, olenemata välisest olukorrast. Konkreetses organisatsioonis reguleeritavate protsesside loetelu koostatakse rangelt individuaalselt, lähtudes paljudest teguritest.

MÄÄRUSE STRUKTUUR JA SISU

Reeglina koosnevad eeskirjad järgmistest põhiosadest:

  1. Üldsätted.
  2. Mõisted, definitsioonid, lühendid.
  3. Protsessi kirjeldus.
  4. Vastutus.
  5. Kontrolli.

Peatükk

Üldsätted

  • Määruse eesmärk ( Käesolev määrus määrab kindlaks korra...);
  • kohaldamisala: organisatsiooni objektid või töötajad, keda määrus mõjutab;
  • normatiivdokumendid, mille alusel määrustik välja töötati (olemasolul);
  • määruste kinnitamise, muutmise ja tühistamise kord

Mõisted, definitsioonid, lühendid

Määruste tekstis kasutatud mõistete määratlus ja lühendite selgitus.

Mõisted on loetletud tähestikulises järjekorras. Igaüks neist on kirjutatud uuele reale ainsuses ja selle määratlus on näidatud mõttekriipsuga ilma sõna "see". Mõistete allikana on soovitatav kasutada seadusandlikke akte, riiklikke standardeid ja muid regulatiivseid dokumente

Protsessi kirjeldus

Protsessi samm-sammult kirjeldus. Mugavuse huvides on see jaotis jagatud alajaotisteks, millest igaüks vastab protsessi järgmisele etapile. Jaotises näidatakse täitmisega seotud töötajad, kirjeldatakse tegevust ja tulemust

Vastutus

Protsessis osalejate vastutus eeskirjade (distsiplinaar-, haldus-, kriminaalkorras) mittejärgimise eest. Viimane puudutab tavaliselt keerulisi tootmisprotsesse, mis on seotud riskidega töötajate tervisele ja elule

Kontrolli

Näidustus Täisnimi eeskirja täitmise järelevalve eest vastutav ametnik, samuti vajadusel kontrollivahendid

MÄÄRUSE PÕHIANDMED

Dokumendi peamised üksikasjad hõlmavad järgmist:

  • organisatsiooni nimi;
  • dokumendi kuupäev ja number, koostamise koht;
  • kinnitustempel;
  • dokumendi nimi;
  • dokumendi tekst;
  • taotlus (kui on);
  • viisa kinnitamine.

Muide

Loetletud andmete registreerimise nõuded on kehtestatud GOST R 6.30-2003-ga. Metoodilised soovitused GOST R 6.30-2003 rakendamiseks selgitavad ja täpsustavad selle standardi rakendamise ja kohaldamise korda.

ÄRIPROTSESSI MUDEL

Äriprotsessi mudelit saab kasutada eeskirjade lisana. Seda on tavaks kujutada graafiliselt (vt joonist), kuid lubatud on ka tabeli koostamine ja protsessi isegi suuline kirjeldamine. Äriprotsesside graafilised mudelid luuakse spetsiaalse tarkvara abil.

See, mis esmapilgul tundub joonte ja geomeetriliste kujundite keerukusena, kujutab endast tegelikult kindlat tegevuste järjekorda konkreetse protsessi, meie puhul kontoritöö protsessi läbiviimisel. Äriprotsesside diagrammi on palju lihtsam mõista kui samade määruste teksti. See näitab selgelt, kes ja kus iga etappi alustab, kuidas nad selle lõpetavad ja kellele annab teatepulga protsessi kallal edasi.

Äriprotsessi graafiline mudel “Dokumendi kavandi kinnitamine” esitab sellised äriprotsessi põhiparameetrid nagu sisendid ja väljundid, kliendid ja osalejad. Iga uus töötaja osaleb mudelit vaadates kiiresti teatud etapis oma protsessi elluviimises ja teab, kuidas käituda igas sellega seotud tööolukorras.

MÄÄRUSEGA TÖÖTAMISE KORD

Määruste kallal töötamine ei erine mis tahes muu organisatsioonilise ja haldusdokumendi kallal töötamisest: esmalt koostatakse dokumendi kavand, mis lepitakse kokku huvitatud ametnikega, seejärel kinnitab selle organisatsiooni juht või tema volitatud isik. Lõpuks tutvuvad protsessis osalejad reglemendiga allkirja vastu ja saavad nendest koopiad.

Eeskirju saab kinnitada mitmel viisil:

  1. otse (juht allkirjastab dokumendi oma käega);
  2. kaudselt (korralduse andmisega) (vt näide 1). Sel juhul lisatakse kinnitustemplile tellimuse registreerimisandmed.

Näide 1

Määrus kinnitamise ja jõustumise kohta
äriprotsesside regulatsioonid


(LLC "Perspektiiv")

TELLIMINE

23.07.2014 nr 456-Pr

Moskva

Äriprotsesside regulatsioonide kinnitamise ja rakendamise kohta

Perspektiva OÜ paberimajanduse parandamiseks

TELLIN:

1. Kinnitada ja jõustada alates 01.08.2014 järgmiste äriprotsesside eeskirjad:

1.1. Dokumentide registreerimine ja arvestus.

1.2. Dokumendi täitmise kontroll.

1.3. Dokumentide säilitamine ja väljatoomine.

2. Määrata käesoleva korralduse punktis 1 nimetatud nõuete täitmise eest vastutavaks haldusdirektor A.V.

3. Büroo juhatajale Parshina V.K. tagama, et OÜ Perspektiva töötajad oleksid tutvunud käesoleva korraldusega allkirja vastu ning esitama kinnitatud eeskirjade koopiad Perspektiva OÜ struktuuriüksustele 30. juuliks 2014. a.

4. Jätan endale kontrolli selle korralduse täitmise üle.

Peadirektor Maksimov JAH. Maksimov

Tellimusega on tutvutud:

Legostajev A.V. Legostajev 24.07.2014

Parshina V.K. Parshina 24.07.2014

P.A. Karpenko

23-78

Äriprotsessi “Dokumendi täitmise kontroll” regulatsioonid on toodud näites 2.

Näide 2

Äriprotsessi reeglid “Dokumendi täitmise kontroll”

Piiratud vastutusega äriühing "Perspektiiv"
(LLC "Perspektiiv")

MÄÄRUS nr 7
äriprotsess "Dokumendi täitmise kontroll"

1. Üldsätted

1.1. Äriprotsessi „Dokumentide täitmise kontroll“ reglemendiga (edaspidi nimetatud eeskiri) määratakse Perspektiva OÜ-s (edaspidi nimetatud organisatsioon) dokumentidel põhinevate ülesannete täitmise järelevalve kord.

1.2. Reglemendi nõuded ja reeglid kehtivad Organisatsiooni kõikidele struktuuriüksustele.

1.3. Reglemendi kinnitab, muudab ja tühistab organisatsiooni peadirektor korraldusega.

1.4. Organisatsiooni töötajad on kohustatud teadma ja järgima Reglemendi nõudeid. Kõiki Organisatsiooni äsja tööle võetud töötajaid peavad struktuuriüksuste juhid kurssi viima Organisatsioonis dokumentide täitmise järelevalve kehtestatud korras.

2. Terminid, definitsioonid, lühendid

2.1. Määrustes kasutatakse järgmisi termineid ja määratlusi:

Dokument- andmekandjale salvestatud teave koos selle tuvastamist võimaldavate üksikasjadega.

Harjutus- juhi juhised.

Ülesanne- vaata ülesannet.

Täitja- organisatsiooni töötaja, kellele on usaldatud ülesande täitmine.

Kontrolli- toimingute kogum, mis tagab dokumendi õigeaegse täitmise.

Vastutav täitja- töötaja esinejate hulgast, kellel on õigus koordineerida teiste esinejate tööd. Resolutsioon näitab kõigepealt.

Resolutsioon- üksikasjad, mis sisaldavad ametniku juhiseid dokumendi täitmiseks. Sisaldab esinejate perekonnanimesid, initsiaale, tellimuse sisu (vajadusel), tähtaega, allkirja ja kuupäeva.

Juhendaja- otsuse teinud ametnik.

Tähtaeg- ülesande täitmise kalendrikuupäev. Dokumendi täitmise tähtaeg algab selle organisatsiooni büroos registreerimise päevast ja seda arvestatakse kalendripäevades. Dokumendid tuleb täita järgmiste tüüpiliste tähtaegade jooksul:

Alates konkreetsest täitmise kuupäevast - kindlaksmääratud tähtaja jooksul, kui organisatsioon sai dokumendi kätte hiljemalt kolm päeva enne määratud tähtaja möödumist;

Ilma konkreetse täitmiskuupäeva ja erimärkuste märkimata - 30 päeva jooksul;

Ilma konkreetset kuupäeva määramata, märgistusega "Kiire" või "Kohe" - kolme päeva jooksul;

Konkreetset kuupäeva määramata, märgistusega "Kohe" - 10 päeva jooksul.

3. Protsessi kirjeldus

3.1. Dokumendi esitamine kontrolliks.

3.1.1. Kõik registreeritud täitmist vajavad dokumendid kuuluvad kontrolli alla.

3.1.2. Dokumendi kontrolli alla võtmise aluseks on organisatsiooni peadirektori või tema asetäitja otsus.

Resolutsioonis öeldakse:

Dokumendi täitja;

Ülesande tähtaeg;

Vajadusel ülesande sisu.

3.1.3. Pärast otsusega dokumendi kättesaamist koostab peadirektori sekretär või peadirektori asetäitja sekretär (edaspidi nimetatud sekretärid) otsusega dokumendist skaneeritud koopia. Skannitud dokument paigutatakse kausta "Juhtimise all".

3.1.4. Töövõtjale saadetud meilisõnumile lisatakse dokumendifaili koopia.

3.1.5. Meilisõnumi parameetrites määrate ülesande täitmise tähtaja ja lubate võimaluse teavitada ülesande autorit selle kättesaamisest.

3.1.6. Pärast ülesandega elektroonilise teate saamist saadab täitja ülesande autorile teate selle kättesaamisest.

3.1.7. Kui töövõtja saab ülesande, mille sisu väljub tema pädevusest, on ta kohustatud sellest ülesande autorit teavitama ühe tööpäeva jooksul ülesande saamisest arvates. Ülesande autor, olles saanud sellise teate, esitab juhile dokumendi teiseks lahendamiseks.

3.2. Ülesande täitmine.

3.2.1. Töövõtja täidab talle pandud ülesande otsuses sätestatud tähtaja jooksul.

3.2.2. Kui ülesande täitmise viimane päev langeb puhkepäevale, tuleb dokument vormistada järgmisel tööpäeval.

3.2.3. Kui tööülesannet ei ole võimalik otsuses sätestatud tähtaja jooksul täita, on töövõtja kohustatud sellest enne tähtaja möödumist juhatajat teavitama ja selgitama viivitamise põhjust. Mõjuva põhjuse korral saab juht ülesande täitmise tähtaega pikendada.

3.2.4. Kui ülesande täitmise tähtaega pikendas juhataja, muudab ülesande autor elektroonilisel dokumendikaardil selle täitmise tähtaega.

3.3. Aruanne ülesande täitmisest.

3.3.1. Pärast ülesande täitmist koostab täitja täitmise akti, mis saadetakse ülesande autorile elektroonilise sõnumina. Ülesandearuanne peab olema informatiivne ja sisaldama konkreetset kirjeldust võetud toimingute ja meetmete kohta. Kui ülesande täitmiseks oli vaja dokumenti, märgitakse selle registreerimise andmed ülesande täitmise aruandesse.

3.3.2. Saanud ülesande täitmise akti, määrab ülesande autor elektroonilisele dokumendikaardile oleku “Lõpetatud”. Dokument eemaldatakse kaustast "Juhtimise all" ja asetatakse faili.

3.3.3. Kui ülesande autor ei ole otsuses märgitud tähtaja jooksul ülesande täitmise kohta aruannet saanud, saadab ta täitjale e-posti teel päringu, milles palub näidata ülesande täitmata jätmise põhjus. Ülesande täitmata jätmisest teatab ülesande autor juhile, lisades täitja selgitused. Mõjuva põhjuse korral saab juht ülesande täitmise tähtaega pikendada.

3.3.4. Kui ülesande täitmise tähtaega on juhataja pikendanud, muudab ülesande autor elektroonilisel dokumendikaardil tähtaega.

3.4. Ülesande täitmise aruande koostamine.

3.4.1. Sekretärid koostavad igakuiselt dokumentide alusel tööülesannete täitmise aruande, mille esitavad juhile.

Aruandes öeldakse:

Aruandeperioodiks määratud ülesannete koguarv;

Täidetud ülesannete arv;

Pikendatud tähtaegadega ülesannete arv;

Õigeaegselt lõpetamata ülesannete arv.

Kui on õigeaegselt täitmata ülesandeid, märgitakse ka nende ülesannete täitjate nimed.

4. Vastutus

Organisatsiooni töötajad, olenemata nende ametikohtadest, kannavad distsiplinaarvastutust käesoleva eeskirja nõuete mittekohase täitmise või mittejärgimise eest.

5. Kontroll

Eeskirjade täitmist jälgib Organisatsiooni haldusdirektor.