Hva er forretningsprosesser? Eksempler vil tillate oss å forstå dette emnet bedre, så vi vil bruke dem aktivt.

generell informasjon

La oss først finne ut hva forretningsprosesser er. Dette er navnet som er gitt til den totale sekvensen av visse handlinger som tar sikte på å transformere ressursene som mottas ved inngangen til et ferdig produkt som har verdi for forbrukerne ved produksjonen. Takket være denne definisjonen kan du forstå at det er forretningsprosesser i hver organisasjon. Om de er formaliserte eller ikke spiller ingen rolle. Husk: du kan finne forretningsprosesser overalt. Eksempler på dem vil bli gitt senere i artikkelen.

La oss se på et husholdningseksempel. Det er en husmor som vil vaske oppvasken (forretningsprosess). Hun overlater denne oppgaven oppvaskmaskin. Ved inngangen har vi skitten oppvask. Vann vil bli brukt under prosessen, vaskemiddel og elektrisitet. Og på slutten vil vi få rene oppvasken. Forretningsprosesser bygges etter en lignende ordning. Eksemplene som vil bli gitt senere vil bare bekrefte disse ordene.

Funksjonell tilnærming

Siden vi er interessert i (spesifikke eksempler), la oss ikke utsette deres vurdering, men gå i gang med en gang. La oss si at vi har et selskap som driver med ledelsesspørsmål. Ifølge ham er en bedrift et sett med divisjoner. Dessuten jobber hver enkelt for å utføre sin spesifikke funksjon. Men i slike tilfeller, når individuelle avdelinger er fokusert på å oppnå sine indikatorer, lider ofte den generelle ytelsen til selskapet.

La oss se på en typisk konfliktprosess. Salgsavdelingen krever en økning i maksimalt mulig sortiment for å øke omsetningen. Samtidig vil de også sørge for at produktet alltid er på lager. Mens forsyningsavdelingen planlegger å kjøpe et smalt utvalg og i store mengder. Faktisk vil de i slike tilfeller fungere effektivt, og hovedindikatoren deres vil øke (mer presist, prisen fra leverandøren vil falle). Det vil si at det er en fsom avdelinger ser annerledes på.

Prosess tilnærming

Han ser på alt som skjer som et sett med prosesser. Det er grunnleggende og støttende. Hver prosess har sitt eget spesifikke mål, som er underordnet oppgaven hele selskapet står overfor. I tillegg kommer en eier som forvalter ressurser og er ansvarlig for gjennomføring av alt nødvendig. Det bør også være et system for kvalitetskontroll og feilretting. Det sier seg selv at ingen prosess kan fortsette uten ressurser. Og listen over komponenter er fullført av et system med indikatorer som forretningsprosesser vurderes etter. Hva er noen eksempler på dette, siden det ble lovet at det skulle være noen? La oss nå se på en.

Tenk deg et kart. Helt i sentrum er Den er delt inn i separate komponenter. De er ledsaget av ledelses- og støtteprosesser som sikrer at alt utføres som nødvendig. Dette er hva som vil skje prosesstilnærming. Når arbeidet med ett element er fullført, overføres arbeidet til det neste.

Beskrivelse av forretningsprosesser

Eksempler på dette i generelt syn kan sees gjennom hele artikkelen. Men dokumentasjon i full lengde kan ofte sammenlignes i tykkelse med små bøker (eller til og med store hvis arbeidet til et gigantisk selskap studeres).

(eksempler på dette er også gitt her) krever at all virksomhet i virksomheten er så tydelig og transparent som mulig. Dette vil tillate dem å bli analysert på best mulig måte og identifisere ulike problemer før de mislykkes. Det må man huske på hovedoppgaven beskrivelser er å forstå samspillet mellom ulike enheter, å overvåke hva og til hvem de overfører på hvert trinn av oppgaven. Takket være dette er det mulig å betydelig forenkle og redusere avhengigheten av stabiliteten til bedriften av den ustabile menneskelige faktoren. Også, med en kompetent tilnærming, og Dette er hvordan beskrivelsen av forretningsprosesser hjelper. Et eksempel på slik optimalisering kan demonstreres av lederen for nesten ethvert vellykket selskap.

Utviklingsrekkefølge

la oss vurdere praktisk eksempel forretningsprosessen i bedriften. I første omgang må vi ta oss av arbeidsgruppen til prosjektet. Den er dannet av ansatte i selskapet. Oftere enn ikke viser det seg at ett arbeidslag ikke er nok. Hva kan da gjøres? For å fylle mangelen på styrke, kan du tiltrekke deg en midlertidig gruppe. Det skader heller ikke å lage en beskrivelse av hvordan prosessen fungerer på et gitt tidspunkt. Samtidig bør man strebe etter å identifisere alle sammenhenger mellom handlinger, og ikke registrere de minste detaljene.

For å unngå sidesporing kan du bruke standard prosesskart og skjemaer. Når du utvikler prosesser, anbefales det å bruke metoden for suksessive tilnærminger. Med andre ord er det nødvendig å gjenta syklusen med forbedringshandlinger til et akseptabelt resultat er oppnådd.

Hva bør du være oppmerksom på?

Du bør fokusere på følgende seksjoner:

1. Standardskjemaer.
2. Kart.
3. Ruter.
4. Matriser.
5. Flytskjemaer.
6. Beskrivelse av skjøter.
7. Støttebeskrivelser.
8. Dokumentasjon.
9. Detaljert beskrivelse.
10. Definisjon av indikatorer og indikatorer.
11. Utførelsesbestemmelser.

Den beste ideen om de nødvendige elementene kan gis av ekte eksempel- omstrukturering av forretningsprosesser eksisterende virksomhet. Men i slike tilfeller må du være forberedt på at du må gjøre deg kjent med en enorm mengde dokumentasjon.

La oss si et ord om kortene

Så vi har allerede sett på hva forretningsprosesser er, eksempler på dem i det virkelige liv. La oss nå gå gjennom teknisk dokumentasjon, som må være hvis vi ønsker en nøyaktig og tydelig beskrivelse. Så til å begynne med vil jeg ta hensyn til forretningsprosesskartet. Det er en grafisk representasjon designet som et blokkdiagram. I dette tilfellet er det nødvendig å sikre at hver deltaker har sin egen separate kolonne. Tidsintervaller legges inn i linjene. Et fullstendig utfylt kort lar deg sjekke om transaksjonen ble synkronisert.

Du kan også overvåke om og hvordan informasjon flyter mellom ulike avdelinger i selskapet. For å få beste effekt Det bør stilles flere spørsmål. Hvem utfører denne operasjonen? Hvorfor må det gjøres? Hva er hun? Når skal operasjonen utføres? Hvor utføres det? Når du skal forbedre eksisterende prosesser, bør du også spørre om det kan forbedres.

Matriser

De er nødvendige for å synliggjøre de viktigste forretningsprosessene i virksomheten. Under sammenstillingen deres blir sammenkoblingen av alt som skjer, så vel som graden av gjensidig påvirkning, tatt i betraktning.

Når man analyserer en kjede av prosesser, er det lett å finne at informasjonsutveksling beveger seg fra øvre venstre til nedre høyre. Det vil si at denne matematiske formen beskriver forholdet mellom leverandør og forbruker, presentert i form av et rektangel. I hver celle i matrisen, alle nødvendige krav for handlinger som er/er/vil bli utført. De er en slags todimensjonale modeller som man ved hjelp av kan bedømme hva som gjøres og hvordan det gjøres og hvilket formål som tilstrebes. Vanskeligheten med å kompilere en matrise her er at for å beregne med maksimal nøyaktighet er det ofte nødvendig å bruke en betydelig mengde data. Og dette innebærer tilstedeværelse av et stort antall data.I slike tilfeller brukes vanligvis digital informasjon, som ofte fortsatt må beregnes.

Bruksanvisning

Den første er å formulere nøyaktig navnet på prosessen som beskrives, som skal være forståelig og reflektere generell essens rekkefølgen av handlinger som utgjør prosessen. For eksempel, i stedet for å "Sende inn en søknad om produksjon og overvåke utførelsen av den", er det nok å kalle prosessen "Produktkontroll." Den andre tingen er å bryte ned hele den beskrevne prosessen korrekt i mindre ("atomare") oppgaver eller delprosessfunksjoner og bestemme rekkefølgen av deres utførelse. Med en slik inndeling vil den beskrevne prosessen være en prosess på toppnivå. Detaljnivået i prosessen på øverste nivå kan variere, men bør være tilstrekkelig til å bli forstått av publikum som skal bruke beskrivelsen din.

Det er flere måter å beskrive en forretningsprosess på. Den mest populære av dem er grafisk, ved hjelp av, laget i forskjellige notasjoner (notasjon er et sett med symboler for å betegne noe).
De vanligste typene notasjoner for å beskrive forretningsprosesser er IDEF0, BPMN, EPC (ARIS), etc.
La oss som et eksempel se på et diagram laget i BPMN (Business Process Modeling Notation) ved hjelp av CASE-verktøyet PowerDesigner (fig. 1). Hovedelementene i diagrammet er:
1. "Prosess" (funksjon) - et rektangel avrundet i hjørnene;
2. "Overgang" - en pil som forbinder prosesser;
3. "Løsning" - en diamant som inneholder et spørsmål som bare kan besvares "Ja" eller "Nei";
4. Betingelser - tekstuttrykk der en overgang fra en funksjon til en annen skjer. Betingelsene er alltid satt i hakeparenteser. Noen ganger er det nyttig å dele din inn i "spor" - vertikale eller horisontale seksjoner som indikerer inndelinger av bedriften eller ansatte som er ansvarlige for å utføre en bestemt funksjon. I dette tilfellet må denne funksjonen være plassert innenfor sin seksjon. I tillegg til de oppførte elementene, kan den også inneholde en liste over data som er input eller output for prosessen, samt lenker til regler eller forskrifter som en bestemt funksjon utføres i henhold til. Et eksempel på en beskrivelse av forretningsprosessen "Produktproduksjonskontroll" er vist i Fig. 1. Det er lett å se at dette diagrammet er veldig likt flytskjemaet til algoritmen for å løse problemet.

En grafisk beskrivelse av en prosess kan også suppleres med en tekstbeskrivelse av dens funksjoner-delprosesser i form av en tabell som inneholder følgende kolonner: prosessnavn, avdeling (prosesseier), prosessbeskrivelse, prosessutførelsesresultat. Et eksempel på en slik beskrivelse er vist i fig. 2. Hvis ytterligere optimalisering av den beskrevne forretningsprosessen forventes, kan en annen kolonne legges til tabellen som beskriver vanskelighetene eller manglene til de for øyeblikket utførte funksjonene-delprosessene.

Nyttige råd

Følg alltid reglene for den valgte grafiske notasjonen for å beskrive forretningsprosesser.

Kilder:

• M. Rybakov. Optimalisering av forretningsprosesser.
• hvordan lage en forretningsprosess

Prosessen som fenomen er en kvalitativ endring som skjer med observasjonsobjektet over tid. Derfor, selv før du starter beskrivelsen, må du angi objektet og tidsperioden for observasjonen.

Bruksanvisning

Først må du beskrive essensen av prosessen, med andre ord, den kvalitative endringen du observerer. For eksempel tok det fyr, brant ut, gikk ut (essensen av hendelsen er forbrenningsprosessen). Endringen kan være eksternt synlig (en hel fyrstikk har blitt til en stang), strukturen til objektet, koblingssystemet kan endres, avhengig av nøyaktig hva du sporer. I alle fall, når du beskriver endringen, må du i tillegg angi tid og hastighet (for eksempel brant fyrstikken i 20 sekunder, forkullingshastigheten var 2 millimeter per sekund). Noen ganger legges en prosesskarakteristikk som "syklalitet" til dette (endringen du observerer skjer en gang eller med jevne mellomrom).

Etter å ha vist essensen av endringen, fortsetter de vanligvis med å beskrive prosessen som en sekvens av "tilstander." For dette formålet, vanligvis hele tiden for observasjon med

Vladimir Repin

administrerende direktør Vladimir Repin Management LLC

Medlem av ABPMP Russland

Ledelseskonsulent

Business trener

Kandidat for tekniske vitenskaper

Artikkelen diskuterer spørsmålene ved valg av notasjon for å beskrive prosesser med henblikk på etterfølgende regulering. Ofte brukte Work Flow-notasjoner sammenlignes, for eksempel: "Simple flowchart" i MS Visio, "Procedure" i Business Studio, ARIS eEPC-notasjon og andre. Ved sammenligning av notasjoner er hovedfokuset på å lage prosessdiagrammer som er enkle og forståelige for organisasjonsansatte.

For forretningsanalytikere av selskaper er tesene som er omtalt i artikkelen en seriøs grunn til å tenke på hvor effektive tilnærmingene de bruker for å utvikle grafiske diagrammer over organisasjonsprosesser er.

Introduksjon

Et av de viktigste målene med å lage grafiske prosessdiagrammer er deres påfølgende bruk i organisasjonens regulatoriske dokumenter. Disse ordningene ansetter som regel ansatte som ikke er opplært i komplekse notasjoner og ikke har kompetansen system analyse osv. Enkelheten og klarheten til diagrammene er veldig viktig for dem. Komplekse, forvirrende diagrammer som inneholder mange forskjellige symboler, blir dårlig oppfattet av folk, noe som gjør deres praktiske bruk vanskelig. Derfor er det viktig for praktiske formål riktig valg og bruk av notasjon (metodikk) for å beskrive prosesser. Hvilke kriterier bør brukes for å velge en slik notasjon? Hvordan sammenligne forskjellige notasjoner med hverandre? La oss se på flere eksempler på å beskrive en forretningsprosess ved å bruke populære notasjoner og prøve å svare på disse spørsmålene.

Sammenligning av notasjoner

Til sammenligning ble følgende prosessbeskrivelsesnotasjoner valgt:

1. "Enkelt flytskjema" (viser bevegelsen av dokumenter, ved hjelp av "Løsning"-blokken);
2. "Enkelt blokkdiagram" (uten å vise bevegelsen til dokumenter, uten å bruke "Løsning"-blokker);
3. "Prosedyre" for Business Studio-systemet (en av mulige alternativer representasjon);
4. ARIS eEPC.

En enkel og intuitiv prosess ble valgt som testcase. Resultatene av å beskrive denne prosessen er presentert i fig. 1-4.

Ris. 1. Prosessdiagram i "Simple flowchart"-notasjonen i MS Visio (med bevegelse av dokumenter, ved å bruke "Solution"-blokken)

I diagrammet presentert i fig. 1, er sekvensen av prosessoperasjoner over tid vist ved hjelp av tykke piler, og bevegelsen av dokumenter er vist ved hjelp av tynne stiplede piler. Løsningsblokker brukes på en klassisk måte. De viser informasjon (spørsmål) som det påfølgende forløpet av prosessen "avhenger av". Denne tilnærmingen til å bruke "diamanter" er veldig vanlig. Men faktisk bør hele logikken for beslutningstaking og dannelsen av visse utdata (dokumenter) være inneholdt i prosessens operasjoner. Hvis du tenker på det, er verdien (betydningen) av å tegne disse "diamantene" ikke åpenbar. Hva slags objekter er dette: prosessoperasjoner, hendelser? Det ser ut til å være verken det ene eller det andre. Dette er snarere operatører for å ta en beslutning basert på en eller annen betingelse. Men vi utvikler et prosessdiagram for mennesker, og ikke skriver et dataprogram på et spesielt språk. I et dataprogram vil en "diamant" være en fullverdig operasjon for å sammenligne forhold osv. Men prosessdiagrammet må vise virkelige objekter - prosesser utført av mennesker, dokumenter, Informasjonssystemer osv. Tenk på om det er riktig å vise "diamanter" separat fra prosessoperasjonen på diagrammet? I stedet kan du:

• Beskriv logikken i beslutningstaking i form av en sekvens av operasjoner på diagrammet over prosessen som vurderes;
• Beskriv logikken i form av et diagram over trinnene i den tilsvarende delprosessen, gå til neste nivå;
• Beskriv logikken i tekst (i tekstattributtene til operasjonen) og vis den deretter i prosessutførelsesforskriften.

La oss formulere "fordeler" og "ulemper" med metoden for å bruke "diamanter" diskutert ovenfor (fig. 1).

"Enkelt flytskjema" i MS Visio (med dokumentbevegelse, ved hjelp av "Løsning"-blokken)

I fig. Figur 2 viser et eksempel på samme prosess, kun beskrevet uten bruk av "Solution"-blokker og dokumenter. Det er lett å sjekke at dette diagrammet har 24 færre grafiske elementer enn diagrammet i fig. 1. Skjema Fig. 2 ser mye enklere ut. De grafiske elementene blender ikke øynene, og med tanke på informasjonsinnhold er dette diagrammet ganske forståelig og tilgjengelig for sluttbrukeren. Hvis du for hver prosessoperasjon beskriver kravene til implementeringen i tekst, kan du ved å kombinere tabellform og grafiske presentasjonsformer ganske tilstrekkelig beskrive prosedyren for å utføre prosessen for selskapets ansatte.

Ris. 2. Prosessdiagram i "Simple flowchart"-notasjonen i MS Visio (uten dokumentbevegelse, uten bruk av "Solution"-blokken)

"Fordeler" og "ulemper" med en grafisk representasjon av prosessen i formen presentert i fig. 2 er vist nedenfor.

"Enkelt flytskjema" i MS Visio (uten dokumentbevegelse, uten bruk av "Løsning"-blokken)

Generelt vil bruken av diagrammer i et format som ligner på de som er presentert i fig. 2 er praktisk for både utviklere og ansatte som jobber med disse ordningene.

I fig. Figur 3 viser et prosessdiagram generert i "Prosedyre"-notasjonen til Business Studio-modelleringsmiljøet. Ordningen har flere funksjoner. For det første brukes "Beslutning"-blokkene på en ikke-standard måte - ikke som et grafisk element for å vise et spørsmål og forgrening, men som en fullverdig prosessoperasjon knyttet til beslutningstaking. I Business Studio har "diamanten" nesten alle egenskapene til en fullverdig prosess, men kan ikke dekomponeres (kanskje systemutviklerne vil gjøre dette mulig over tid). Ved å bruke en "diamant" (i stedet for en firkant) blir diagrammet mer visuelt. Samtidig kan du legge inn hvilken som helst tekstinformasjon i "diamant"-attributtene: beskrivelse, begynnelse, fullføring, fristkrav, etc.

Den andre funksjonen i prosessdiagrammet presentert i fig. 3, er bruken av piler. For å vise en sekvens av operasjoner, kan du bruke en pil med en enkelt spiss - "precedens"-pilen. Du kan bruke en tohodet pil for å vise dokumentbevegelse. Men i Business Studio kan du klare deg med å bruke bare én type piler - "precedens"-piler. I dette tilfellet kan du binde til navngitte piler nødvendig beløp dokumenter som er definert i katalogen over aktivitetsobjekter.

Denne tilnærmingen gjør det mulig:

• Reduser antall grafiske elementer på prosessdiagrammet betydelig, og samtidig;
• Legg til prosessforskrifter nødvendig informasjon om innkommende og utgående dokumenter.

Dermed kan vi, uten å fylle diagrammet med unødvendige elementer, likevel beskrive prosessen fullt ut og laste opp all nødvendig informasjon til regelverket.

Det faktum at navnet på pilen ikke avhenger av dokumentene som er vedlagt den, lar deg navngi pilene på diagrammet på den mest forståelige og praktiske måten for ansatte. For eksempel kan et sett med spesifikke dokumenter kobles til prioritetspilen "Et sett med rapporter er utarbeidet." Navnet på pilen i dette tilfellet indikerer for utøveren hendelsen som fullførte den forrige operasjonen kalt "Generer innsamlingsrapport for dagen." (Merk at i metodikken til STU-selskapet er pilen etter prosessoperasjonen en enhet, ikke en hendelse. Etter "Beslutninger"-blokken kan du vise mulige resultater av beslutningen).

Ris. 3. "Prosedyre" for Business Studio-systemet (alternativ med utradisjonell bruk"Løsning"-blokker)

"Fordeler" og "ulemper" med en grafisk representasjon av prosessen i formen presentert i fig. 3 er vist nedenfor.

"Prosedyre" for Business Studio-systemet (alternativ med utradisjonell bruk av "Solution"-blokker)

Når du bruker Business Studio, kan prosedyrenotasjonen brukes på litt forskjellige måter. Forfatteren av artikkelen er tilbøyelig til tilnærmingen presentert i fig. 3.

I fig. Figur 4 viser et diagram over prosessen som vurderes, utviklet i ARIS eEPC-notasjonen. Merk at noen prosessoperasjoner ikke passet på diagrammet. Dette delvise diagrammet av en enkel prosess, skrevet i ARIS eEPC-notasjon, inneholder fire logiske utsagn og åtte hendelser! Personen som leser diagrammet må være i stand til å tolke alle disse logiske operatorene riktig. Uten spesiell opplæring og noen ferdigheter i å lese slike diagrammer, er det usannsynlig at en vanlig ansatt vil kunne forstå logikken i den aktuelle prosessen uten en detaljert tekstbeskrivelse eller hjelp fra en kvalifisert forretningsanalytiker.

Merk at prosessdiagrammet i ARIS eEPC-notasjonen tar betydelig opp mer plass enn diagrammene presentert i fig. 1-3. Kompleksiteten ved å danne et slikt opplegg er også betydelig høyere.

Ris. 4. Prosessdiagram i ARIS eEPC-notasjon (innebygd i Business Studio)

Prosessdiagram i ARIS eEPC-notasjon (innebygd i Business Studio)

Generelt, hvis du ikke skal kjøpe SAP R/3, er det ikke den optimale løsningen å velge og bruke ARIS eEPC-notasjonen fra artikkelens forfatters synspunkt. Det er verdt å ta hensyn til notasjoner for å beskrive prosesser som er mer visuelle og intuitive for utøvere. Noen kan imidlertid finne ARIS eEPC-notasjonen mer visuell og forståelig. Til en viss grad er dette en smakssak.

Beskrivelse av prosessen for påfølgende automatiseringsformål

Det er interessant å vurdere eksemplet ovenfor på en forretningsprosessbeskrivelse hvis den presenteres i BPMN 2.0-notasjon. Denne notasjonen er ment å beskrive "kjørbare" prosesser, dvs. prosesser som BPM-systemet støtter.

Din mening om bruk av BPMN 2.0. A. A. Belaichuk, generaldirektør i Business Console-selskapet, deler:

"I fig. Figur 5 viser den samme prosessen i BPMN-notasjon. Som vi kan se, ligner denne figuren på fig. 1: i BPMN-notasjon er oppgaver avbildet som rektangler, gafler som diamanter og data som et ikon som ligner på et dokument. Kontrollflyter er heltrukne linjer, dataflyter er prikkete.

Det bør tas i betraktning at dette diagrammet bare bruker en liten del av BPMN-notasjonen: kun én type gaffel av 5 tilgjengelig i paletten, én type oppgave av 8. I tillegg til en bredere palett er denne notasjonen kjennetegnet ved evnen til å modellere ikke bare en isolert arbeidsflyt, men også flere prosesser, som samhandler med hverandre gjennom meldinger eller data. I tillegg er denne notasjonen mer streng: den definerer ikke bare ikoner, men også reglene som de kan kombineres med hverandre. Behovet for slike regler er diktert av det faktum at BPMN-notasjonen er fokusert ikke bare på det faktum at den vil bli lest av folk, men også på direkte utførelse av spesiell programvare - "motoren" til BPM-systemet.

Samtidig, som dette eksemplet viser, når du bruker et begrenset delsett av paletten, viser det seg at BPMN ikke er mer komplisert enn et konvensjonelt flytskjema. Vel, for de som ønsker å mestre BPMN profesjonelt, anbefaler vi spesialisert opplæring bpmntraining.ru."

Ris. 5. Prosessdiagram i BPMN 2.0-notasjon

Livspraksis

I fig. Figur 6 viser et fragment av et prosessdiagram utviklet av forretningsanalytikere fra et veldig spesifikt selskap i notasjonen de fant opp. Diagrammet er bygget ved å bruke prinsippene til "Enkelt flytskjema" - "Løsning"-blokken brukes i sin klassisk versjon. I tillegg viser diagrammet mange andre symboler som brukes på en ikke-standard måte.

Ris. 6. Eksempler på prosessdiagram for en av bedriftene

Når du danner diagrammet Fig. 6, "slitet" forretningsanalytikere åpenbart for klarhet og maksimal forståelighet for den gjennomsnittlige brukeren. De forsøkte å minimere, eller til og med eliminere, tekstkommentarer på prosessdiagrammer. Utøverne ble ganske enkelt skrevet ut med et diagram i A3-format, etter å ha lest det ble alt umiddelbart klart: hva de skulle gjøre, hvordan, hvilke dokumenter de skulle bruke, etc.

Ordningen som vurderes er selvsagt ikke et eksempel på enkelhet og klarhet. Men den ble dannet for å formidle maksimal nyttig informasjon til de involverte i prosessen.

konklusjoner

Så det er åpenbart at når du beskriver prosesser, må du strebe etter enkelhet og klarhet for ansatte.

Bruken av komplekse, formaliserte notasjoner når man beskriver prosesser fører til:

• Vanskeligheter med å bruke (tolke) diagrammer av vanlige ansatte;
• Umuligheten (vanskeligheten) med å organisere arbeid for å beskrive prosesser av ansatte i avdelinger som ikke har gjennomgått spesiell opplæring;
• En betydelig økning i lønnskostnadene til forretningsanalytikere for dannelsen av ordninger;
• Ytterligere vanskeligheter ved å dokumentere kretsløp (stort volum, etc.).

Derfor bør du ikke fylle prosessdiagrammet med ulike grafiske elementer. Men hvis du bruker dem, er det bedre at de bærer nyttig informasjon for ansatte, i stedet for bare å være en konsekvens av den formelle bruken av modelleringsnotasjoner.

http://finexpert.ru/ - kommunikasjonsmiljø for fagfolk http://bpm3.ru/ - prosesser, prosjekter, effektivitet

I vårt selskap, som administrerer byggeprosjekter for store energianlegg, er beskrivelsen av forretningsprosesser spesielt relevant i dag for prosjekter og prosjektteam.

Hvert prosjekt er nytt lag, mange interesserte parter og relasjoner, sine egne detaljer, høy arbeidsmengde for ansatte. Prosjektledelsen setter i oppgave å beskrive prosesser raskt, enkelt og oversiktlig. Og naturligvis skal de fungere.

Etter å ha beskrevet forretningsprosesser en stund, prøvde jeg ulike teknikker, verktøy og maler. Jeg deler metode, som jeg har brukt i det siste og som har "slått rot" i selskapet vårt.

Så, definere prosessen, som må beskrives. Lengre

- møte den som er ansvarlig for prosessen og hoveddeltakere/eksperter (opptil 3 personer);
- vi bestemmer grensene for prosessen, deltakere, input/outputs, stadier av prosessen– blokker som vi deler prosessen og resultatene av disse stadiene inn i;
- vi kommer til enighet og tegner etter hvert følgende prosessdiagram:

Vi beskriver hver blokk (delprosess). For å gjøre dette bruker vi et grafisk funksjonelt blokkdiagram, malen som er tilgjengelig i MS Visio:

I beskrivelsen bruker vi følgende notasjon:

Som et resultat ser prosess(trinn)diagrammet slik ut:

Diagrammet viser deltakerne i prosessen, handlingene de utfører og deres varighet. Vi viser resultatene på pilene som forbinder handlingene.

Et diagram tegnet i MS Visio er allerede siste versjon. Hele poenget ligger i dens tilblivelse. Og det viktigste her er involvering av direkte deltakere i prosessen.

Vi beskriver prosessen slik:

1. Vi arrangerer et arbeidsmøte med prosessdeltakere og eksperter;

2. Forbered en "klebrig vegg", A5-kort, markører;

3. Vi oppnevner en moderator som leder diskusjonen, skriver og stikker kort på veggen;

4. Merk horisontale linjer maskeringstape;

5. Vi identifiserer deltakerne i prosessen, skriver dem ned på kort og limer dem på venstre side av veggen i passende linjer;

6. Bestem (bekreft) input/output av prosessen (gule kort);

7. Vi deler deltakerne inn i to grupper, hver gruppe diskuterer og skriver på kort handlingene i prosessen fra "input" til "output". Legger ut på bordet;

8. På sin side tar vi ett kort fra hver gruppe, med start fra "inngangen" til prosessen; Vi bestemmer hvem som gjør det og fester det på veggen, kobler det i serie med maskeringstape (disse er piler). Under dette arbeidet blir vi enige om ordlyd og bruk av ulike kort, og bringer deltakerne til et felles opplegg;

9. Vi går gjennom diagrammet (les), legger til de manglende handlingene, stiller spørsmål til gruppene, bestemmer resultatene av handlingene (skriv på pilene);

10. Vi tar bilder og sender til digitalisering.

Som et resultat får vi et diagram i MS Visio, som i forrige figur.

All beskrivelse vi plassert på én side– kompakt og oversiktlig. Handlingene til hver deltaker er beskrevet på en egen linje, som lar deg raskt bestemme deres rolle og funksjoner i prosessen.

Hvis prosessen er kompleks, krever handlingene forklaring eller er inkonsekvente, legg til kommentarsiden eller skriv dem på en ledig plass i en ramme direkte på diagrammet.

Det endelige opplegget sendes alle deltakere for godkjenning. Prosjektlederen (eller annen ansvarlig person) godkjenner den, den lagres i prosjektprosessalbumet og blir en veiledning til handling.

I dag vanlig ble det faktum at forretningsprosessens tilnærming til organisering av arbeid anses som moderne, innovativ løsning, som, hvis implementert, bidrar til å forbedre kvaliteten på arbeidet og øke fortjenesten til bedriften. Jeg har også allerede skrevet om forretningsprosesser og systemer for å jobbe med dem (BPMN, BPMS) mer enn én gang. For eksempel, i artikkelen "Hva er en forretningsprosess" beskriver jeg de grunnleggende konseptene, funksjonene og fordelene ved denne tilnærmingen. Og nå bestemte jeg meg for å snakke om ulempene ved å implementere en prosesstilnærming, om hvilken negativ effekt som venter selskapet og dets ansatte hvis denne tilnærmingen implementeres.

Det ser ut til at en spesialist ble ansatt for jobben - en bedriftskonsulent eller en forretningsanalytiker, han kan sin virksomhet. Du kan slappe av, spesialistene vil gjøre alt "som det skal." Men i virkeligheten er ikke alt så enkelt som det kan virke ved første øyekast. Og i tilfelle feilaktige beslutninger venter problemer på klienten og hans ansatte.

Før du leser denne artikkelen, anbefaler jeg på det sterkeste at du leser mine tidligere publikasjoner om dette emnet:

Selvfølgelig kan du prøve å beskrive selskapets arbeid i tekst, til og med algoritmisering, dvs. faktisk kan beskrivelsen av prosesser også implementeres i tekstform. For eksempel foretrekker noen spesialister denne tilnærmingen til arbeid. Og det er deres rett.
Men å kalle en notasjon en tekstliste over ansattes handlinger å løse forskjellige typer oppgaver er uakseptabelt. Beskrivelser (notasjoner) av forretningsprosesser er underlagt visse regler og har, som alle språk, sin egen "syntaks" og "vokabular". Men hvis for eksempel "regler" og "ord" i programmeringsspråk er et sett med tekstkommandoer, så er de i BPM-notasjoner først av alt grafikk.

Hvorfor er dette så viktig? I tillegg til de etablerte og etablerte reglene, er det også en logisk forklaring. Det grafiske bildet er lettere å oppfatte som en helhet. Men først etter at vi har sett og klart å forstå helhetsbildet kan vi si at vi har beskrevet forretningsprosesser. Situasjonen som er avbildet på bildet begynner å eksistere først etter at vi har malt den. Dette er essensen, også når man skal beskrive forretningsprosesser.

Derfor foreslår jeg å være enig:

Hvis jeg snakker om å beskrive forretningsprosesser, snakker vi om forretningsprosesser beskrevet grafisk i en av notasjonene.

Men la oss gå tilbake til hovedemnet i artikkelen, og la oss prøve å finne ut hva som er ulempene ved å bruke forretningsprosesser i praksis, hvorfor de oppstår og hva de kan føre til.

Hvordan en forretningsprosessbeskrivelse lages

Oftest jobber en ekstern bedriftskonsulent med å lage en beskrivelse av en forretningsprosess. Denne spesialisten kjenner sin virksomhet, og selvfølgelig, før han oppretter en notasjon, studerer han arbeidet til virksomheten og dens funksjoner. Men det er nødvendig å forstå at selv den best inviterte spesialisten ikke kan bli en ekspert på aktivitetsfeltet til dette selskapet på den korte tiden brukt på å studere. Jeg forklarer umiddelbart dette til kunden for å fjerne negativitet og misforståelser:

For eksempel ble jeg invitert til å beskrive forretningsprosessene til en sybedrift, men jeg har ikke ekspertkunnskap i sybransjen, dvs. Jeg kan ikke sy noe selv. Jeg jobbet også med et reiseselskap, men prosessen med å følge et barn på ferie til en sommerleir for meg er fortsatt bare "en viss prosess"; jeg har aldri gjort det på egen hånd. Jeg jobbet også med medisinsk senter, og her kan jeg heller ikke fortelle hvordan nøyaktig informasjon om pasienten samles inn for operasjonen, fordi jeg ikke er lege.

Litt om begrepene som brukes i denne artikkelen

Før du fortsetter, er det nødvendig å avklare bildet av hva som skjer og rollen til den personen eller gruppen av personer i optimaliseringsarbeidet.

En ansatt er en enhet som representerer en person eller gruppe mennesker som er en kilde til informasjon. Den ansatte er kompetent i forretningsprosessen, har ingen beslutningsrettigheter og er vanligvis ikke kompetent i modellering.

En forretningsanalytiker er en enhet som representerer en person eller personer som modellerer en forretningsprosess og kan i noen tilfeller gi anbefalinger for å forbedre forretningsprosessen. I de fleste tilfeller er de ikke i utgangspunktet kompetente i prosessen og har ikke rett til å ta avgjørelser.

En leder er en enhet som representerer en person eller gruppe mennesker som er ansvarlige for å ta beslutninger. Lederen er kompetent i beslutningstaking, og vanligvis inkompetent i forretningsprosesser og modellering.

Notasjon/forretningsnotasjon er et språk for å beskrive forretningsprosesser.

Kan noen rette meg på at én person kan være som god medarbeider så og god forretning analytiker. Jeg vil si med en gang at jeg aldri har sett slike mennesker, og det er vanskelig å forestille seg en person som ville vært like god i to disipliner så forskjellige fra hverandre, som forretningsanalyse og all virksomhet i selskapet.

For klarhetens skyld gir jeg deg en tabell (sekvensen av kolonner og rader spiller ingen rolle):

Hvorfor trenger du en gjesteforretningsanalytiker?

Forretningsmodellering er nødvendig for å få et klart bilde av hvordan virksomheten fungerer nå, dvs. "som det er". Samtidig blir "tynne flekker" og segmenter der optimalisering kan utføres merkbare.

For å kompilere notasjonen studerer analytikeren selskapets arbeid og lager en beskrivelse av forretningsprosessen "som den er". Deretter, med tanke på ønsker og problemer beskrevet av selskapets ledelse (kunden), bestemmer han "hvordan det skal være." Og ved hjelp av grafiske elementer i notasjonen kan den avsløre hvor og hva som faktisk kan endres for å flytte fra den første tilstanden til den andre.

For å kompilere en kompetent notasjon, kreves følgende komponenter:

1. Kunnskap om forretningsanalyse og evne til å arbeide med notasjoner.
2. Informasjon om driften av en bestemt prosess.
3. Optimaliseringskrav: hvilket resultat streber bedriftsledelsen etter.

Kunnskap og evne til å arbeide med notasjoner er kompetansen til en forretningsanalytiker. Informasjon om selskapets arbeid gis til ham av ansatte og ledelse. Samtidig opptrer forretningsanalytikeren bestemt arbeid om datainnsamling. Han bruker bedriftsrapporter, gjennomfører intervjuer med ledere og ansatte ved ulike avdelinger, og streber etter å få et så fullstendig bilde som mulig. Resultatet avhenger i stor grad av hvor godt dette arbeidet utføres, og hvor aktivt selskapets representanter er villige til å bidra til å innhente nødvendig informasjon. Dette er et eget verk, med sine egne spesifikasjoner og teknikker.

Det er også viktig å forstå at beslutningen om hvilke av de foreslåtte alternativene for å optimalisere arbeidet som skal implementeres i praksis, tas av forretningsføreren, og det endelige resultatet avhenger av dette ikke mindre enn kvaliteten på virksomhetsanalytikerens arbeid.

Eksempler

Deretter vil jeg vise med eksempler hvordan feil startdata fører til feil konklusjoner. Og hvorfor slike forsøk på å bli kvitt en person ofte ender trist. Jeg ga det første eksemplet for å demonstrere hvordan dette fungerer.
Det andre eksemplet er å gjøre det klart at selv omfanget av selskapet ikke kan redde deg fra problemer.

Eksempel 1. Automatisering av nettbutikk

En svært vanlig situasjon er å optimalisere driften av en nettbutikk.

Opprinnelig jobbet flere med ordrebehandling:

• Operatører som manuelt overførte bestillinger mottatt fra nettsiden til regnskapssystemet.
• En lagerarbeider som var direkte involvert i frakt av bestillinger.

Etter optimalisering forsvant behovet for operatører, siden ordren automatisk overføres til regnskapssystemet, hvor alle Påkrevde dokumenter og reserverer varene.

Som et resultat kan personen som er involvert i fraktbestillinger uavhengig skrive ut dokumenter og utarbeide en liste over varer for forsendelse uten hjelp fra operatører. Operatører viser seg ikke å være nødvendig i det hele tatt.

"På papiret" ser det hele perfekt ut. Systemet er implementert, operatørene sparkes. Lagerarbeideren får en liste over ansvarsområder (skrive ut dokumenter), og hvis han er veldig heldig, økes lønnen hans. Selskapet sparer penger ved å redusere flere priser, og eliminerer feil knyttet til den menneskelige faktoren. Alt skal fungere bedre enn før.

I praksis viser det seg at situasjonen langt fra er så rosenrød.

Hvis tidligere antall bestillinger mottatt av montøren på lageret var begrenset av arbeidshastigheten til menneskelige operatører, genereres nå bestillinger automatisk, nesten umiddelbart, og akkumuleres "på lageret."

Antall bestillinger som behandles per dag er nå bare begrenset av lagerarbeiderens evner. En person ser en konstant "kø av bestillinger." Hans overordnede observerer henne også, og uttrykker vanligvis misnøye.

Selv om det ikke er negativitet "ovenfra", ser en person selv en konstant "blokkering", han må jobbe mer enn før. Dette blir selvsagt delvis kompensert av lønnsøkningen. Men fortsatt, på grunn av den økte belastningen, akkumuleres tretthet, inkludert psykologisk tretthet. En person er ikke en maskin; han kan ikke jobbe perfekt dag etter dag uten pauser. Hver person har et visst maksimum - hvor mange bestillinger han kan behandle per skift.

Som et resultat begynner lagerarbeidere å slutte etter hverandre. Omsetning oppstår, noe som fører til ytterligere problemer, forsinkelser i sending av bestillinger og feil knyttet til arbeidet til uerfarne og slitne ansatte. I stedet for forventet optimalisering av arbeidet, lider bedriften tap og omdømmetap.

Og alt fordi, revet med av den vakre "forenklede" notasjonen, sørget analytikeren og selskapets leder ikke for noen mekanismer for å regulere arbeidshastigheten, ikke tok hensyn til hvor mye belastningen økte, dvs. oppfattet ansatte ikke som ekte mennesker, men som abstrakte «forretningsprosesser».

Eksempel 2. Taxiautomatisering

I dag hører vi ofte snakk om at taxier i nær fremtid vil kjøre uten sjåfør. Uber og Yandex Taxi-eksperter snakker om dette. I prinsippet beveger begge disse selskapene seg allerede langs automatiseringens vei og forlater den menneskelige faktoren der det er mulig.

Som et resultat kan vi komme til følgende diagram:

1. Bestill taxi automatisk, gjennom en nettside eller applikasjon, uten deltakelse fra en ekspeditør.
2. Levering av klienten til destinasjonen
3. Betaling – automatisk, med bankkort eller Internett-penger etter en tur basert på GPS-data.

Selvfølgelig, samtidig sysselsetter taxitjenesten selv fortsatt folk (teknisk støtteoperatører, spesialister på vedlikehold av programvare og maskinvare, vurderingsmoderatorer, etc.). Men i forretningsprosessen beskrevet ovenfor, hvis sjåfører nekter, slutter de å delta helt.

På den ene siden viser alt seg praktisk og lønnsomt. Ingen mennesker - ingen tilfeldige feil, ingen kostnader for å skape arbeidsplasser og lønn.

På den annen side, hvis folk blir fullstendig ekskludert fra kjeden, oppstår det mange risikoer. Hva skjer hvis det automatiske førerprogrammet feiler og personen blir ført til feil sted? Hvordan vil roboten reagere i tilfelle en ulykke, spesielt hvis en maskinvarekomponent er skadet på grunn av ulykken? Hva om kriminelle eller terrorister bestemmer seg for å fange og bruke robottaxien til sine egne formål?

Som du kan se, til tross for alle eksterne fordeler, fører utelukkelse av en person fra kjeden til uforutsigbare konsekvenser og krever innføring av noen forsvarsmekanismer, som et resultat av hvis implementering (eller til og med ikke-implementering) selskapet pådrar seg ekstra utgifter, dvs. resultatet er det motsatte av det som var planlagt.

Hovedårsaker til feil og problemer

Det er nødvendig å forstå at i prosessen med å lage en notasjon, prøver enhver forretningskonsulent å forenkle notasjonen så mye som mulig, "redusere" stadier og handlinger som fra hans synspunkt ikke er veldig viktige og kan forstyrre forståelsen. bildet som helhet. Han lager tross alt en prosess som skal være forståelig for forbrukere og spesialister. Et av prinsippene er "Du bør ikke multiplisere eksisterende ting uten nødvendighet" (den såkalte Occam's Razor).

På selskapets side studerer virksomhetslederen notasjonen. På den ene siden kan han mye mer om sitt virkefelt enn en invitert spesialist. På den annen side er han heller ikke ekspert på arbeidet til hver enkelt avdeling og medarbeider. Som leder ser han hele bildet og har også en tendens til å forenkle. I tillegg må du forstå at i næringslivet er det nå et stort antall tilfeldige mennesker som kom i virksomhet enten ved et uhell eller har en ikke-spesialisert utdanning.

Som et resultat opprettes en forenklet forretningsmodell, som er skapt av en person som er kompetent i modellering, men ikke kompetent i spesifikasjonene til et bestemt aktivitetsfelt. Arbeidet hans (forretningsnotasjon) er akseptert av selskapets leder, som ikke er ekspert på forretningsmodellering, og kan derfor, uten en nøye felles studie av alle detaljene, si nøyaktig hvor forenklinger er akseptable og hvor de ikke er det. I tillegg er forretningsføreren i de fleste tilfeller heller ikke ekspert på enkelte prosesser som foregår i bedriften. Han er kanskje en utmerket organisator, men han er ingen lege. Eller en kjenner av mote og stil, men ikke en syerske osv.

Dessverre, når man jobber med å optimalisere forretningsprosesser, er hovedmålet vanligvis ikke så mye å forbedre arbeidet (som det burde være), men først og fremst å redusere kostnadene. Ledelsen i et selskap som har henvendt seg til en spesialist på søker å redusere kostnadene. Og dette betyr nesten alltid å redusere bemanningen. Dette høres vanligvis ut som "Å redusere den menneskelige faktoren."

Det er mange flere eksempler som ligner på de ovenfor; de er alle forent av flere viktige faktorer som fører til triste resultater:

• Utilstrekkelig kompetanse hos analytikeren i spørsmål om driften av en bestemt virksomhet;
• Mangel på lederkompetanse i å forstå forretningsprosesser og manglende vilje til å fordype seg i detaljer;
• For mye tillit til grafiske notasjoner (de gir graden av frihet som lar deg omfavne prosessen som helhet og se optimale løsninger, men ikke ta hensyn til folk som i virkeligheten utfører funksjonene til "piler" og "svarte bokser");
• Overdreven tillit til teknologi (en feil som er vanlig for mange moderne mennesker).

Resultatet er en forretningsprosess som i teorien ser ideell ut, på et eller annet stadium begynner å mislykkes.

En annen viktig faktor, som kombinerer eksemplene beskrevet ovenfor:

Ved utarbeidelsen av notasjonen og implementeringen av prosesstilnærmingen tok ikke analytikeren og selskapets leder hensyn til at organisasjonen nødvendigvis består av mennesker. Så snart folk blir ekskludert fra prosessen, slutter den å være en forretningsprosess og blir en teknologisk prosess. Og denne typen prosesser har sine egne beskrivelsesregler, sikkerhetskrav osv. Å beskrive dem som forretningsprosesser er uakseptabelt.

En enkel løsning på problemet: sett pris på mennesker

Den enkleste og mest åpenbare utveien er å ta vare på dine ansatte og behandle dem humant. Definer tilstrekkelige arbeidsstandarder, ikke ekskluder personer fullstendig fra forretningsprosessen, reduser antall funksjoner, for eksempel, la dem overvåke, sjekke og skrive ut dokumenter eller utføre andre typer hjelpearbeid. Forkorte arbeidsdagen, for eksempel gjøre skift på 6 timer. Folk vil ikke bli overarbeidet, de vil ha tid til å gjøre alt i tide, prosessen vil være under kontroll.

Selvsagt vil kostnadsbesparelsen være mindre sammenlignet med et fullstendig avslag på å involvere ansatte i visse prosesser. Men du slipper garantert mange problemer.
Samtidig vil det med stor sannsynlighet gi deg profitt i seg selv å redusere arbeidsbelastningen på ansatte. En person som ikke er overarbeidet og har tid til å hvile godt, fungerer mye bedre. Han er mer produktiv, gjør færre feil, er klar til å ta en kreativ tilnærming til arbeidet, for å gjøre mer og bedre.

Enhver erfaren leder vil imidlertid bekrefte dette overfor deg. Hvis du tvinger en person til å jobbe i 8 timer i strekk uten pauser, vil ytelsen hans synke betydelig. Å tvinge ansatte til å jobbe "ekstremt" er ikke bare umenneskelig, men i de fleste tilfeller ikke lønnsomt. Folk vil slutte, eller i visse tilfeller vil du bli tvunget til å sparke dem, fordi de begynner å gjøre jobben veldig dårlig, som de sier om slike ansatte, de "brenner ut." Du må bruke tid og krefter på å søke etter en ny person, trene ham, og så videre fra tid til annen. Fast ansatte som er lojale mot selskapet vil gi mye mer fordel og vil koste mindre enn regelmessig skifte av personell.

Vær forsiktig med teknologi

Helt i begynnelsen av artikkelen påpekte jeg hovedfeilen - overdreven tillit til moderne teknologier, som også inkluderer forretningsmodellering, kombinert med ønsket om å forenkle alt mulig, fører til akkumulering av feil.

Gå i detalj, spesielt hvis du planlegger å erstatte en person med et program på et eller annet område. Pass på at dette ikke fører til tap av kontroll eller naturlig tilpasning av arbeidsbelastningen til tilstøtende avdelinger. Du bør ikke stole "blindt" på moderne programvare og teknologiske løsninger rett og slett fordi vi lever i en tid med masseautomatisering.

Forretningsmodellering og IT-sfære

Til slutt vil jeg si noen ord om hvordan forretningsmodellering og relaterte funksjoner forholder seg til arbeidet til IT-spesialister. Jeg tror at disse verktøyene kan være svært nyttige for IT-spesialister. Forretningsmodellering hjelper til med å forstå hvordan organisasjonen som helhet fungerer, for å se det store bildet før automatisering starter.

Slik analyse bidrar til å foreslå og implementere optimale alternativer løsninger for arbeid ulike organisasjoner og individuelle divisjoner.

Til tross for at artikkelen er viet manglene ved forretningsmodellering, tror jeg personlig at det ikke bare er mulig, men virkelig nødvendig, å bruke forretningsprosesser og notasjoner når man optimaliserer og automatiserer arbeidet til organisasjoner.

Men samtidig er det viktig å forstå at, som ethvert verktøy, kan forretningsmodellering også fungere i begge retninger, og gi ikke bare fordeler, men også skade. Som du vet, fordi du kan kutte deg med en kniv, har ikke en eneste person kastet ut alle knivene fra kjøkkenet sitt. Så her, studer verktøyene så dypt som mulig, husk de mulige ulempene ved å bruke forretningsprosessnotasjoner, og unngå overdreven forenkling. Og ikke glem at disse notasjonene beskriver organisasjonens arbeid, dvs. først og fremst mennesker, og først da – deres arbeid med teknologi.

Jeg vil også påpeke at når jeg skriver om manglende kompetanse hos en forretningsanalytiker eller bedriftsleder, så antyder jeg ikke at noen av dem er en dårlig kvalifisert spesialist. Det jeg sier er at de kan ha mangel på kunnskap på visse områder.

Dermed kan det hende at en forretningsanalytiker ikke er kompetent nok innen kundens aktivitetsfelt. Og hvis dette faller sammen med selskapets leders mangel på oppmerksomhet på detaljer, med en motvilje i komplekse eller tvilsomme tilfeller for å rådføre seg med ansatte som er ansvarlige for et bestemt aktivitetsområde, kan dette ende på den triste måten beskrevet ovenfor. Dessuten, som du kan se fra eksemplene, kan negative faktorer like mye påvirke både en liten bedrift (et eksempel på en nettbutikk) og stort selskap(eksempel på en stor taxitjeneste). Det er nødvendig å forstå at dette bare er nok et eksempel på arbeidsdeling for større effektivitet i å løse et problem.