Lag en beskrivelse av forretningsprosessen i en visuell. Forretningsmodellering i Microsoft Visio: fra strategi til forretningsprosesser og kvalitet. Layout formål Funksjonelt blokkskjema




Hendelsesdrevet prosesskjede (EPC) Organisasjoner bruker EPC-diagrammer for å planlegge arbeidsflyter for forretningsprosesser. Det finnes en rekke verktøy for å lage EPC-diagrammer, som ARIS-verktøysettet og ARIS Express, Microsoft Visio, Adonis fra BOC Group, Mavim Rules fra Mavim BV, Business Process Visual Architect fra Visual Paradigm. Noen av disse verktøyene støtter det verktøyuavhengige EPC-datautvekslingsformatet, EPML-markeringsspråket. EPC-diagrammer bruker flere typer symboler for å vise kontrollflytstrukturen (rekkefølgen av beslutninger, funksjoner, hendelser og andre elementer) i en forretningsprosess. EPC-metoden ble utviklet av August-Wilhelm Scheer som en del av hans arbeid med ARIS på begynnelsen av 1990-tallet. Brukes av mange organisasjoner til å modellere, analysere og omorganisere forretningsprosesser.


Ved å bruke MS Visio I Visio 2013 inneholder Business-kategorien en EPC-diagrammal som du kan bruke til å lage et EPC-diagram (Event Driven Process Chain) for å dokumentere forretningsprosesser.






Konklusjoner Bruk programvareverktøy Microsoft® Visio® er praktisk, enkel og tilgjengelig som plotter for prosessmodeller, men er ikke et ekte modelleringsverktøy. I profesjonelle modelleringsverktøy lagres objekter og deres egenskaper i databaseceller, som lar deg utføre forskjellige operasjoner med dem. Når du bruker komplekse modelleringssystemer, kreves det imidlertid anskaffelse, installasjon, utvikling og seriøs støtte til slike systemer. Dette er berettiget bare i tilfeller der det er et reelt behov for å bruke alle egenskapene til databaser ganske fullt ut. Valget ditt vil avhenge av bruksomfanget: om du trenger en "lett" løsning eller et profesjonelt programvareprodukt.

I dag er Microsoft Visio et av de vanligste programvareproduktene for forretningsmodellering og er installert på datamaskinene til mange forretningsanalytikere. Praksis viser at tilstedeværelsen av et så enkelt, billig og samtidig funksjonelt verktøy flere ganger øker effektiviteten ved å fullføre prosjekter og oppgaver for å formalisere og optimalisere virksomheten til en virksomhet.

Under seminaret diskuteres fog beskrivelser av forretningsprosesser innebygd i MS Visio, metoder for å utvikle forretningsmodeller og implementere ulike prosjekter ved bruk av MS Visio, grunnleggende og servicefunksjoner til MS Visio, og en lang rekke eksempler fra ekte. organisasjoner er gitt.

Hovedvekten på dette seminaret er ikke på "hvilke knapper å trykke på", men på hvordan man løser praktiske forretningsproblemer ved hjelp av MS Visio (dvs. utvikle strategiske kart, beskrive og analysere forretningsprosesser, utvikle effektive forretningsmodeller og reguleringer). Derfor, basert på resultatene fra seminaret, får deltakerne kunnskap + ferdigheter både i å jobbe i MS Visio og i grunnleggende metoder og vellykkede praksiser innen business engineering.

Workshopen vil gi svar på følgende spørsmål:

  • Hvordan raskt og effektivt utvikle forretningsmodeller i ulike notasjoner?
  • Hvordan utvikle en forretningsmodell i samsvar med alle kravene til den valgte notasjonen og automatisk sjekke riktigheten (riktigheten)?
  • Hva er kjennetegnene og funksjonene ved bruken av notasjoner innebygd i MS Visio: Basic FlowChart (enkelt flytskjema), Cross Functional FlowChart (funksjonelt flytskjema), IDEF0, ARIS VACD (Value Added Chain Diagram), eEPC (Event driven Process Chain), Årsak-og-virkningsdiagram (årsaks-og-virkningsanalysemodell), BPMN (forretningsprosessmodell og notasjon) og mange andre?
  • Hvordan bruke grunnleggende og servicefunksjoner til MS Visio på et profesjonelt nivå?
  • Hvordan løse hverdagslig og kompleks praktiske problemer bruker du MS Visio?
  • Hva er eksemplene og resultatene av bruk av MS Visio i ulike organisasjoner og prosjekter?
  • Hva er en organisasjons omfattende forretningsmodell, og hvordan utvikles og formaliseres den?
  • Hvordan utvikle regelverk og normative dokumenter basert på forretningsmodeller og sikre implementering av de ansatte?
Verkstedet er tiltenkt for ledere og spesialister ved følgende avdelinger:
  • Avdeling for forretningsprosesser og teknologier;
  • Institutt for metodikk og dokumentflyt;
  • Institutt for strategisk og organisasjonsutvikling;
  • Kontor for informasjonsteknologi;
  • Kvalitets- og standardiseringstjeneste;
  • Personalavdeling;
  • Prosjektkontor;
  • Finansielle avdelinger;
  • I tillegg til avdelinger, hvis ledere og spesialister deltar i prosjekter om strategisk og organisasjonsutvikling, regulering og optimalisering av forretningsprosesser, organisasjonsstruktur, forbedring av arbeidseffektivitet, utvikler de ofte ulike forretningsmodeller og reguleringer.
Innføringen av teknologier og forretningstekniske verktøy for organisasjonen som helhet kan øke åpenheten og kontrollerbarheten betydelig, sikre bærekraftig utvikling og forretningsreplikering, oppnå de nødvendige konkurransefortrinnene.

På seminaret får hver deltaker en datamaskin med MS Visio installert, hvor praktiske oppgaver utføres. Dette lar deltakerne, umiddelbart etter å ha fullført seminaret, integrere den ervervede erfaringen i aktivitetene til organisasjonene sine og videreutvikle dem.

Alt materiale og forretningsmodeller i MS Visio som demonstreres på seminaret sendes til deltakerne elektronisk.

For effektiv opplæring på seminaret kreves grunnleggende kunnskap og ferdigheter i å arbeide med MS Word og MS Excel programvare.

Seminarprogram:

  1. Grunnleggende om forretningsmodellering og forretningsteknikk
    • Grunnleggende konsepter innen forretningsmodellering, forretningsteknikk og organisasjonsutvikling
    • Grunnleggende styringssystemer og forretningsmodeller i organisasjonen, integrert styringssystem (IMS)
    • Divisjoner involvert i prosjekter og forretningstekniske oppgaver, deres samhandling
    • Kompleks forretningsmodell for en organisasjon: struktur, innhold og eksempler
    • MS Visio programvareprodukt: funksjoner og oppgaver som skal løses
    • Organisering av et prosjekt for implementering av MS Visio, formalisering og optimalisering av virksomhetsaktiviteter
  2. Grensesnitt og grunnleggende funksjoner til MS Visio
    • Hovedmeny ("bånd")
    • Lage modeller, jobbe med ark, sette opp visning og design av modeller
    • Verktøylinje ("former")
    • Arbeide med objekter (former): opprettelse, redigering, formatering (design), automatisk justering, oppsett for plassering av objekter på modellen, objektattributter og deres fylling
    • Arbeide med objektkoblinger, lage nye koblingspunkter på objekter, auto-koble objekter (hotspots-teknologi)
  3. Utvikling av grunnleggende og strategiske forretningsmodeller i MS Visio, eksempler
    • Strategisk ledelsesmetodikk og balansert målstyring (BSC/KPI)
    • Strategikart og BSC/KPI målkort, tildeling av indikatorer og prosjekter for strategiske mål
    • Tre av produkter og forretningsområder
    • Organisasjonsstruktur
    • Forretningsprosesstre, tildeler de ansvarlige for forretningsprosesser
    • Modell for årsak-og-virkning problemanalyse "Årsak og virkning Diagram" (Ishikawa diagram)
    • Systemarkitektur (informasjonssystemer, applikasjoner og IT-infrastruktur)
    • Modeller for prosjektledelse (GANT-Chart, PERT-Chart)
  4. Utvikling av prosessforretningsmodeller i MS Visio ved hjelp av ulike notasjoner (maler), eksempler
    • Metodikk for å beskrive forretningsprosesser og (BMS)
    • Metoder for å forbedre kvaliteten på forretningsprosesser og kvalitetsstyringssystem (QMS)
    • Gjennomgang av notasjoner for å beskrive forretningsprosesser, deres egenskaper og applikasjoner
    • Regler for utvikling av grafiske modeller av forretningsprosesser
    • Klassiske notasjoner: Grunnleggende flytskjema, kryssfunksjonelt flytskjema, IDEF0, IDEF3, DFD
    • ARIS-notasjoner: VACD (Value Added Chain Diagram), eEPC (Event Driven Process Chain), etc.
    • BPMN-notasjon (Business Process Model and Notation).
    • Visuell representasjon av forretningsprosesser (arbeidsflytdiagram)
    • Eksempler på forretningsprosessmodeller ( teknologiske kart) i ulike notasjoner: personalledelse, kvalitetsledelse, strategisk ledelse, risikostyring, ITIL / ITSM-prosesser (IT-støtte), krisehåndtering, markedsføring og kundeservice, økonomiske prosesser, etc.
  5. MS Visio tjenestefunksjoner, applikasjonseksempler
    • Koble data til forretningsmodeller (tilkobling til eksterne datakilder), automatisk oppdatering, datavisualisering
    • Kontrollere KPI-indikatorer (overvåking av forretningsprosesser)
    • Koble eksterne dokumenter til forretningsmodellobjekter
    • Dekomponering av forretningsprosesser (oppretting av nestede modeller)
    • Synkronisering av objekter på modeller
    • Utvikling av nye f(egne figurer/objekter)
    • Funksjonell kostnadsanalyse (FCA) av forretningsprosesser
    • Sjekke forretningsmodeller for korrekt konstruksjon og samsvar med notasjon (standard)
    • Web-utgiver (publisering av forretningsmodeller i HTML-format)
    • Utvikling av rapportmaler, automatisk generering av rapporter basert på forretningsmodeller (forretningsprosessforskrifter, målkort, forskrifter om organisasjonsstruktur, produkter etc.)
  6. Gjennomgå og komparativ analyse andre programvareprodukter for forretningsmodellering
    • Business Studio
    • AllFusion Process Modeler (BPWIN)
    • Forretningsingeniør

Forfatter og programleder:
Ekspert på forretningsteknikk og ledelse i banksektoren.
Medlem av koordineringskomiteen til Association of Russian Banks (ARB) for bankkvalitetsstandarder.
Partner i gruppen av selskaper "Modern Management Technologies".

Hvis du ønsker å delta, fyll ut skjemaet nedenfor:

Hvis det er nødvendig å analysere ulike problemer med å administrere en organisasjon (bedrift), vurderes problemer som "forstyrrer livet" til selskapet, for eksempel:

- lav hastighet i beslutningsprosessen,

– ansattes uansvarlighet,

− funksjonsfeil.

Konsekvensene av disse problemene er:

– reduksjon i lønnsomhet og konkurranseevne,

- nedgang i utviklingen,

– til og med oppsigelse av selskapets virksomhet.

Og når eieren eller lederen en dag innser at "det er umulig å fortsette å jobbe slik!", vil spørsmål dukke opp: « Hvem er skyldig? Hva bør jeg gjøre først?"

Samtidig er det intuitivt klart at for å løse problemer er det nødvendig å "sette ting i orden":

− beskrive på en bestemt måte, i samsvar med klare regler, alle aktiviteter i organisasjonen, fordi det er umulig å presentere alle forretningsprosesser på en gang;

− forklare ansatte hvordan de skal jobbe, hva de skal strebe etter

Med andre ord krever presserende problemer en systematisk tilnærming og formalisering av organisasjonens aktiviteter - et sett med praktiske og brukervennlige dokumenter som bestemmer hva som skal skje og hvordan, og hvem som er ansvarlig for hva.

Hvis du setter deg selv oppgaven med å forstå ledelsesspørsmål grundig, vil dette kreve ganske alvorlig investering av tid og krefter, og du kan til og med ha et ønske om å gjennomgå ytterligere opplæring. Her vil vi svare på noen reelle spørsmål som ofte stilles av bedriftseiere og ledere av innenlandske selskaper på forskjellige stadier av utviklingen.

1. Din bedrift er i begynnelsen av utviklingen: den har nylig kommet inn på markedet og begynner akkurat å utvikle den. Vanligvis på dette stadiet er antallet ansatte i organisasjonen lite (opptil 30 personer), organisasjonsstrukturen er ikke for formalisert, det er ikke mer enn 3 nivåer av hierarki, ledelsens fokus er oftest på produksjon og salg av produktet/tjenesten.

§ mangel på tydelig markert strategier videreutvikling (hva og hvorfor skal vi?)

§ usikkerhet i avgrensning av plikter og ansvar hver ansatt og hele avdelinger, reduserer kvaliteten på arbeidet og forårsaker interne konflikter

§ fremvekst alvorlige problemer ved bytte av ansatte selv på lavere nivå i selskapet, siden det ikke er noen mekanismer for å overføre kunnskap og ferdigheter til nye ansatte, på grunn av disse må de lære av sine feil. Etter å ha møtt en lignende situasjon minst et par ganger, begynner lederen uunngåelig å tenke på behovet for på en eller annen måte å formalisere arbeidsreglene til underordnede som utfører standardoperasjoner dag etter dag.

§ umulighet for videreutvikling av selskapet uten tiltrekke seg flere spesialister med spesielle kunnskaper og ferdigheter.

Regelmessigheten av disse og lignende vanskeligheter indikerer behovet for å skape i organisasjonen ryddig Og formalisert kontrollsystemer. Med andre ord, styringssystemet må for det første bli ordentlig organisert, og for det andre like forståelig for alle, det vil si dokumentert i presise termer.

Du kan utvikle regelverk og holde dem oppdatert manuelt, men etter en stund vil dette bli en kostbar tortur. Denne oppgaven kan løses raskere og enklere ved å bygge en forretningsmodell som skal legge grunnlaget for selskapets utvikling i fremtiden.

I tillegg til at det å utvikle en forretningsmodell er en nyttig og interessant aktivitet i seg selv, kan du ganske raskt føle en rekke positive effekter:

1. I prosessen med å beskrive selskapets aktiviteter, begynner du å bedre forstå hvordan fungerer virkelig bedriften, dvs. hvordan hovedprosessene foregår i den. Det er stor sannsynlighet for at ideer allerede på dette stadiet vil begynne å dukke opp. systemisk forbedring av arbeidet.

2. Resultatet av beskrivelsen er et sett med dokumenter (prosessforskrifter, stillingsbeskrivelser, forskrift om delinger osv.), som faktisk registrerer din arbeidsteknologi. Deretter er det praktisk å bruke det hvis det er nødvendig å raskt trene ansatte (hvis en ansatt slutter, blir det mye lettere å trene en ny).

3. Når teknologien for å utføre arbeid er tydelig presentert, er det mye lettere for lederen avgrense ansvarsområder mellom ansatte.

4. Generelt, tilstedeværelsen av en ekte fungerende forretningsmodell forbedrer kontrollerbarheten selskaper og effektiv bruk av ressursene: hvis modellen oppdateres kontinuerlig, har lederen muligheten til å "holde fingeren på pulsen" til selskapet, overvåke overholdelse av organisasjonsstrukturen og ressursallokering med reelle oppgaver.

I prinsippet kan du bygge en forretningsmodell for et lite selskap på kne, ved å bruke kjente MS Office-verktøy og MS Visio, som er mye brukt til å jobbe med grafikk. Men i fremtiden, ettersom selskapet utvikler seg, vil du definitivt trenge å gjøre endringer og tillegg til modellen opprettet gjennom prøving og feiling, og jo mer dynamisk selskapet utvikler seg, jo flere korrigeringer må du gjøre i ulike diagrammer og tabeller , noe som betyr at du må bruke alt mer tid på det. Det er mye mer praktisk å opprettholde relevansen til modellen hvis den i utgangspunktet er bygget i et spesielt miljø designet for forretningsmodellering.

De fleste ledere av ledende selskaper i deres markeder som med suksess bruker foinnrømmer at da de bestemte seg for å starte transformasjoner i organisasjonene sine, så de ikke for seg at den innledende fasen ville kreve en sterk vilje - de må gjenoppbygge ikke bare sine egne ideer og stereotypier, men også tenkningen til deres kolleger og underordnede, et system for å evaluere deres aktiviteter og en kjent organisasjonsstruktur. Men ved å vise utholdenhet og overvinne det umiddelbare ønsket om å avslutte prosjektet, får lederen et praktisk verktøy for å sette ting i orden i virksomheten sin. En ekstra "bonus" for de som helt i begynnelsen av organisasjonens dannelse ikke sparte tid og krefter på å utforme den, er muligheten til å unngå mange problemer på senere stadier av utviklingen, noe som betyr en betydelig økning i sjansene for suksess i konkurransen.

Spesielt formalisering av strategien og beskrivelse av selskapets forretningsprosesser gjør at ledelsen kan fokusere på ytelsesresultater organisasjoner. Forståelse forretningsprosess som et sett av handlinger som utføres i et selskap for å oppnå et gitt resultat, og vurderer alle selskapets aktiviteter som en kombinasjon av et visst antall forretningsprosesser, unngår prosesstilnærmingen overdreven utvidelse av antall personell og reduserer sannsynligheten for intern konkurranse mellom divisjoner i organisasjonen.

2. Selskapet har passert startfasen og er i aktivt vekst, flere og flere funksjonelle enheter og ledelsesnivåer vises i den, antallet ansatte er slik at toppledelsen ikke lenger er kjent med hver person personlig.

I praksis må de i bedrifter som sysselsetter mer enn 50 personer oftest forholde seg til et funksjonelt-hierarkisk styringssystem. Dens essens kan kort beskrives som å identifisere et visst antall funksjonsområder i virksomheten til en virksomhet og bygge et styringssystem i samsvar med dem. Etter hvert som organisasjonen vokser, bygger hvert av funksjonsområdene sitt eget hierarki av ledere - fra lederen (en slags "ekspert" på dette feltet) til den ordinære utøveren, og jo større organisasjonen er, jo flere nivåer i dette hierarkiet . Og hvis først hele systemet fungerer mer eller mindre vellykket, og gir organisasjonen håndterbarhet, vil effektiviteten uunngåelig reduseres etter hvert som selskapet vokser. Dette skyldes spesifikke beslutninger i systemet, når for å vurdere et problem fra alle sider, er samspillet mellom alle "eksperter" på forskjellige funksjonsområder nødvendig. Selv om det er få nivåer av hierarki i avdelinger, organiseres samhandlingen ganske raskt, men etter hvert som organisasjonen vokser, overskrider tiden brukt på beslutningstaking alle rimelige grenser. Resultatet av dette er overføringen ALLE løsninger for de fleste høy level og en global nedgang i kontrollerbarhet.

Mulige problemer, som får deg til å tenke på å optimalisere kontrollen:

§ Å løse driftsproblemer tar opp alt arbeidstid hode

§ Selskapets personalvekst overgår inntektsveksten

§ Konkurranse i markedet tvinger oss til å se etter reserver for å redusere produksjonskostnadene

§ Hver av selskapets funksjonelle avdelinger «lever sitt eget liv»; koordinering mellom dem skjer kun på høyeste nivå – på direktørnivå.

På dette stadiet er det allerede ekstremt vanskelig for selskapets ledelse å klare seg uten en klart definert modell av styringssystemet, siden strukturen til selskapet og informasjonsstrømmene i den er ganske kompleks, og det blir umulig å administrere dem "på et innfall." Samtidig er det dessverre lite å forbedre effektiviteten av virksomheten ved å bare vise den hierarkiske funksjonelle strukturen til et selskap på et stykke papir. Problemer er spesielt uttalte funksjonell ledelse dukke opp i store selskaper i perioder med ekstern ustabilitet, når beslutningshastigheten blir en kritisk egenskap ved systemet.

Løsningen på problemene som ligger i funksjonell ledelse er overgangen til prosessledelse: alle aktiviteter, uavhengig av hvilke funksjonelle egenskaper de tilhører, grupperes i blandede enheter, hvor hver eksekutor er ansvarlig for sin egen driftsblokk. Den grunnleggende forskjellen mellom disse tilnærmingene er overgangen fra å administrere FUNKSJONEN til organisasjonen (og dens strukturelle inndelinger, forent på grunnlag av EMNE av aktivitet: regnskap, juridisk avdeling, forsyning, salg, etc.) til ledelsen av FORRETNINGSPROSESSER basert på RESULTATER av aktivitet. Dermed, fokus flyttes mot effektiviteten i organisasjonen. Samtidig er alle mulige situasjoner når man utfører forretningsprosesser beskrevet så detaljert som mulig, siden i praksis er 80 % av situasjonene som oppstår typiske, og for dem er det tilrådelig å lage detaljerte regler for aktiviteter. I dette tilfellet personell i typiske situasjoner kan opptre så effektivt som mulig og, viktigst av alt, uavhengig, dvs. uten deltakelse fra en leder. Faktisk er lederen bare involvert i prosessen når det oppstår en ikke-standard situasjon, handlingene som ikke er regulert.

Takket være overgangen til prosessledelse er selskaper med stor skala av operasjoner i stand til å systematisere aktivitetene sine, og oppnå fordeler i to retninger samtidig:

1. Antall hierarkinivåer reduseres, siden styringsstrukturen er bygget i samsvar med strukturen til prosesser, og i praksis er det sjelden mer enn 5-6 av dem

2. Standardene for kontrollerbarhet i prosesstilnærmingen er 2-3 ganger høyere, siden ledelsen består i å koordinere ansatte og involvere dem i prosessen kun når de avviker fra dens vanlige kurs.

For å omorganisere styringssystemet basert på prosesstilnærmingen, må ledelsen bestemme utformingen av et nytt system, og retningen for dette designet er ovenfra og ned, dvs. De strategiske målene og målene for organisasjonen og indikatorer for deres oppnåelse bestemmes i utgangspunktet, og et system av prosesser er bygget på dette grunnlaget. Med utgangspunkt i prosessene dannes organisasjonsstrukturen. Bruken av moderne programvare for det riktige formålet, spesielt Business Studios forretningsmodelleringssystem, kan redusere arbeidsintensiteten betydelig og øke hastigheten på design. I tillegg tillater dette systemet ikke bare å forberede omorganiseringen, men også å støtte implementering og påfølgende vedlikehold av prosessstyring.

3. Organisasjonen har gått inn i en ny utviklingsfase: Du åpner grener og blir til en nettverksstruktur.

Noen ganger er en bedrifts utvikling så dynamisk at den ikke har tid til å transformere styringssystemet. Dette skjer vanligvis i raskt voksende markeder med gunstige forhold.

Når man bestemmer seg for å åpne eksterne divisjoner, kan man ikke undervurdere viktigheten av selskapets interne beredskap for et slikt skritt. Det er ingen hemmelighet at noen selskaper lykkes med å reprodusere og utvikle virksomheten sin uavhengig av region, mens andre har mange grener som er ulønnsomme.

Faktum er at metoder og teknologier for funksjonell ledelse, opp til et visst punkt effektive for "enkel virksomhet," ikke kan fungere på nettverksstrukturer.

Et selskaps beredskap til å åpne regionale divisjoner vurderes vanligvis på følgende nivåer:

§ ledelsesmessig;

§ økonomisk;

§ markedsføring;

§ prosess

Hvis en bedrift ledet etter et funksjonelt-hierarkisk prinsipp begynner å danne et nettverk, blir overgangen til prosessledelse nærmest uunngåelig, fordi den alvorlige omfanget av oppgaver og problemer med ekstern virksomhetsstyring gjør innføringen av vanlige ledelsesteknikker til en presserende nødvendighet.

Mulige problemer som får deg til å tenke på å optimalisere kontrollen:

§ Mangel på formalisert effektiv driftsteknologi

§ Umulighet (eller høye kostnader) for kontroll alle aspekter datterselskapenes aktiviteter

Vanligvis, når du åpner filialer, er den optimale måten fra alle synspunkter å overføre allerede utviklede driftsteknologier (ja, de samme teknologiene som du får når du beskriver og optimaliserer organisasjonens forretningsprosesser). Dette lar deg effektivt bruke eksisterende erfaring og "replisere" den med minimale problemer: tross alt, hvis aktivitetsteknologien ikke er formalisert, blir lederen tvunget til å organisere grenen personlig eller tildele den mest kompetente medarbeideren for dette. Og hvis du trenger å åpne mer enn en eller to grener, og til og med inn kort tid? Tilstedeværelsen av en forretningsmodell i dette tilfellet løser en betydelig del av organisatoriske problemer.

Videre er det å åpne filialer bare det første trinnet, og når du planlegger en slik utviklingsvei, må du være klar over at nettverket må administreres. Effektiv styring av et nettverk av filialer er umulig uten at de har en høy grad av uavhengighet til å tilpasse seg en rekke ytre forhold. I dette tilfellet fungerer bedriftssenteret utelukkende som et koordinerende organ som kontrollerer økonomiske og materielle strømmer. Nettverksledelse er derfor beslektet med prosessledelse, når ledelsens oppmerksomhet ikke er rettet mot å fungere, men på ytelsesresultater.

Som praksis viser, bruker de fleste selskaper med en vellykket regional strategi flere verktøy:

1. optimal struktur– fleksibel og lydhør overfor markedskrav;

2. riktig valgt filialstyringsmodell, som bestemmer graden av deres uavhengighet;

3. detaljert instrukser, forskrifter og dokumenter, definere arbeid

4. filialnett.

I en reell markedssituasjon må bedriftssenteret lage et styringssystem som på den ene siden skal gi et tilstrekkelig høyt nivå av regulering av virksomheten til filialer, og på den andre gi muligheter for en fleksibel respons på endringer i markedet. forhold.

Hvordan bestemme den optimale graden av standardisering av individuelle prosesser?

Et alternativ kan være å bruke en slik algoritme: Ved å definere standardprosesser løser bedriften problemet med optimal fordeling av funksjoner mellom senter og grener. Dermed blir hver regulert prosess i selskapet (leder, hoved, hjelpeperson) fordelt i henhold til regelen: utført bare i sentrum, utført bare i grenen, utført sammen. Det er åpenbart at prosesser som utføres kun i sentrum er standard og må reguleres. Når prosesser gjennomføres på begge nivåer, er det vanligvis lurt å også standardisere og regulere dem. For prosesser på avdelingsnivå er det mulig å enten standardisere gjennomføringen av prosessen – hvis alle grener er like, eller standardisere rapportering på prosessen – dersom utførelsen av prosessen i ulike grener kan variere vesentlig.

Som et resultat får selskapet en liste over prosesser som må standardiseres.

For å lykkes med å gjennomføre hele forberedende arbeid og bygge en effektiv nettverksstruktur, er det nødvendig, basert på klart definerte strategiske mål, å danne et prosessstyringssystem med optimal fordeling av krefter og ansvar mellom bedriftssenter og filialer. Bruken av prosesstilnærmingen i dette tilfellet er diktert av logikken i organisasjonens utvikling og behovet for å gi den tilstrekkelig ledelse.

Derfor, uansett hvilket utviklingsstadium selskapet befinner seg på, jo raskere ledelsen og eieren legger merke til å bygge et styringssystem ved hjelp av en prosesstilnærming, desto større er sannsynligheten for å komme i forkant av konkurrentene og forhindre forekomsten av typiske "voksesmerter". ”

Utformingen av et styringssystem, dets implementering og påfølgende riktig funksjon forenkles betydelig ved bruk av spesialisert programvare for forretningsmodellering.

Når du modellerer en prosess i Visio, må du huske det hovedmålet er å vise logikken i prosessen, deltakerne og handlingene de utfører. Følgelig, for å vise logikken i prosessen, bruker vi hendelser og logiske forbindelser mellom dem, vi viser deltakerne ved å bruke rollespillspor, og deres handlinger ved å bruke elementer av typen "prosess". Alle andre aspekter (dokumenter, ressurser) bør vises på en slik måte at det ikke kompliserer forståelsen av logikken; for å avsløre disse aspektene av prosessen fullt ut, er det bedre å bruke en tekst- eller tabellbeskrivelse.

For modelleringsformål vil vi i dette eksemplet vurdere en forenklet prosess for å selge et bestemt egenprodusert produkt.

Det er best å starte direkte modellering ved å spesifisere navnet og klargjøre grensene for prosessen. Grenser kan registreres umiddelbart i form av hendelser på diagrammet. I vårt eksempel vil grensehendelsene være «Kundens behov identifisert» og «Behov støttet av gjensidige forpliktelser» (se figur 3).

Ris. 3. Tittel- og prosessgrenser

For å gjøre diagrammene lettere å forstå, bør beskrivelsen av prosessen begynne i øvre venstre hjørne (se fig. 4). Det er ikke tilrådelig å bryte denne regelen, men det er mulig hvis artist-/sporrekkefølgen av en eller annen grunn er satt i utgangspunktet og de første jobbene i prosessen er på midt- eller bunnsporet.

Hvert arbeid/prosedyre på prosessdiagrammet skal utformes som en integrert blokk som har logiske grenser i form av hendelser og dokumenter. Disse logiske grensene lar deg bedre forstå og strukturere prosessen bedre.

Struktureringen av den beskrevne prosessen, hvis den ikke er utført på forhånd, er tilrådelig å utføre basert på en forståelse av kjeder av mellomresultater (hendelser) som er nødvendig for å oppnå prosessmål. Denne kjeden implementeres gjennom en trinnvis overgang fra den innledende til den siste hendelsen i prosessen. Når du formulerer hendelser, er det tilrådelig å operere gjenstander og deres tilstander("behov identifisert", "ordre behandlet", etc.).

Et forenklet eksempel på en prosessbeskrivelse er vist i fig. 5.

Ris. 5. Forenklet eksempel på en prosessbeskrivelse

I diagrammet er to blokker («Utarbeidelse av utkast til kontrakt» og «Inkludering av ordre i produksjonsplan») utpekt som «delprosesser». Dette betyr at det er tilsvarende dekomponeringsskjemaer for dem - detaljerte beskrivelser av disse underprosessene på separate sider i samme Visio-fil eller i andre filer.

Vladimir Repin

Generaldirektør for 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 brukes som regel av ansatte som ikke er opplært i komplekse notasjoner, ikke har systemanalyseferdigheter osv. Enkelheten og klarheten i ordningene er svært viktig for dem. Komplekse, forvirrende diagrammer som inneholder mange forskjellige symboler er dårlig forstått av folk, noe som gjør dem vanskelige å bruke i praksis. Derfor, for praktiske formål, er det viktig å velge riktig og bruke notasjonen (metodikken) 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. "Fremgangsmåte" Forretningssystemer Studio (ett av de mulige presentasjonsalternativene);
  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 dataprogram"diamant" ville 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 prosessdriften på ordningen? 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. Samtidig kan det nødvendige antallet dokumenter som er definert i katalogen over aktivitetsobjekter kobles til navngitte piler.

Denne tilnærmingen gjør det mulig:

  • Reduser antall grafiske elementer på prosessdiagrammet betydelig, og samtidig;
  • Vis i prosessreglementet nødvendig informasjon om inngående 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 av "Solution"-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 opp betydelig 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 folk vil lese den, men også på direkte utførelse av spesielle programvare— «motor» 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 klassiske 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

Lignende artikler

  • Workshop "Mennesket i den sosiale dimensjonen"

    Samfunnsfagstest Man er en personlighet for elever i 6. klasse i Federal State Education Standard. Testen inneholder 2 alternativer med 8 oppgaver hver og er ment å teste kunnskap om temaet Mennesket i den sosiale dimensjonen. Alternativ 1 1. Finn den mest korrekte slutten...

  • Testvurderingskriterier

    Testoppgaven ligger nær Unified State Exam-formatet i geografi Test for 10. klasseelever om temaet Politisk kart over verden Oppgavene er laget for én leksjon og består av del A, B og C. Første del inneholder 15 oppgaver, del B består av 4 oppgaver og del ...

  • Bioenergi etter fødselsdato Hvordan bestemme en persons energitester

    De som seriøst studerer esoterisme kommer før eller senere til undervisningen om energipotensialet til mennesker, deres aura og påvirkningen av dens farge på livet. Det viser seg at vitenskapen om bioenergi kan fortelle mye om en persons fødselsdato ...

  • Angel Alexei Day i henhold til kirkekalenderen

    Hoveddatoene som St. Alexei hedres på: 25. februar, 30. mars, 4. og 7. mai, 2. og 23. juni, 2. august, 6. oktober, desember Hvis vi tar hensyn til mindre betydningsfulle datoer, så er det bare 50 dager i året da en person ved navn Alexey kan...

  • Navnet Nicholas i den ortodokse kalenderen (helgener)

    Når, ifølge kirkekalenderen, er Nikolas navnedag: 22. mai, 19. desember – Nikolas av Myra, erkebiskop, vidunderarbeider, 10. august – Nikolas av Novgorod, Fool for Kristi skyld, 22. mars – Nikolas av Sevastopol, martyr. Karakteristisk...

  • Hellig navn Igor. Når heter Igors navnedag? Diminutive kjæledyrnavn

    Opprinnelsen til navnet Igor er ikke kjent med sikkerhet. Det er mange versjoner, men bare en av dem er den vanligste: det antas at dette er et skandinavisk navn og det kommer fra navnet Ingvar (krigeren til guden Ing). I følge denne versjonen...