Affärsprocess hur man skriver korrekt. Hur man snabbt beskriver en affärsprocess. Förändra samtidigt som du behåller essensen

Skapandet av affärsprocesser börjar med deras beskrivning. Beskrivning av affärsprocesser kan göras på olika sätt. Var och en har både för- och nackdelar. Det finns tre typer av beskrivningar: text, tabellform och grafisk. Naturligtvis finns de sällan i sin rena form. I de flesta fall kombinerar vi dessa metoder i en eller annan form. Men om du fokuserar på, tar som utgångspunkt ett av 3 element - en beskrivning i text, tabeller eller ett diagram över en affärsprocess, så väljer du därmed en av beskrivningstyperna.
Att hantera affärsprocesser utan att beskriva dem är extremt svårt.

Textbeskrivning av affärsprocesser

Förmodligen det enklaste att implementera och vanligaste alternativet. Allt som händer i affärsprocessen beskrivs i ord, d.v.s. Som ett resultat får vi text. Att bygga affärsprocesser kräver att man beskriver ett ganska stort antal element och alternativ för utvecklingen av en affärsprocess, texten kan visa sig vara ganska krånglig. Jag minns verkligen processen, vars textbeskrivning tog 32 sidor och diagrammet - bara 3.

Fördelar med att beskriva affärsprocesser i text

• Det är väldigt enkelt att göra – det är bara att sitta ner och skriva.
• Kräver inga speciella färdigheter - de mörka tiderna är över, nu kan alla skriva :)

Minus

• Text är svår att bearbeta - att arbeta med uppsättningar av text är mycket svårt, eftersom vi måste hitta essensen gömd bakom orden.
• Det gör det svårt att uppfatta processen holistiskt – genom att läsa den andra sidan kan du redan glömma vad som stod på den första. Det är väldigt svårt att läsa en text som beskriver en komplex, förgrenad process. Man måste hela tiden gå tillbaka för att förstå vad det handlar om. Som ett resultat störs uppfattningen av bilden helt.
• I princip är det svårt att förstå - om texten är förberedd av en person utan skrivförmåga, kommer läsningen att förvandlas till tortyr. Alla har sitt eget språk och ibland kan det vara väldigt komplicerat. Har du stött på "dåliga" böcker? Beskrivningen av processen kan vara ännu värre :)
• Svår att strukturera och analysera – processen kan ha många utvecklingsvägar. Det innebär att vi, beroende på resultat, händelser och förutsättningar, utför olika åtgärder i processen. Föreställ dig nu hur det är att beskriva det i text. Det är väldigt svårt att upprätthålla en enkel struktur när du har dussintals "om" på en sida. Som ett resultat av detta kommer analysen att kräva enorma ansträngningar och ett enormt förarbete från dig.

Tips – använd strukturerade listor

Beskrivning av affärsprocesser i form av tabeller

Bordet är jättefint! Jag älskar bord. Du kan titta på dem i timmar... och inte hitta svaret på din fråga :) Skojar bara. Att beskriva ett företags affärsprocesser i form av länkade tabeller är faktiskt inte en så dålig idé. Åtminstone mycket bättre än textbeskrivningen. Den största svårigheten är att förbereda en bra tabellmall, i vilken faktiskt uppgifterna sedan kommer att matas in.

Fördelar med att beskriva affärsprocesser i text i form av tabeller

• Relativt lätt att förbereda – att förbereda mallen är inte så svårt. Huvudsaken är att det är klart för dem som ska fylla i. Dessutom låter alla kalkylbladsprogram (som Excel) dig lägga till beskrivningar i tabellceller. Använd denna möjlighet att förklara data.
• Det är relativt enkelt att fylla i mallen – återigen, om mallen är tydlig borde den inte vara för svår att fylla i. Detta kräver inga speciella färdigheter eller kunskaper.
• Förekomst av struktur - själva tabellen förutsätter redan någon form av struktur.
• Bekvämlighet med att behandla digital data - det är bäst att arbeta med siffror i en tabell. Så för den här typen av data är den här typen av beskrivning bäst lämpad. Data i en tabell, även text, är mycket bekvämare att jämföra och analysera.

Minus

• Inte kompakt - beskrivningen av stora processer, med alla de många delprocesserna och elementen, kommer att se ut som ett "ark". Det är svårt att kalla den här typen kompakt.
• Den nödvändiga detaljen saknas - för att tabellen ska få ett mer kompakt utseende måste mängden data begränsas. Det betyder att även om du skriver in text i en tabell så måste den begränsas. Detta innebär att det kanske inte är lätt att uppnå den nödvändiga detaljen.
• Det finns ingen uppfattningsintegritet - en stor mängd data bidrar inte till detta. Även om du behöver se data för en operation (underprocess) i en rad eller data av en typ i en kolumn, kan du inte tänka dig en bättre tabell.
• Svårt att visa grenar - samma problem som med text. Ett stort antal grenar, och, viktigare, utvecklingen av processen baserat på förgreningsförhållandena, är ganska svårt att visualisera.
• Kräver förberedelser – du behöver lägga tid på att förbereda en bra mall.

Tips - placera delprocesser, operationer i rader och data i kolumner. Detta gör det lättare att förstå. Använd relaterade tabeller istället för ett stort bord.

Beskrivning i form av ett diagram, affärsprocessmodell

Jag kommer inte att dra in katten i mars. En grafisk beskrivning av ett företags affärsprocesser, i form av ett diagram eller modell, är den bästa typen av beskrivning. De flesta experter har länge föredragit den grafiska typen av beskrivning. Se bara på för- och nackdelarna med denna typ.

Fördelar med att beskriva affärsprocesser i form av en modell

• Lätt att uppfatta - vår hjärna är designad på ett sådant sätt att vi uppfattar en bild snabbare än något annat. Därför är diagrammet mycket lätt att förstå. Hjärnan "fotograferar" schemat och bearbetar det på en omedveten nivå, många gånger snabbare än vårt medvetande. Diagrammet är lätt att uppfatta eftersom vi omedelbart ser elementens sammankopplingar.
• Perceptions integritet - 1 diagram är en modell av processen på en viss nivå. Detta innebär att diagrammet omedelbart ger oss en uppfattning om processen som helhet. I synnerhet om dess gränser, huvudelement osv. Om processen är detaljerad på flera nivåer, förblir diagrammen fortfarande sammankopplade.
• Nödvändig och tillräcklig detaljering - samtidigt kan ett relativt stort antal detaljer visas på diagrammet, utan att förlora kvaliteten på uppfattningen.
• En visuell visning av processens grenar och utvecklingsvägar - ett korrekt konstruerat diagram ger omedelbart en uppfattning om hur processen ska utvecklas i rätt version. Samt andra alternativ för utveckling av evenemang.
• Bekvämligheten med automatisering - många mjukvaruverktyg låter dig översätta diagram till programmeringsspråk, vilket avsevärt förenklar livet för mjukvaruutvecklare och implementerare.

Minus

• Kräver speciella färdigheter - du måste veta hur man bygger diagram korrekt. Kan olika notationer. Och ibland kan du till och med göra din egen uppsättning element som du kommer att använda för beskrivningar och regler.
• Relativt mer tid krävs för att utarbeta en beskrivning – en välkonstruerad processmodell ska vara enkel och begriplig. För att göra ett sådant här schema måste du spendera mycket tid. Vilken dåre som helst kan göra något komplicerat, men enkelhet kräver skicklighet;)

Investeringar i en grafisk typ av beskrivning lönar sig ganska bra.

Tips: 3-5 grafiska element (former) kan vara tillräckligt för att beskriva affärsprocesser.

Så småningom

Så småningom kommer du att använda alla typer av beskrivningar. Ett dokument som heter "Beskrivning av en affärsprocess..." kommer att innehålla ett grafiskt diagram, tabeller och text. Det här är okej. Men mitt råd till dig är att fokusera på grafiska modeller och undvika text. En bra modell behöver inte åtföljas av text. I de flesta fallen.
Skapandet av affärsprocesser börjar med deras beskrivning.

Beskrivning av ett företags affärsprocesser är en av metoderna för att bekämpa ineffektivitet. Alla företags aktiviteter kan beskrivas som summan av många processer som utförs sekventiellt och parallellt. När de väl har formaliserats på papper blir det lättare att planera dem och föreställa sig "hur det borde vara." Läs artikeln om hur du beskriver dem och se ett exempel på en beskrivning av affärsprocesserna för en finansiell tjänst.

Varför beskriva affärsprocesser

Varje företag råkar ut för olika förluster i sin verksamhet (tid, defekter, bristande ledning, missade möjligheter) och ådrar sig förluster.

Efter att ha beräknat mängden skada i slutet av året finns det ibland en stark önskan att gå tillbaka i tiden och rätta till ett misstag, att göra en del av arbetet annorlunda. Men du kan inte återvända till det förflutna, och hur ofta finns det fall när ett företag nästa år gör samma misstag? Fel som inte analyserats ordentligt och kommunicerats till personalen uppstår gång på gång och påverkar vinsten.

En av metoderna för att bekämpa ineffektivitet är införandet av ett processorienterat förhållningssätt och en beskrivning av företagets affärsprocesser. Alla företags aktiviteter kan beskrivas som summan av många affärsprocesser som utförs sekventiellt och parallellt.

Varför är detta nödvändigt?

1. När en kaotisk idé om ett företags verksamhet formas till affärsprocesser och formaliseras på papper, blir det kristallklart vilka åtgärder som utförs korrekt och i tid, vilka som behöver justeras och vilka som helt kan överges. Prickar - felgeneratorer - blir märkbara.
2. När de väl har formaliserats på papper blir det lättare att planera dem och föreställa sig "hur det borde vara."
3. Varje affärsprocess har en ägare och varje åtgärd i den tilldelas en anställd (grupp). Om ett fel upptäcks är det lätt att identifiera "skyldige" och tillsammans förhindra att det upprepas.
4. Med hjälp av de beskrivna affärsprocesserna är det mycket lättare att få nya medarbetare att komma igång. Och även om 60 % av teamet byter, kommer hotet mot verksamheten att vara minimalt.
5. Implementeringen av ett integrerat informationssystem åtföljs alltid av skrivning av affärsprocesser.
6. En verksamhet med de beskrivna processerna är ojämförligt enklare att skala. Öppna filialer (), divisioner, partnerskap, sälja franchiseavtal - alla möjligheter är öppna för dig.

Vad är en affärsprocess

En affärsprocess är en uppsättning åtgärder som måste utföras för att producera en produkt eller tillhandahålla en tjänst. I det här fallet utförs åtgärder inte kaotiskt, utan bibehåller en given sekvens.

Det är bekvämt att representera dem grafiskt i form av blockdiagram - flöden. Varje affärsprocess har konsumenter, oavsett om de är interna eller externa. Konsumenten ställer krav på affärsprocessen och slutresultatet. Konsumenten kan också påverka existensen av själva affärsprocessen. Vid ingången av varje kommer det att finnas ett krav (efterfrågan) från konsumenten, vid utgången - tillfredsställelsen av detta krav.

En affärsprocess har en ägare – en tjänsteman i företaget som ansvarar för resultatet av processen. I stora företag kan även en processledare utses – någon som sköter genomförandet av processen, men som inte är ansvarig för resultatet.

Konsumenter skulle till exempel vara finansdirektören och den kommersiella direktören. Resultatet blir summan av förfallen skuld vid periodens slut och det belopp som inkasserades från gäldenärer. Ägaren kommer att vara styrekonomen. Konsumenter kan ställa krav på processen, såsom verifieringsfrekvens, en uppsättning inkassoåtgärder och ett planerat returbelopp.

Affärsprocesser är:

1. Grundläggande.
2. Extra.
3. Chefer.

De viktigaste är de som skapar en produkt (en produkt produceras, en tjänst tillhandahålls). Utan deras implementering är existensen av ett företag omöjligt, så de kan inte elimineras, bara optimeras.

Hjälpåtgärder utförs parallellt med de viktigaste och behövs för att upprätthålla verksamheten i företaget. Dessa inkluderar personalval, löner, kvalitetskontroll etc. Källan till besparingar ligger i hjälpprocesser. De kan optimeras, synkroniseras, kombineras och ibland elimineras.

Styr affärsprocesser är den svåraste gruppen av processer att beskriva och den mest lämpade för optimering. De uppfyller kraven på styrning, planering och prognos samt företagsutveckling. Å ena sidan är management ett väldigt kreativt område, som inte alltid går att dokumentera. Men å andra sidan finns det en hel del processer inom förvaltningen som kan och bör formaliseras och optimeras. Detta. Till exempel:

1. Upprättande av en årlig budget.
2. Kassaflödesplanering.
3. Kontrollera potentiella partners osv.

De utgör en betydande del av förvaltningskostnaderna, så de måste analyseras och föras till det optimala resultatet.

Hur man beskriver affärsprocesser

Beskrivningen ska alltid börja med en lista över funktioner "som är" (vad som faktiskt utförs). Både för ett företag som för första gången möter en processansats, och för ett företag där några av processerna redan har beskrivits.

Listan är förberedd i tre steg:

1. Studera (skapa) företagets organisationsstruktur.
2. För varje avdelning, skriv ner de funktioner och aktiviteter som den är involverad i. Det är viktigt att notera att för att lista alla processer som utförs av anställda måste du kommunicera med dessa anställda personligen. Det är bara i processen för kommunikation ansikte mot ansikte som du kan få en adekvat bild.
3. Granska listan för att se om några funktioner är dubblerade eller om några funktioner saknas. Det finns situationer när två avdelningar gör samma arbete, till exempel görs beräkningen av KPI:er för säljavdelningsanställda av Finanstjänsten och säljavdelningen själv. Det händer att det finns en funktion, men det finns inga anställda som utför den.

Som ett resultat bör du ha en lista: funktion - anställd (grupp), där det inte finns några korsningar eller tomma fält.

För att forma affärsprocesser från en pool av funktioner måste du bestämma på vilken grund du ska gruppera dem. Huvudmålet med affärsprocessen är att skapa en "färdig produkt" och tillgodose användarnas krav. Om du tittar noga kommer målet för varje funktion också vara att skapa en specifik "produkt". Därför skapas affärsprocesser från funktioner som visas i figur 1.

Bild 1. Hur man skapar en affärsprocess från en funktion

När du har slutfört dessa steg får du en lista:

• Affärsprocess 1 och ytterligare funktioner
• Affärsprocess 2 och ytterligare funktioner
• Och så vidare.

Ge varje process ett namn som återspeglar dess väsen. Det förberedande arbetet är nu klart och det är dags att rita en processkarta.

Processkartan påminner en del om ett vattenflöde, som börjar med små källor, för att sedan fyllas på med nya bäckar, som smälter samman och rinner ut i havet som en fullströmmande flod.

Ordna figurerna på bilden i den ordning som de utförs. Det är vanligt att rita en karta från vänster till höger, med hjälp av figurer - pilar - för att indikera processen.

figur 2. Beteckning

Placera de processer som kan utföras parallellt ovanför och under de viktigaste.

Anslut dem med pilar. Det är inte nödvändigt att endast använda pilen för en process. Processen kan läggas in från en eller flera. Situationen är liknande för utgångar.

Nu när kartan är klar är in- och utdata för alla processer tydliga. Du kan börja skildra varje specifik process.

1. För att göra detta, placera in- och utdata från processen på en tom bild.
2. Dela upp arket horisontellt i områden - deltagarnas roller.
3. Enligt deltagarnas roller, ordna huvudblocken - processens funktioner. Behåll konsistensen.
4. Lägg till gafflar och ytterligare funktioner.
5. Placera på diagrammet de dokument som måste genereras under utförandet. Ett mail, en excel-tabell är också dokument ur processsynpunkt.
6. Identifiera de program och databaser som används. Det är tillrådligt att inte skriva namnet på programmet, utan ett specifikt programvarublock (till exempel inte 1C utan 1C Payment Calendar, etc.).
7. Lägg till prestandaindikatorer i processen där de testas.
8. Länka det resulterande diagrammet till andra processer.

Efter att ha gjort alla dessa steg får du ett komplett diagram (se figur 3).

Figur 3. Exempel på en affärsprocessbeskrivning

När du beskriver en affärsprocess är ditt huvudmål att se till att även "mannen på gatan" kan läsa den. Därför detalj, styrd av principen om effektivitet. En affärsprocess skriven i allmänna streck, vagt, kommer att vara obegriplig utan ytterligare förklaring. Och för mycket detaljer kommer att resultera i mycket extraarbete för dig (och läsaren) men lite mervärde.

Och avslutningsvis, låt oss lägga till en mycket viktig regel: du bör aldrig blanda begreppen "som är" och "som borde vara" i beskrivningen. Många anställda som är involverade i datainsamling tenderar att försköna verkligheten och lägga till funktioner som, enligt deras åsikt, borde finnas, men i verkligheten inte utförs. Sträva efter att tydligt skilja mellan sådana "önskningar".

I det första steget skriver du affärsprocesser "som de är", i det andra steget ändrar du dem till "som borde vara".

Hur man hittar olönsamma affärsprocesser

För att identifiera företagets affärsprocesser som medför ytterligare förluster och identifiera de ansvariga, använd ledningsrapportering. Bryt ner det i affärsprocesser och tilldela en ansvarig toppchef till var och en. På så sätt kan du förstå vem som är ansvarig för framgång eller misslyckande för en viss process, och samordna ledningsgruppen för framtida perioder.

Se steg-för-steg-algoritmen om hur du ska agera för att hitta och eliminera ineffektiva affärsprocesser. Ekonomichefen för produktionsbolaget STAN delar med sig av sin erfarenhet.

Nackdelar med att beskriva affärsprocesser

Förutom många fördelar har beskrivningen av affärsprocesser även en rad nackdelar.

Den första, och mest betydande, är den höga kostnaden för att implementera en processmetod. Du kan beskriva processerna antingen på egen hand eller med hjälp av inbjudna konsulter, men i båda fallen kommer genomförandekostnaderna att uppgå till en betydande summa. Företagsledningen måste vara intresserad av beskrivningen och veta hur man tillämpar resultaten av processmetoden. Annars kommer företagets pengar att gå till spillo.

Den andra, inte mindre betydelsefulla, är utvecklingen av företaget och dess affärsprocesser, som också kommer att behöva beskrivas. Lösningen "beskriven - fick resultatet - glömde" är inte lämplig för processmetoden. Annars kommer processerna om sex månader till ett år att bli irrelevanta och pengarna kommer återigen att vara bortkastade. Var beredd på löpande underhållskostnader.

Den tredje nackdelen är genomförandets varaktighet. Projektet kan ta från 6 månader till 1 år.

Den fjärde nackdelen är motstånd från medarbetare och chefer. Liksom alla effektivitetsförbättringsprojekt leder införandet av en processmetod till optimering av företagets kostnader, inklusive personalminskning och ökad arbetsbelastning.

Stanislav Tulchinsky

Generaldirektör och partner för LLC "b2b.Development Technologies"

I nuvarande arbetspraxis, särskilt efter att ekonomin har tagit sig ur krisens akuta fas, måste vårt företag ganska ofta hantera förfrågningar från potentiella kunder om hjälp med att beskriva affärsprocesser. Själva idén med att utföra ett sådant arbete, som alla andra försök till förändring, kan ge både stora fördelar för dem som initierar dessa förändringar, och även ha obehagliga biverkningar. Vårt företag har lång erfarenhet av att utveckla och förbättra företag, och därför har vi åtagit oss att klassificera och beskriva några av funktionerna i arbetsorganisationen och de tillvägagångssätt som används. Det är möjligt att vårt arbete kommer att hjälpa dem som bestämmer sig för att förbättra verksamheten i sitt företag att undvika de vanligaste misstagen när de börjar arbeta med att beskriva affärsprocesser, för att inte tala om den efterföljande optimeringen och praktiska implementeringen av de förändrade processerna.

Var börjar det oftast?

Som redan nämnts kan felaktig organisation av arbetet för att beskriva, optimera och implementera förändrade affärsprocesser i slutändan ge företaget som påbörjat ett sådant arbete antingen ett positivt resultat i sin rörelse mot en ljus framtid, eller ekonomiska, moraliska förluster och djup besvikelse för alla som tog del i detta. Varför startar sådana projekt egentligen?

Det finns flera vanligaste anledningar till att ledningen (ägarna) i en organisation kommer på idén att de behöver beskriva sina affärsprocesser. För mig själv delar jag in dem i tre grupper.

Den första av dessa beskrivs av företagsledare i inledande samtal ungefär så här: "Vår verksamhet har nyligen vuxit kraftigt (ökat), men något i det började hända annorlunda än vanligt." De vanligaste problemen som nämns är ungefär desamma:

• Antalet konflikter som bara kan lösas med inblandning av ägare (toppchefer) har ökat;
• Kostnaderna har ökat oproportionerligt i förhållande till företagens tillväxt, men orsaken till detta är inte alls tydlig;
• Antalet problem relaterade till produktion och kundservice har ökat, såsom missade deadlines, defekter, likgiltighet, oförskämdhet hos personalen i receptionen;
• Företaget börjar förlora mot sina mindre konkurrenter när det gäller kvalitet och snabbhet för att få ut nya produkter på marknaden.

Den andra gruppen beskrivs ungefär så här: ”Det är väldigt svårt att förstå vem som är ansvarig för vad i företaget, vad som motiveras av det vid kriser inom företaget, det är absolut omöjligt att förstå vem som bär skulden och vad som behöver göras för att förhindra att detta händer igen. Vi måste förbättra hanterbarheten och transparensen i verksamheten.”

Den tredje gruppen beskrivs ungefär så här: "Vi beslutade att avsevärt förbättra vårt informationssystem (implementera ett nytt), det är detta som borde ge en betydande impuls till utvecklingen av vår verksamhet."

Denna lista kan förmodligen utökas. En viktig slutsats av en sådan självdiagnos är slutsatsen som företaget drar för sig själv: vi behöver beskriva våra nuvarande affärsprocesser (”as ​​is”) för att bli av med de problem som identifierats hos oss själva.

Några anteckningar om problemformuleringen

Redan i själva formuleringen av problemet finns det flera "svaga" ögonblick som kan leda till obehagliga konsekvenser.

Först och främst betraktas beskrivningen av affärsprocesser i de flesta fall av kunden som en magisk besvärjelse som definitivt kommer att orsaka regn. Det finns en åsikt att du bara måste beskriva affärsprocesser, och problemen kommer att lösas av sig själva. Detta är faktiskt långt ifrån fallet. En affärsprocessbeskrivning kan hjälpa till att lösa problemen ovan (och är ofta vad du bör använda), men det är ingen magisk kula i sig. För att lösa dessa problem behöver vi ett handlingsprogram, ett integrerat tillvägagångssätt, där en av komponenterna kan vara en beskrivning av affärsprocesser.

Det andra problemet med ovanstående problemformuleringar är avsaknaden av ett affärsproblem i dem. Och faktiskt, varför ändra något om företaget fungerar och tar in lite vinst som passar alla. Ja, det finns vissa svårigheter med kommunikation och problemlösning, men de är bara arbetsproblem. Beskrivningen av affärsprocesser kommer att kräva investeringar (och ofta mycket mer än det verkar i början) i programvara, utbildning av specialister, utföra arbete och distraherande företagsanställda. Om företaget inte sätter sig som mål att öka affärsindikatorerna, kommer detta projekt bara att minska företagets effektivitet (kostnaderna kommer bara att öka).

Det tredje problemet är förhoppningen att det nya programmet MRP, ERP, CRM, SCM, BPM, DFM, etc. etc. (ofta flaggskeppet för den västerländska ekonomin), som (enligt sina säljare) är en outtömlig källa till visdom och referens affärsmodeller, efter implementering kommer att göra underverk. Och själva verksamheten kommer att förändras i "rätt" riktning. Intäkterna kommer att öka, rätt marknadssegment kommer att väljas, kostnader och konflikter mellan anställda ska minska. Men, som säljarna av det "magiska" programmet säger, för att implementera det måste du beskriva processerna.

Erfarenheten visar att slutet på ett projekt som innehåller sådana utelämnanden sannolikt är mycket osäkert. Att ta sig an ett sådant projekt är som att spela rysk roulette med en TT-pistol – chanserna är mycket små.

Viktig anmärkning om optimering

Som redan nämnts uppfattas ofta idén om att beskriva processer som ett universalmedel, och företagsledningen tänker inte på varför det är nödvändigt att helt enkelt beskriva befintliga affärsprocesser? Vad hjälper detta (förutom de papper som dyker upp)? Är en signatur på de nya befattningsbeskrivningarna verkligen vad företaget saknade för sitt "happily ever after"? Med största sannolikhet är detta inte fallet. Det finns ett ganska litet antal uppgifter som direkt kommer att få en betydande effekt av att beskriva processer, i alla andra fall kräver detta en preliminär optimering av processer.

Men även i det fall då kunden i sitt uttalande kommer ihåg problemet med att optimera affärsprocesser, ser det ofta ut som ett etablerat lexem, inget mer. Till exempel är Internet helt enkelt fullt av lediga tjänster för specialister på att "beskriva och optimera affärsprocesser", som faktiskt helt enkelt borde rita och rita om bilder (måla dem i olika färger - och det här är inte ett skämt) i en viss notation från ord från sina andra kollegor. Tillägget av ord om "optimering" lyder nu som "kebab-mashlyk", "grön-krita", vilket lämnar känslan av ett ogräsord som inte bär någon annan belastning än känslomässigt.

Och problemet är inte ens att själva ordet "optimering" är komplext och obegripligt. Själva idén med förbättring (optimering), som borde ge befrielse, och längre ner på listan, "vem har vad", är tydlig för alla. Problemet är att optimeringskriteriet är viktigt: exakt vad och hur mycket du vill förbättra genom acceptabla förändringar. Och, som regel, om det inte finns några problem med "vad att förbättra" (vanligtvis efter en påminnelse): "exakt, vi måste minska tiden det tar att slutföra en affärsprocess, dess kostnader, förbättra kvaliteten på tjänsten, ” då är det i de flesta fall väldigt svårt med allt annat .

Låt oss börja med det faktum att det kan vara väldigt svårt att bestämma sig för "hur mycket som ska förbättras", för i en organisation brukar sådana "småsaker" som indikerar "vad som ska förbättras" i regel helt enkelt inte mätas på något sätt. Även de enklaste (som kostnad, tid eller varians i en affärsprocess). Därför är det omöjligt att avgöra "hur mycket" utan speciell erfarenhet och kunskap. Utan detta, hur kan du avgöra att det finns förbättringar och att de passar kunden (värt ansträngningen han lagt ner) - bara "med ögat", efter känsla? Men konstigt nog är den svåraste delen av "optimeringspusslet" inte "hur mycket", utan vad de "tillåtna ändringarna" är. För den vanligaste önskan är: ”förändring där, i dina affärsprocesser, du kan förändra det inom IT också, men i affärer, produkter, marknader, i relationer, inom respekterade människors ansvarsområden behöver du inte röra vid något." Du måste med andra ord optimera med endast kosmetiska förändringar.

Den beskrivna logiska återvändsgränden kan sätta ett stort "kors" på själva idén att beskriva affärsprocesser (en andra patron sätts in i klämman för god åtgärd). Även om situationen med förändringar under optimering faktiskt inte är så dödlig som kunden ser det. Det är möjligt att välja lösningar som, inom ramen för befintliga (inte imaginära) restriktioner, gör det möjligt att uppnå vissa mål. Det återstår att bestämma pris/kvalitetsförhållandet - om de kommer att passa kunden.

Övergång till nya (optimerade) processer

Som redan nämnts kommer beskrivningen av affärsprocesser med största sannolikhet att leda till behovet av att förändra något i företaget. Antingen det etablerade sättet att arbeta för anställda, deras relationer, kommunikationsordningen, eller produkter/tjänster eller marknader, eller företagets kunder, och med största sannolikhet, i någon proportion, alla de beskrivna. Och väldigt ofta blir detta obehagliga nyheter. De beskrivna affärsprocesserna fungerar inte av sig själva. Men kunden själv, företagets anställda och i synnerhet företagets chefer är inte redo och strävar inte efter något annat som behöver göras. Ja, bra eller dåligt, företaget fungerar, tjänar något, men vad händer om allt förändras? Ingen vet. Och detta förvärrar det faktum att den initiala uppgiften "bara att beskriva affärsprocesser" inte precis inkluderar utvecklingen av ett program för övergången till nya processer, eller ett program för att hantera affärsprocesser i framtiden. Det finns en förenklad åsikt: "låt oss anta nya regler med en beställning för företaget från första dagen, och allt kommer att fungera." När beskrivningen av processerna är klar står det klart att en beställning inte kommer att fungera. Det finns många förändringar, inte alla förstår dem, inte alla är redo för dem, många komponenter för övergången saknas (till exempel är det nödvändigt att ändra IT-systemet, göra ändringar i verktyg, utrustning, infrastruktur, omskola personal ). Och investeringar i beskrivning och optimering av affärsprocesser skrivs av som förlust.

Val av verktyg och metodik för att beskriva processer

Ofta uppmärksammas inte denna fråga alls när man beslutar om beskrivningen av affärsprocesser. Detta innebär (helt felaktigt) att det inte är någon skillnad i vilken programvara och vilken metodik som används.

Märkligt nog borde de avgörande faktorerna i valet av metodik och programvara för att beskriva och optimera affärsprocesser vara samma ökända mål som verksamheten har definierat för sig själv. Det finns två diametrala formuleringar av problemet som avgör vilken metodik för att beskriva processer som är mest acceptabel.

Kanske låter problemformuleringen ungefär så här: ”för att lösa de tilldelade problemen är det nödvändigt att skapa, i ett av stegen, en funktionell (process)modell av företaget som visar systemets struktur, relationer och funktioner, som såväl som flöden av information och materiella objekt som förbinder dessa funktioner.” I detta fall ligger tonvikten på att skapa en beskrivning av systemet, identifiera och beskriva kontrollobjekt, spåra kontrollhierarkier och obligatorisk spårning av kopplingar mellan processer.

Eller en lite annan uppgift är möjlig, som kan låta ungefär så här: ”beskrivningar av algoritmer (scenarier) för att exekvera processer krävs. Först och främst är det nödvändigt att identifiera orsak-och-verkan-samband och den tidsmässiga sekvensen av åtgärder, en ordnad kombination av händelser och funktioner." I det här fallet ligger tyngdpunkten på att beskriva handlingssekvenser, identifiera initiala och slutliga händelser, identifiera deltagare, artister, material- och dokumentflöden.

Det är värt att notera att i allmänhet är dessa problemformuleringar inte ömsesidigt uteslutande situationer är möjliga när det finns ett behov av att lösa båda problemen, men i det här fallet är det värt att gå från det allmänna till det specifika: första modellen företagets; företag, och använd sedan denna modell för ytterligare beskrivning av individuella algoritmer.

Kanske för att denna fråga verkar mycket högspecialiserad, ägnas den ingen uppmärksamhet alls, och förgäves. Befintliga tillvägagångssätt för att beskriva affärsprocesser, som befintlig programvara, med sällsynta undantag, är specialiserade och dåligt lämpade för att lösa uppgifter som de ursprungligen inte var avsedda för. Till exempel har ett företag beslutat att öka sin effektivitet, och för detta kommer det att skapa en sammankopplad, konsekvent affärsmodell för hela företaget, som beskriver ett system av affärsprocesser, som var och en är kopplad till varandra genom arbetsresultat, varje deltagare i processen har KPI-indikatorer, varje division av företaget har planer och budgetar som syftar till att uppnå gemensamma strategiska mål. I det här fallet kommer beslutet att använda metoder och programvara som utvecklats främst för att beskriva algoritmer och relationer på operativ nivå vara extremt svårt, dyrt och tidskrävande för företaget. Och därför, genom att överlåta lösningen på denna fråga till smala (tekniska) specialister, riskerar företaget att hamna i en inte särskilt trevlig situation: betydande ekonomiska resurser, tid, ansträngning spenderas och det formella resultatet som erhålls ger inte den förväntade effekten .

En ytlig analys av Internet visar att detta ämne (val av metod och verktyg) inte är tillräckligt täckt (META Groups analys är inte bara mer fokuserad på IT-lösningar, utan tar praktiskt taget inte hänsyn till den ryska marknadens särdrag, med tanke på endast typiska representanter för den etablerade västerländska marknaden). De vanligaste artiklarna jämför ARIS- och IDEF-metoderna. Ett annat vanligt tema är att lista styrkorna och svagheterna hos (vanligtvis metoder) utan att ta hänsyn till problemet för vilka dessa styrkor analyseras. Det blir lite konstigt: är det verkligen till exempel att bärförmågan på en lastbil alltid är en obestridlig fördel, oavsett vad jag väljer bil till?

En detaljerad analys av de verktyg (metoder, mjukvara) som används för att beskriva affärsprocesser är ett ämne för en separat diskussion. Vi har försökt ge en kort översikt (inte för specialister) endast av författarens och hans kollegors personliga erfarenhet. Därför är listan nedan specifik och inte uttömmande. Utan att göra anspråk på djup kommer vi att ge en allmän beskrivning av produkterna mot bakgrund av ovan beskrivna uppgifter:

• CA ERwin Data Modeler (tidigare AllFusion Data Modeler, BPwin). Förmågan att beskriva sammankopplade komplexa modeller implementeras mest framgångsrikt. Enkla (koncisa) beskrivningsbeteckningar. Ytterligare uppgifter är svåra eller implementeras inte alls (länka mål och processer, skapa ett träd av indikatorer, genomföra simuleringsmodellering);
• ARIS (en uppsättning mjukvara, moduler från IDS Scheer). Själva namnet (Architecture of Integrated Information Systems) antyder att programvaran från början var fokuserad på att lösa problemet med att beskriva algoritmer och sekvenser av åtgärder. Allt annat kan göras i ARIS, men det kommer att bli väldigt svårt. För att beskriva affärsprocesser måste du använda ett stort antal modeller (det finns fler än 80 av dem i ARIS, och deras antal växer) med ganska komplex semantik, där även de mest ivriga anhängarna blir förvirrade. Utan omfattande erfarenhet och betydande omtanke om grunderna i metodiken är det inte lätt att implementera komplexa beskrivningar av sammankopplade modeller;
• Corporate Modeler (Casewise Systems) är på många sätt den engelska yngre analogen till ARIS – inte i metodik och lösningar, utan i själva idéerna med mjukvaran. Fokuserade även på hjälp med att beskriva affärsprocesser för efterföljande mjukvaruutveckling. Men det kostar mindre i genomsnitt;
• iGrafx Enterprise Central (en division av Corel Inc) är fortfarande mindre känt i Ryssland, men en mycket trevlig lösning från Kanada. Innehåller en hel uppsättning moduler för beskrivning, processmodellering, applikationer för planering och kvalitetsledning och riskhantering. Dess betydande nackdel är dess brist på distribution;
• Business Studio (GK "Modern Management Technologies"). Den mest kända ryska utvecklingen från familjen av programvara i fråga. Kanske (enligt vår privata uppfattning) kombinerar den framgångsrikt (så långt det är möjligt) några av de mest användbara funktionerna i BPwin och ARIS, något som påminner om iGrafx i sin lösning (men inte i kostnad). Om pris/funktionsförhållandet är viktigt för kunden är detta förmodligen det bästa valet för ryska företag. Det har en nackdel, eftersom det är mycket tätt integrerat med MS Office (Word, Excel, Visio), och därför överförs alla grova kanter av dessa lösningar automatiskt till Business Studio.

Vad kan kunden få?

Kunden tar i regel inte hänsyn till det som beskrivits ovan. Mycket ofta drivs han av tanken att det är nödvändigt att beskriva processer som inte var svårvunna för honom, utan "föll" på honom från utsidan:

• Från en smart bok (trots allt, "Porter skrev något om det här, men vi har det inte!") eller under utbildning, till exempel, på den nu fashionabla MBA-examen;
• Från en IT-direktör eller säljare av dyra informationssystem ("det här programmet kommer definitivt att lösa alla problem, titta på listan över framgångsrika företag som använder det, detta är programmets förtjänst, men för att implementera det måste du beskriva processerna" );
• Från en ung och energisk ställföreträdare som också hörde det någonstans och framgångsrikt "sålde ett program för affärsprocesser" till sin chef utan att förmedla dess viktigaste nyanser.

I det här fallet låter den sista uppgiften ungefär så här: "vi måste beskriva våra affärsprocesser, låt oss leta efter en specialist för att beskriva och optimera affärsprocesser." Om du börjar undra varför, så kommer svaren med största sannolikhet vara logiskt sett väldigt orelaterade till den slutliga uppgiften. Och då är två fundamentalt olika alternativ möjliga.

I den första börjar utföraren, utan onödiga frågor som gör kunden nervös, samvetsgrant att beskriva processerna. Alla, eller de som erbjuds honom: "låt oss börja med processen att utfärda och returnera stödjande dokument till entreprenörer, redovisningsavdelningen ber om detta." Som regel används bekanta och enkla procedurbeskrivningsnotationer (eller korsdiagram eller EPC). Arbetet går mycket snabbt, utan onödiga frågor (vi beskriver vad de kommer att säga eller hur det är). Men i slutändan är resultatet okomplicerat. Som IT-specialister säger: "när du försöker automatisera en röra, slutar du med en automatiserad röra", men med processer blir det ännu värre - en enda röra. De beskrivna processerna, som beskrivs exakt som de sker i livet och på papper, är komplexa och förvirrande. Nästa steg kan utföraren försöka förbättra något ( tyvärr, de kallar det högt - optimera). Men samtidigt tar den som regel hänsyn till en begränsad krets människors synvinkel, tar inte hänsyn till alla möjliga kopplingar till andra processer, företagskulturens egenskaper, och gör därför faktiskt inte förbättra någonting. Men samtidigt spenderades en betydande mängd tid och resurser. Efter detta, troligen, beslutar kunden att beskrivningen av processerna inte hjälpte.

Det andra alternativet är vanligtvis mycket mindre vanligt. Utövaren börjar ställa frågor: varför är det nödvändigt att beskriva, och vad vill du få till slut, och hur är detta relaterat till varandra genom orsak-och-verkan-samband, och vilka är optimeringskriterierna. Och här kan troligen den "rätta" artisten få allvarlig negativ feedback från sin kund. Och inte bara för att han helt enkelt inte har svar på sina frågor, utan för att uppgiften som kunden marknadsför ”hänger” i luften, inte baserad på en verklig orsak-och-verkan-kedja av uppgifter. Plötsligt börjar ett antal pikanta detaljer helt enkelt dyka upp, som faktiskt är obehagliga för kunden:

• Det är omöjligt att beskriva processer i ett företag "som de är" (och detta är ett axiom för företag som funderar på att beskriva processer för första gången) bara för att företaget ofta inte har dem. Aktiviteter utförs baserat på de anställdas erfarenhet (och det är olika för alla), beslut om uppgifter fattas situationsmässigt (och därför är de inte heller samma i olika fall). Även regelbundet utförda processer - och de i företaget genomförs inte på det sätt som ledningen tänker, utan på det sätt som det är bekvämt för utförarna (ofta, inte alls som cheferna tänker på det). Därför är det nödvändigt att inte beskriva, utan att skapa en serie processer som en repetitiv, standardiserad aktivitet;
• När man beskriver processerna visar det sig att den befintliga verksamheten inte är optimal i sin essens (till exempel finns det inga målindikatorer, några av de nödvändiga aktiviteterna utförs inte och vissa utförs på ett suboptimalt sätt, ett felaktigt motivationssystem , det finns ingen kompetent kostnadsredovisning);
• Verksamheten är väsentligt exponerad för externa och/eller interna risker;
• Vid beskrivning av affärsprocesser kommer det att vara nödvändigt att göra betydande förändringar i affärsmodellen (till exempel inom ansvarsområden, utförda uppgifter, relationer mellan avdelningar och människor, motivationssystemet).

Dessutom kan det plötsligt visa sig att om de beskrivna processerna är något modifierade och inte exakt återspeglar den existerande verkligheten (och detta kommer med största sannolikhet att vara fallet om inte artisten bestämmer sig för att öppet "fuska"), så behövs ett annat projekt: implementering: av förändrade processer i praktiken av deras tillämpning i kundens företag. Och detta projekt kommer att kräva ännu större ansträngningar för att faktiskt förändra hur människor i företaget arbetar: från det vanliga, etablerade sättet att leva till ett nytt - ovanligt, inte uppfunnit av dem.

Inte den bästa lösningen

Inför alla ovan beskrivna frågor, när du inte bara behöver beskriva processer utan behöver förändra en betydande del av verksamheten, händer det att inte alla kunder har ett internt motiv för detta. I det här fallet kommer det att vara viktigt för artisten att först hitta exakt detta - detta ökända motiv. Annars kanske arbetet med att beskriva processer helt enkelt inte börjar. Är det bra eller dåligt? Om du inte letar efter "universell sanning", så är det förmodligen bra, och för båda sidor:

• Den misslyckade kunden slösade inte bort tid eller pengar på jakten på en hägring. Dessutom, när han kanske mognar i att förstå varför han faktiskt behöver en beskrivning av affärsprocesser, kommer han inte att ha tidigare negativa erfarenheter som kan dra ner honom som en sten, vilket hindrar honom från att påbörja det arbete som kan gynna honom;
• En misslyckad artist kommer inte att få pengar för sitt arbete, men samtidigt kommer han inte att få ett uppenbart problematiskt projekt, som inte kommer att ta bort en betydande del av hans liv, nerver, rykte, men kommer att tillåta honom att göra något mer användbart . Och ett misslyckat samarbete blir möjligt när den misslyckade kunden är redo att utföra arbetet.

Även om detta naturligtvis snarare är en tillfredsställande lösning som minimerar omedelbara risker, men som inte ger någon vinst över en längre horisont. En bättre lösning kräver lite mer än förmågan att beskriva affärsprocesser. Att beskriva affärsprocesser är i alla fall en uppgift som kräver inte bara erfarenhet och kunskap från den direkta utföraren, utan också kunskap, beredskap och vilja att gå denna svåra väg från kunden.

Hur kan du undvika att göra de misstag som beskrivs i artikeln? Allt är väldigt enkelt. Det borde du inte göra. Låt oss försöka beskriva lite mer detaljerat vad som behöver göras, från författarens synvinkel. Nedan finns en lista över uppgifter som bör lösas (eller börja lösas) innan huvudpengarna (resurserna) tilldelas och specialprogramvara köps, nya personer dyker upp och ritar de första "rutorna", skriv de första bestämmelserna. Eftersom detta bara är början på ett eventuellt förändringsprojekt är det ingen som hindrar oss från att lägga lite mer tid än vad som är brukligt och fundera på vad och hur företaget vill få och hur mycket det är villigt att betala. För att göra detta bör du åtminstone göra följande:

• Bestäm exakt vilka affärsuppgifter (affärsindikatorer) verksamheten vill förbättra. Vad vill kunden egentligen uppnå när de överväger förändringar i sin verksamhet? För att göra detta kan det bli nödvändigt att tänka om visionen för verksamheten;
• Bestäm optimeringskriterier för affärsprocesser: vad företaget vill förbättra i dem och hur mycket som ska förbättras. En viktig punkt i denna uppgift kommer att vara att förstå de uppenbara (inte imaginära) begränsningarna - vad som definitivt är oacceptabelt i organisationen, och vad som definitivt inte kan ändras;
• Bestäm ett handlingsprogram för att uppnå målen, vilket kan eller inte kan innehålla en beskrivning av affärsprocesser. Det är absolut nödvändigt att i detalj utarbeta åtgärderna för övergången till nya (optimerade) processer i programmet;
• Välj den nödvändiga uppsättningen verktyg (främst den nödvändiga programvaran) som är tillräcklig för det valda handlingsprogrammet och de uppsatta målen (i första hand den nödvändiga programvaran), som bäst motsvarar de uppsatta målen;
• Först efter att arbetet som beskrivs i de första styckena har utförts, leta efter värdiga utförare för uppgiften.

Som framgår av listan över angivna uppgifter behöver initiativtagaren till förändringar i det första skedet inte ens en teknisk specialist i beskrivningen, utan en affärsmotståndare, i viss mån en "djävulens advokat", kanske inte ens en fast anställd hos företaget. Den person som kan ställa de rätta frågorna, invända någonstans och argumentera med kunden, men som låter honom se på företaget och hans uppgift utifrån ("med en öppen" vy), hjälper kunden att undvika de felaktiga beslut som beskrivs i artikeln i hans rörelse mot förbättring.

1 ”För varje befintlig produkt kommer samma analog att utvecklas, integrerad med SAP-lösningar. Detta kommer att hanteras av en separat division i vårt företag. Därför kan vi säga att vi går in i ett nytt marknadssegment på global skala – SAP-kunder kommer att bli våra kunder.” Från en intervju med Bernard Fisher, VD för Casewise.

Vi tittade på de grundläggande koncepten för affärsprocesser. I denna del kommer vi att titta på affärsprocessmodellering och ge ett exempel på modellering.

Affärsprocessmodellering

Modellering är processen att studera verksamheten i en organisation för att konstruera en formaliserad (grafisk, tabellform, text) beskrivning av organisationens affärsprocesser.

• intervjua;
• arbeta med lagstiftning, organisationsdokument;
• brainstormingsmetoder osv.

Affärsprocessmodelleringsprocessen är unik inom en organisation. Innan arbetet påbörjas rekommenderas det att klargöra existensen och innehållet i denna process i organisationen.

Nedan kommer vi att titta på ett exempel på en affärsprocessmodelleringsalgoritm. Så för att modellera en affärsprocess måste du:

1. Bestäm resultatet och ägaren av affärsprocessen.
2. Bestäm uppsättningen och ordningen för åtgärder som utgör affärsprocessen.
3. Bestäm verkställarna för affärsprocessen: i detta steg är det nödvändigt att separera ansvarsområden, identifiera vilka anställda på vilka avdelningar som är ansvariga för att utföra processåtgärder och koppla utförarna till åtgärderna.
4. Definiera affärsprocesshändelser. Bestäm typerna av händelser: initial, sista, mellanliggande. Koppla mellanhändelser till åtgärder.
5. Bestäm resurser: dokument, information etc. som förbrukas av affärsprocessåtgärder. Koppla resurser till åtgärder.

Ett diagram som illustrerar modelleringsalgoritmen visas i figuren nedan:

När algoritmen har slutförts, rekommenderas det att utföra en "vad-om"-analys. Exempel: vad händer om åtgärdsinmatningen innehåller ett dokument som innehåller fel; vad som händer om den godkännande chefen avvisar dokumentet. Det finns två sätt att ta hänsyn till resultaten av analysen:

• komplettera den befintliga modellen med filialer;
• tillhandahålla separat för åtgärderna i den "alternativa" processen.

Om vi ​​uppenbart inte kan föreslå en gren/alternativ processåtgärd, registrerar vi det alternativa villkoret i listan "öppna frågor". Det rekommenderas att denna lista sedan lämnas till ämnesexperterna och processägaren.

Det rekommenderas inte att analysera alla möjliga och omöjliga fall av processen. Situationer som inte omfattas av processen hanteras vanligtvis av den funktionella chefen för avdelningen (inom vars ansvarsområde situationen uppstod).

För att registrera affärsprocesser i grafisk form används ett system av symboler för element (notation). De mest kända notationerna: SADT/IDEF0, IDEF3, DFD, BPMN, ARIS, UML. En genomgång och jämförande analys av notation ligger utanför ramen för denna artikel; De som är intresserade av Internet kan hitta många artiklar om ämnet att jämföra notationer, till exempel "IDEF vs ARIS".

Exempel på en affärsprocessbeskrivning

Låt oss ge ett exempel på en affärsprocessbeskrivning. Låt oss som exempel ta processen att bevilja obetald ledighet. Låt oss överväga ordningen och arbetsflödet som uppstår under ovanstående process. Metod för att samla in information: Rysk lagstiftning som preliminärt material inför intervjuer med ämnesexperter och processägaren. Beskrivningsbeteckning: ARIS eEPC.

1. Insamling av källmaterial.

1.1 Tillhandahållandet av ledighet regleras av arbetslagstiftningen (vid insamling av material är det nödvändigt att förlita sig på den senaste utgåvan, vid tidpunkten för artikelns skrivning - som ändrat den 30 december 2015 nr 434-FZ), artikel 128 Ledighet utan lön

Av familjeskäl och andra giltiga skäl kan en arbetstagare efter skriftlig ansökan beviljas ledighet utan lön, vars längd bestäms i överenskommelse mellan arbetstagaren och arbetsgivaren.

Arbetsgivaren är skyldig att på skriftlig ansökan från arbetstagaren ge ledighet utan lön:

• deltagare i det stora fosterländska kriget - upp till 35 kalenderdagar per år;
• för arbetande ålderspensionärer (efter ålder) - upp till 14 kalenderdagar per år;
• föräldrar och hustrur (män) till militär personal, anställda vid organ för inre angelägenheter, den federala brandkåren, myndigheter för kontroll av cirkulationen av narkotika och psykotropa ämnen, tullmyndigheter, anställda vid institutioner och organ inom straffsystemet, som dog eller dog till följd av skada, hjärnskakning eller skada, mottagen under utförande av militärtjänst (tjänstgöring) eller till följd av en sjukdom i samband med militärtjänst (tjänstgöring) - upp till 14 kalenderdagar om året;
• för arbetande funktionshindrade - upp till 60 kalenderdagar per år;
• anställda i fall av ett barns födelse, äktenskapsregistrering, nära släktingars död - upp till fem kalenderdagar;

i andra fall enligt denna kod, andra federala lagar eller ett kollektivavtal.

1.2. Dokumentflödet vid registrering av ledighet regleras av resolutionen från Ryska federationens statliga statistikkommitté av den 5 januari 2004 N 1 "Om godkännande av enhetliga former av primär redovisningsdokumentation för registrering av arbete och dess betalning", avsnittet "Beställning (instruktion) om bevilja ledighet till en anställd.”

De används för registrering och redovisning av semester som beviljats ​​anställd(erna) i enlighet med lag, kollektivavtal, lokala bestämmelser för organisationen och anställningsavtal.

De upprättas av en personaltjänstanställd eller av denne befullmäktigad person, undertecknas av organisationschefen eller av honom befullmäktigad person och tillkännages för den anställde mot underskrift. Baserat på ordern (instruktionen) att bevilja ledighet görs märken i det personliga kortet (formulär N T-2 eller N T-2GS(MS)), personligt konto (formulär N T-54 eller N T-54a) och löner beräknas, förfallen till ledighet, i blankett N T-60 "Anteckningsberäkning om beviljande av ledighet till arbetstagaren."

Vi presenterar de data som behövs för att modellera affärsprocessen (vi agerar enligt det tidigare beskrivna schemat):

1. Resultat av affärsprocessen- Dokument som upprättats i enlighet med Ryska federationens lagstiftning och organisationsstandarder.

2. Affärsprocessägare: Chef för HR. Hur bestämmer man ägaren? Ägaren är en anställd som har resurserna att genomföra affärsprocessen (i detta fall är resurserna HR-anställda) och ansvarar för resultatet av affärsprocessen.

3. Rekrytering och förfarande:

skriva en ansökan -> upprätta en beställning -> -> –> .

Det finns ingen löneberäkning i sekvensen av åtgärder, eftersom Artikeln i arbetslagstiftningen, enligt vilken ledighet utfärdas, är Ledighet utan lön.

4. Verkställande av affärsprocesser.. För att ge information tydligare presenterar vi sekvensen av steg och utförare i tabellen:

5.evenemang. Låt oss komplettera tabellen ovan med information om evenemang:

6. Resurser, dokument och information. I det här exemplet tar vi inte hänsyn till resurser som artisternas tid, material och utrustning, eftersom Vi värdesätter dokument som upprättats i enlighet med Rysslands lagstiftning och organisationsstandarder (se resultatet av processen). Vi behöver analysera vilka dokument som deltar i processen. Låt oss lägga till information till den befintliga tabellen:

7. Låt oss genomföra "tänk om" analys.

• Vad händer om applikationen innehåller fel (från grammatiska fel till felaktiga detaljer)? Ansökarens initiativtagare behöver inte ha tillräckliga kvalifikationer för att fylla i ansökan korrekt (men måste kunna utföra sina omedelbara arbetsuppgifter på ett kompetent sätt). För att eliminera fallet med felaktig ifyllning av en ansökan kommer vi att lägga till åtgärden att kontrollera ansökan till huvudprocessen, eftersom Det är viktigt för oss att förhindra förekomsten av ett felaktigt dokument i processen.
• Vad händer om semesterordern inte är korrekt skriven? Därför att Eftersom en HR-specialists ansvar innefattar att upprätta personalhandlingar utgår vi från att beställningen i ett stort antal fall är korrekt upprättad. Detta ersätter inte verifieringen av en personalservicespecialists kvalifikationer (anställnings- och certifieringsprocesser) och den periodiska verifieringen av dokument (revisionsprocessen av personaldokument).
• Vad händer om chefen inte undertecknar ordern och initiativtagaren:
  • har rätt till ledighet, i enlighet med artikel 128 i arbetslagen. Vi kommer att skriva denna fråga i öppna frågor för denna process och ställa den till processägaren när vi kommer överens om processen. Processägaren bär det fulla ansvaret för genomförandet av processen det är han som bestämmer reglerna för att utföra arbete på den avdelning som anförtrotts honom;
  • inte har rätt till ledighet, enligt artikel 128 i arbetslagen. Vi kommer också att skriva denna fråga till öppna frågor.

• Vad händer om initiativtagaren vägrar att underteckna ordern (till exempel har omständigheterna under vilka han tog ledigt ändrats)? Vi stoppar processen.
• Vad händer om uppgifterna i personaldokumenten T-2 och T-54a är felaktiga? Denna fråga liknar den fråga som diskuteras i punkt 3.2.

Låt oss komplettera den befintliga tabellen med mottagen information. Faktum är att vi fick en preliminär beskrivning av processen i tabellform:

Öppna frågor

• Vad händer om initiativtagarens chef vägrade att underteckna ledighetsordern och initiativtagaren har rätt att lämna, enligt artikel 128 i arbetslagen
• Vad händer om initiativtagarens chef vägrade att underteckna ledighetsordern och initiativtagaren inte har rätt att lämna, enligt artikel 128 i arbetslagen

En kort beteckning av elementen i ARIS eEPC-notationen ges i tabellen nedan (inte alla element i notationen beskrivs, men de som används. Den grafiska beteckningen för elementen är hämtad från MS Visio-paketet):

Ett diagram som visar interaktionen mellan element visas nedan:

Den grafiska representationen av processen som tillhandahålls är som följer:

Grafisk och tabellformig visning av processen är föremål för godkännande av experter och processägaren. En affärsprocessanalytiker kan ofta inte känna till alla krångligheterna i den aktuella domänen, så det rekommenderas att alltid samordna sina modeller med domänexperter och processägaren.

Istället för en slutsats

Efter att ha skrivit artikeln, men innan den publicerades, hade jag en chans att prata med en god vän, jag förklarade för honom ämnet och kärnan i artikeln. En bekant ställde flera intressanta frågor, jag bestämde mig för att publicera vår konversation, jag tror att vår konversation kommer att vara intressant för läsarna:

– Jag tvivlar inte på att du skrivit en intressant artikel. Men varför sådana svårigheter? Varför behövs affärsprocesser, är det verkligen omöjligt utan dem?

– Se, affärsprocesser minskar variationen i resultaten genom att standardisera verksamheten. Variabilitet innebär att minska spridningen av acceptabla variationer i resultatet av en process. Jag beskrev ett enkelt exempel, affärsprocesser gäller inte bara personalfrågor, utan även verksamheten i organisationen. Föreställ dig att en organisation som specialiserat sig på leverans av reservdelar kommer att producera delar med olika kvalitetsnivåer (vi kommer ihåg att kvalitet är överensstämmelse med produktens egenskaper). Därefter kommer bildelar att installeras på bilar och vi kommer att ta emot... AvtoVAZ-produkter. AvtoVAZ-produkter hittar sina köpare, men på senare tid föredrar vi bilar av högkvalitativ montering.

– Jag tror att allt handlar om artisterna. Det räcker med att hitta kompetenta utförare så får vi ett bra resultat. Som i ditt exempel måste du hitta en kompetent personalofficer, det är allt.

– Bra utförare får redan arbete, deras arbete är dyrt. Du tänker inte på att optimera organisationens utgifter, anställa smarta specialister och ge specialister metodiskt stöd. En annan faktor är skalningen av arbetet. Låt oss föreställa oss att vår organisation har 2 000 anställda. I det här fallet kommer vi att ha flera HR-specialister och de kommer att ha olika erfarenhet. Vår uppgift i detta fall är att tillhandahålla ett verktyg för utbildning, genomförande av verksamheten och kontroll av verksamheten av avdelningschefen.

– Även om det är 2 000 personer och även om experterna gör fel. Vad är priset för ett misstag - bara felaktigt utförda personalhandlingar, dessa papperslappar.

– Först gav jag ett exempel på en affärsprocess. Affärsprocesser kan täcka en mängd olika aktiviteter i ett företag, vare sig det är ekonomi eller produktion. För det andra kan även felaktigt utförda personalhandlingar leda till böter för organisationen från tillsynsmyndigheter.

Tack till läsarna för att ni kommit så långt. Mycket skulle kunna sägas utöver det: prata om verktygen som används för att beskriva affärsprocesser, berör notationer mer i detalj... Men allt detta är en fortsättning på introduktionen till affärsprocesser.

Evgenij Ponomarev

Instruktioner

Den första är att noggrant formulera namnet på processen som beskrivs, vilket bör vara förståeligt och återspegla den allmänna essensen av sekvensen av åtgärder som utgör processen. Till exempel, istället för att "Skicka in en ansökan för produktion och övervaka dess utförande", räcker det att namnge processen "Produktkontroll." delprocessfunktioner och bestämma sekvensen för deras exekvering. Med en sådan uppdelning kommer den beskrivna processen att vara en process på toppnivå. Detaljnivån i processen på översta nivån kan variera, men bör vara tillräcklig för att förstås av publiken som kommer att använda din beskrivning.

Det finns flera sätt att beskriva en affärsprocess. Den mest populära av dem är grafisk, med hjälp av, gjord i olika notationer (notation är en uppsättning symboler för att beteckna något).
De vanligaste typerna av notationer för att beskriva affärsprocesser är IDEF0, BPMN, EPC (ARIS), etc.
Som ett exempel, låt oss titta på ett diagram gjort i BPMN (Business Process Modeling Notation) med hjälp av CASE-verktyget PowerDesigner (Fig. 1). Huvudelementen i diagrammet är:
1. "Process" (funktion) - en rektangel avrundad i hörnen;
2. "Övergång" - en pil som förbinder processer;
3. "Lösning" - en diamant som innehåller en fråga som bara kan besvaras "Ja" eller "Nej";
4. Villkor - textuttryck under vilka en övergång från en funktion till en annan sker. Villkoren är alltid inom hakparenteser. Ibland är det användbart att dela in din i "Spår" - vertikala eller horisontella sektioner som indikerar divisioner av företaget eller anställda som ansvarar för att utföra en viss funktion. I detta fall måste denna funktion placeras inom dess sektion. Utöver de listade elementen kan den även innehålla en lista över data som matas in eller ut för processen, samt länkar till de regler eller föreskrifter enligt vilka en viss funktion utförs. Ett exempel på en beskrivning av affärsprocessen "Produktproduktionskontroll" visas i Fig. 1. Det är lätt att se att detta diagram är mycket likt flödesschemat för algoritmen för att lösa problemet.

En grafisk beskrivning av en process kan också kompletteras med en textbeskrivning av dess funktioner-delprocesser i form av en tabell som innehåller följande kolumner: processnamn, avdelning (processägare), processbeskrivning, processexekveringsresultat. Ett exempel på en sådan beskrivning visas i fig. 2. Om ytterligare optimering av den beskrivna affärsprocessen förväntas, kan ytterligare en kolumn läggas till i tabellen som beskriver svårigheterna eller bristerna i de för närvarande utförda funktionerna-delprocesserna.

Användbara råd

Följ alltid reglerna för den valda grafiska notationen för att beskriva affärsprocesser.

Källor:

• M. Rybakov. Optimering av affärsprocesser.
• hur man skapar en affärsprocess

En process som fenomen är en kvalitativ förändring som sker med ett observationsobjekt under en tid. Därför, även innan du påbörjar beskrivningen, måste du ange objektet och tidsperioden för observationen.

Instruktioner

Först måste du beskriva essensen av processen, med andra ord den kvalitativa förändringen du observerar. Till exempel fattade det eld, brann ut, slocknade (essensen av händelsen är förbränningsprocessen). Förändringen kan vara externt synlig (en hel tändsticka har förvandlats till en stav), objektets struktur, systemet med anslutningar kan förändras, beroende på vad exakt du spårar. I alla fall, när du beskriver förändringen, måste du dessutom ange tid och hastighet (till exempel brann tändstickan i 20 sekunder, förkolningshastigheten var 2 millimeter per sekund). Ibland läggs en processegenskap som "cyklikalitet" till detta (förändringen du observerar sker en gång eller periodvis).

Efter att ha visat essensen av förändringen, fortsätter de vanligtvis att beskriva processen som en sekvens av "tillstånd" för detta ändamål, vanligtvis hela tiden för observation