Metoder for å beskrive forretningsprosesser. Analyse av modernerktøy Bruke modellering i forretningsprosesser er

Forretningsprosessanalyse er et av stadiene i arbeidet knyttet til å forbedre virksomhetens aktiviteter: beskrivelse, analyse og forbedring. Disse verkene er syklisk forbundet med hverandre (fig. 8.1). For å optimalisere noe, må du først beskrive objektet som vil bli gjenstand for endring, deretter utforske det, analysere dets styrker og svakheter, mulige alternativer for å forbedre effektiviteten, velge det beste fra dem, og først da gjøre alt nødvendig Endringer. Det samme gjelder arbeid knyttet til optimalisering av forretningsprosesser. Først av alt må de beskrives. Hvordan dette gjøres, ved hjelp av hvilke metoder, metoder og verktøy, er vist i de forrige kapitlene i denne opplæringen. Etter at disse arbeidene er fullført, kan du begynne å analysere forretningsprosesser, identifisere vanskeligheter, problemer med implementeringen av dem, samt finne måter å løse disse problemene og forbedre effektiviteten til prosessimplementering.

Ris. 8.1.

for deres forbedring

For vellykket analyse av forretningsprosesser er det nødvendig å fullføre beskrivelsen og bestemme analysemetodene. Beskrivelse som vist i fig. 8.1 er utført på forrige trinn. Metodene som skal brukes for å analysere forretningsprosesser diskuteres som regel helt i starten av prosjektgjennomføringen eller under forprosjektarbeid ved utforming av en problemstilling eller skriving av en teknisk oppgave. Det bør også tas i betraktning at analysemetodene bør være tilstrekkelige til metodene for å beskrive prosesser, siden hvis prosessen

ble beskrevet, for eksempel bare ved å bruke IDEF0-metodikken, er det nesten umulig å analysere prosessens implementeringstid.

Analyse er en aktivitet som utføres for å fastslå egnetheten, tilstrekkeligheten og effektiviteten til objektet som vurderes for å nå de fastsatte målene.

Konvensjonelt kan alle typer forretningsprosessanalyser deles inn i to typer: kvalitativ og kvantitativ. Metodene som brukes for å analysere prosessen med hensyn til dens bestanddeler, elementer og implementeringsmetode er kvalitative. Metodene som brukes for å evaluere prosessen i numeriske termer (utførelseshastighet, produksjonsmengde, salgskostnader, etc.) når man måler eventuelle indikatorer på effektiviteten av implementeringen, er kvantitative (tabell 8.2).

Tabell 8.2

Forretningsprosessanalyse

Som en del av prosess kontinuitetsanalyse sekvensen av operasjoner utført under gjennomføringen av prosessen blir studert, behovet for å forenkle forretningsprosesser bestemmes ved å redusere eller omfordele (overføre myndighet) ansvar mellom utførerne av prosessoperasjoner. Et eksempel er prosessen med å behandle et innkommende dokument (fig. 8.2), hvor operasjonen med å kopiere det innkommende dokumentet utføres to ganger (uthevet i grått). I tillegg til å kopiere et dokument to ganger, kaste bort papir (eller serverplass), ta dobbelt så lang tid, er det også problemet med å identifisere og kanskje til og med registrere disse kopiene.

Ris. 8.2.

Prosessressursanalyse er å studere ressursene som kreves for å implementere prosessen: menneskelig, logistisk og informasjonsmessig. Her er studieobjektene:

• eieren og ansvarlige utførere av prosessen og dens operasjoner;
• innkommende og utgående informasjon, samt informasjon som regulerer gjennomføringen av prosessen (instruksjoner, organisatoriske, administrative og regulatoriske rettsakter, etc.);
• materialer, utstyr, maskinverktøy, verktøy, informasjons- og kommunikasjonssystemer mv.

Alle disse ressursene, i varierende detaljeringsgrad, spesifiseres nesten alltid i løpet av modellering av forretningsprosesser. Detaljeringsgraden avhenger av organisasjonens spesifikasjoner og målene for analysen. Det skal bemerkes at innenfor rammen av denne analysen undersøkes ikke økonomiske ressurser, siden analysen av kostnadene ved å implementere prosessen utføres ved bruk av kvantitative typer analyser.

En av hovedoppgavene til denne typen analyse er å identifisere tilstedeværelsen av alle elementene som er nødvendige for gjennomføringen av prosessen.

Siden et av hovedprinsippene for prosessledelse er tilstedeværelsen av et subjekt som er ansvarlig for gjennomføringen av prosessen, dvs. dens eier, så vil et viktig skritt i denne analysen være identifiseringen av eieren av prosessen og de ansvarlige utførerne av alle delprosesser og operasjoner. Det er verdt å være oppmerksom på at det ikke kan være mer enn én ansvarlig utfører for hver prosess, delprosess eller operasjon.

Deretter analyseres antall deltakere i prosessen, samt gjennomførbarheten av deres bruk i denne prosessen. Det er hensiktsmessig å bruke sunn fornuft og benchmarking her. For eksempel, for å gå tilbake til prosessen med å behandle et innkommende dokument (se figur 8.2), er det verdt å merke seg at kopieringsfunksjonen utføres av to utøvere: den generelle avdelingen og direktørens sekretær. I tillegg til ovennevnte (duplisering av funksjonen), kan også spørsmålet om ansvar for oppbevaring av en kopi av det innkommende dokumentet oppstå. Hvilket eksemplar bør oppbevares og hvor? Eller bør begge kopiene beholdes? Kanskje vil det være mer hensiktsmessig å overføre funksjonene med å kopiere et innkommende dokument til en felles avdeling, og dermed redusere operasjoner, utførere og mulige risikoer forbundet med å lagre ulike versjoner av samme dokument på ulike steder.

Innenfor rammen av analysen av input og output studeres to hovedaspekter: 1) behovet for input og output; 2) identifisere ubrukte utganger.

I en detaljert studie av prosessen bestemmes det hvilken informasjon som kreves for effektiv implementering, og tilgjengeligheten av denne informasjonen fra utøveren blir kontrollert. Innenfor produktforbedringsprosessen (Figur 8.3) er det for eksempel kun kundeklager som fungerer som input, dvs. klager, så analysen av kundetilfredshet utføres kun på grunnlag av den negative opplevelsen av å bruke selskapets produkter, samt på grunnlag av kunnskapen og intuisjonen til analyseutøverne. For å gjennomføre en fullverdig analyse er det imidlertid nødvendig å få informasjon om hva kundene liker med selskapets produkter, hva er deres forslag og ønsker når det gjelder forbedring. Men denne informasjonen finnes ikke i den innkommende strømmen kalt "Kundeklager".

Ris. 8.3. Utdrag fra "Product Improvement"-prosessen

Det kan antas at denne viktige informasjonen ikke brukes i denne prosessen fordi den rett og slett ikke eksisterer. Følgelig blir prosessen, som et resultat av hvilken den skulle vises, enten ikke utført eller utført feil, dvs. produserer det ikke. Dermed kan en analyse av behovet for output fra en annen prosess utføres.

For eksempel har «Customer Satisfaction Management»-prosessen en av sine utganger knyttet til «Product Improvement»-prosessen. Dersom det innenfor rammen av «Customer Satisfaction Management»-prosessen gjennomføres en delprosess med innhenting av ønsker og forslag fra kunder, men ikke overføres som utgang/innspill til «Product Improvement»-prosessen, betyr dette. at det er snakk om en produksjon som ikke er formalisert og ikke overført til en annen prosess, selv om det er et klart behov for det.

Dermed kan vi konkludere med at dersom det er mangel på innkommende data, så er det mangel på utgående ressurser. Derfor må du se etter en prosess som er en leverandør av innkommende ressurser og analysere den for riktig utførelse og overføring av resultater til input fra andre prosesser.

Det skal bemerkes at denne utgangen ofte eksisterer, men den overføres til inngangen til en annen prosess kaotisk og i en uformalisert form.

Denne sekvensielle analysen av innganger/utganger til prosesser lar deg også identifisere ubrukte innkommende og utgående ressurser. For eksempel, i eksemplet med innkommende dokumentbehandlingsprosessen beskrevet ovenfor (se figur 8.2), ble operasjonene med å kopiere et innkommende dokument vurdert. Som du vet opprettes kopier slik at det i tilfelle tap av originalen vil være mulig å gjenopprette fremdriften i arbeidet med behandling og utførelse av dokumenter. Som et resultat av analysen av utdataene fra denne prosessen, oppstår spørsmålet: "Hvem er forbrukeren av dokumentene "Kopi av det innkommende dokumentet" og "Kopi av det innkommende dokumentet med en oppløsning"? Det er åpenbart at i dette tilfellet er det bare én forbruker og en siste kopi er nok for ham. Og det er to av dem. Dette betyr at ett av disse to dokumentene ikke vil bli brukt som utgang/inngang i andre prosesser, dvs. han er overflødig. Dette eksemplet viser en situasjon som ofte oppstår i forskjellige selskaper, hvor det opprettes mange dokumenter som ikke brukes eller bare brukes fordi de i henhold til regelverket må aksepteres og "støttes" i saken, men det er ingen reell behov for dem.

For å søke etter ubrukte utganger anbefaler V. V. Repin og V. G. Eliferer å bruke tabellen nedenfor (tabell 8.3).

Tabell 8.3

Finne ubrukte prosessutganger

Denne tabellen lar deg visuelt evaluere bruken av dokumentet i løpet av ulike bedriftsprosesser. For eksempel brukes Dokument 1. opprettet under implementeringen av operasjon 1.1 i prosess 1 når operasjon 3.1 og operasjon 10.4 utføres.

Ved å studere bevegelsen av data i en organisasjon fra tidspunktet for opprettelse eller inntreden i organisasjonen til øyeblikket av ødeleggelse eller overføring til det ytre miljø, er det nødvendig å analysere hele livssyklusen til data/dokument, inkludert bruken innenfor rammen. av ulike prosesser og lagring.

Analyse av etterlevelse av kravene til gjennomføring av prosessen utføres for å identifisere samsvar med den faktiske implementeringen av forretningsprosessen med kravene og standardene for den. Enhver virksomhet i selskapet er til en viss grad regulert av ulike lover, forskrifter og organisatoriske og administrative handlinger. Som regel blir kravene i lovgivningen i Den russiske føderasjonen tatt i betraktning i interne regulatoriske og organisatoriske og administrative handlinger, standarder, forskrifter og instruksjoner.

Krav - Et dokumentert kriterium som må oppfylles dersom det kreves samsvar med et dokument, og som det ikke er tillatt å avvike fra.

Derfor, når du forsker, er det tilrådelig å begrense oss til å sammenligne "som den er"-prosessmodellen med dokumentene som en bestemt organisasjon opererer med (med mindre annet er gitt av selskapets forskningsprosjekt). Slike dokumenter inkluderer: instruksjoner, forskrifter, standarder, pålegg, pålegg, lover og vedtekter og andre dokumenter innhentet i løpet av forskning på selskapets virksomhet.

Som en egen type analyse av samsvar med kravene for gjennomføring av prosessen, er det verdt å fremheve sjekken for samsvar med forretningsprosessen med kravene som stilles av kvalitetsstyring i samsvar med standarden som brukes i organisasjonen som studeres. Hvis selskapet ikke har et kvalitetsstyringssystem på plass, anbefales det å bruke PDCA- eller DMAIC-prosesskontrollsyklusen (se kapittel 2 for mer om disse syklusene).

SWOT-analyse en av de vanligste metodene for å kompilere egenskapene til en forretningsprosess på høyeste detaljnivå, siden den gjør det mulig å analysere prosessen både fra innsiden og i forhold til miljøet, noe som lar deg identifisere mulige måter å forbedre den.

SWOT (Strength, Weakness, Opportunities, Treatment) oversettes som styrker, svakheter, muligheter, fare. Når det gjelder analyse av forretningsprosesser, lar denne metoden deg analysere styrkene og svakhetene til forretningsprosessen, utviklingsmuligheter og risikoer. Den interne tilstanden til prosessen vurderes ved å identifisere styrker og svakheter, og analysen av muligheter og trusler lar deg evaluere prosessen fra siden av miljøet (i dette tilfellet betyr miljøet alt som går utover den spesifikke forretningsprosessen under studere).

Resultatene av SWOT-analysen presenteres i form av en matrise bestående av fire blokker. I tabellen. Figur 8.4 viser et eksempel på en SWOT-analyse av prosessen «Tilbud av frisørtjenester».

Tabell 8.4

Prosess SWOT-analyse

SWOT-analyse lar deg utføre en foreløpig kvalitativ vurdering av toppnivåprosessen, kun basert på resultatene av en undersøkelse og avhør av selskapets ledelse og direkte utøvere av forretningsprosessen. For implementeringen er det ikke nødvendig å bygge prosessmodeller. Den konstruerte SWOT-matrisen gir en slags holistisk generalisert forståelse av prosessen, som lar deg bestemme retningene for dybdestudie av prosessen og dens operasjoner, samt å formulere indikatorer på dens effektivitet.

Analyse av resultatene av prosessovervåking(ytelsesindikatorer) er et viktig verktøy for å styre organisasjonen som helhet og dens prosesser. Denne metoden brukes til å opprettholde prosesser i en håndterbar tilstand, for å kontrollere overholdelse av regulatoriske krav og forpliktelser til forbrukere av resultatene av gjennomføringen av prosesser, for å vurdere nivået av effektivitet og fleksibilitet.

Et system for måling av forretningsprosesser bør utvikles på designstadiet, men i praksis skjer alt ganske annerledes. I løpet av beskrivelsen og defineringen av forbedringsmetoder utvikles det derfor også indikatorer, som deretter evalueres i henhold til.

Avhengig av formålet og graden av viktighet, kan følgende grupper av målte prosessindikatorer skilles:

kvalitetsindikatorer:

kritisk indikatorer - etablere samsvar med produkter med sikkerhetskrav og gjeldende lovgivning;

nøkkel egenskaper som ikke er relatert til sikkerhet og lovverk, dvs. målbare indikatorer - gi en rask tilbakemelding og gi en mulighet for umiddelbar justering av prosessen, lar deg oppdage problemer fra det øyeblikket de dukker opp, samt måle kundemisnøye kvantitativt og kvalitativt;

• - nivå kundetilfredshet og lojalitet;
• prosessytelsesindikatorer:
• - økonomisk effektivitet - forholdet mellom utgangskostnadene og inngangskostnadene og ressursene som er brukt;

opptreden- en indikator på produksjonsvolumet per enhet av tildelte ressurser;

• - varighet syklus fra øyeblikket du mottar bestillingen til levering av det ferdige produktet;
• - effektivitet- graden av gjennomføring av de planlagte aktivitetene og oppnåelsen av de planlagte resultatene.

Prosessproduktivitetsindikatorer er ment å karakterisere prosessen med tanke på dens varighet og ressursbruk for implementeringen. Disse indikatorene kan uttrykkes i absolutte eller relative termer.

Som en del av forretningsprosessanalysen er kvantitative absolutte og relative indikatorer som karakteriserer prosessutførelsestid, teknologibruk, kostnad og kvalitet av interesse. Eksempler på disse indikatorene er gitt i tabell. 8.5.

Kategorien "teknologi" refererer til indikatorer som lar oss karakterisere teknologiene som brukes for gjennomføring av prosessen, jobber, personell, utstyr, telekommunikasjonsutstyr, programvare, etc. - alt som faller inn under "mekanismer og verktøy for gjennomføring av prosessen." Relative indikatorer i denne kategorien lar deg evaluere effektiviteten av organiseringen av en forretningsprosess, hvor rasjonelt ressursene brukes sammenlignet med andre prosesser i organisasjonen eller sammenlignet med lignende prosesser i et annet selskap. De absolutte verdiene til disse indikatorene brukes oftere til å bestemme andre indikatorer, for eksempel antall forespørsler til databasen til en operatør per skift.

Kategorien "kostnad" inkluderer indikatorer som karakteriserer prosessen når det gjelder økonomiske kostnader for implementering og oppnåelse av målene. En av de vanlige metodene for å beregne disse indikatorene er LAN- kostnadsanalyse.

Tabell 8.5

Eksempler på prosessmengde

Merk. Tabellen ble utarbeidet basert på materialene til V. V. Repin, V. G. Yeliferov.

Analyse av simuleringsresultater Det utføres vanligvis ved hjelp av analyser av slike resultater som:

• analyse av resultatene av modellering av de tidsmessige egenskapene til prosessen og ressursparametere (analyse av prosessens dynamikk);
• analyse av resultatene av beregningen av kostnadsegenskapene til prosessen (ABC-analyse, trinn-for-trinn-beregning av kostnaden).

Analysen av simuleringsresultater består i å tolke simuleringsresultatene oppnådd etter å ha behandlet informasjon om forretningsprosessen som studeres av et spesialisert dataprogram. Basert på denne informasjonen konkluderes det under hvilke forutsetninger prosessen som studeres vil bli gjennomført mest effektivt.

For referanse

Simulering- dette er prosessen med å beskrive funksjonen til systemet i tid, og de elementære fenomenene som utgjør prosessen imiteres, mens de opprettholder deres logiske struktur og sekvens av flyt i tid.

Simulering er en universell metode for å analysere og evaluere effektiviteten til systemer hvis oppførsel i stor grad avhenger av forekomsten av tilfeldige hendelser. Disse systemene inkluderer organisasjoner som opererer i en markedsøkonomi, spesielt i tider med politisk og økonomisk ustabilitet. Denne metoden lar deg analysere scenariene for utvikling av hendelser, oppførselen til ansatte i organisasjonen under visse forhold, for å evaluere effektiviteten av å ta visse ledelsesbeslutninger.

Grunnlaget for simuleringsmodellering er Monte Carlo-metoden (statistisk eksperiment) og uunnværlig bruk av informasjonsteknologi.

Simuleringsmodellering innebærer implementering av fire hovedtrinn: 1) å bygge en forretningsprosessmodell; 2) behandling av modellen i passende informasjonssystem designet for simulering; 3) analyse av de oppnådde resultatene; 4) evaluering av alternative scenarier for gjennomføring av forretningsprosessen.

Som en del av analysen av resultatene av simuleringsmodellering studeres dynamikken i prosessimplementeringen, endringer i prosessens tids- og ressurskarakteristikker. Ofte brukes simuleringsmodellering også for å analysere kostnadene ved prosessen (ABC-analyse, steg-for-steg kostnadsberegning). Resultatet av slike studier er som regel forslag og anbefalinger for bruk av visse tilnærminger som gjør det mulig å optimere bruken av økonomiske ressurser, redusere tiden for gjennomføring av disse prosessene, ved å øke effektiviteten til å organisere informasjonsutveksling mellom operasjoner. innenfor prosessen og med eksterne prosesser, samt gjennom bruk av informasjonssystemer og øke personalets produktivitet.

Derfor, ved hjelp av analysen, bestemmes spesielt følgende indikatorer:

• effektiviteten av informasjonsflytstyring;
• prosessutførelsestid;
• overholdelse av handlingene utført under gjennomføringen av prosessen med regulatoriske og andre krav;
• intern kontroll over utførelse av operasjoner og behandling av informasjon under gjennomføringen av prosessen;
• muligheten for å standardisere prosessoperasjoner;
• tilstedeværelsen av duplisering (operasjoner, data) og overflødige handlinger;
• effektiviteten til mekanismene som brukes, inkludert informasjonssystemer.

Som et resultat av analysen er det mulig å trekke konklusjoner om samsvar av prosessen (system av prosesser) med målene og målene, samt kravene til implementeringen av dem.

• Repin V.V., Eliferov V.G. Prosesstilnærming til ledelse. Modellering av forretningsprosesser.
• GOST ISO 9000-2011. Interstate standard. Kvalitetsstyringssystemer. Grunnleggende og ordforråd.
• Balandin E. MED., Yudaeva V.G. Internasjonale standarder ISO 9000-2000-serien: Retningslinjer for bruk. Ulyanovsk, 2003.
• Snetkov N.N. Simuleringsmodellering av økonomiske prosesser: pedagogisk og praktisk veiledning. Moskva: EAOI Publishing Center, 2008.

Forelesning 8. Analyse og modellering av virksomhetens forretningsprosesser Emne 4. Analyse og modellering av funksjonsområdet IS-implementering. Grunnleggende konsepter for organisatorisk forretningsmodellering. Selskapets misjon, treet av mål og strategier for å nå dem. Statisk beskrivelse av selskapet: selskapets forretningspotensial, selskapets funksjonalitet, ledelsens ansvarsområder. Dynamisk beskrivelse av selskapet. Prosessflytmodeller. Datastrukturmodeller. Den komplette forretningsmodellen til selskapet. Organisatoriske maler for forretningsmodellering. Bygge den organisatoriske og funksjonelle strukturen til selskapet. Stadier i utviklingen av forskriften om selskapets organisatoriske og funksjonelle struktur. Informasjonsteknologier for organisasjonsmodellering.

• • 1. Komplett forretningsmodell for selskapet
  • 2. Organisatoriske maler for forretningsmodellering
  • 3. Bygge en organisatorisk og funksjonell modell av selskapet
  • 4. Verktøy for organisasjonsmodellering
  • 5. Et eksempel på implementering av forretningsprosessmodeller i prosessen med å bygge en bedrifts markedsstrategi
  • 6.1 Foreløpig informasjon
  • 6.2 Visjon om prosjektgjennomføringen og dens grenser
  • 6.3 Utredningsrapport. Prosjektkrav.
• 7. Generalisert forretningsmodell for organisasjonen
• 8. Grunnleggende forretningsprosesser. Inn- og utdatainformasjon.
• 8.1 Beskrivelse av driften av de viktigste forretningsprosessene
• 8.1.1 Kontekstdiagram.

1. Komplett forretningsmodell for selskapet

Praksis har utviklet en rekke tilnærminger til organisasjonsanalyse, men ingeniørtilnærmingen har blitt den mest utbredte. Organisasjonsanalyse av selskapet med denne tilnærmingen utføres i henhold til en bestemt ordning ved å bruke hele selskapets forretningsmodell. Selskapet betraktes som et målrettet, åpent, sosioøkonomisk system som tilhører et hierarkisk sett av åpne eksterne supersystemer (marked, offentlige etater, etc.) og interne undersystemer (avdelinger, verksteder, team, etc.). Selskapets evner bestemmes av egenskapene til dets strukturelle divisjoner og organiseringen av deres samhandling. På fig. 1.1 presenterer et generalisert opplegg for organisatorisk forretningsmodellering. Konstruksjonen av et selskaps forretningsmodell begynner med en beskrivelse av modellen for interaksjon med det ytre miljø i henhold til loven om enhet og kamp om motsetninger, det vil si med definisjonen av selskapets oppdrag.

Ris. 1.1. Generalisert

Definisjonen av oppdraget er etter vår mening best representert i den normative handlingen definert av ISO. Oppdraget forstås som aktivitetene til organisasjonen, og mekanismene som gjør det mulig å nå målene.

Oppdraget er et slags mål på selskapets ambisjoner og bestemmer spesielt selskapets markedskrav (konkurransegjenstand). Definisjonen av oppdraget lar deg danne et tre med bedriftsmål - hierarkiske lister over foredling og spesifikasjon av oppdraget.

Måltreet danner et tre av strategier - hierarkiske lister over avklaring og detaljering av måloppnåelse. Samtidig utvikles strategier for vekst, integrasjon og investering av virksomheter på bedriftsnivå. Forretningsstrategiblokken definerer produkt- og konkurransestrategier, samt segmenterings- og markedsføringsstrategier.

Forretningspotensialet bestemmer på sin side funksjonaliteten til selskapet - en liste over forretningsfunksjoner, ledelsesfunksjoner og støttefunksjoner som kreves for å opprettholde denne typen forretningsaktiviteter med jevne mellomrom.

I tillegg spesifiseres ressursene som kreves for dette (materiell, menneskelig, informasjon) og strukturen til selskapet.

Å bygge forretningspotensialet og funksjonaliteten til selskapet gjør det mulig å bruke projeksjonsmatrisen til å bestemme ledelsens ansvarsområde.

Projeksjonsmatrise - en modell presentert i form av en matrise som definerer et system av relasjoner mellom klassifikatorer i hvilken som helst av kombinasjonene deres.

Beskrivelse av forretningspotensial, funksjonalitet og tilsvarende ansvarsmatriser er en statisk beskrivelse av selskapet. Samtidig identifiseres, klassifiseres og, viktigst av alt, de prosessene som fortsatt kjører i bedriften i minimert form (som funksjoner), til utøverne (de fremtidige eierne av disse prosessene).

På dette stadiet av forretningsmodellering dannes et generelt anerkjent sett med grunnleggende interne selskapsforskrifter:

grunnleggende forskrifter om selskapets organisatoriske og funksjonelle struktur;

en pakke med forskrifter om visse typer aktiviteter (økonomi, markedsføring, etc.);

en pakke med forskrifter om strukturelle inndelinger (verksteder, avdelinger, sektorer, grupper, etc.);

jobbinstruksjoner.

Dette gir åpenhet om virksomhetens aktiviteter ved å tydelig avgrense og dokumentere ledernes ansvarsområde.

interaksjon mellom deltakerne i prosessen, og deretter (på lavere nivå) - arbeidsteknologien til individuelle spesialister på deres arbeidsplasser.

Denne tilnærmingen gjør det mulig å beskrive virksomhetens aktiviteter ved hjelp av et universelt sett med ledelsesregistre (mål, strategier, produkter, funksjoner, organisatoriske enheter, etc.).

Ledelsesregistre i sin struktur er hierarkiske klassifiserere. Ved å kombinere klassifikatorer til funksjonelle grupper og feste elementer av forskjellige klassifiserere til hverandre ved hjelp av matriseprojeksjoner, kan du få en komplett forretningsmodell av selskapet.

Samtidig skjer det en prosess-målbeskrivelse av virksomheten som gjør det mulig å få innbyrdes relaterte svar på følgende spørsmål: hvorfor-hva-hvor-hvem-hvordan-når-til hvem-hvor mye (fig. 1.2) ).

Den organisatoriske forretningsmodelleringen fullføres ved utvikling av en datastrukturmodell som definerer listen og formatene til dokumenter som følger med prosessene i selskapet, og setter også formatene for å beskrive objektene til det ytre miljøet, komponenter og forskrifter til selskapet selv. . Samtidig opprettes et system med kataloger, på grunnlag av hvilke pakker med nødvendige dokumenter og rapporter mottas.

Ris. 1.2. Hovedstadiene i prosess-målbeskrivelsen av selskapet

Derfor er den komplette forretningsmodellen til selskapet et sett med funksjonelt orienterte informasjonsmodeller som gir innbyrdes relaterte svar på følgende spørsmål: "hvorfor" - "hva" - "hvor" - "hvem" - "hvor mye" - "hvordan" - "når" - "til hvem" (fig. 1.3).

Ris. 1.3. Komplett forretningsmodell for selskapet

Dermed involverer organisasjonsanalyse konstruksjonen av et kompleks av sammenhengende informasjonsmodeller for selskapet, som inkluderer:

· Strategisk målsettingsmodell (svarer på spørsmålene: hvorfor bedriften er engasjert i akkurat denne virksomheten, hvorfor den har til hensikt å være konkurransedyktig, hvilke mål og strategier som må implementeres for dette);

Organisasjons- og funksjonsmodell (svarer på spørsmålet om hvem som gjør hva i bedriften og hvem som har ansvaret for hva);

Funksjonell-teknologisk modell (svarer på spørsmålet om hva-hvordan implementeres i selskapet);

Prosess-rollemodell (svarer på spørsmålet hvem-hva-hvordan-til hvem);

Kvantitativ modell (svarer på spørsmålet om hvor mange ressurser som trengs);

· Datastrukturmodell (svarer på spørsmålet i hvilken form virksomhetens regelverk og objekter for det ytre miljø er beskrevet).

Det presenterte settet med modeller gir den nødvendige fullstendigheten og nøyaktigheten av beskrivelsen av selskapet og lar deg utvikle klare krav til informasjonssystemet som utformes.

2. Organisatoriske maler for forretningsmodellering

Teknologien for organisatorisk forretningsmodellering innebærer bruk av typiske malteknikker for å beskrive et selskap.

2.1 Mal for oppdragsutvikling

Som nevnt ovenfor er ethvert selskap med sitt mikro- og makromiljø et hierarki av nestede åpne, fagorienterte systemer. Selskapet er på den ene siden en del av markedet, og på den andre siden forsvarer det sine egne interesser i konkurransen. Oppdraget er et resultat av selskapets posisjonering blant andre markedsaktører. Derfor kan ikke selskapets oppdrag beskrives ved å analysere dets interne struktur. For å bygge en modell av selskapets interaksjon med det ytre miljø (definisjon av selskapets misjon i markedet), er det nødvendig:

identifisere markedet (supersystemet) som selskapet er en del av;

bestemme egenskapene (behovene) til markedet;

bestemme formålet (oppdraget) til selskapet, basert på dets rolle i markedet.

I tillegg er oppdraget, som nevnt ovenfor, et kompromiss mellom markedets behov på den ene siden og selskapets evner og ønske om å tilfredsstille disse interessene på den andre. Søket etter et kompromiss kan utføres i henhold til mønsteret vist i fig. 4.4.

Ris. 1.4. Oppdragsutviklingsmal (projeksjonsmatrise)

Beskriv grunnlaget for bedriftens konkurranseevne - et sett med egenskaper ved bedriften som et sosioøkonomisk system. For eksempel:

for objektet - det unike ved de mestrede teknologiene og eksklusiviteten til ressursene som er tilgjengelige i selskapet (finansielle, materielle, informative, etc.)

for faget - kunnskapen og ferdighetene til de ansatte og ledernes erfaring.

Dette bestemmer det unike ved bedriftens ressurser og ferdigheter og danner «kan»-holdningen.

Finn ut markedsforholdene, dvs. bestemme tilgjengeligheten av effektiv etterspørsel etter de tilbudte varene eller tjenestene og graden av tilfredshet med markedet fra konkurrenter. Dette lar deg forstå behovene til markedet og danne en "must"-posisjon.

Å identifisere tilstedeværelsen av medvirkende og motvirkende faktorer for den valgte typen aktivitet fra statlige institusjoner innen politikk og økonomi.

Vurdere utsiktene for utvikling av teknologi i det valgte aktivitetsfeltet.

Vurder mulig støtte eller motstand fra offentlige organisasjoner.

Sammenlign resultatene av handlingene ovenfor, ta i betraktning de juridiske, moralske, etiske og andre restriksjonene fra personalet og form stillingen "Jeg vil ha".

Vurder nivået på mulige kostnader og inntekter.

Vurder muligheten for å oppnå et kompromiss som er akseptabelt for alle parter og formuler selskapets oppdrag i samsvar med malen vist i fig. 1.5.

Ris. 1.5. Oppdragsdesignmal

Oppdraget i vid forstand er hovedforretningskonseptet til selskapet, angitt i form av åtte bestemmelser som definerer selskapets forhold til andre enheter:

1. Hva vil Kunden motta for å møte sine behov;

2. hvem, for hva og hvordan kan opptre som partner i selskapet;

3. på hvilket grunnlag det er ment å bygge relasjoner med konkurrenter (hva er spesielt viljen til å inngå midlertidige kompromisser);

4. hva vil eieren og aksjonærene få fra virksomheten;

5. hva ledere vil få ut av selskapets virksomhet;

6. hva vil personalet motta fra selskapet;

7. hva kan være samarbeidet med offentlige organisasjoner;

8. hvordan selskapets forhold til staten skal bygges (spesielt mulig deltakelse i støtte til statlige programmer).

2.2 Mal for virksomhetsdannelse

I samsvar med selskapets utviklede oppdrag bestemmes sosialt betydelige behov, hvis tilfredsstillelse er rettet mot selskapets virksomhet.

Utviklingen av selskapets forretningspotensial kan utføres i henhold til Forretningsformasjonsmalen vist i fig. 1.6.

Ris. 1.6. Mal for forretningsdannelse

Som et resultat dannes det et basismarked og et basisprodukt, hvis detaljering avgjør bedriftens tilbud gjennom øynene til kjøpere (produktgrupper) og grupper av kjøpere som er homogene i forhold til bedriftens produkter (markedssegmenter). Ved hjelp av en matriseprojeksjon (fig. 1.7) etableres en korrespondanse mellom de genererte produktgruppene og markedssegmentene og en liste over virksomhetens virksomheter fastsettes (bedriftens virksomheter ligger i skjæringspunktet mellom rader og kolonner).

Ris. 1.7. Forretningsformasjonsmal (projeksjonsmatrise)

2.3 Mal for dannelse av selskapets funksjonalitet (hovedforretningsfunksjoner)

Basert på listen over virksomheter, ved hjelp av en matriseprojeksjon (fig. 1.8), dannes en klassifiserer av selskapets forretningsfunksjoner.

Ris. 1.8. Mal for dannelse av grunnleggende forretningsfunksjoner

For å danne hovedfunksjonene til selskapets ledelse, blir først to grunnleggende klassifikatorer utviklet og godkjent - "Management Components" (en liste over verktøy / kontrollsløyfer som brukes i bedriften) og "Stages of the management cycle" (en teknologisk kjede av operasjoner) konsekvent implementert av ledere når de organiserer arbeid i enhver kontrollsløyfe). Videre, på samme måte, ved hjelp av en projeksjonsmatrise, dannes en liste over hovedstyringsfunksjonene. På fig. 4.9 eksempler på klassifiseringer er gitt, på grunnlag av hvilke en matrise er bygget - en generator av hovedstyringsfunksjonene.

Ris. 1.9. Mal for dannelsen av hovedfunksjonene til ledelsen

De presenterte matriseprojeksjonene (fig. 1.8, fig. 1.9)) lar deg danne funksjoner av enhver detaljgrad ved en mer detaljert beskrivelse av både rader og kolonner i matrisen.

2.4 Mal for utforming av ansvarsområder for virksomhetens funksjonalitet

Dannelsen av ansvarsområder for funksjonaliteten til selskapet utføres ved å bruke matrisen av organisatoriske projeksjoner (fig. 4.10).

Ris. 1.10. Mal for fordeling av funksjoner på organisasjonsenheter

Matrisen av organisasjonsfremskrivninger er en tabell, i radene som det er en liste over utøvende enheter, i kolonnene - en liste over funksjoner utført i selskapet. For hver funksjon bestemmes lederleddet som er ansvarlig for denne funksjonen.

Ved å fylle ut en slik tabell kan du finne divisjonene eller ansatte som utfører den for hver funksjon. En analyse av den fullførte tabellen lar deg se "hull" både i utførelsen av funksjoner og i arbeidsmengden til ansatte, samt rasjonelt omfordele alle oppgaver mellom utøvere og konsolidere som et system i dokumentet "Forskrift om organisasjonsstrukturen" .

Forskriften om organisasjonsstrukturen er et internt dokument som fikser: produktene og tjenestene til selskapet, funksjonene som utføres i selskapet, utøvende lenker som implementerer funksjonene, fordelingen av funksjoner mellom koblingene.

Tabellen over projeksjoner av funksjoner på lederleddene kan ha en veldig stor dimensjon. I mellomstore bedrifter er dette for eksempel 500 enheter - 20 lenker for 25 funksjoner. I store selskaper kan dette være 5000 enheter - 50 lenker per 100 funksjoner.

Matrisen for kommersielt ansvar er konstruert på lignende måte.

2.5 Mal for flytprosessbeskrivelse

Malen for flytprosessbeskrivelse er vist i fig. 4.11. En slik beskrivelse gir en ide om prosessen med suksessiv transformasjon av ressurser til produkter ved innsatsen til forskjellige utøvere på grunnlag av relevante forskrifter.

Ris. 1.11. Flytprosessmodell

Metoder for å bygge prosessmodeller vil bli gitt nedenfor.

3. Bygge en organisatorisk og funksjonell modell av selskapet

Organisasjons- og funksjonsmodellen til selskapet er bygget på grunnlag av funksjonsdiagrammet over selskapets aktiviteter i fig. 1.12.

Ris. 1.12. Funksjonell ordning for selskapet

Basert på oppdraget dannes målene og strategiene til selskapet. Med deres hjelp bestemmes det nødvendige settet med produkter og som et resultat de nødvendige ressursene. Reproduksjon av produkter skjer på grunn av prosessering av ressurser i hovedproduksjonssyklusen. Komponentene danner de nødvendige forretningsfunksjonene for tilførsel av ressurser, produksjon av produkter og distribusjon til salgsstedene. For å administrere den spesifiserte reproduksjonsprosessen, dannes et sett med styringskomponenter, som genererer et sett med styringsfunksjoner. For å støtte prosessene med reproduksjon og styring, dannes sett med passende støttefunksjoner (sikkerhet, teknisk utstyr, forebygging og reparasjon, etc.). Denne tilnærmingen gjør det mulig å beskrive en virksomhet ved å bruke et universelt sett med ledelsesregistre (mål, strategier, produkter, funksjoner, organisasjonsenheter, etc.). Ledelsesregistre er hierarkiske klassifikatorer. Ved å kombinere klassifikatorer i funksjonelle grupper og fikse elementene til forskjellige klassifikatorer ved hjelp av matriseprojeksjoner, kan du få en modell av selskapets organisasjonsstruktur.

For å bygge en organisasjonsfunksjonell modell brukes kun to typer elementære modeller.

Trelignende modeller (klassifikatorer) er presise hierarkiske lister over utvalgte styringsobjekter (organisasjonslenker, funksjoner, ressurser, inkludert utøvende mekanismer for forretningsprosesser, dokumenter og deres struktur, etc.). Hvert element i klassifisereren kan i tillegg karakteriseres av en rekke attributter: type, skala, kommentar, etc. Klassifikatorene er faktisk et sett med ledelsesregistre som hovedsakelig inneholder ikke-kvantitativ informasjon, hvis helhet setter koordinatsystemet for å beskrive virksomhetens aktiviteter. Antallet slike listeklassifiserere bestemmes av formålet med å bygge modellen.

Matrisemodeller er projeksjoner som definerer et system av relasjoner mellom klassifikatorer i en hvilken som helst kombinasjon. Koblinger kan ha flere attributter (retning, tittel, indeks, skala og vekt).

I den innledende modellen brukes bare noen få domeneklassifiserere:

hovedgruppene av produkter og tjenester i selskapet;

ressurser som forbrukes av selskapet i løpet av dets aktiviteter;

funksjoner (prosesser) støttet i selskapet;

organisatoriske enheter i selskapet.

Det er vanligvis tre hovedseksjoner i funksjonsklassifisereren:

hovedfunksjoner - direkte relatert til prosessen med å konvertere eksterne ressurser til produkter og tjenester til bedriften;

ledelsesfunksjoner - eller bedriftsledelsesfunksjoner;

støttefunksjoner - støtte produksjon, kommersiell og ledelsesaktiviteter.

Selskapets hovedfunksjon er å tilby produkter og tjenester, derfor utføres først en formell beskrivelse, avtale og godkjenning fra ledelsen av foretaket av listen over dets virksomheter (kommersiell aktivitet), produkter og tjenester. Fra denne klassifikatoren bør det være klart for eksterne motparter hvorfor selskapet er interessant for markedet, og for interne formål - hvorfor denne eller den funksjonaliteten til selskapet er nødvendig.

Som et resultat av disse operasjonene blir funksjonen identifisert og det opprettes en enhetlig terminologi for å beskrive virksomhetens funksjoner, som må avtales av alle ledende ledere. Ved kompilering av en klassifikator av organisasjonslenker er det viktig at detaljnivået på funksjoner samsvarer med detaljnivået på lenker. Etter dannelsen av alle grunnleggende klassifikatorer ved bruk av matriseprojeksjoner, blir de tildelt organisasjonsenhetene til bedriften:

Prosessen med å danne en matrise av projeksjoner av funksjoner på organisatoriske koblinger ligner i praksis et spill med tikken (fig. 1.10).

Radene i tabellen indikerer divisjonene, kolonnene - funksjonene som utgjør innholdet i styringsprosessen eller forretningsprosessen i et gitt selskap. I skjæringspunktet mellom funksjoner og avdelinger som har ansvar for gjennomføringen av funksjonen, settes et kryss. For projeksjoner av store dimensjoner brukes en mekanisme for å arrangere koblinger mellom to klassifiserere, representert av lister.

Standardpraksisen for å bygge modeller for den organisatoriske og funksjonelle strukturen til selskaper støtter to detaljnivåer:

aggregert modell;

detaljert modell.

En aggregert modell er en modell av en organisasjonsstruktur, hvis regnskapsregistre er begrenset i detaljgraden til 2-3 nivåer.

Hensikten med å bygge denne modellen er å gi informasjon om organisasjonsstrukturen til topplederne i selskapet for strategisk analyse, analyse av samsvar med denne strukturen med strategien og det ytre miljøet til selskapet. Modellen kan også leveres til eksterne brukere (for eksempel potensielle investorer som illustrasjon til en forretningsplan, store kunder, etc.).

Detaljert modell - en modell av organisasjonsstrukturen, hvor detaljering av regnskapsregistre utføres på dypere nivåer enn i den aggregerte modellen. Detaljeringsgraden i modellen skyldes de spesifikke behovene til bedriften (oppretting av visse organisatoriske forskrifter).

Formålet med å bygge denne modellen er å gi informasjon om fordeling av funksjonsansvar mellom virksomhetens divisjoner, samt om organisering av forretningsprosesser i virksomheten. Å bygge en detaljert modell lar deg lage ulike selskapsinterne forskrifter: Forskrift om organisasjonsstruktur fig. 1.13.

Nedenfor er et eksempel på en beskrivelse av fragmenter av den organisatoriske og funksjonelle modellen til en produksjonsbedrift fig. 1.14 og handelsselskap fig. 4.15. De gitte projeksjonsmatrisene er grunnlaget for å identifisere forretningsprosessene til et foretak og deres eiere i de påfølgende stadiene av å opprette en IS.

Ris. 1.13. Ordningen for å lage Forskrift om virksomhetens organisasjons- og funksjonsstruktur

Funksjonene til divisjonene til produksjonsbedriften vurderes innenfor følgende funksjonsområder:

corporate governance;

personale;

materielle ressurser;

produksjon;

produktutvikling;

planlegger;

forsyning/kjøp;

kvalitet;

salg/salg.

Fordelingen av funksjoner etter strukturelle divisjoner i sammenheng med individuelle funksjonelle aktivitetsområder for ledelse av en produksjonsbedrift er vist i fig. 1.14.

Funksjonene til handelsbedriftens avdelinger vurderes innenfor rammen av andre funksjonsområder (se fig. 1.15).

4. Verktøy for organisasjonsmodellering

Bruken av moderne teknologier for organisasjonsmodellering kan fremskynde organisasjonsdesign betydelig. På begynnelsen av 1990-tallet dukket de første programmene opp i Vesten for å løse problemer knyttet til organisatoriske problemer med bedriftsledelse. Orgware - en ny klasse programmer - var fokusert på å løse problemene med systematisering, lagring og behandling av "ikke-kvantitativ" informasjon om en forretningsorganisasjon, som tidligere ikke hadde tilstrekkelig datastøtte.

Det første russiske produktet - BIG-Master - ble opprettet som et dataverktøy for å støtte et bestemt konsept for bedriftsledelse, kalt vanlig ledelse. Hovedoppgaven til orgware var overgangen til strengt dokumenterte prosedyrer og forskrifter. Dataparadigmet for vanlig ledelse var basert på følgende tilnærming: "Det er nødvendig å ikke lage et system med sammenkoblede dokumenter, men et system med sammenkoblede informasjonsmodeller for en bedrift, som vil generere de nødvendige dokumentene."

Det konseptuelle grunnlaget for BIG-Master var en moderne prosesstilnærming til organiseringen av selskapets aktiviteter. På toppnivå er prosesssystemet vanligvis beskrevet av et funksjonstre – begrepet funksjonell brukes ofte for å betegne det. Funksjoner behandles her som "foldede" prosesser. Alle prosess-funksjoner, som et minimum, bør defineres (det vil si identifisert som en aktivitet som har et bestemt formål og resultater) og klassifisert etter type (hoved-, støtte-, ledelsesprosesser). Ansvar og myndighet bør også tildeles for å administrere prosesser med jevne mellomrom. På dette nivået brukes to typer modeller for å beskrive en bedrift i BIG-Master: tremodeller (klassifiserere) og matrisemodeller (projeksjoner).

På lavere nivå kan utvalgte ("nøkkel") prosesser beskrives som en teknologisk sekvens av operasjoner (for å oppnå de nødvendige resultatene). For å gjøre dette brukes flytmodeller av forretningsprosesser, hvis formål er å beskrive horisontale relasjoner i en organisasjon som kobler sammen de tidligere beskrevne objektene gjennom informasjons- og materialflyter. For strukturell analyse og design av prosesser beskrevet av flytmodeller, støtter BIG-Master SADT (IDEF) metodikken. Tilstedeværelsen av mekanismen til matriseprojeksjoner lar deg definere og beskrive selskapets prosesser som et integrert sammenkoblet system.

På grunn av klassifisørenes hierarkiske struktur inneholder forretningsmodellen samtidig «funksjons-utfører»-relasjoner på alle detaljnivåer, noe som gjør det mulig å bruke den innebygde rapportgeneratoren for å justere «oppløsningen» av synet på selskapet ift. en bestemt forvaltningsoppgave. Projeksjonssystemet lar deg reflektere i rapporten eventuelle tilleggsegenskaper knyttet til dette objektet (for eksempel kvalifikasjonskrav til personellet som er involvert i prosessen). I tillegg kan en titt på virksomheten knyttes til en hvilken som helst «referansekoordinat» – for eksempel fra et dokument eller en ansatt – i hvilke prosesser og hvordan de deltar mv.

Klassifiserere, projeksjoner og flytmodeller av forretningsprosesser støttes av ulike måter å visualisere dem på. For klassifikatorer - i form av lister og trær (digrafer), for projeksjon - i form av koblede lister og transponerte matriser, og for flytmodeller av forretningsprosesser - i form av IDEF0 (IDEF3) diagrammer og tekstbeskrivelse, som letter prosessdeltakernes forståelse av oppgaver. Samtidig skjer konstruksjonen av selve strømningsmodellene i de vanlige tabellformene.

I modellen er det mulig å danne et ubegrenset antall nye klassifiserere, fremskrivninger og flytmodeller, og følgelig rapporter og dokumenter for å beskrive og, viktigst av alt, lage regelverk for virksomhetens virksomhet.

Tilstedeværelsen av flere modelleringsverktøy i BIG-Master er ekstremt nyttig. Matrisemodeller støtter vertikal integrasjon - en detaljert systemmålbeskrivelse av selskapet, bygget i henhold til ledelseshierarkiet og kjørbare funksjoner. Prosessmodellen domineres av den funksjonell-teknologiske tilnærmingen - horisontal integrasjon av forretningsdrift ved prosedyrer. Alle funksjonene ovenfor til BIG-Master gjør det til et praktisk verktøy for organisasjonsmodellering.

5. Et eksempel på implementering av forretningsprosessmodeller i prosessen med å bygge en bedrifts markedsstrategi

5.1 Foreløpig informasjon

La den betingede bedriften "Progress" være den ledende innenlandske leverandøren av IT-produkter og løsninger innen selvbetjening, samt løsninger for banker og forhandlere. Selskapet har et bredt spekter av produkter og tjenester som tilbys, derfor er det nødvendig med en grundig porteføljeanalyse, dvs. vurdere organisasjonens produkt- og markedsmuligheter utover omfanget av dens nåværende aktiviteter og ta en endelig beslutning: om selskapet skal endre grensene for sin portefølje. Selskapet har et hovedkontor i Moskva og flere filialer over hele Russland og CIS-landene.

Hovedmålene for selskapets automatiseringsprosjekt:

automatisering av selskapets forretningsprosesser som gir kontrollpunkter for organiseringen av porteføljeanalyseprosessen;

forbedre effektiviteten til selskapets markedsavdelinger;

innføring av et fundamentalt nytt informasjonssystem som gir fullstendig informasjon om selskapets prosesser knyttet til porteføljeanalyse;

forbedre kvaliteten på arbeidet når du tar beslutninger om utvalget av produkter og tjenester til selskapet;

sikre effektiv samhandling mellom hovedkontoret og filialene på grunnlag av ett enkelt informasjonssystem;

gir muligheten til å overvåke statusen til systemelementer i sanntid.

5.2 Visjon om prosjektgjennomføring og dens grenser

Hovedmålet med prosjektet til det nye informasjonssystemet er en detaljert studie av delsystemene for å administrere strategisk ledelse og strategisk markedsføring av Progress-selskapet når det gjelder porteføljeanalyse og innovasjon.

Følgelig, innenfor rammen av prosjektet, forventes distribusjonen av det nye systemet kun å bli utført i følgende divisjoner av selskapet:

Ledelsesportefølje

markedsføring

innovasjon

For vellykket drift har disse divisjonene tilgang til informasjon fra undersystemene "direktesalg" og "salgsfremmende tiltak".

Omfanget av prosjektet inkluderer ikke:

Finansdepartementet

Regnskap

Personalavdelingen

Alle andre divisjoner som ikke er direkte relatert til porteføljeanalyse og innovasjon.

Som et resultat av prosjektet ser kunden et vellykket implementert informasjonssystem som bidrar til effektiv innsamling, lagring og analyse av data på selskapets porteføljeanalyse.

5.3 Utredningsrapport. Prosjektkrav

Personalet ved de studerte avdelingene (hovedkontor og filialer) er i dag 310 ansatte. Systemet lagrer og behandler data innhentet som et resultat av aktivitetene til følgende brukerkategorier:

ansatte i Porteføljeforvaltningsavdelingen;

ansatte i markedsavdelingen;

ansatte i produksjonsavdelingen;

ansatte i innovasjonsavdelingen;

selgere;

ansatte i kundeserviceavdelingen;

ansatte i den konkurrerende etterretningsavdelingen;

ansatte i analyseavdelingen;

Liste over programvare brukt av selskapet på tidspunktet for undersøkelsen:

produkt "BEST-Marketing" - utvikling av Intellect-Service-selskapet;

applikasjonspakke "SPSS" for statistisk analyse av data og beregning av ulike koeffisienter;

MS Excel kontorverktøy for å konsolidere allsidig informasjon.

Bruk av automasjonsobjekter av avdelinger

Selskapet har et tre-nivå system for arbeid med informasjon:

Nivå 1 - inndata og behandling av informasjon, elektroniske data ("BEST-Marketing");

Nivå 2 - lagring og behandling av informasjon (“BEST-Marketing” og MS Excel);

Nivå 3 - analyse av tilgjengelig informasjon, beslutningstaking, kontroll over deres utførelse (MS Excel og "SPSS").

Dokumentasjon

Til å følge selskapets markedsføringsaktiviteter er det ingen regulerte standarder innen dokumentasjon og rapportering, derfor er alle standardskjemaer for innsamling, lagring, analyse av data, samt rapportering, utviklet direkte av selskapets representanter.

Den nåværende trenden er å utvide prosesser som markedsføringsdatainnsamling og informasjon og analytisk støtte til det operasjonelle nivået, nivået til hver ansatt i selskapet som kan legge inn slike data eller som trenger markedsføringsinformasjon. I dette tilfellet går informasjonen til brukeren ikke gjennom spesielle tjenester i form av referanse- og analytiske rapporter, men direkte fra databasen. Som et resultat er funksjonene til systemet desentralisert: en rekke delsystemer for innsamling og distribusjon av informasjon vises i det, spredt over avdelinger Sergey Kartyshov. "MIS eller CRM: la oss finne det ut" (fullversjon av artikkelen publisert i mai-utgaven (2007) av magasinet "Marketing Management"). Derfor foreslås det å innføre generelle skjemaer for implementering av arbeidet med følgende delsystemer:

delsystemer for innsamling og konsolidering av intern informasjon

delsystemer for innsamling og konsolidering av ekstern informasjon (markedsinformasjon)

markedsundersøkelsesundersystemer

delsystem for informasjonsstøtte av operasjonelle markedsføringsprosesser

delsystem for utvikling av informasjonssystem (konsepter, teknologier, modeller, etc.)

Oppgavene til informasjonssystemet krever at programvaren kombinerer mulighetene for fleksibel konfigurasjon av regnskapsfunksjoner og rask konstruksjon av vilkårlig analytisk rapportering. Disse oppgavene er ikke fullt implementert i noen av de for tiden aksepterte programvareklassene.

Hvis vi summerer opp alle oppgavene som er inkludert i funksjonaliteten til det fremtidige informasjonssystemet, blir det åpenbart at omfanget av oppgavene her er ikke mindre enn i markedsføringsinformasjonssystemet (MIS), og til og med ikke mindre enn i bedriftens informasjonssystem (CIS). Og de generelle målene er identiske - alle disse systemene er rettet mot å støtte markedsorienterte styringsprosesser på strategisk, taktisk og operasjonelt nivå. Den grunnleggende forskjellen mellom CIS og MIS er at CIS konsentrerer hovedinnsatsen på regnskap for interne data, mens MIS fokuserer på eksterne data. I vårt tilfelle vil informasjonssystemet (regnskap og analytisk) være en kombinasjon av disse to typer systemer.

Når det gjelder spesifikasjonene til fagområdet, er det verdt å merke seg her at i tillegg til standardfunksjonene som utføres av markedsførere, for å utføre porteføljeanalyse og bedre bruk av økonomiske ressurser, jobber Progress-ansatte på følgende områder:

Studie av populariteten til individuelle produkter for ulike målgrupper.

Studiet av effektiviteten til firmaets portefølje som helhet.

Utforske muligheter for å utvide firmaets forretningsportefølje.

Detaljert undersøkelse av konkurrenter.

Studerer den synergistiske effekten i den eksisterende porteføljen og i den potensielle, så vel som hos konkurrenter.

Naturligvis stilles det visse krav til prosjektet til et informasjonssystem. Informasjonssystemet må være anvendelig på problemene som stilles. Betingelsen om pålitelighet av informasjonssystem er fastsatt som en av de første betingelsene. Informasjonen som er lagret i systemet, i tilfelle systemfeil, bør lagres i arkivene (databasene) som er beregnet for det. Innføring av et informasjonssystem bør øke produktivitetsnivået i bedriften, da tiden brukt på å løse oppgaver vil reduseres betydelig. Et brukervennlig grensesnitt bidrar til å redusere behandlingstiden for informasjon dersom brukeren ikke kaster bort tid på å søke etter nødvendige funksjoner i programmenyen. Informasjonssystemet skal ikke ta opp mye plass på harddisken og skal ikke bremse prosessoren. Som et resultat av konstruksjonen må systemet være brukbart og ikke funksjonsfeil under drift.

Systemet skal gi rapporter om alle forhold som er avtalt med kunden. Type og format på dokumenter er forhandlet på forhånd. Avhengig av brukerens behov, kan andre forespørsler og, som et resultat, rapporter opprettes.

Informasjonssystemet er ment å lagre et sett med kataloger. Listen over kataloger er gitt i tabell 1.1 med en beskrivelse av informasjonen som er lagret i dem. Arbeidsflytautomatisering er et nødvendig krav i dag. Opprettelsen av elektroniske kataloger vil tillate strukturering av informasjon, sortering og valg i samsvar med forespørselen.

Tabell 1.1. Referanse bøker

For bedre å forstå hvordan funksjoner tildeles avdelinger, er det nødvendig å vurdere det generaliserte organisasjonskartet til firmaet (fig. 1.14). Et organisasjonskart illustrerer rapporteringsforholdene i en bedrift.

Ris. 1.14. Organisering av informasjonsflyt i den betraktede strukturen til selskapet.

Ledelsen tar beslutninger knyttet til større endringer i selskapets virksomhet. Avdelinger på andre nivå er ansvarlige overfor lederen, og utveksler også data seg imellom. Porteføljestyringsavdelingen, basert på data mottatt fra kundeservice og markedsavdelinger, utarbeider sammendragsrapporter for planlegging av selskapets forretningsportefølje.

Porteføljeforvaltningsavdelingen rapporterer til Analytics-avdelingen og Competitive Intelligence-avdelingen. Spesielt får de ansatte i Porteføljeforvaltningsavdelingen informasjon fra produksjonsavdelingen. Porteføljeforvaltningsavdelingen samarbeider også tett med Innovasjonsavdelingen. Dermed samler porteføljestyringsavdelingen inn data i et visst format (praktisk for påfølgende analyse) fra nesten alle avdelinger i bedriften og gjennomfører en omfattende analyse av forretningsporteføljen når det gjelder eksterne og interne indikatorer. Deretter er det en rapport til ledelsen om tilstanden til forretningsporteføljen og anbefalinger for endring av selskapets policy for produktene i forretningsporteføljen, forslag til diversifisering. Når du tar beslutninger om diversifisering, samhandler Porteføljeforvaltningsavdelingen med Innovasjonsavdelingen gjennom ulike analyserapporter. I løpet av dette samarbeidet velges ideer, rapporter til ledelsen, diskusjoner med produksjonsavdelingen, budsjettering og kontroll over implementering av ideer godkjent av ledelsen.

Alle de ovennevnte prosessene ved virksomheten er ikke systematiske og tydelig formaliserte. Derfor ser selskapets ledelse behovet for å automatisere disse prosessene.

Basert på denne analysen av samspillet mellom ulike avdelinger kan vi formulere forretningsprosesser som må automatiseres (tabell 1.2).

Tabell 1.2.

Automatiserte forretningsprosesser

6. Generalisert forretningsmodell for organisasjonen

Organisasjonsanalyse av firmaet utføres ved hjelp av forretningsmodellen. Organisasjonen betraktes som et mål, åpent, sosioøkonomisk system som tilhører et hierarkisk sett av åpne eksterne supersystemer og interne undersystemer Beskrivelsen av å bygge en komplett forretningsmodell av selskapet presenteres på nettsiden http://www.intuit.ru/department/se/devis/4/(kurs for informasjonssystemdesign - http://www.intuit.ru/department/se/devis/).. Selskapets evner bestemmes av egenskapene til dets strukturelle enheter og organiseringen av deres samhandling. Å bygge en forretningsmodell av et selskap begynner med en beskrivelse av modellen for samhandling med det ytre miljø.

Selskapets oppgave på dette stadiet er å ta en beslutning om å gjøre endringer i forretningsporteføljen. Som et resultat av å definere hovedoppgaven kan vi formulere et tre av mål (fig. 3.1), det vil si hierarkisk ordne målene og midlene rettet mot å nå det globale målet.

Ris. 1.15. Måltre

For å bygge en prosessflytmodell er det nødvendig å bestemme prosessene hvor informasjonsstrømmen endres (tabell 1.3).

Tabell 1.3.

Endring av informasjonsflyt

7. Grunnleggende forretningsprosesser. Inn- og utdatainformasjon

7 .1 Beskrivelse av driften av de viktigste forretningsprosessene

7.1.1 Kontekstdiagram

Figur 4.1 er et kontekstdiagram av Business Portfolio Management-prosessen. Inndatainformasjonen bestemmes, som på en eller annen måte endres av verket og blir til utdatainformasjon. Samtidig er pilene til mekanismen (arbeidet utføres av personellet og eksisterende programvare) og ledelsen (arbeidet er underlagt kontrollhandlingen, regulatoriske dokumenter og utføres under hensyntagen til bedriftsbegrensninger).

Ris. 1.16. Funksjonsdiagram over forretningsprosesser.

Overvåking av det nåværende og tiltenkte miljøet

situasjonsanalyse

Analyse av Ansoff-matrisen (fig. 1.17).

Ris. 1.17. Ansoff matrise

Lignende dokumenter

Generelle systemprinsipper for simuleringsmodellering av forretningsprosesser. Karakteristiske trekk ved komplekse organisatoriske og tekniske systemer, midler for deres representasjon, prognoseverktøy. Stadier av å bygge strukturelle modeller av systemet; prosjektledelse.

presentasjon, lagt til 11.09.2013


Konseptet med en forretningsplan, dens formål, funksjoner i organiseringen av utviklingsprosessen og innholdet. Generelle kjennetegn ved forsikringsvirksomheten. Utarbeidelse av en forretningsplan for å åpne et representasjonskontor for forsikringsselskapet Yugoria i byen Asbest.

avhandling, lagt til 20.03.2011


Formål, matematisk modell av forretningsplanen. Innholdet i delene. Indikatorer for effektiviteten av bruken av selskapets kapital. Reengineering av forretningsprosesser. Analyse av virksomhetens økonomiske aktivitet, utvikling av et system med økonomiske planer for selskapet.

semesteroppgave, lagt til 21.08.2016


Analyse av kundekrav, vurdering av nivået på selskapet, sette mål for reengineering. Bygge organisasjonsstrukturen til en eksisterende virksomhet. Analyse av eksisterende virksomhet og identifisering av problemer. Bygge en presedensmodell for en ny forretningsprosess.

semesteroppgave, lagt til 28.07.2013


Historien om etableringen av LLC "Veliky Korol". Generelle kjennetegn ved organisasjonens profesjonelle aktiviteter. Analyse av hovedindikatorene for den finansielle og økonomiske aktiviteten til selskapet. Analyse av selskapet når det gjelder forretningslinjer og forretningsprosesser.

praksisrapport, lagt til 14.04.2014


Studiet av organisasjonsstrukturen og hovedindikatorene for den økonomiske aktiviteten til selskapet på eksemplet med LLC "BBK". Markedsundersøkelser for produkter og konkurrerende selskaper. Utarbeide forretningsplan for virksomheten, produksjons- og økonomiplaner.

avhandling, lagt til 14.08.2010


Kort om oljevirksomheten i Russland. På selskapet "Lukoil". Historien om selskapet "Lukoil". Oljevirksomheten i Russland faller inn under kategorien entreprenørskap, klassifisert av staten som et marked med naturlige monopoler.

semesteroppgave, lagt til 06.02.2006


Konseptet og typologien til forretningsplaner. Bli kjent med aktivitetene og målene til det russiske Straus-selskapet. Utvikling av markedsførings-, produksjons-, organisasjons- og økonomiplaner for utvikling av en gård for oppdrett av struts.

forretningsplan, lagt til 17.11.2013


Analyse av utkast til forretningsplan for åpning av studioet "ReD dummy". De viktigste typer dekorasjon av selskapet "ReD dummy": vinylapplikasjon, lette kranser, lette figurer. Kjennetegn på den økonomiske planen til selskapet, kontantstrøm.

kontrollarbeid, lagt til 05.12.2012


Bli kjent med forretningsplanen for utviklingen av bedriften, dens seksjoner, stadier av utvikling og implementering. Produksjonskapasitet, produkter, sikre etterspørsel fra markedet. Analyse av selskapets finansielle og økonomiske aktiviteter. Beregning av produktlønnsomhet.

verktøy for forretningsprosessmodellering

I Russland er følgende modelleringsverktøy mye brukt for modellering og analyse av forretningsprosesser: Rasjonell Rose, Oracle-designer, AllFusion Process Modeler (BPWin) og AllFusion ERwin Data Modeler (ERWin), ARIS, kraftdesigner. I utlandet brukes aktivt i tillegg til de nevnte verktøy som System Architect, Ithink Analyst, ReThink etc. Tabell 1 viser en liste over verktøy som er involvert i gjennomgangen. Informasjonen som gis inkluderer:

• navnet på verktøyet;
• data om leverandøren og representanten i Russland;
• kort beskrivelse av verktøyet.

Vi skiller ut hovedkriteriene som lar oss velge fra de presenterte modelleringsverktøyene de hvis bruk i Russland mer sannsynlig kan rettferdiggjøre seg selv. Disse kriteriene er:

• produktets stabile posisjon i markedet(levetiden, produktutviklingsprogram, problemrapporteringssystem, sett med applikasjoner, etc.);
• produktprevalens(antall solgte lisenser, tilstedeværelse, størrelse og aktivitetsnivå for brukergruppen);
• leverandørstøtte tilgjengelighet. Slike tjenester kan omfatte en telefonhotline, teknisk og rådgivende støtte gjennom en leverandørs representant i Russland;
• tilgjengelighet til utdanning. Opplæring kan gjennomføres i lokalene til leverandørens representant i Russland, brukeren eller andre steder;
• tilgjengelighet av produktmaterialer. Disse kan inkludere datalæringsmateriell, veiledninger, bøker, artikler, online informasjon, demoer.

Fra listen over verktøy gitt i tabellen, for en mer detaljert analyse, velger vi de programvareproduktene som oppfyller de angitte kriteriene. I dette tilfellet faller BPWIn / ERWin, Oracle Designer, Rational Rose, Power Designer, ARIS innenfor rammen av vår videre vurdering, som en mer detaljert beskrivelse er gitt nedenfor.

BPWin og ERWin fra Computer Associates. Computer Associates International Inc. (CA) er en av de fem beste programvareleverandørene som tilbyr modellering, sikkerhetskopiering, administrasjon av bedriftsinfrastruktur (nettverk, servere, etc.), informasjonssikkerhet, business intelligence, etc.-verktøy. BPWin-pakken er basert på IDEF-metodikken og er beregnet på funksjonell modellering og analyse av virksomheten. IDEF-metodikken, som er den offisielle amerikanske føderale standarden, er et sett med metoder, regler og prosedyrer designet for å bygge en funksjonell modell av et objekt i ethvert fagområde. IDEF-funksjonsmodellen reflekterer den funksjonelle strukturen til et objekt, dvs. handlingene den utfører og sammenhengene mellom disse handlingene.

BPwin-funksjoner:

• støtter tre standardnotasjoner samtidig - IDEF0 (funksjonell modellering), DFD (dataflytmodellering) og IDEF3 (arbeidsflytmodellering). Disse tre hovedperspektivene lar deg beskrive fagområdet på den mest omfattende måten;
• lar deg optimalisere prosedyrer i selskapet;
• støtter fullt ut metoder for å beregne kostnadene for volumet av økonomisk aktivitet (funksjonell kostnadsanalyse, ABC);
• forenkler ISO9000 kvalitetssertifisering;
• integrert med ERwin (for databasemodellering), Paradigm Plus (for modellering av programvarekomponenter), etc.;
• integrert med Arena-simuleringsverktøy;
• inneholder sin egen rapportgenerator;
• lar deg effektivt manipulere modeller - slå sammen og dele dem;
• har et bredt utvalg av verktøy for å dokumentere modeller, prosjekter.

ERWin-pakken er et konseptuelt databasemodelleringsverktøy. Den brukes til å modellere og lage databaser med vilkårlig kompleksitet basert på "entitetsforhold"-diagrammer. For øyeblikket er ERWin den mest populære datamodelleringspakken på grunn av støtten for et bredt spekter av DBMS i forskjellige klasser. ERWin funksjoner:

• støtter SADT-strukturmodelleringsmetodikken og følgende notasjoner: standard IDEF1x-notasjon for ER-diagrammer av datamodeller, IE-notasjon og en spesiell notasjon for utforming av datavarehus - Dimensjonsmessig;
• direkte (oppretting av en database basert på en modell) og omvendt (modellgenerering fra en eksisterende database) design støttes for 20 typer DBMS: desktop, relasjonsbasert og spesialisert DBMS designet for å lage datavarehus;
• integrert av Computer Associates-produktlinjen for å støtte alle stadier av IS-utvikling, Oracle Designer CASE-verktøy, Rational Rose, utviklingsverktøy, etc.;
• lar deg gjenbruke komponenter fra tidligere opprettede modeller, samt bruke utviklingen til andre utviklere;
• samarbeid mellom en gruppe designere med de samme modellene er mulig (ved hjelp av AllFusion Model Manager);
• lar deg overføre databasestrukturen (ikke selve dataene!) fra en DBMS av en type DBMS til en annen;
• lar deg dokumentere strukturen til databasen.

Oracle Designer av Oracle. Oracle Designer-verktøysettet tilbyr en integrert løsning for utvikling av bedriftsapplikasjonssystemer for web- og klient-/serverapplikasjoner. Oracle Designer er involvert i alle faser av programvareutviklingens livssyklus, fra forretningsprosessmodellering til implementering. Bruken av et enkelt depot gjør det mulig å bruke hvilken som helst av komponentene for den raske utviklingen av skalerbare distribuerte applikasjoner på tvers av plattformer. Oppgaven til Oracle Designer er å samle inn data om brukernes behov og automatisere konstruksjonen av fleksible grafiske applikasjoner. Oracle Designer brukes ikke bare til å lage applikasjoner, men også til å holde styr på endringene som uunngåelig skjer under driften av systemet. Grafiske prosjektdefinisjonsmodeller integrert med flerbrukerlageret gjør det mye enklere å jobbe med Oracle Designer. Verktøyene er bygget rundt vanlige metoder som spenner over hele utviklingslivssyklusen og lar brukerne jobbe på en måte som er kjent for deres organisasjon. Dette gir fleksibilitet og en åpen tilnærming til programvareutvikling ved å bruke kun de delene av produktet som kreves for en gitt oppgave. Utviklingsprosessen støtter RAD, JAD, informasjonsdesign, fossefallsmetode, iterativ metode osv. Ved å bruke disse prinsippene kan du oppnå en vellykket balanse mellom organisatoriske behov og teknologiske evner, og til og med effektivt håndtere risikoen forbundet med hyppige uunngåelige og viktige endringer i begge områdene. Oracle Designer konseptuelle modelleringsverktøy inkluderer:

• ER-diagrammer (diagrammer over informasjonsstrukturen til fagområdet, representert som objekter og deres relasjoner);
• funksjonelle hierarkidiagrammer som beskriver funksjonene som systemet utfører;
• diagrammer over datastrømmer som sirkulerer i virksomheten.

Slike modeller representerer informasjonsbehov i en praktisk og visuell form, noe som gjør dem til et godt kommunikasjonsmiddel mellom designere og brukere i prosessen med å avgrense oppgavesettingen. Enhver utvikler er interessert i at beskrivelsen av den konseptuelle modellen brukes til å lage spesifikasjoner som beskriver strukturen og hovedkomponentene i det fremtidige systemet. I Oracle Designer er alle systemdesignspesifikasjoner utviklet fra konseptuelle nivåmodeller og sikrer at alle krav og begrensninger som finnes deri, er oppfylt. De resulterende systemkomponentene kan konverteres til ekte databaseobjekter, skjermskjemaer og rapporter. Den siste delen av prosjektutviklingen - automatisk generering av serverkomponenter - er ikke bare mulig for Oracle-databaseserveren, men også for Microsoft SQL Server, DB/2, Sybase og en rekke andre. Eventuelle endringer i forretningsprosesser kan gjøres i modellene og en modifisert applikasjon genereres umiddelbart, basert på nye forretningsopplegg. Samtidig vil alt som er utviklet tidligere, lagres og inkluderes i det nye prosjektet. Open Designer lager automatisk rapporter som inneholder all informasjon om prosjektet og kan brukes som et sett med dokumenter som gjenspeiler den nåværende statusen til prosjektet.

IBM Rational Rose . IBM Rational Rose er en del av IBM Rational Suite og er designet for å modellere programvaresystemer ved å bruke et bredt spekter av verktøy og plattformer. Rational Rose er et av de ledende visuelle modelleringsverktøyene i programvareindustrien med full UML-støtte og flerspråklig teamutviklingsstøtte. Verktøyet støtter fullt ut den komponentorienterte prosessen med å lage IP. Alle prosjektdeltakere - analytikere, modellbyggere, utviklere og andre - kan bruke modeller bygget i Rational Rose for å lage det endelige produktet mer effektivt. For forretningsanalytikere gir Rational Rose-verktøyet muligheten til å beskrive og analysere forretningsprosesser i et gitt fagområde i detalj. Systemanalytikere vil ved hjelp av disse beskrivelsene kunne utvikle den nødvendige IS-funksjonaliteten som best tilfredsstiller kundens behov. For arkitekter vil Rational Rose-verktøyet være nyttig for å lage en kraftig og fleksibel systemarkitektur. For databaseanalytikere gir Rational Rose deg muligheten til å visuelt designe og generere databaser i alle størrelser. Dermed kan du lage Microsoft SQL Server, Oracle, Sybase, SQL Anywhere, IBM DB2 og alle andre databaser som støtter muligheten til å kjøre ANSI SQL-standardskript. Alle modeller opprettet med dette verktøyet henger sammen: forretningsmodell, funksjonell modell, analysemodell, designmodell, databasemodell, komponentmodell og fysisk systemimplementeringsmodell. Det er mulig å lage maler for arkitektoniske løsninger som lar deg bruke erfaringen fra tidligere prosjekter. Det er Rational Rose-utvidelser som lar deg utføre skjelettutvikling (tur-retur) av IS opprettet på grunnlag av C/C++, Java, Smalltalk, Ada, Object Pascal (Borland Delphi), etc. Dermed kan du generere et programkoderammeverk på et hvilket som helst av de spesifiserte språkene eller utfør en omvendt utviklingsprosedyre, som lar deg lage en modell basert på eksisterende kode. Det er mulig å publisere modellen på Internett, som fungerer som grunnlag for å samle arbeidet til eksterne utviklingsteam. Integreringen av Rational Rose med Rational RequisitePro lar deg utvikle et komplett sett med krav basert på en visuell modell som må implementeres for å lage det endelige produktet. Rational Rose-integrasjon med Rational TestManager lar deg lage testskript basert på en visuell modell. Integreringen av Rational Rose med Rational ClearCase lar deg versjonskontrollere hele modellen eller i deler. Integreringen av Rational Rose med Rational SoDA lar deg automatisere prosessen med å lage dokumenter og rapporter basert på en visuell modell.

Sybase PowerDesigner. Siden grunnleggelsen har Sybase tradisjonelt vært en ledende leverandør av informasjonsteknologi til det globale markedet for finansinstitusjoner: Sybase-teknologier brukes av 90 % av verdens verdipapirmarkedsselskaper, 60 % av verdens banker og 68 % av Wall Street-selskapene. Siden 1996, da et kontor ble åpnet i Moskva, har Sybase jobbet aktivt i Russland og andre CIS-land. I april 2002 ble selskapets kontorer åpnet i St. Petersburg og Kiev. Sybase-kontorer i Moskva, St. Petersburg og Kiev gir omfattende arbeid med kunder, inkludert levering av teknologier, utstyr, utvikling av komplette løsninger, brukeropplæring, teknisk støtte og konsulenttjenester med alle funksjoner. PowerDesigner er en omfattende applikasjons- og forretningsprosessmodellerings- og utviklingsløsning for organisasjoner som trenger å raskt, konsekvent og kostnadseffektivt bygge eller omkonstruere forretningsapplikasjoner. PowerDesigner eliminerer følgende barrierer for effektiv prosjektutvikling: forskjeller i faglig bakgrunn til prosjektdeltakere, heterogene plattformer og en overflod av utviklingsspråk - som er typisk for de fleste moderne bedrifter. Dette lar deg fokusere på forretningsbehovene for å lage applikasjoner gjennom hele utviklingsprosessen - fra systemanalyse og design, til direkte kodegenerering for applikasjonen. Den nyeste versjonen av produktet, PowerDesigner, har nye muligheter for forretningsprosessmodellering, UML-basert objektmodellering, og støtter både tradisjonelle og nye modelleringsteknologier innenfor ett avansert grafisk miljø. Dette lar deg redusere kostnadene og tiden til prosjektet betydelig, som må operere på ulike plattformer og verktøymiljøer. En av hovedfordelene med PowerDesigner er også bruken av et bedriftsomfattende arkiv for å lagre og administrere all informasjon relatert til applikasjonsmodellering og design på alle forretningsnivåer i selskapet. Dette lar deg organisere arbeidsflyten ordentlig og dramatisk øke effektiviteten til utvikleren. Hovedfunksjoner i PowerDesigner:

• Forretningsprosessmodellering: PowerDesigner lar ikke-tekniske forretningsfolk designe og modellere forretningsprosesser basert på forretningsmål og begreper de kjenner, ved å bruke en enkel og intuitiv grafisk ikke-teknisk modell.
• Datamodellering: PowerDesigner lar deg designe og generere et databaseskjema gjennom to-nivå (konseptuell og fysisk) relasjonsdatabasemodellering som støtter klassiske databasedesignteknikker. Den har også innebygde datavarehusmodelleringsverktøy.
• Objektmodellering: PowerDesigner tilbyr en komplett teknologi for å analysere og designe systemer ved å bruke UML-standarden (forretningsprosessdiagrammer, utførelsessekvenser, klasser og komponenter). Basert på klassediagrammet genererer og redesigner PowerDesigner automatisk kode for populære rammeverk som JavaTM (inkludert EJB 2.0), XML, Web Services, C++, PowerBuilder, Visual Basic og mer gjennom en tilpasset kodegenerator.
• Enterprise Repository: Enterprise-versjonen av PowerDesigner inneholder funksjonaliteten i enterprise-klassen. Depotet lar alle medlemmer av teamet ditt enkelt se og dele modeller og annen informasjon. Depotet er svært skalerbart og støtter brukerrollebasert sikkerhet, versjonskontroll, søk og rapporteringsfunksjoner.

ARIS fra IDS Scheer AG. For tiden er det en tendens til å integrere ulike metoder for modellering og analyse av systemer, noe som manifesterer seg i form av å lage integrerte modelleringsverktøy. Et slikt verktøy er et produkt kalt ARIS, utviklet av det tyske selskapet IDS Scheer. IDS Sheer AG ble grunnlagt i 1984. Hovedretningen er programvare og rådgivning. Selskapet betjener i dag 4000 kunder i 50 land gjennom sitt nettverk av kontorer og partnere. Kvaliteten på IDS Scheer-løsninger ble bekreftet i juni 2005 av gullmedaljen til Poznań International Fair, hvor kun de beste produktene blir premiert. Og også i juli 2005, da ARIS 7-programvareprodukter med helt nye web-produkter ble presentert på verdensmarkedet - har de alle en felles funksjon - et intuitivt og uttrykksfullt grensesnitt. ARIS-systemet er et sett med verktøy for å analysere og modellere virksomheten til en virksomhet. Det metodiske grunnlaget er en kombinasjon av ulike modelleringsmetoder som reflekterer ulike syn på systemet som studeres. Den samme modellen kan utvikles ved hjelp av flere metoder, som gjør at spesialister med ulik teoretisk kunnskap kan bruke ARIS og tilpasse den til å jobbe med systemer som har sine egne spesifikasjoner. ARIS-modelleringsteknikken er basert på teorien om å bygge integrerte informasjonssystemer utviklet av professor August Scher, som bestemmer prinsippene for visuell visning av alle aspekter av funksjonen til de analyserte selskapene. ARIS støtter fire typer modeller som reflekterer ulike aspekter ved systemet som studeres:

• organisasjonsmodeller som representerer strukturen til systemet - hierarkiet av organisasjonsenheter, stillinger og spesifikke personer, koblingene mellom dem, så vel som den territorielle bindingen av strukturelle enheter;
• funksjonelle modeller som inneholder et hierarki av mål som står overfor styringsapparatet, med et sett med funksjonstrær som er nødvendige for å nå målene;
• informasjonsmodeller som gjenspeiler strukturen til informasjonen som er nødvendig for implementering av hele settet med systemfunksjoner;
• styringsmodeller som representerer et helhetlig syn på implementeringen av forretningsprosesser i systemet.

For å bygge denne typen modeller brukes både ARIS egne modelleringsmetoder og ulike kjente modelleringsmetoder og språk, spesielt ER og UML. I prosessen med modellering blir hvert aspekt av virksomhetens aktivitet først vurdert separat, og etter en detaljert studie av alle aspekter bygges det en integrert modell som gjenspeiler alle koblingene mellom ulike aspekter. ARIS pålegger ingen restriksjoner på rekkefølgen for å bygge de ovennevnte modellene. Modelleringsprosessen kan startes fra hvilken som helst av dem, avhengig av de spesifikke forholdene og målene utviklerne forfølger. Modeller i ARIS er diagrammer, hvis elementer er forskjellige objekter - "funksjon", "hendelse", "strukturell enhet", "dokument", etc. Det etableres ulike forbindelser mellom objekter. Hvert objekt tilsvarer et spesifikt sett med attributter som lar deg legge inn tilleggsinformasjon om et bestemt objekt. Attributtverdier kan brukes i simuleringer eller for kostnadsanalyse. Basert på resultatene fra dette stadiet dukker det derfor opp et sett med sammenhengende modeller, som er kildematerialet for videre analyse. Det er verdt å merke seg flere funksjoner i ARIS-systemet. Den første er familien av ARIS-programvareprodukter med fokus på prosessbeskrivelse. Hovedforretningsmodellen til ARIS er eEPC (extended Event-driven Process Chain – en utvidet modell av den hendelsesdrevne prosesskjeden). I hovedsak utvider eEPC-modellen egenskapene til IDEF0, IDEF3 og DFD med alle deres styrker og svakheter. Den andre funksjonen er at ARIS-systemet har en intern database som lar deg sjekke modellen for konsistens, integritet og verifisere modellen. Dette er ikke tilfellet for andre produkter. Den tredje funksjonen: ARIS er det eneste systemet som fokuserer på beskrivelsen av virksomheten, hvor det er ulike syn på forretningssystemet, som vi kan vurdere og vurdere fra ulike vinkler, noe som ikke er tilfelle i andre programvareprodukter. I løpet av de siste fem årene har ARIS vært en selvsikker leder blant modelleringsverktøy.

Vi angir hovedformålet med hvert produkt som vurderes fra en rekke bruksområder:

• Erwin, Power Designer og Rational Rose-verktøy er mer egnet for databasemodellering;
• Oracle Designer, Power Designer og Rational Rose er mer egnet for å modellere komponentene i applikasjoner som utvikles;
• BPwin, ARIS og Rational Rose er mer egnet for forretningsprosessmodellering.

Tabell 2 nedenfor sammenligner funksjonaliteten og funksjonene til arbeidsområder designet for forretningsprosessmodellering.

Tabell 2. Komparativ analyse etter grunnleggende funksjoner

En forretningsprosess er et logisk, sekvensielt, sammenhengende sett med aktiviteter som forbruker ressurser, skaper verdi og leverer resultater. I den internasjonale standarden ISO 9000:2000 er begrepet «prosess» tatt i bruk, men i dag kan disse begrepene betraktes som synonyme. Business Process Modeling er et effektivt verktøy for å finne måter å optimalisere en bedrifts aktiviteter på, slik at du kan bestemme hvordan bedriften fungerer som en helhet og hvordan aktiviteter organiseres på hver arbeidsplass. Metodikken (notasjonen) for å lage en modell (beskrivelse) av en forretningsprosess forstås som et sett med måter som virkelige objekter og relasjoner mellom dem er representert i form av en modell. Hvert objekt og lenker er preget av en rekke parametere eller attributter som gjenspeiler visse egenskaper ved et reelt objekt (objektnummer, navn, beskrivelse, utførelsestid (for funksjoner), kostnad, etc.).

Grunnlaget for mange moderne metoder for modellering av forretningsprosesser var SADT-metodikken (Structured Analysis and Design Technique - en metode for strukturanalyse og design), IDEF-familien av standarder (Icam DEFinition, hvor Icam er Integrated Computer-Aided Manufacturing) og algoritme. språk.

Hovedtyper av metoder for modellering og analyse av forretningsprosesser:

• Modellering av forretningsprosesser (Business Process Modeling). Den mest brukte metodikken for å beskrive forretningsprosesser er IDEF0-standarden. Modeller i IDEF0-notasjon er ment for en overordnet beskrivelse av en bedrifts virksomhet i et funksjonelt aspekt.
• Beskrivelse av arbeidsflyter (Work Flow Modeling). IDEF3-standarden er ment å beskrive arbeidsflyter og er nær algoritmiske metoder for å konstruere flytskjemaer.
• Beskrivelse av datastrømmer (Data Flow Modeling). DFD-notasjonen (Data Flow Diagramming) lar deg gjenspeile rekkefølgen av arbeidet som utføres under prosessen, og informasjonsstrømmene som sirkulerer mellom disse arbeidene.
• andre metoder.

IDEF0

Modellen består av diagrammer, tekstfragmenter og en ordliste med lenker til hverandre. Diagrammer er hovedkomponentene i modellen, alle funksjoner og grensesnitt presenteres som blokker og buer. Tilkoblingspunktet til buen med blokken bestemmer grensesnitttypen:

grensesnitttype:

• Kontrollinformasjon kommer inn i blokken fra toppen.
• Inndatainformasjonen er inkludert i blokken til venstre.
• Resultatene går ut av blokken til høyre.
• Mekanismen (menneskelig eller automatisert system) som utfører operasjonen kommer inn i enheten nedenfra.

Hver komponent i modellen kan dekomponeres (dechiffreres mer detaljert) i et annet diagram. Det anbefales å stoppe modelleringen når detaljnivået til modellen tilfredsstiller formålet. Totalt antall nivåer i modellen bør ikke overstige 5-6.

Diagrammering begynner med representasjon av hele systemet i form av en enkelt blokk og buer som viser grensesnitt med funksjoner utenfor systemet. Deretter er blokken som representerer systemet som en enkelt modul detaljert i et annet diagram ved hjelp av flere blokker forbundet med grensesnittbuer. Hvert detaljert diagram er en blokkdekomponering fra diagrammet på forrige nivå. Ved hvert dekomponeringstrinn kalles diagrammet for forrige nivå for overordnet diagram for det mer detaljerte diagrammet.

Slike diagrammer angir ikke eksplisitt verken rekkefølge eller tid. Metoden har en rekke ulemper: kompleksiteten til persepsjonen (et stort antall buer i diagrammene og et stort antall dekomponeringsnivåer), vanskeligheten med å koble sammen flere prosesser.

IDEF3

Denne metoden er designet for å modellere handlingssekvensen og den gjensidige avhengigheten mellom dem i prosessene. IDEF3-modeller kan brukes til å bore ned IDEF0 funksjonsblokker som ikke har dekomponeringsdiagrammer.

IDEF3-diagrammer viser en aktivitet som et rektangel. Handlinger navngis ved hjelp av verb eller verbale substantiv, og hver handling tildeles et unikt identifikasjonsnummer (handlingsnummeret er vanligvis foranført av nummeret til dens overordnede, f.eks. 1.1.). Alle lenker i IDEF3 er ensrettet og er organisert fra venstre til høyre.

Typer IDEF3-lenker:

• Tidsmessig forrang, enkel pil. Kildeaktiviteten må fullføres før sluttaktiviteten kan begynne.
• Objektflyt, dobbeltippet pil. Utdata fra den opprinnelige handlingen er inngangen til den endelige handlingen. Kildeaktiviteten må fullføres før sluttaktiviteten kan begynne. Navnene på strømmingslenker må tydelig identifisere objektet som overføres med deres hjelp.
• Uklart forhold, stiplet pil.

Fullføringen av én handling kan sette i gang starten på utførelsen av flere andre handlinger på en gang, eller omvendt, en viss handling kan kreve fullføring av flere andre handlinger før utførelsen av den startes (prosessforgrening).

Prosessforgrening gjenspeiles ved hjelp av spesielle blokker:

• "Og", blokk med tegn &.
• "Eksklusiv ELLER" ("en av"), blokk med X-tegn.
• "ELLER", blokk med O-tegn.

Hvis handlingene "OG", "ELLER" må utføres synkront, indikeres dette med to doble vertikale linjer inne i blokken, asynkront - en.

IDEF3-metoden lar deg dekomponere en aktivitet flere ganger, noe som sikrer at alternative prosessflyter dokumenteres i en enkelt modell.

DFD

Hensikten med en slik representasjon er å demonstrere hvordan hver prosess transformerer sine input til output. Det kan reflektere ikke bare informasjon, men også materialflyter.

Også, som i andre modeller, støttes dekomponering.

Hovedkomponentene i dataflytdiagrammer er:

• Eksterne enheter (et materiell objekt eller en person som er en kilde eller mottaker av informasjon, for eksempel kunder, personell, leverandører, kunder, lager).
• Systemer og delsystemer (for eksempel et delsystem for arbeid med individer).
• Prosesser (transformasjon av inngangsdatastrømmer til utdatastrømmer i samsvar med en bestemt algoritme; fysisk kan dette for eksempel være en underavdeling av en organisasjon (avdeling) som behandler inndatadokumenter og utsteder rapporter, et program, en maskinvareimplementert logikk enhet osv.).
• Datalagringsenheter (abstrakte enheter for lagring av informasjon).
• Dataflyter (piler på diagrammet).

Det er nødvendig å plassere på hvert diagram fra 3 (mindre gir ikke mening) til 7 (flere - ikke oppfattet) prosesser, uten å fylle diagrammene med detaljer som er ubetydelige på dette nivået. Det første trinnet i å bygge et DFD-hierarki er å bygge kontekstdiagrammer. Vanligvis, når man designer relativt enkle systemer, bygges et enkelt kontekstdiagram med en stjernetopologi, i sentrum av dette er den såkalte hovedprosessen, koblet til mottakere og informasjonskilder. For komplekse systemer (ti eller flere eksterne enheter, distribuert natur og multifunksjonalitet av systemet), bygges et hierarki av kontekstdiagrammer. Samtidig inneholder kontekstdiagrammet på øverste nivå ikke en enkelt hovedprosess, men et sett med delsystemer koblet sammen av datastrømmer.

Hver prosess på en DFD kan detaljeres ved hjelp av en DFD eller (hvis prosessen er elementær) en spesifikasjon. Spesifikasjoner er beskrivelser av algoritmer for oppgaver utført av prosesser. Spesifikasjonsspråk kan variere fra strukturert naturlig språk eller pseudokode til visuelle modelleringsspråk.

I forretningsprosessmodellering brukes dataflytdiagrammer (DFD-er) for å bygge "AS-IS" og "AS-TO-BE"-modeller, og reflekterer dermed en organisasjons eksisterende og foreslåtte forretningsprosessstruktur.

ARIS

For tiden er det en tendens til å integrere en rekke modelleringsmetoder, manifestert i form av å lage integrerte modelleringsverktøy. Et av disse verktøyene er et programvareprodukt kalt ARIS (Architecture of Integrated Information Systems), utviklet av det tyske selskapet IDS Scheer.

ARIS støtter fire typer modeller (og mange typer modeller i hver type) som reflekterer ulike aspekter ved systemet som studeres.

Støttede modelltyper i ARIS:

• Organisasjonsmodeller som representerer strukturen til systemet - hierarkiet av organisasjonsenheter, posisjoner og spesifikke individer, koblingene mellom dem, samt den territorielle bindingen av strukturelle enheter.
• Funksjonelle modeller som inneholder et hierarki av mål som står overfor styringsapparatet, med et sett med funksjonstrær som er nødvendige for å nå målene.
• Informasjonsmodeller som gjenspeiler strukturen til informasjonen som er nødvendig for implementering av hele settet med systemfunksjoner.
• Ledelsesmodeller som representerer et helhetlig syn på implementeringen av forretningsprosesser i systemet.

For å bygge denne typen modeller brukes både ARIS egne modelleringsmetoder og ulike kjente modelleringsmetoder og språk, spesielt UML. Modelleringsprosessen kan startes med hvilken som helst av modelltypene.

Hovedforretningsmodellen til ARIS er eEPC (extended Event-driven Process Chain, extended event-driven process chain model). ARIS eEPC-notasjonen er en utvidelse av IDEF3-notasjonen. En forretningsprosess i eEPC-notasjon er en flyt av sekvensielt utført arbeid (prosedyrer, funksjoner) ordnet i den rekkefølgen de utføres. Den faktiske varigheten av prosedyrene i eEPC reflekteres ikke visuelt. For å få informasjon om den faktiske varigheten av prosesser, er det nødvendig å bruke andre beskrivelsesverktøy, for eksempel MS Project.

Modeller i ARIS er diagrammer, hvis elementer er forskjellige objekter - "funksjoner", "hendelser", "strukturelle inndelinger", "dokumenter" etc. Mellom objekter av visse typer kan det etableres koblinger av visse typer ("utfører", "tar en beslutning", "bør informeres om resultatene" etc.). Hvert objekt tilsvarer et spesifikt sett med attributter som lar deg legge inn tilleggsinformasjon om et bestemt objekt.

Hovedobjektene for eEPC-notasjonen er:

• Funksjon. Tjener til å beskrive funksjonene (prosedyrer, arbeid) utført av avdelinger / ansatte i bedriften. Hver funksjon må startes av en hendelse og må avsluttes med en hendelse; Hver funksjon kan ikke angi mer enn én pil, "starter" utførelsen av funksjonen, og avslutter mer enn én pil, som beskriver fullføringen av funksjonen.
• Begivenhet. Brukes til å beskrive virkelige hendelser som påvirker utførelsen av funksjoner.
• Organisasjonsenhet. For eksempel ledelse eller avdeling.
• Dokument. Gjenspeiler ekte medier, for eksempel papirdokumenter.
• Søknadssystem.
• informasjonsklynge. Karakteriserer et sett med enheter og relasjoner mellom dem.
• Kommunikasjon mellom objekter. Typen av forhold mellom objekter, for eksempel aktivering av utførelse av en funksjon av en eller annen hendelse.
• boolsk operatør."OG", "ELLER" eller den eksklusive "ELLER"-operatøren lar deg beskrive forgreningen av prosessen.

Hvis du, når du oppretter en modell i eEPC, spesifiserer bare sekvensen av prosedyrer, og ikke bryr deg om refleksjon av kontrolldokumenter og informasjon, vil de resulterende modellene være av lav verdi når det gjelder analyse og videre bruk.

Informasjonsteknologi

© Skorodumov P.V.

MODELLERING AV FORRETNINGSPROSESS: TILNÆRMINGER, METODER OG VERKTØY

SKORODUMOV PAVEL VALERIEVICH

Kandidat for tekniske vitenskaper, leder av Laboratory of Intelligent and Software and Information Systems Federal State Budgetary Institution of Science

Institutt for sosioøkonomisk utvikling av territorier til det russiske vitenskapsakademiet E-post: [e-postbeskyttet]

Forretningsprosessteknikk er grunnlaget for den moderne tilnærmingen til forretningsorganisasjon, og dens viktigste retning er reengineering. Reengineering er rettet mot bruk i organiseringen av fundamentalt nye forretningsprosesser basert på bruk av moderne innovative teknologier.

Når man analyserer en eksisterende virksomhet og utvikler en ny, spilles en viktig rolle ved å bygge modeller av selskapet og forretningsprosessene som foregår i det. Modellering er en prosess for å reflektere virkeligheten ved hjelp av en spesiell metodikk. Artikkelen presenterer hovedtilnærmingene, metodene og verktøyene for modellering av forretningsprosesser. De mest populære formalismene til Petri-nett som brukes til disse formålene, vurderes.

Som et alternativ foreslås det å bruke det modifiserte apparatet til nestede hybride petrinett som et verktøy for å studere forretningsprosesser. Det er fremmet et forslag om å utvikle et universelt simuleringssystem basert på et modifisert apparat av petrinett.

Forretningsprosess, reengineering,toder, Petri-nett, universelt simuleringssystem.

Mange moderne selskaper fortsetter å bygge sin virksomhet på de gamle ledelsesprinsippene introdusert av Adam Smith i 1776. I sitt arbeid deler Smith opp produksjonsprosessen i elementære jobber, som hver utføres av én arbeider, mens det er nok for ham å kunne utføre individuelle operasjoner og det kreves ikke høye kvalifikasjoner.

Naturligvis, etter så mange år, sluttet prinsippene som ble bemerket av Smith, å oppfylle moderne krav. I dag bør produktene fokuseres på smale grupper av forbrukere, det trengs utøvere med god utdanning, som ikke er redd for ansvar, streber etter å løse komplekse problemer. Produktmarkedet har blitt mye bredere, og konkurransen og kampen om forbrukeren

kropp - mer aggressiv. Midlene og teknologiene som brukes til produksjon har endret seg betydelig. Informasjonsteknologi begynte å spille en spesiell rolle.

Mange selskaper prøver å revurdere de gamle måtene å organisere virksomheten på, og bygger nye forretningsprosesser ved hjelp av moderne teknologier.

En forretningsprosess er et sammenhengende sett med interne aktiviteter i et selskap, som ender i etableringen av et produkt eller en tjeneste som forbrukeren trenger.

Et viktig skritt i å strukturere aktivitetene til enhver organisasjon er allokering og klassifisering av forretningsprosesser. I forhold til å oppnå merverdien av et produkt eller en tjeneste, skilles hoved- og støtteprosessen. Den første - verdiøkende - er fokusert på produksjon av varer eller levering av tjenester som utgjør hovedaktiviteten til organisasjonen og gir inntekt. Sistnevnte tilfører ikke verdi til produktet eller tjenesten for forbrukeren, men øker verdien. De er nødvendige for driften av virksomheten og er designet for å støtte gjennomføringen av kjernevirksomhetsprosesser.

Grunnlaget for den moderne tilnærmingen til forretningsorganisasjon er forretningsprosessteknikk, hvor den viktigste retningen er reengineering.

Reengineering er forstått som "en grunnleggende omtenkning og radikal redesign av forretningsprosesser til bedrifter for å oppnå grunnleggende forbedringer i de viktigste indikatorene for deres aktiviteter - kostnad, kvalitet og tempo".

Reengineering er et sett med verktøy, tiltak og metoder, inkludert relevant informasjon

teknologiske teknologier designet for å radikalt forbedre bedriftens viktigste ytelsesindikatorer. For dette formålet utføres analyse og påfølgende modifikasjon av eksisterende forretningsprosesser. For å oppnå dramatiske forbedringer i eksisterende bedriftsytelse, innebærer reengineering en grunnleggende endring i eksisterende forretningsprosesser. Derfor kan reengineering-metoder brukes av en bedrift i prosessen med å utvikle en innovativ utviklingsstrategi.

Reengineering er rettet mot bruk i organiseringen av fundamentalt nye forretningsprosesser basert på bruk av moderne innovative teknologier.

Overgangen til en virksomhet til bruk av ny informasjonsteknologi betyr ikke automatisering av eksisterende prosesser. Deres anvendelse kan føre ikke bare til grunnleggende endringer i ansattes aktiviteter, men også til fullstendig erstatning av eksisterende forretningsprosesser.

Når man analyserer en eksisterende virksomhet og utvikler en ny, spilles en viktig rolle ved å bygge modeller av selskapet og forretningsprosessene som foregår i det. Modeller kan variere i detaljgraden av prosesser, formen på deres presentasjon, og tar kun hensyn til statiske eller også dynamiske faktorer, etc.

Ved modellering av forretningsprosesser er det svært viktig å ta stilling til strukturen og innholdet til modelleringsobjekter, for å bestemme hvilke elementer forretningsprosessen skal bestå av. Enhver ganske kompleks forretningsprosess kan inkludere fem hovedelementer som bør gjenspeiles i dannelsen av modeller: aktivitetsplanlegging, aktivitetsimplementering, registrering av faktisk informasjon.

formasjoner, kontroll og analyse, ledelsesbeslutninger.

Modellering av forretningsprosesser er en refleksjon av den subjektive visjonen til prosessene som virkelig eksisterer i organisasjonen ved hjelp av grafiske, tabellformede, tekstlige representasjoner.

Modellering er prosessen med å reflektere de faktiske (eller planlagte) aktivitetene til organisasjonen ved å bruke en spesiell metodikk. Det er viktig å forstå at modelleringsprosessen er subjektiv. Faktum er at 80% av informasjonen for dannelsen av modeller kommer fra de intervjuede ansatte og ledere i organisasjonen. Samtidig er både de ansattes mening om den faktiske fremdriften i arbeidet og synet på prosessene til analytikeren som gjennomførte intervjuet, subjektivt. Graden av subjektivitet til de oppnådde modellene kan bli en alvorlig hindring for videre bruk.

Følgende mål for forretningsprosessmodellering kan skilles:

1. Gi en forståelse av strukturen i organisasjonen og dynamikken i prosessene som skjer i den.

2. Gi en forståelse av organisasjonens nåværende problemer og muligheter til å løse dem.

3. Sørg for at kunder, brukere og utviklere deler den samme forståelsen av organisasjonens mål og mål.

4. Bestem kravene til programvare som automatiserer organisasjonens forretningsprosesser.

Metodikken (notasjonen) for å lage en forretningsprosessmodell forstås som et sett med måter som virkelige objekter og forbindelsene mellom dem er representert i form av en modell. Enhver metodikk inkluderer tre hovedkomponenter:

1. Teoretisk grunnlag.

2. Beskrivelse av trinnene som kreves for å oppnå ønsket resultat.

Hvis metodikken er basert på et teoretisk grunnlag, gjør dens tilstedeværelse metodikken mer fornuftig og forutsigbar. Men i fravær av en teori (matematisk modell), kan metodikkene også brukes med hell. Hovedsaken i metodikken er å gi brukeren en praktisk sekvens av trinn som fører til et gitt resultat. Det er evnen til å oppnå et resultat med gitte parametere som kjennetegner effektiviteten til metodikken. Metoder (teknikker) kan brukes både hver for seg og sammen.

Organisasjonsmodellen i det generelle tilfellet er en kombinasjon av funksjonelle, organisatoriske og informasjonsmodeller:

1. Den funksjonelle modellen beskriver et sett av funksjonelle delsystemer og relasjoner som gjenspeiler rekkefølgen av interaksjoner mellom delsystemer under driften av selskapet eller dets divisjoner.

2. Organisasjonsmodellen beskriver sammensetningen og strukturen til virksomhetens divisjoner og tjenester.

3. Informasjonsmodellen beskriver informasjonsstrømmene som finnes i funksjons- og organisasjonsmodellene.

For å modellere forretningsprosesser benyttes flere ulike metoder, som bygger på både strukturelle og objektorienterte tilnærminger til modellering. Imidlertid er inndelingen av selve metodene i strukturelle og objekter ganske betinget, siden de mest utviklede metodene bruker elementer fra begge tilnærmingene. De vanligste metodene inkluderer:

1. Metode for funksjonell modellering SADT (IDEF0).

2. IDEF3 prosessmodelleringsmetode.

3. Simulering av DFD-datastrømmer.

4. ARIS-metoden.

5. Ericsson Penker-metoden.

6. Modelleringsmetode brukt i Rational Unified Process-teknologi.

Noen av de eksisterende metodene er basert på statlige standarder, noen er basert på bedriftsutviklingen til individuelle selskaper, noen er fremsatt av individuelle forfattere, de er delt inn i tre kategorier:

1. Prosjektledelsesmetodikk.

2. Metoder for modellering og analyse av forretningsprosesser.

3. Metoder for bruk av programvareprodukter for modellering av forretningsprosesser i et prosjekt.

For tiden er det flere ganske tydelig identifiserbare prosjektledelsesmetoder knyttet til å endre forretningsprosessene som eksisterer i organisasjonen. En av de mest populære tilnærmingene er metodikken til Hammer og Champi. Reengineering ifølge Hammer og Champy er "en grunnleggende omtenkning og radikal redesign av forretningsprosesser for å oppnå dramatiske, trinnvise forbedringer i et selskaps kritiske moderne ytelsesindikatorer som kostnad, service og tempo." Grunnlaget for denne tilnærmingen er å gjennomgå aktivitetene til organisasjonen "fra bunnen av" og utviklingen av nye, mer effektive forretningsprosesser.

I tillegg til metodikken til Hammer og Cham-pi, er det andre metoder som ikke har entydig forfatterskap, men som tilhører individuelle selskaper, for eksempel metoder for implementering av prosjekter for å implementere automatiseringssystemer for Oracle, SAP R / 3, BAAN, RUP fra Rational, etc. .

Den andre gruppen inkluderer metodikk for modellering og analyse av forretningsprosesser. For tiden er det flere grunnleggende måter å beskrive prosesser på, basert både på standarder (IDEF0) og allment aksepterte tilnærminger (DFD).

I tillegg er det en rekke notasjoner (metoder) for å beskrive prosesser foreslått av enkeltselskaper – programvareutviklere. Sistnevnte inkluderer ARIS (eEPC)-metodikken fra IDS S^eer AG, Tyskland. Bemerkelsesverdig er også BPMN 2-metodikken støttet av OMG-organisasjonen, som har blitt en standard blant fagfolk og brukes aktivt til å utvikle "kjørbare" automatiserte forretningsprosessmodeller.

Den tredje metodegruppen inkluderer metoder for bruk av modelleringsverktøy for å lage forretningsprosessmodeller. Moderne modelleringsverktøy er så vanskelige å bruke at de krever utvikling av spesielle metoder for deres anvendelse i prosjektet. Derfor, for enkle prosjekter, er det ofte mer hensiktsmessig å bruke et standard flytskjema-tegnespråk og de enkleste verktøyene for å lage dem (MS Word, Visio, etc.).

Historien om fremveksten av ulike metoder er oppsummert i tabellen.

Tallrike prosjekter blir for tiden implementert, hvis formål er å integrere eksisterende modelleringsmetoder og språk og skape et enhetlig metodisk og teknologisk grunnlag for forretningsprosessmodellering, og i en bredere sammenheng - bedriftsmodellering.

I august 2000 ble BPMI-konsortiet etablert etter initiativ fra Intalio. BPMI er en uavhengig organisasjon

Bord. Historie om utviklingen avtoder

Periode med BP-modelleringsmetodikk

1940 - 1960-tallet Fremveksten av algoritmiske språk

1960-tallet Strukturell analyse og designmetodikk (SADT)

1970 - 1980 IDEF-seriens metodikker (IDEF0, IDEF3, IDEF1x), DFD, ERD

1990 Architecture of Integrated Information Systems (ARIS), Universal Modeling Language (UML), metodikker fra Oracle, Baan, Rational, etc.

2000 ISO 9000:2000-standarder, definerer prosesstilnærmingen for å lede en organisasjon

2003-notasjon for modellering av "kjørbare" prosesser (BPMNv1)

2004 Emneorientert tilnærming til BP-modellering (S-BPM)

2008–2009 ISO 9000:2008 standardoppdatering

2011 Modell og notasjon for modellering av "kjørbare" prosesser (BPMNv2)

engasjert i utvikling av åpne spesifikasjoner for styring av e-handelsprosesser.

Disse spesifikasjonene inkluderer utkast til standarder for Business Process Modeling Language (BPML) og BPQL (Business Process Query Language) for administrasjon av forretningsprosesser. BPML er et metaspråk for forretningsprosessmodellering, akkurat som XML er et metaspråk for datamodellering. BPML lar deg lage en abstrakt kjørbar modell av samvirkende prosesser basert på konseptet om en tilstandsmaskin.

I 2003 publiserte BPMI et utkast til Business Process Modeling Notation (BPMN) standard. Formålet med dette prosjektet er å lage en felles notasjon for ulike kategorier av fagfolk: fra forretningsanalytikere og eksperter fra organisasjoner til programvareutviklere.

BPMN består av et enkelt diagram kalt Business Process Diagram (BPD) som tilordnes direkte til BPML-konstruksjonen.

Unified Enterprise Modeling Language (UEML)-prosjektet ble gjennomført med mål om å integrere en rekke Enterprise Modeling Languages ​​i et enhetlig modelleringsspråk med veldefinerte syntaks, semantikk og kartleggingsregler mellom ulike modelleringsverktøy. Basis for

slik integrasjon ble levert av GERAM (Generalized Enterprise Reference Architecture and Methodology) og Zachman-modeller. UEML-prosjektet inkluderer utvikling av:

1) et vanlig visuelt, malbasert språk for kommersielle modelleringsverktøy;

2) standard, verktøyuavhengige mekanismer for overføring av modeller mellom prosjekter;

3) et oppbevaringssted for bedriftsmodeller.

OMG er et konsortium av programvareutviklere og brukere fra ulike kommersielle, offentlige og akademiske organisasjoner med ca. 800 medlemmer. OMG utvikler ulike standarder innen interaksjon mellom distribuerte systemer (de mest kjente av dem er CORBA og UML).

OMGs arbeid innen forretningsprosessmodellering er hovedsakelig knyttet til konseptet Model Driven Architecture (MDA).

MDA integrerer ulike modelleringstilnærminger og introduserer et sett med kartlegginger mellom modeller på ulike abstraksjonsnivåer. Enhver organisasjon som bruker MDA kan bare utvikle modeller som er nødvendige for sine egne formål.

For tiden er de tre viktigste OMG-initiativprosjektene opprettelsen av metamodeller for å beskrive forretningsprosesser (Business Process Definition Metamodel -BPDM), business

pitchfork (Business Semantics of Business Rules, and Production Rule Representation) og ontologi (Ontology Definition Metamodel). Hensikten med BPDM er å integrere og gi interoperabilitet mellom modeller som brukes av ulike organisasjoner (som UML- eller BPMN-diagrammer). BPDM forventes å bli implementert som en UML 2.0-profil. På samme måte jobber OMG med standardisering av forretningsregler og deres kompatibilitet med BPDM. Alt dette samlet bør i fremtiden gi et nytt nivå av kompatibilitet mellom modellene som brukes til å beskrive forretningsprosesser og programvare.

Blant moderne verktøy for modellering og analyse av forretningsprosesser er Rational Rose, Oracle Designer, BPWin og ERwin, ARIS osv. mye brukt. BPwin, ARIS og Rational Rose er mer egnet for modellering av forretningsprosesser, la oss se på dem mer detaljert.

Rational Rose er et av de ledende visuelle modelleringsverktøyene i programvareindustrien med full støtte for UML-språket og flerspråklig støtte for teamutvikling, som støtter en komponentorientert systemopprettingsprosess. Alle modeller opprettet med dette verktøyet henger sammen: forretningsmodell, funksjonell modell, analysemodell, designmodell, databasemodell, komponentmodell og fysisk systemimplementeringsmodell. Lar deg løse nesten alle oppgaver i utformingen av informasjonssystemer: fra analyse av forretningsprosesser til kodegenerering i et spesifikt programmeringsspråk. Lar deg utvikle både høynivå- og lavnivåmodeller, og implementerer derved enten abstrakt design eller logisk design.

VRST-pakken er basert på IDEF-metodikken og er beregnet på funksjonell modellering og analyse av virksomhetens aktiviteter. IDEF-metodikken, som er den offisielle amerikanske føderale standarden, er et sett med metoder, regler og prosedyrer designet for å bygge en funksjonell modell av et objekt i ethvert fagområde. IDEF-funksjonsmodellen gjenspeiler den funksjonelle strukturen til et objekt, det vil si handlingene det utfører og relasjonene mellom disse handlingene.

BPwin støtter tre standardnotasjoner - IDEF0, DFD og IDEF3, lar deg optimere prosedyrer i selskapet, gjør det lettere å sertifisere for samsvar med kvalitetsstandarder ^09000, inneholder egen rapportgenerator, har et bredt utvalg av verktøy for å dokumentere modeller, prosjekter.

ERWin-pakken brukes til å modellere og lage databaser med vilkårlig kompleksitet basert på entitetsforholdsdiagrammer; det er den mest populære datamodelleringspakken på grunn av dens støtte for et bredt spekter av DBMS av forskjellige klasser.

ERWin støtter SADT strukturell modelleringsmetodikk og IDEF1x-notasjonen for ER-diagrammer av datamodeller, lar deg gjenbruke komponenter fra tidligere opprettede modeller, samt bruke arbeidet til andre utviklere, det er mulig for en gruppe designere å jobbe sammen med de samme modellene.

ARIS-systemet er et sett med verktøy for å analysere og modellere virksomheten til en virksomhet. Det metodiske grunnlaget er en kombinasjon av ulike modelleringsmetoder som reflekterer ulike syn på systemet som studeres. Samme modell kan

utvikles ved hjelp av flere metoder, som gjør at ARIS kan brukes av spesialister med ulik teoretisk kunnskap og konfigureres til å jobbe med systemer som har sine egne spesifikasjoner. ARIS-modelleringsteknikken er basert på teorien om å bygge integrerte informasjonssystemer utviklet av professor August Scher, som bestemmer prinsippene for visuell visning av alle aspekter av funksjonen til de analyserte selskapene. ARIS støtter fire typer modeller som reflekterer ulike aspekter ved systemet som studeres: organisasjons-, funksjons-, informasjons- og ledelsesmodeller.

For å bygge ovennevnte typer modeller brukes både ARIS egne modelleringsmetoder og ulike kjente modelleringsmetoder og språk. Modeller i ARIS er diagrammer, hvis elementer er ulike objekter – «funksjon», «hendelse», «strukturell enhet», «dokument» osv. ARIS er fokusert på prosessbeskrivelsen.

Det ble bemerket ovenfor at bruken av ny informasjonsteknologi er en integrert del av reengineering. Samtidig implementeres modeller av nye forretningsprosesser direkte i miljøet til informasjonsstøttesystemet (SIS) til en ny virksomhet. Betydningen av ISP ligger ikke bare i det faktum at det er et nødvendig element i reengineering, men i det faktum at ofte bruken av ISP i stor grad bestemmer teknologien for å gjøre nye forretninger. ISP er en spesialutviklet programvare – et programvaresystem som er bygget på grunnlag av bruk av passende verktøy.

Et annet verktøy for modellering av forretningsprosesser er apparatet til Petri nets (SP). Hovedfordeler

Egenskapene ved bruk av SP i modellering er som følger: 1) prosessen definert i form av SP har en klar og presis representasjon; 2) synligheten til nettverkskonstruksjonsplanen, takket være hvilken alle dens definisjoner og algoritmer lett kan oppfattes; 3) muligheten for å bruke ulike analysemetoder.

Populariteten til SP skyldes også den vellykkede representasjonen av ulike typer objekter som finnes i mange simulerte systemer, og "hendelses"-tilnærmingen til modellering. De er best egnet til å beskrive relasjoner og interaksjoner mellom prosesser som kjører parallelt.

Generelt er et Petri-nett definert av følgende sett:

C = (P, T, E), (1)

P er et ikke-tomt begrenset sett med nettverksposisjoner;

T er et ikke-tomt begrenset sett med overganger;

E - forholdet mellom forekomsten av stillinger og

overganger (et sett med nettverksbuer).

Med hensyn til forretningsprosessmodellering er WF Petri-nett eller arbeidsflytnettverk mest brukt. Denne formalismen ble introdusert av Wil van der Aalst for å modellere arbeidsflyter i arbeidsflytsystemer. Et Petri-nett PN = (P, T, F) kalles et arbeidsflytnettverk (WF-net) hvis følgende betingelser er oppfylt:

1) det er bare én startposisjon i, slik at det ikke er noen overganger inkludert i i;

2) det er bare én endeposisjon o, slik at det ikke er noen overganger som forlater o;

3) hver node i dette nettverket er plassert på banen fra i til o.

Det skal bemerkes at Petri-nett, i motsetning til alle tilnærmingene presentert ovenfor, gjør det mulig å oppnå en dynamisk simuleringsmodell av en forretningsmodell.

prosess. Fra et synspunkt om atferd i tid, kan forretningsprosesser generelt klassifiseres som hybride systemer; både kontinuerlige og diskrete komponenter kan være tilstede i dem samtidig. Den kontinuerlige komponenten reflekterer kontinuiteten til prosessene i en reell organisasjon i tid; diskret - kan reflektere kontrollhandlinger rettet mot kontinuerlige prosesser. For å modellere hybridsystemer ble et modifisert apparat av nestede hybride petrinett presentert.

GSP kan defineres av følgende sett:

NHPN=(Atom, Lab, SN(HPN), (EN!,..., ENk),Á), (2) hvor:

Atom = Var ^ Con - sett av atomer, bestående av sett med variabelnavn og konstantnavn;

Lab = Labv ^ Labh - sett med etiketter som brukes for vertikal og horisontal synkronisering av overganger; (EN1,...,ENk)(k > 1) - et begrenset sett med vanlige SP-er;

L - funksjon for å markere overganger av elementer fra settet Lab.

SN(HPN) - systemnettverk som en del av SHPN, som er et hybrid Petri-nett (HPN):

HPN = (P, T, Pre, Post, D, C), (3)

P = Pd ^ Pc - sett med diskrete og kontinuerlige posisjoner;

T = Td ^ Tc ^ TK ^ TE - sett med diskrete, kontinuerlige kvantiserings- og ekstrapolasjonsoverganger; Pre, Post - insidensmatriser som karakteriserer settet med buer; D: Tt ^ R+ - en funksjon som bestemmer forsinkelsesintervallene for diskrete tidsoverganger;

C: Tc ^ R0 x R+m er en funksjon som bestemmer kapasiteten til kontinuerlige overganger.

Det er mulig å bruke begrepene global og lokal tid i GHSP-apparatet. Den første er tiden utenfor systemet, som det er assosiert med konseptet med et modelleringstrinn, som gjør det mulig å estimere den tidsmessige endringen i systemets tilstand i forhold til eksterne systemer. Den andre brukes til å bestemme responsforsinkelsene for diskrete overganger og gjennomstrømningen av kontinuerlige overganger til SHG. Alle diskrete overganger er delt inn i øyeblikkelige, deterministiske tidsbestemte og eksponentielt bestemte. Inndelingen er knyttet til definisjonen av forsinkelsesintervallet for overganger. For kontinuerlige overganger introduseres konseptet med gjennomstrømning, som gjenspeiler bevegelseshastigheten gjennom overgangen til en kontinuerlig strøm av sjetonger.

I tillegg til alt det ovennevnte inkluderer apparatet konseptene buevekt og inhiberende buer som er karakteristiske for høynivå SP.

Et betydelig tillegg til apparatet er muligheten til å bruke brøk- og negative verdier for vekten av buen som kommer fra overgangen. Når du bruker en negativ buevekt, bør man snakke om potensialet til brikkene i denne posisjonen. Uavhengig av tolkningen av nettverksmerking, endres ikke nettverksdynamikkligningen.

Dynamikken i oppførselen til SHG er beskrevet av følgende fire typer triggertrinn:

1. Et systemautonomt trinn er utløsning av en systemnettverksovergang i henhold til reglene for GSP, mens elementnettverk anses som brikker som ikke har egen struktur.

2. Det elementært-autonome trinnet endrer bare den interne tilstanden (merkingen) til elementnettverket, uten å endre dets plassering i systemnettverket.

3. Det horisontale synkroniseringstrinnet brukes til å synkronisere overganger i to elementære nettverk lokalisert i samme posisjon av systemnettverket.

4. Det vertikale synkroniseringstrinnet brukes til å synkronisere overgangen i systemnettverket med noen overganger av elementære nettverk.

Følgende ligning brukes for å beskrive dynamikken til SHG-atferden:

Mk = M-1 + C(p, b)un (4)

M - nettverksmarkeringsmatrise. Nettverksmerking tildeler for hver diskret posisjon et helt antall brikker, med tanke på potensialet deres, og for hver kontinuerlig posisjon - enten det er et signal i den eller ikke; uk - kontrollvektor, bestemmer settet med overganger som er klare til å skyte på gjeldende tidspunkt;

C(p, b) er den resulterende GHG-forekomstmatrisen.

Det modifiserte apparatet til nestede hybride Petri-nett utvider omfanget av klassiske PN-er og eksisterende utvidelser betydelig, og lar deg studere hybridsystemer med en kompleks struktur som helhet.

Som nevnt ovenfor, er opprettelsen av et universelt verktøy for modellering av forretningsprosesser en presserende oppgave i dag. Nestede hybride petrinett kan bli et slikt apparat. Ved å kombinere funksjonene til ulike utvidelser av klassiske Petri-nett, har de alle sine fordeler, slik at du kan utforske systemer med varierende kompleksitet.

Det modifiserte apparatet til nestede hybride Petri-nett kan brukes som grunnlag for å bygge et universelt modelleringssystem, som ikke bare vil spare tid for utvikling og implementering av en simuleringsmodell, men også gjøre prosessen med å modellere seg selv enklere og mer tilgjengelig. Dette reduserer sannsynligheten for feil under oppretting av modeller på grunn av utilstrekkelig kunnskap om språkverktøy, uoppmerksomhet i arbeid med store mengder informasjon, etc. .

Forskning innen modellering av forretningsprosesser ved bruk av apparatet til Petri nets og bygging av et universelt simuleringssystem vil bli videreført i fremtiden.

LITTERATUR

1. Analyse av moderne metoder for modellering av forretningsprosesser [Elektronisk ressurs]. - Tilgangsmodus: http://www.reengine.ru/index.asp?Menu=2&Sub=2

2. Baranov, V. V. Reengineering av forretningsprosesser: stadier av utvikling og implementering [Elektronisk ressurs] / V. V. Baranov. - Tilgangsmodus: http://www.elitarium.ru/2012/11/14/reinzhiniring_biznes_processov_jetapy_razrabotki_realizacii.html

3. Barinov, V. A. Reengineering: essens og metodikk [Elektronisk ressurs] / V. A. Barinov. - Tilgangsmodus: http://www.elitarium.ru/2006/05/12/reinzhiniring_sushhnost_i_metodologija.html

4. Vendrov, A. M. Metoder og verktøy for modellering av forretningsprosesser (gjennomgang) [Tekst] / Vendrov A. M. // Informasjonsbulletin. - 2004. - Nr. 10 (137). - 32 s.

5. Dukhanov, A. V. Simuleringsmodellering av komplekse systemer [Tekst] / A. V. Dukhanov, O. N. Medvedeva // Forelesningskurs. - Vladimir: VSU 2010. - 118 s.

6. Kotov, V. E. Petri nett [Tekst] / V. E. Kotov. - M. : Nauka, 1984. - 160 s.

7. Malkov, M. V. Petri-nett og modellering [Elektronisk ressurs] / M. V. Malkov, S. N. Malygina. - Tilgangsmodus: http://site/artide/n/seti-petri-i-modelirovanie

8. Oikhman, E. G. Business reengineering: reengineering av organisasjoner og informasjonsteknologier [Tekst] / E. G. Oikhman, E. V. Popov. - M. : Finans og statistikk, 1997. - 336 s.

9. Peterson, J. Teori om Petri-nett og systemmodellering [Tekst] / J. Peterson. - M.: Mir, 1984. - 264 s.

10. Poleshchuk, N. A. Kostnadsmodellering i økonomiske systemer ved bruk av Petri-nett [Elektronisk ressurs] / N. A. Poleshchuk. - Tilgangsmodus: http://www.marketing-mba.ru/article/v4_11/Paliashchuk.pdf

11. Repin, VV Prosesstilnærming til ledelse. Modellering av forretningsprosesser [Tekst] / V. V. Repin, V. G. Eliferov. - M. : Mann, Ivanov og Ferber, 2013. - 544 s.