Hver ting er en form for manifestation af uendelig mangfoldighed.

Kozma Prutkov

Introduktion til eEPC-notation

I øjeblikket er der mange forskellige principper for grafisk fremstilling af forretningsprocesser, kaldet notationer. Hvorfor er der så mange af dem? Dette spørgsmål er blevet stillet af alle, der står over for behovet for at beskrive forretningsprocesser i årtier. Lad os se på årsagerne. Der er tre af dem (efter min mening):

• - Forskellige opgaver. Ikke alle notationer er lige praktiske til at løse forskellige problemer. For eksempel kan en notation være praktisk til en forretningsproces på øverste niveau, men slet ikke praktisk til at beskrive en arbejdsgang.

Der er forskellige udviklere af sådanne notationer. I anden tid Forskellige udviklere forsøgte at komme med nye principper til at beskrive kredsløb. Det gjorde de ud fra gode intentioner, når de i praksis stødte på en situation, hvor den notation, de brugte, ikke kunne afspejle de nødvendige finesser (eller ikke var klar). Nogle gange blev sådanne notationer i evolutionsprocessen så at sige parallelle, dvs. se anderledes ud, men løse de samme problemer.

Ønsket om at skille sig ud. Det er, når der af ukendte årsager pludselig dukker en ny notation op, som ikke har noget udestående i sig selv, men af ​​en eller anden grund bliver promoveret af sin skaber som den mest perfekte knowhow. Dette sker stadig i dag.

Formålet med denne artikel er ikke at overveje alle slags notationer (jeg nævner bevidst ikke deres navne), men at dvæle ved en detaljeret beskrivelse af notationen, som jeg valgte til mine projekter i en lang søgen efter den mest optimale mulighed.

Hvis nogen er interesseret i at finde ud af, hvilke andre notationer der findes, og hvad de bruges til, planlægger jeg at gøre det i en anden artikel, som vil hedde “Lad os tale om notationer,” men det er stadig i planerne.

Det er tid til at starte vores historie om den meget interessante, enkle og praktiske eEPC-notation (oversat: udvidet beskrivelse af begivenhedskæden af ​​processer). Dens bogstavelige oversættelse afslører også dens hovedformål: en beskrivelse af kæden af ​​forretningsprocesser. Den vigtigste "funktion" i notationen er dens "begivenhed"-princip, som vi vil overveje i detaljer.

Hvad er fordelene ved eEPC-notation:

1. For det første er dette ikke helt en notation i sin rene form. De der. hvis der i nogle notationer er et strengt sæt af elementer og regler for deres brug (ellers bliver alt forvirret), så giver eEPC-princippet dig mulighed for at tilføje dine egne elementer. Hvordan sikres dette? Selvfølgelig er der en vis “kerne”, som alt er bygget op omkring, dvs. et sæt klare regler, som et diagram er opbygget efter, og som det derefter læses efter. Derudover kan du tilføje dit eget element, inkludere reglerne for dets brug i din egen virksomhedsstandard (for at udelukke amatøraktiviteter, der kan forvirre diagrammet og komplicere dets læsbarhed), og det er det! Dette er et meget vigtigt punkt. Derudover kan du angive andre begrænsninger og regler i din virksomhedsstandard.
2. eEPC indeholder logiske elementer. Dette giver dig mulighed for at bygge diagrammer med betingelser, som er nødvendige for at beskrive aktiviteten ("hvis kontrakten er aftalt, så ...., ellers ...")
3. Enkelheden af ​​elementerne giver dig mulighed for at tegne diagrammer både i software og på enhver anden måde, selv på papir, vil du ikke blive forvirret.
4. eEPC er så let at lære og forstå, at det kan bruges i virkelige aktiviteter, og ikke bare samle støv i skabet. Det vil tage omkring 2 timer at lære reglerne (hvis eleven ønsker det).

Selvfølgelig, som alt i denne verden, har det også sine ulemper. Men rationel brug reducerer dem til et minimum. Den største ulempe er efter min mening det faktum, at hvis vi bruger simple værktøjer (det vil sige programmer til at tegne diagrammer og ikke til modellering af forretningsprocesser), så har vi ikke en enkelt database med objekter. Derudover er det vanskeligt at kontrollere input og output (du skal kontrollere dem, dvs. komme med en måde til en sådan kontrol, hvis det er nødvendigt). Men på den anden side koster brugen af ​​komplekse forretningsprocesmodelleringsværktøjer meget imponerende summer, og et projekt, der bruger dem, måles i millioner. Og så har vi et meget økonomisk og forståeligt værktøj. For at være mere præcis relaterer denne ulempe sig specifikt til den beskrivelsesmetode, jeg overvejer, dvs. ved hjælp af MS Visio eller lignende software. Hvis du bruger specialiserede systemer til at beskrive forretningsprocesser, der understøtter objektdatabaser, så kan denne ulempe undgås. Nå, det er tid til at starte...

Den vigtigste "kerne" i eEPC-notationen

Som jeg allerede har nævnt, indeholder den bogstavelige oversættelse af eEPC akronymet begrebet begivenhedsrigt. Dette er et meget vigtigt punkt, som hele princippet om at konstruere kredsløbet er baseret på. Så der er to nøglebegreber: "Begivenhed" og "Funktion". Når nogen først forsøger at tegne deres proces i form af et eEPC-diagram, opstår spørgsmålet ofte, hvad er forskellen mellem en hændelse og en funktion? Du skal klart forstå dette, ellers får du et uforudsigeligt resultat. Altså: en begivenhed er en kendsgerning, at noget sker, og den har ingen varighed i tid, eller denne tid har en tendens til nul (eller er ligegyldig). Desuden forårsager en begivenhed altid behovet for at udføre en funktion, og udførelsen af ​​en funktion ender altid med en begivenhed. Lad mig forklare med et eksempel. Telefonen ringer. Lederen tog telefonen til en telefonsamtale. I dette tilfælde er "Telefonen ringer" en begivenhed. Telefonsamtale er en funktion. Samtalen er slut (lægger røret på) - endnu en begivenhed. Således observeres en hændelseskæde: Opkald - samtale - afslutning af opkald. Og at afslutte opkaldet vil sandsynligvis kræve, at du udfører en ny funktion: optagelse af resultatet af opkaldet osv.

Lad os prøve at tegne det. Først skal du finde ud af, hvordan begivenheds- og funktionselementerne vises.

Disse to simple elementer danner grundlag for reglerne for beskrivelse af forretningsprocesser i eEPC-notation. Jeg tror, ​​jeg skal sige et par ord om de anvendte farver. Hvis du stødte på beskrivelser af processer i andre notationer, var de som regel sort/hvide. Og det er korrekt, der bør ikke være en åbenlys afhængighed af indholdet af farven, fordi diagrammet kan tegnes med blyant på papir, printes på sort/hvid printer osv. I dette tilfælde (i eEPC-notationen) har det historisk udviklet sig, at elementerne har bestemte farver. Ikke for at sige, at dette er nødvendigt, men vanen er udviklet, og opfattelsen i elektronisk form er bedre - du kan straks se, hvad der er hvad. Disse farver kan betragtes som en anbefaling. Hvorfor er de sådan? Jeg er ikke helt sikker, men det forekommer mig, at fordi ARIS-virksomheden, da den understøttede eEPC-notation i sit produkt, gav dem sådanne farver, "skød de rod." Forresten, nogle gange kaldes denne notation også "ARIS", "ARIS EPC", hvilket ikke er helt korrekt, fordi ARIS opfandt ikke denne notation, men understøttede den i sitgram. Generelt anbefaler jeg at bruge farver. Det vigtigste er, at formen på selve elementerne ikke bør være den samme (dvs. kun afvige i farve), fordi i sort/hvid kan dette forårsage forvirring. Der er andre regler, der gør det muligt at gøre eEPC-diagrammet "harmonisk", vi vil tale om dem.

Så der er en begivenhed, der er en funktion. Hvordan er de forbundet?

Vi ser, at begivenhed1 førte til behovet for at udføre en bestemt funktion, som endte med begivenhed2. Hvis for eksempel med et telefonopkald, ville det være sådan her:

Forbindelseshændelsen - funktion - hændelsen vises normalt fra top til bund i én linje eller fra venstre mod højre. Kædens retning er angivet med forbindelseslinjer med pile. For at gøre diagrammet mere visuelt giver notationen flere standardelementer:

• Stilling (performer). Den, der udfører denne funktion
• Information. Enhver information, der bruges til at udføre en anden funktion end dokumentarisk information. For eksempel, telefon opkald, instruktioner til udførelse af en operation mv.
• Dokument. "Dokument"-elementet er beregnet til at vise informationsmedier (papir eller elektronisk). De der. præsentation af information i en bestemt struktur.
• Program (applikation). Softwaren, der bruges til at udføre funktionen.

Alle andre elementer er hjælpeelementer og er praktisk talt ikke reguleret af kravene i selve eEPC. Der er dog ingen hindring for at tilføje dine egne elementer. Hovedsagen er at rette dette i en intern standard, så der er en fælles forståelse af, hvordan de ser ud, og hvorfor de bruges. En sådan udvidelse er ikke i strid med kravene, hvis begivenhed-funktion-event-forbindelsen ikke er overtrådt, og har kun til formål at forbedre opfattelsen af ​​information eller tilpasse beskrivelsesreglerne til eventuelle branchespecifikke forhold. Jeg tilføjede mit eget sæt af elementer, som jeg vil diskutere nedenfor.

Det er også nødvendigt at finde ud af, hvordan de overvejede elementer skal placeres. Alle disse elementer skal være relateret til funktionen på den ene eller anden måde. Dette er en generel regel: intet andet element end en funktion er knyttet til en hændelse. De der. alle disse elementer skal være forbundet med pile til funktionen. Hvad angår pilene og deres retninger: Det er generelt accepteret, at hvis der ikke er nogen retning for transmission af information, vises der kun en linje i stedet for en pil. Hvis information kommer ind (kommer ind i input), så er pilens retning fra objektet til funktionen, hvis det kommer ud, så omvendt.

Et par flere ord om placeringen af ​​disse elementer på diagrammet, og vi kan tegne vores diagram igen, hvilket tydeliggør udførelsen af ​​opkaldsbehandlingsfunktionen. Der er ingen strenge krav til arrangementet af elementer, men det er sædvanligt at vise dem ens på alle diagrammer (for ensartethed og harmoni af diagrammet). For at forene det ydre udseende af grafiske diagrammer over forretningsprocesser skal sådanne regler nedfældes i en intern standard og følges. Lidt senere vil jeg give nogle anbefalinger i denne sag. Lad os nu tegne vores diagram igen:

Vi ser, at operatøren behandler et indgående opkald, handler i overensstemmelse med reglerne for behandling af indgående opkald og bruger CRM-programmet til dette. Hverken indgående eller udgående dokumenter bruges.

Som jeg allerede har nævnt, er en af ​​styrkerne ved notation dens elementer af logik. Samtidig er dette et af de sværeste øjeblikke at forstå. Derfor vil jeg først give et eksempel, og derefter vil vi separat behandle logikkens elementer.

I vores eksempel, lad det være sådan: Hvis kunden er interesseret, udfører salgschefen yderligere arbejde med ham og fremsætter et kommercielt tilbud, som han sender med posten ved hjælp af MS Outlook-e-mail-klienten. Hvis der ikke er interesse, er opkaldsbehandlingen afsluttet. I I virkeligheden Det ville være rart at bruge reglerne for at afslutte et opkald, men det er bare mig, forresten, lad os forenkle det for nu. Her er hvad der sker:

Logiske elementer i eEPC-notationsdiagrammer

Logikkens elementer er enkle, men der er specifikke funktioner og regler for at sikre, at diagrammet er logisk og entydigt fortolket. For det meste vigtig regel, som skal overholdes 100%: logiske beslutninger kan kun træffes, når en funktion udføres. De der. efter en begivenhed kan der ikke være nogen forgrening. Hvorfor? For i dette tilfælde er det i modstrid med selve konceptet om en begivenhed - det er enkelt og øjeblikkeligt, uden eksekveringstid. Hvis telefonen for eksempel ringer, og en person sidder og tænker på, om han skal tage telefonen eller ej, vil dette teoretisk set allerede være en funktion, hvor vedkommende træffer en beslutning. Men i praksis, herunder sund fornuft, overtræder han reglerne for behandling af opkald, fordi... han får løn for at behandle disse opkald, og der er ikke noget at diskutere her (generelt som vist i diagrammet).

I alt er der 3 forskellige elementer af logik:

• I. Når to eller flere hændelser indtræffer samtidigt;
• ELLER. Når en eller flere begivenheder kan ske, men mindst én skal ske;
• EKSKLUSIV ELLER. Enten det ene eller det andet. De der. to muligheder er umulige på samme tid.

Som du kan se, er der to muligheder for grafisk repræsentation af logiske elementer. De er ikke anderledes, helt alternative. Jeg tog dem begge med, fordi... i praksis kan begge muligheder ses i forskellige kilder. Hvilken man skal bruge er op til dig. Jeg kan bedre lide den første.

Nu skal du forstå brugen af ​​logiske elementer. Lad os først se på de muligheder, vi støder på, og derefter gå videre til et eksempel. Lad os se på hvert element separat.

Logisk element "AND". Når en funktion kræver, at flere hændelser forekommer samtidigt:

Eksempel: Hvis indberetningsperioden er lukket (begivenhed 1), og fristen for indsendelse af rapport til lederen er nået (begivenhed 2), udarbejder medarbejderen en månedlig rapport.

Forbindelse af elementer, hvis der opstår flere hændelser ved udførelse af en funktion:

Eksempel: Noget arbejde er udført med en kunde. To begivenheder blev registreret på samme tid: gensidige forlig blev forliget (begivenhed 1), loven blev underskrevet (begivenhed 2). I praksis forekommer denne anvendelse ikke ofte. Som regel, hvis mange handlinger kombineres i en funktion

Forbindelseselementer, hvis hændelsen opstår ved udførelse af flere funktioner:

Eksempel: Lagerholderen afhentede ordren (funktion 1), operatøren udstedte dokumenter (funktion 2), varerne er klar til forsendelse (hændelse).

Forbindelse af elementer, hvis forekomsten af ​​en hændelse fører til udførelse af flere funktioner:

Eksempel: En forsendelse af varer er ankommet (hændelse). Samtidig begynder forsendelsen af ​​varer, der tidligere er bestilt af kunder, og placeringen af ​​de resterende varer på lageret.

Logisk element "ELLER".

Forbindelse af elementer, hvis en af ​​hændelserne kan få funktionen til at blive udført:

Eksempel: En ansøgning er modtaget telefonisk (begivenhed 1) eller en ansøgning er modtaget pr e-mail(hændelse 2) vil føre til behovet for at behandle det.

Forbindelseselementer, hvis én funktion kan rejse mindst én hændelse:

Eksempel: Der er udarbejdet en faktura på varer og sendt til fremsendelse til kunden. Fakturaen kunne sendes pr. post (begivenhed 1), pr. fax (begivenhed 2).

Logisk element "EKSKLUSIVT ELLER".

En forbindelse af elementer, når én og kun én af begivenhederne er nødvendig for at udføre en funktion:

Eksempel: Kunden kom personligt til butikken (begivenhed 1) eller lavede en bestilling via internettet (begivenhed 2). Det er nødvendigt at sende varerne (funktion 1).

Forbindelse af elementer, hvis der som følge af udførelsen af ​​funktionen højst opstår en af ​​følgende hændelser:

Eksempel: Beslutningen er enten truffet eller ej.

Forbindelse af elementer, hvis hændelsen indtræffer efter, at én og kun én af funktionerne er blevet udført.

Eksempel: Varerne blev leveret (hændelse 1) enten af ​​vores egen transport (funktion 1) eller af et transportfirma (funktion 2)

Korrekt anvendelse af logiske elementer kræver en vis øvelse. Men det er ikke svært. Det skal bemærkes, at ikke alle overvejede kombinationer er udbredt i praksis (og generelt er dette bestemt af analytikerens måde at tænke på). Prøv at anvende logikkens elementer i praksis. Hvis du har problemer, så skriv til mig, jeg vil prøve at hjælpe.

Udvidelse af notationen med dine egne elementer

Som jeg allerede har sagt, er eEPC ikke ligefrem en notation, men snarere regler for beskrivelse. Og disse regler forbyder ikke at tilføje dine egne elementer til diagrammet. Det vigtigste er, at disse elementer er forståelige, og at der er et dokument, hvor sådanne udvidelser af elementer er registreret. Eksempelvis bruger jeg følgende tillægselementer, som er opstået gradvist i processen med at beskrive reelle processer for forskellige opgaver, fra simpel beskrivelse til opsætning af opgaver til automatisering.

Datafil. Bruges, hvis en handling resulterer i, at en datafil oprettes, eller en fil bruges til at udføre en handling.

Database. Bruges til at beskrive informationsstrømme mellem automatiserede systemer.

Kartotek. Bruges til at vise en papirfil eller et arkiv.

Materiale flow. Bruges til at angive indgående og udgående materialestrømme, samt ressourcer, der forbruges under udførelsen af ​​en proces. Materialeflowet vises til venstre for de ledsagende dokumenter.

Informationsklynge. Bruges til at betegne struktureret information (entitetsrepræsentation). Diagrammet kan bruges til at indikere dokumenter genereret programmatisk ved brug af brugerapplikationer. I dette tilfælde er Cluster-elementet placeret til venstre for det tilsvarende dokument. De der. angiver, at brugeren ikke kun har oprettet et papirdokument, men også har lavet en kopi af det i programmet.

Aftaler om reglerne for placering af figurer på et diagram

Selve eEPC-notationen stiller ikke strenge krav til arrangementet af elementer i forhold til hinanden, selvom det er sædvanligt at tegne et diagram fra top til bund eller fra venstre mod højre. Hvis dette ikke er forenet i tilfælde af flere specialisters arbejde, kan en slags "vinaigrette" resultere. For at undgå dette anbefales det at udvikle og godkende dine egne regler for arrangement af elementer. Jeg overholder (og anbefaler) følgende regler:

• Rækkefølgen af ​​begivenheder og funktioner er arrangeret fra top til bund (bedre) eller venstre mod højre (hvis der ikke er nok plads);
• Elementer, der angiver udøvere, er placeret til højre for funktionerne;
• Indgående dokumenter er øverst til venstre i funktionerne; pilens retning fra dokumenter til funktioner;
• Udgående dokumenter nederst til venstre i funktionerne; pilens retning fra funktion til dokumenter;
• Informationselementet er placeret nederst til højre i funktionen. Hvis der ikke er plads nok, tillades en vilkårlig placering, så tæt på funktionen som muligt;
• Applikationselementet er placeret øverst til højre i funktionerne. (hvis fillager, der ikke er rapporter, bruges til dette, vises de på samme måde). Link uden pil.
• Elementerne "Database" og "Kortindeks" er arrangeret tilfældigt;
• "Material Flow"-elementet er placeret til venstre for de medfølgende dokumenter og er forbundet med dokumentet med en linje uden en pil;
• "Klynge"-elementet, når det bruges i kombination med "Dokument"-figuren til at betegne et dokument i elektronisk form, er placeret til venstre for det tilsvarende dokument.

For eksempel: Lønassistenten beregner løn baseret på de "Brigade Order"-dokumenter, som han har fået udleveret. I den forbindelse er han vejledt af dokumentet ”Forskrifter vedr løn", er beregningen udført i programmet "1C: ZiK". Resultatet af beregningen er dokumentet "Erklæring".

Identifikation af elementer i et diagram

En kompetent tilgang til at beskrive forretningsprocesser involverer som bekendt deres identifikation, dvs. når hver proces har sit eget kodenavn. Derfor har individuelle funktioner i en proces også deres egne navne og identifikatorer.

Tallene "Dokument" og "Funktion" skal identificeres på diagrammet.

Dokumentet identificeres ved i øverste venstre hjørne at angive koden for rapporten eller dokumentet i overensstemmelse med registret. Dokumenter modtaget fra leverandører af varer og tjenester (indgående) identificeres kun ved navn.

En funktion identificeres ved at angive funktionssekvensnummeret for en given procesgruppe. De der. Funktionsnummeret begynder altid med procesgruppekoden. Spørgsmål med at identificere procesgrupper ligger uden for rammerne af denne artikel, vi vil overveje dem separat. Desuden bør du lære at identificere processer, før du begynder at beskrive dem, ellers kan der være et ønske om at beskrive alle virksomhedens aktiviteter på ét diagram, som det nogle gange forsøges.

Derfor vil jeg nu kun vise med et eksempel, hvordan dette kan repræsenteres i diagrammet. Lad os vende tilbage til eksemplet med opkaldsbehandling. Lad os antage, at vi tildelte koden "04" til salgsafdelingen og koden "VK" til processen med at behandle indgående kontakter. Så vil diagrammet antage følgende form (identifikation er fremhævet med rødt for tydelighedens skyld). Dokumentkoden angiver dokumentets serienummer i det almindelige dokumentregister (vi vil også overveje dette separat, når vi kommer til at undersøge dokumentflowsystemet).

Feedback display

Når man bygger modeller, er der ofte behov for at udføre en proces cyklisk i henhold til nogle forhold eller behovet for at vise beslutningstagernes aktiviteter. I dette tilfælde taler vi om feedback. For at vise kontrolfeedback bruges princippet om "direkte inklusion" i processen med en ekstra kontrolfunktion med efterfølgende forgrening (det logiske element "Eksklusiv ELLER" bruges). For eksempel:

Tekstbeskrivelse af processer

Uanset hvor hårdt vi prøver at vise en forretningsproces på et diagram, vil vi ikke være i stand til at opnå fuldstændige detaljer, ellers kan vi hænge fast i endeløse kæder af elementer og forhold. For at undgå dette, samt at tilføje information til procesbeskrivelsen, der ikke kan vises grafisk, er beskrivelsen suppleret med tekstakkompagnement. Til dette formål udvikles forskellige tekstskabeloner, som udfyldes under beskrivelsesprocessen. Formerne for sådanne skabeloner kan være forskellige og omfatte separate sektioner, der beskriver input og output, forbrugte ressourcer, anvendt software osv.

I det enkleste tilfælde kan en skabelon til forretningsprocesbeskrivelse se sådan ud:

Forretningsproces:	Behandler en indgående kontakt	04.VK
Proces funktioner:
Navn	Beskrivelse	Nummer på diagrammet
Behandler et indgående opkald	Når et indgående opkald ankommer, behandler operatøren opkaldet i overensstemmelse med reglerne for behandling af indgående opkald. Afslører kundernes interesse og giver information om tjenester	04.VK.01
Dannelse af et kommercielt tilbud	Hvis kunden er interesseret, videregiver operatøren kontakten til salgschefen. Salgschefen udarbejder et kommercielt forslag og sender det til kunden via e-mail	04.VK.02
Procesindikatorer:
Navn	Metode til evaluering/måling
Antal fejl	Database statistik

Ud over omfanget af denne artikel er følgende: vigtige emner, såsom indsamling af information, fremhævelse af forretningsprocesser, nedbrydning, fremhævelse af indikatorer. Vi vil helt sikkert studere disse spørgsmål i fremtidige numre.

Noder til erhvervslivet

Artiklen blev publiceret i magasinet "Management News" i januar 2012.

Musikken har bundet os
Er blevet vores hemmelighed

Alle epigrafer til denne artikel er taget fra sangen "Music Has Connected Us" af bandet Mirage.

I klassisk musik musikeren er et instrument i komponistens hænder og spiller efter noderne. I populærmusikken skriver musikere oftest selv musikken, og improvisationskunsten involverer slet ikke noder. Ganske vist bliver berømte improvisationer, der er blevet klassiske, så oversat til noder, og det er de blevet nyt liv: arrangementet ændres, en ny lyd og stemning tilføjes.

Ligeledes kræver en virksomhed, der er vokset som en dygtig improvisation til at flytte til et nyt niveau, at sætte fakta på papir for at analysere, hvad der sker, og træffe beslutninger om forbedring.

På det seneste kan du i stigende grad finde beskrivelser af forretningsprocesser (BP'er) lavet, som de siger, "alene". Det var denne omstændighed, der foranledigede skrivningen af ​​artiklen. Desværre var de fleste af disse dokumenter, som jeg tilfældigvis så, til lidt brug for seriøse forretninger. Dermed ikke sagt, at de grundlæggende var forkerte, men en række udeladelser forkælede dem så meget, at jeg straks ville glemme deres eksistens. Hvilken slags udeladelser disse er, og hvordan man håndterer dem, vil vi finde ud af i løbet af denne artikel, hvor vi gradvist nærmer os essensen af ​​problemet. Vi vil forsøge at undgå en lang række tekniske detaljer, men vi kan ikke helt undgå dem, fordi... samtaleemnet kræver det.

Er det virkelig mig
Jeg kan ikke finde svaret på alt

Denne artikel henvender sig til dem, der ønsker at spare på at beskrive forretningsprocesser ved at overlade udarbejdelsen af ​​dokumentet til interne specialister. En beskrivelse af forretningsprocesser er jo ikke obligatorisk for en virksomhed, og alt fungerer uden det. Men i enhver stabil virksomhed er der en mekanisme til at overføre myndighed, den kaldes "jobbeskrivelser". Hvis virksomheden er kompleks, og stillingen er nøglen, så er det nyttigt at tegne jobbeskrivelser for at gøre det lettere at forstå. Akkumulering af forretningsprocesser i generel beskrivelse nødvendigt for at gøre virksomheden mere gennemsigtig, især i forbindelse med salget.

Dokumentet "Beskrivelse af BP" bliver særligt relevant, så snart der er behov for omorganisering (eller, som det nu er på mode at sige, omstrukturering) af virksomheden. I dette tilfælde bruges dokumentet til at:

1. På det, som på et kampkort, marker essensen af ​​de planlagte transformationer,
2. Bring transformationsdeltageren opdateret,
3. Brug en pen og ikke dine fingre til at tildele opgaver til afdelingsledere og eksterne specialister.

Der er fordele ved selv at udarbejde dokumentet:

• Det virker billigere;
• Intern specialist, bedre bevandret i praksis i sin oprindelige virksomhed.

En tredjepartskonsulent skal først studere terminologien og nøglefunktionerne i emnet samt industristandarder. Dette tager tid. Sandt nok ved han bedre hvordan og hvad der skal beskrives. Der er visse regler, almindeligt accepterede notationer og speciel software. Et eksempel på en sådan notation kan ses i fig. 1 og fig. 2.

IDEF0 notation

Fig.1.

Et eksempel på beskrivelse af en strømforsyning ved hjælp af IDEF0

Fig.2.

Lad være med at forelæse os

Lad være med at forelæse mig
Mor, det nytter ikke noget

Har vi virkelig brug for dette? - Direktøren vil spørge, rimeligvis forudsat at overholdelse af alle standarder vil øge omkostningerne ved resultatet markant. En af de direktører, jeg kender, ræsonnerede sådan: “At invitere en tredjepartsspecialist er en dyr forretning, men vores opgaver er enkle - hvorfor har vi brug for alle disse notationer. Og specialisten, nogle gange tegner han noget med sine kroge klart, det er ikke praktisk at indrømme, så han er stadig bagud. Det er det, du skal betale for."

Jeg er enig, hvis opgaverne er enkle, hvorfor gider det så? Og hvis de er komplekse, så skal de forenkles og ikke kompliceres med fancy notation. Der er trods alt ingen åbenlyse fordele ved at bruge smukke kroge. Hvis der ikke er nogen åbenlyse, betyder det ikke, at der ikke er nogen. Disse regler og notationer er ikke opfundet, for at konsulenten ikke skulle kede sig... Enhver, der er involveret i erhvervslivet, ved godt, at ikke alt brugbart er indlysende. Nå, lad os se efter det skjulte positive, og for at gøre dette, lad os se på historien om problemet.

Markedet for beskrivelse af strømforsyninger har eksisteret i meget lang tid. Men i løbet af det sidste halvandet årti har den taget et hurtigt spring takket være fremkomsten ny industri- automatisering af regnskab og ledelse på virksomheder. Det voksende marked gav nytilkomne, der kom med nye notationer, en chance for at bryde igennem og satse deres plads. For eksempel på det russiske marked for et par stykker seneste år massive reklame- og informationskampagner fra IDS Scheers side (hovedleverandøren af ​​ARIS - se fig. 3) skabte et lag af specialister i at beskrive automatiserede processer.

Brug af ARIS-notation kræver store detaljer i forretningsprocesser.

Fig.3.

Implementering af systemer som ERP (ressourcestyring), CRM (kunderelationer), MRP (produktionsplanlægning) fører uundgåeligt til ændringer i processer, og hvis dette ikke er planlagt på forhånd, kan resultatet blive dårligere end ønsket. Derudover arbejder automatisering med information, hvilket betyder, at det er nyttigt at vide, hvilken information der genereres af hvem, hvor den kommer fra, og hvor den går hen. Men specielle notationer for at indføre automatisering har aldrig slået rod her og bruges sjældent.

Beskrivelsen af ​​forretningsprocesser i Rusland er en relativt ny tendens på trods af det imponerende antal GOST'er på dette område (3.1109, 34, ISO osv.). Nu, med kvaliteten af ​​beskrivelsen af ​​deres egne forretningsprocesser, er tingene bedst i banker. Faktum er, at i modsætning til andre kommercielle strukturer er en bank en infrastrukturorganisation, og den er derfor inden for de strenge rammer af regler, der er defineret ved lov. Banken opererer efter princippet om dagstyring. Som et resultat viser selv en forenklet beskrivelse af bankens forretningsprocesser (på russisk uden brug af notationer) sig at være mere detaljeret, fordi hviler på et fundament bygget på mængder af regler, der definerer standarder, terminologi, roller og regler. Disse standarder er det almindeligt accepterede sprog i bankmiljøet, og beskrivelsen af ​​forretningsprocesser vil være let at læse for enhver specialist.

I kommercielle strukturer kræver beskrivelsen af ​​forretningsprocesser en foreløbig ordbog over termer. Og når man begynder at forberede og koordinere det, står mange over for, at de samme ting hedder forskelligt i forskellige afdelinger. Går man i detaljer, viser det sig, at de forskellige navne virkelig betyder forskellige nuancer følelse. Koordinering af terminologi er en af ​​de mest arbejdskrævende processer til at beskrive en forretningsproces. Det er vigtigt at få denne proces op at køre. Jeg kan påtage mig det meste af arbejdet fra virksomhedens egne afdelinger, fordi behovet for at regulere virksomhedens aktiviteter fører til større organisering af processer og procedurer.

Når beskrivelse er nødvendig for automatisering, er den omvendte rækkefølge også mulig. Ændring af forretningsprocesser sker sideløbende med implementeringen af ​​informationssystemet, og beskrivelsen af ​​nye forretningsprocesser udføres "varmt i hælene" og er integreret i systemdokumentationen.

Personale

Jeg glemte alt
Vi er blevet undervist i så mange år

Mærkeligt nok er valget af notation og rigtigheden af ​​beskrivelsen mere kritisk for små og mellemstore virksomheder. Store virksomheder har normalt større procesfleksibilitet på grund af medarbejdernes udskiftelighed. For en mindre virksomhed, hvor eksekveringen af ​​kritiske punkter kommer ned til 2-3 beslutningstagere, kan en forkert angivelse af procesvejen give anledning til et fundamentalt forkert koncept for løsningen. Da resultatet er kritisk, så er værktøjet vigtigt, men hvordan vælger man det?

Hver notation er tilpasset til en specifik række opgaver. Vi vil betragte den mest presserende opgave som at ændre forretningsprocesser inden for rammerne af et ledelsesautomatiseringsprojekt. Til disse formål er der et godt sæt værktøjer, der er ret udbredte: disse er russiske GOST'er og de samme ARIS og IDEF samt EPC (fig. 4 og fig. 5).

EPC notation

Fig.4.

Beskrivelse af en forretningsproces ved hjælp af EPC

Fig.5.

Hvis en bog er skrevet på et bestemt sprog, så er det vigtigste at have en læser, der kan dette sprog og kan læse det. Baseret på dette er den mest almindelige standard til at beskrive BP den bedste.

Når du vælger en notation, er et andet vigtigt kriterium evnen til at bruge et velkendt softwareværktøj. For eksempel tilbød Microsoft Business Solution i 2002 On-Target notation til Navision informationssystemet, ledsaget af en speciel softwareløsning. Dette er netop tilfældet, når det er bedre at vælge noget andet - ikke kun kender ingen On-Target-notationen, men også softwaremiljøet vil kræve tid til at studere det. Et positivt eksempel vil jeg kalde brugen af ​​IDEF-notationen og Visio-programmet, som er meget udbredt og har det nødvendige sæt værktøjer til at tegne IDEF-diagrammer (fig. 6).

IDEF forretningsprocesser udført i Visio

Fig.6.

Naturligvis kan beskrivelsen af ​​strømforsyningen gøres ganske enkelt i ord, såvel som ved hjælp af forskellige symboler (efter din egen opfindelse), da det virker forståeligt. At have en sådan beskrivelse er bedre end ingenting, men det er stadig nyttigt at opretholde standarder.

Fylde og dybde af lyd

Jeg ved ikke, hvad der trækker mig her

1. vil tage lang tid
2. Nogle detaljer vil ændre sig under oprettelsen af ​​dokumentet.

En almindelig fejl er at forsøge at tilpasse beskrivelser, så de passer til notationen. For eksempel at forsøge at beskrive procedurer i ARIS-format, dvs. opnå tilsyneladende redundans i beskrivelsen, når det ikke er påkrævet.

Men mere almindelig fejl er utilstrækkelig dybde af dokumentet. Som følge heraf er resultatet et formelt dokument, der ikke er egnet til arbejde, pga alle vigtige detaljer skal afklares i processen.

En melodi er en sekvens af lyde, ikke noder.

Glem alt om denne dag
Ingen har brug for et argument

Det betyder, at strømforsyningen kan beskrives enkelt med ord, uden noter. Selvfølgelig er notationen mere korrekt, men det er ikke det, der er vigtigt. Beskrivelse BP er ikke et slutprodukt, men kun et værktøj til nye præstationer. Det betyder, at den skal tilpasses til videre aktiv brug. hovedproblemet De fleste af gør-det-selv-dokumenterne er ubelejlige at bruge. For eksempel bestod et sådant dokument af en beskrivelse af, hvad der blev lavet i Microsoft Word, og tegninger lavet i PowerPoint var frygteligt ubelejligt. Det viser sig, at dokumentet skal have følgende egenskaber:

1. Hav en klar rækkefølge og gruppering af afsnit, dvs. være konceptuelt holistisk (normalt betyder det, at hvis du har et koncept, så har du lært at bruge det);
2. Identificer tydeligt forretningsenheder og giv dem tydelige navne og nummerering;
3. Fremhæv tydeligt forretningsprocesser og giv dem også et klart navn og nummerering;
4. Elementer skal nummereres på en sådan måde, at forvirring undgås (dette gør søgningen meget lettere): F.eks. skal afdeling nr. 1 have nummeret afd.001 i dokumentet, og forretningsproces nr. 1 skal have nummeret BP001 ;
5. Dokumentet skal have en indholdssektion med en træstruktur;
6. En virksomhed er en integreret organisme og ingen forretningsproces hænger i luften - den er altid forbundet med andre forretningsenheder, forretningsenheder og afdelinger. For at afspejle disse forbindelser kan du bruge hyperlinks - dette vil gøre det nemmere at finde information og flytte fra et objekt til et andet.

Til dette formål kan du bruge enhver teksteditor, der understøtter hyperlinks.

Nogle mennesker tror, ​​at det i en professionel musikgruppe er nok at have en eller to rigtige musikere. Ingen oprigtig musikkender vil være enig i dette. Disse samtaler opstår på grund af manglen på fagfolk og kreative individer.

Virksomheder har lignende vanskeligheder. Der er få gode specialister, der kender deres virksomhed fra top til tå, og de har meget travlt. Ved at analysere forretningsprocesser på egen hånd sparer vi penge og sparer måske tid. Men det er ikke altid muligt at vælge de bedste til at beskrive strømforsyningen. Du kan overlade rutinen til kunstnere af lavere rang, men så er der risiko for at forsinke processen. Uvidenhed om principperne for at konstruere sådanne dokumenter medfører risiko for ineffektivitet (resultatet er ubrugeligt, det er det samme som dets fravær).

Den bedste kvalitet og hurtighed i dokumentforberedelse er mulig i en alliance med en nøglespecialist og en erfaren konsulent. Resultatet vil være et aftalt sprog til at beskrive forretningsprocesser (dvs. terminologien for virksomhedens forretning) og selve beskrivelsen i detaljer tilstrækkelig til at løse yderligere problemer.

Jeg gentager som svar på al overtalelse
De vil ikke adskille os, nej

Vi minder dig om, at alle epigrafer til denne artikel er taget fra sangen "Music Connected Us" af gruppen Mirage

En tredjepartskonsulent vil skrive et dokument i et notationssprog, der er forståeligt for andre konsulenter og ofte mere egnet til sagen. Forstår du ikke alle disse kroge? Men disse notationer er slet ikke komplicerede, måske er det værd at lære dem?

ARIS EPC-notationen, der bruges til at modellere forretningsprocesser i ARIS-værktøjssættet, er en sekvens af hændelser og funktioner, der afspejler logikken i at udføre indbyrdes forbundne handlinger med det formål at opnå et bestemt resultat.

ARIS EPC-modellen er beregnet til at beskrive algoritmen til at udføre en forretningsproces i form af en sekvens af hændelsesdrevne funktioner. ARIS EPC-modellen fokuserer på rækkefølgen af ​​funktioner, og til at beskrive forholdene i forretningsprocesmodellen anvendes hændelser og regler, som kan beskrive komplekse algoritmer til at eksekvere en forretningsproces.

Funktioner i ARIS EPC-modellen udløses af hændelser, for eksempel "Faktura modtaget til godkendelse", og slutter med begivenheder, for eksempel "Faktura er godkendt" eller "Faktura er ikke godkendt". Hvis der som følge af udførelse af en funktion kun er én mulighed for videre eksekvering af forretningsprocessen, dvs. Som følge heraf genereres der kun én hændelse, hvorefter den næste funktion kommer, hændelsen mellem disse funktioner muligvis ikke tegnes.

En forretningsprocesmodel af ARIS EPC-notation begynder og slutter nødvendigvis med en eller flere hændelser eller grænseflader til andre forretningsprocesmodeller. For at afspejle grænseflader bruges specielle objekter "Process Interface" - objekttypen "Function".

Ved oprettelse af en ARIS EPC-model kan der opstå situationer, hvor det samme dokument er et udgående dokument for en funktion og et indgående dokument for den næste. I disse tilfælde er det, for at forbedre modellens ergonomi, tilladt at bruge én dokumentrepræsentation med én indgående forbindelse (fra den funktion, hvori den oprettes eller justeres) og én udgående forbindelse (til den funktion, hvori den bruges) .

EPC-modellen kan ikke frakobles, dvs. Det er en fejl at placere ét objekt på modellen, som ikke er forbundet med de andre.

Placeringen af ​​dokumenter i forhold til funktioner er normalt følgende: øverst til venstre er indgående dokumenter, nederst til venstre er udgående dokumenter, udførende er normalt placeret til højre for funktionen.

Følgende oplysninger er angivet på ARIS EPC-modellen:

• udførte funktioner
• informationsressourcer for funktioner (indgående/udgående dokumenter)
• begivenheder
• procesgrænseflader
• logiske operatorer
• udøvere (stillinger, forretningsroller)
• Informationssystemer

Hændelsesnavngivningsregler i ARIS EPC

Begivenhedsnavnet skal indeholde et navneord og en verbal beskrivelse af tilstandsændringen. Eksempel: "Transaktion gennemført."

Funktionsnavngivningsregler i ARIS EPC

For at navngive en funktion skal du bruge dens rigtige navn. Navnet skal bestå af to dele - et verbalt navneord, der beskriver den udførte funktion, og et navneord, der angiver det objekt, det udføres på. Navnet på funktionen består af det korte navn på objektet, der starter med et stort bogstav, for eksempel "Søg efter kundekontakter."

Regler for navngivning af roller/stillinger i ARIS EPC

Navnet på forretningsrollen (Person Type) skal svare til essensen af ​​de ansvarsområder, som udøveren er tildelt. Som regel indeholder titlen sætningen "Ansvarlig for...". Jobtitler (stilling) skrives i overensstemmelse med bemandingstabellen.

Regler for navngivning af dokumenter

Objektet svarer til et dokument (Informationsbærer) (i papir og/eller elektronisk form). For at navngive dokumenter (uanset hvilket symbol der bruges), skal du bruge deres rigtige navn.

Regler for navngivning af informationssystemer i ARIS EPC

For at navngive informationssystemer (applikationssystemtype) skal du bruge deres etablerede navne.

Regler for navngivning af procesgrænseflader

Processgrænsefladen viser et link til en tilstødende proces. Navnet på procesgrænsefladen svarer til navnet på den model, der beskriver den tilstødende del af forretningsprocessen. Interfacet kan bruges til at referere til forretningsprocesmodeller, som ikke er en del af den forretningsproces, der beskrives.

"Jo tydeligere informationen formidles, jo hurtigere og mere præcis vil den blive opfattet af den person, den er rettet til." Denne sandhed har længe været aktivt brugt af marketingfolk, undervisere og forskere. Ledere blev heller ikke udeladt. Denne artikel diskuterer EPC-notation som en af ​​de mest populære moderne metoder, som giver dig mulighed for at gøre beskrivelsen af ​​komplekst arbejde ikke kun praktisk, men også meget mere præcis og forståelig for alle deltagere i projektet eller processen.

Historien om fremkomsten af ​​grafiske modelleringsstandarder

Nu, hvor udviklingstempoet af alle processer i samfundet vokser, og systemerne bliver mere komplekse, er ledelse som kunsten at påvirke mennesker også tvunget til at tilegne sig evnen til at styre systemer, i lighed med ledelse af tekniske systemer. I begyndelsen af ​​90'erne af forrige århundrede blev ordet " rekonstruktion Michael Hammer og James Champy introducerede først denne definition i deres bog Reengineering the Corporation." Og efter det dukkede begrebet "teknik" af forretning op. Hvis den første er redesign af forretningsprocesser, så er den anden design af et effektivt organisationssystem fra bunden.

Denne tendens indikerer, at søgningen efter metoder til at beskrive og endda opbygge en organisation som et system har stået på i lang tid og med stor succes. Hvis vi betragter ledelse ikke kun som en kunst, men også som en videnskab, så har den, som enhver anden videnskabelig disciplin, brug for sine egne specifikke notationssystemer til fastsættelse af formler og love. Sådanne systemløsninger bruges med succes af ingeniører inden for mange aktivitetsområder, kemikere, fysikere, matematikere osv.

Det socioøkonomiske system, som er organisationen, er meget mere forskelligartet end naturvidenskaberne, og der er endnu ikke fundet en enkelt form for registrering af "aksiomer" og ledelsesformler. Men vejen er blevet asfalteret. Og det begynder med de velkendte flowcharts, som giver os mulighed for at beskrive proceduren for at opnå et givet resultat. Men desværre er de visuelle muligheder i et flowchart meget begrænsede, og det giver dig ikke mulighed for at vise hele rækken af ​​elementer i forretningsledelsesprocessen.

I dag er der udviklet en hel del muligheder for flowcharts, som du kan skildre interaktionen mellem mennesker og systemer i processen med kreativ aktivitet. De kombineres i sæt af værktøjer for mere fuldstændigt at beskrive alle aspekter af virksomhedens aktiviteter. Sådanne værktøjer kaldes modelleringsmetoder. De mest komplette og velkendte er tre af dem:

• ARIS (Arkitektur af integrerede informationssystemer);
• SADT (Structured Analysis and Design Technique);
• UML (Unified Modeling Language).

(klik for at forstørre)

For fuldt ud og omfattende at beskrive en virksomheds aktiviteter er det nødvendigt at bruge forskellige grafiske standarder, som er inkluderet i metoden og kaldes notationer. Men for at løse snævre problemer er det nok at vælge den notation, der blev opfundet til den tilsvarende beskrivelse. Ovenfor er en af ​​de grafiske notationstyper, der vil blive diskuteret i denne artikel.

Egenskaber ved EPC-notation

EPC (Event-driven Process Chain) modelleringsnotationen er fokuseret på at bygge interaktionsalgoritmer i processen med at udføre et specifikt job. Dens hovedelementer er:

• begivenheder, der starter eller afslutter arbejdet;
• handlinger (arbejde), der overfører systemet fra en tilstand til en anden;
• udførende af værket;
• ressourcer og arbejdsresultater (input og output).

Denne notation er en integreret del af ARIS-metoden, forfattet af Wilhelm-August Scheer, udviklet i begyndelsen af ​​1990'erne. I slutningen af ​​det foregående afsnit viser figuren en oversigt over processen med at standardisere arbejdet ved hjælp af EPC-notationen. Lad os overveje funktionerne ved at beskrive en organisations forretningsprocesser ved hjælp af denne notation. Selv uden at dykke ned i essensen af ​​diagrammet, fanger vekslen mellem røde og grønne elementer straks øjet - dette er kæden af ​​begivenheder og processer, der er iboende i notationens navn. Sammensætningen af ​​modelelementerne er bestemt af fire hovedpositioner.

Det er sandsynligt, at vi i løbet af beskrivelsen af ​​procesmodellen kommer til at bruge et informationssystem. Så kan vi vise det ved hjælp af specielle tre-niveaus sæt af elementer ( orange farve).

1. IS – informationssystem.
2. IC modul.
3. IS funktion.

Databaser har traditionelt deres eget billede - i form af en cylinder. Selvom at bruge dem uden et informationssystem og et system uden en database forekommer mig umuligt i dag. For at vise logikken i overgange mellem funktioner bruges logiske operatorer, som hjælper med at specificere betingelserne for udførelse af parallelt arbejde eller forekomsten af ​​begivenheder. De viser muligheder for at flette eller forgrene både funktioner og begivenheder. Der er kun tre logiske operatorer: "AND", "OR" og "Exclusive OR". Forskellige systemer kan bruge forskellige grafiske symboler.

Notation og brug af logiske operatorer i EPC-notation

Algoritme til at konstruere et EPC-diagram

Som vi kan se, er den utvivlsomme fordel ved denne notation det intuitive sæt af elementer og regler for konstruktion af diagrammer. For at lave procesdiagrammer anbefales det at bruge specielle procesmodelleringsprogrammer. For EPC er dette primært ARIS-systemet. Men det er dyrt og ret komplekst og bruges ikke til små periodiske projekter for at strømline afdelingernes aktiviteter.

Enkelheden og populariteten af ​​notationen stimulerede skabelsen af ​​andre værktøjer til at tegne forretningsprocesser, herunder i EPC-notationen. Den enkleste af dem er Visio - en af ​​skabelonerne i den hedder "EPC Diagram". Det mest nyttige værktøj for mig er Business Studio-systemet. I den kan du, ud over evnen til at tegne en proces, automatisk generere et dokument (Process Regulations) og arbejdsinstruktioner til dets deltagere, hvilket væsentligt forenkler den rutinemæssige del af processen med at udvikle præstationsstandarder.

Farver og betegnelser for sekundære elementer kan variere lidt mellem programmer, men almindelige regler altid konsekvent. Eksemplet med EPC-notation præsenteret i artiklens første afsnit afspejler en forenklet algoritme til at arbejde med denne notation. Lad os tage det skridt for skridt.

Efter at have gennemført alle trinene, modtager vi en detaljeret plan for udførelse af processen, forståelig for dens udførende. Og klart definerede hændelser og resultater giver dig mulighed for at indstille kontrolpunkter for alle væsentlige stadier af processen. Og jeg henviser dig igen til eksemplet med den visuelle model, der er postet i begyndelsen af ​​artiklen.

Fordele og ulemper ved EPC-notation

Ud over enkelhed og tilgængelighed har brugen af ​​EPC følgende fordele.

1. Giver dig mulighed for at vise alle væsentlige organisatoriske elementer på ét diagram (i modsætning til et simpelt rutediagram).
2. Den kan bruges på forskellige niveauer af modellen - til at beskrive både globale processer og lave detaljerede instruktioner på grund af det faktum, at hver funktionsblok kan blive en delproces.
3. Det er nemt at lave kompleks parallelisering af en proces, da du kan indtaste et hvilket som helst antal hændelser i en serie.

Samtidig blev denne notation ikke den eneste på grund af følgende mangler.

1. Behovet for at komme med begivenheder for hver selv mindre handling komplicerer i høj grad ordningen.
2. Organisatoriske sammenbrud skyldes sandsynligvis ubelejlig sporing af opgaver.
3. Højkvalitetsregistrering af input og output fører til en overbelastning af kredsløbet med rektangler og pile, som begynder at skære hinanden og derved yderligere komplicere opfattelsen af ​​kredsløbet.
4. Ved parallelisering af arbejde er det meget svært at afspejle de udførende. Hvis én person udfører en gruppe funktioner, bliver billedet mere kompliceret med pile. Hvis der er flere kunstnere, eller vi ikke ønsker at tegne lange pile, skal vi duplikere "ovalerne" med kunstnerne. Alt dette kan meget snart føre til fuldstændig forvirring i diagrammet.

Fra min egen erfaring kan jeg sige, at lokale driftsprocedurer tegnet i denne notation er ret praktiske for både udvikleren og brugeren af ​​instruktionerne. Notationen er også velegnet til projektledere, da den giver dem mulighed for visuelt at planlægge fordelingen af ​​arbejdet i et projekt i et sprog, der er intuitivt for forskellige projektdeltagere. Og til at udvikle en mere kompleks multi-level model for virksomhedsaktivitet er andre modelleringsnotationer mere egnede, som vi vil overveje i de følgende artikler.

1. Et EPC-funktionsdiagram skal begynde med mindst én starthændelse (starthændelsen kan følge procesgrænsefladen) og slutte med mindst én sluthændelse (sluthændelsen kan gå forud for procesgrænsefladen).

2. Begivenheder og funktioner skal veksles under processen. Beslutninger om det videre forløb af processen træffes af funktioner.

3. Det anbefalede antal funktioner på diagrammet er ikke mere end 20. Hvis antallet af funktioner på diagrammet væsentligt overstiger 20, så er der mulighed for, at processerne på øverste niveau er forkert identificeret, og modellen skal justeres .

4. Begivenheder og funktioner skal strengt taget indeholde én indgående og én udgående forbindelse, der afspejler processens fremskridt.

5. Hændelser og udsagn omkring funktionen i ovenstående diagram ( Fig.16), bør være de indledende/resulterende begivenheder og udsagn i funktionsnedbrydningsdiagrammet ( Fig.17).

Figur 16. Procesdiagram, hvor funktion 1 forekommer	Figur 17. Dekomponeringsdiagram af funktion 1

6. Diagrammet bør ikke indeholde objekter uden en enkelt forbindelse.

7. Hver fusionsoperatør skal have mindst to indgående forbindelser og kun én udgående forbindelse, en filialoperatør skal kun have en indgående forbindelse og mindst to udgående. Operatører kan ikke have flere indgående og udgående forbindelser på samme tid.

8. Hvis en operatør har en indgående forbindelse fra "event"-elementet, så skal den have en udgående forbindelse til "function"-elementet og omvendt.

9. En enkelt hændelse må ikke efterfølges af en "ELLER" eller "XOR" operator.

10. Operatører kan kun kombinere eller forgrene funktioner eller kun begivenheder. Samtidig sammenlægning/afgrening af en funktion og en begivenhed er ikke mulig.

11. Den operatør, der fordeler filialer, og den operatør, der slår disse filialer sammen, skal matche. Det er også muligt at bruge filialoperatøren "AND" og fagforeningsoperatøren "ELLER".

Eksempler på acceptable situationer ( Fig.18, Fig.19, Fig.20, Fig.21):

Figur 18	Figur 19	Figur 20	Figur 21

Et eksempel på en uacceptabel situation ( Fig.22).