Affärsmodelleringsverktyg och funktioner i dess applikation. Analys av moderna verktyg för modellering av affärsprocesser Verktyg för modellering av affärsprocesser

Materialet bereddes av specialisterna på företaget "Abis Soft"

Hur man gör ett val

Innan du börjar välja en mjukvaruprodukt måste du svara på tre grundläggande frågor:

1. Vad behöver beskrivas?

2. I vilken utsträckning behöver du beskriva?

3. Hur kommer prestanda att övervakas?

När du svarar på den första frågan bör du avgöra vilka delar av styrsystemet du ska beskriva, om en omfattande beskrivning av hela systemet är nödvändig.

Svaret på den andra frågan bör ge en uppfattning om huruvida ledningssystemet kommer att beskrivas för ett visst företag, en avdelning eller för hela organisationen som helhet.

Den tredje frågan kommer att avgöra vilka begränsningar som kan läggas på en mjukvaruprodukt så att dess integration med exekutivsystemet kan genomföras i framtiden.

Med svar på dessa frågor kan du avsevärt begränsa utbudet av möjliga programvaruprodukter.

• Möjlighet till fleranvändararbete,
• Metoder för att presentera resultat,
• Gränssnitt och ergonomi,
• Tillgänglighet av dokumentation och teknisk support,
• Hårdvara och programvara,
• Pris.

Utan att låtsas vara den yttersta sanningen erbjuder granskningsförfattarna några alternativ för utvärdering av de granskade produkterna.

1. Om företaget redan har utvecklat en strategi och det måste kontrolleras, så är lösningen bäst lämpad för detta av de utländska produkter som diskuteras i artikeln Hyperion Performance Scorecard Presenterat av Orakel.

2. Om huvudfokus ligger på affärsprocesserna i företaget, är företagets produkt optimal. IBM - IBM WebSphere Business Modeler.

(Det bör klargöras att valet av programvara från tillverkare som t.ex. IBM, Oracle, SAP, bestäms av valet ERP-system från respektive tillverkare. Deras affärsmodelleringsprogramvara är delsystem av komplexa produkter.)

3. Av de ryska produkterna är det mest lämpligt att använda INTALEV: Corporate Navigator om du vill göra en beskrivning av hela företaget (innehavet) som helhet, och inte bara en enda affärsenhet (division eller filial).

Informationen erhölls från representanter för tillverkare i Ryska federationen eller från tillverkares officiella webbplatser.

ARIS Business Performance Edition.

Implementeras med hjälp av systemet IBM Rational ClearCase

Affärsprocessmodelleringär ett effektivt verktyg för att hitta sätt att optimera företagets aktiviteter, så att du kan avgöra hur företaget fungerar som helhet och hur aktiviteter organiseras på varje arbetsplats. Metoden (notation) för att skapa en modell (beskrivning) av en affärsprocess förstås som en uppsättning sätt på vilka objekt i den verkliga världen och kopplingarna mellan dem representeras i form av en modell. Varje objekt och länkar kännetecknas av ett antal parametrar eller attribut, som återspeglar vissa egenskaper hos ett verkligt objekt (objektnummer, namn, beskrivning, varaktighet för utförandet (för funktioner), kostnad, etc.).

Beskrivning av affärsprocesser utförs för vidare analys och omorganisation. Syftet med omorganisationen kan vara införandet av ett informationssystem, minska kostnaderna, förbättra kvaliteten på kundservicen, skapa jobb- och arbetsinstruktioner etc., och en detaljerad beskrivning av processerna i sig är inte värdefull.

Reengineering affärsprocesser (eng. Business process reengineering) är en grundläggande nytänkande och radikal omformning av affärsprocesser för att uppnå maximal effektivitet i produktion, ekonomisk och finansiell och ekonomisk verksamhet, formaliserad av lämplig organisatorisk och administrativ och regleringsdokument... Business engineering består av att modellera affärsprocesser (utveckla en modell "som den är", analysera den, utveckla en modell "som den ska") och utveckla och genomföra en plan för övergången till ett tillstånd av "som den ska".

Många moderna metoder för affärsprocessmodellering är baserade på SADT-metodiken (Structured Analysis and Design Technique), IDEF-familjen av standarder (Icam DEFinition, där Icam står för Integrated Computer-Aided Manufacturing) och algoritmiska språk.

Huvudtyperna av metoder för modellering och analys av affärsprocesser:

Affärsprocessmodellering ( Affärsprocessmodellering). Den mest använda metoden för att beskriva affärsprocesser är IDEF0 -standarden. Modeller i IDEF0-notering är avsedda för en högnivåbeskrivning av ett företags verksamhet i en funktionell aspekt.

Beskrivning av arbetsflöden ( Arbetsflödesmodellering). IDEF3 -standarden är avsedd att beskriva arbetsflöden och ligger nära algoritmiska metoder för att bygga blockdiagram.

Beskrivning av dataströmmar ( Dataflödesmodellering). DFD -notation ( Dataflödesdiagram), låter dig reflektera arbetssekvensen som utförs under processen och informationsflödena som cirkulerar mellan dessa verk.

Andra metoder.

När det gäller att erhålla mervärdet för en produkt eller tjänst kan följande klasser av processer särskiljas:

Viktiga affärsprocesser (till exempel marknadsföring, tillverkning, leverans och service av produkter).

Att stödja affärsprocesser ger inte mervärde till produkten, utan ökar dess värde (till exempel ekonomiskt stöd för verksamheten, personal, juridiskt stöd, administration, säkerhet, leverans av komponenter, reparationer och Underhåll etc.).

Hantera affärsprocesser.

Affärsmodellär en formaliserad (grafisk, tabell, text, symbol) beskrivning av affärsprocesser. Det huvudsakliga tillämpningsområdet för affärsmodeller är omarbetning av affärsprocesser.

Målen för affärsprocessmodellering formuleras vanligtvis enligt följande:

Ge förståelse för organisationens struktur och dynamiken i processerna som äger rum i den;

Ge förståelse för organisationens nuvarande problem och möjligheterna att lösa dem;

Se till att kunder, användare och utvecklare har samma förståelse för organisationens mål och mål;

Skapa en grund för kraven för programvara som automatiserar affärsprocesser i en organisation (krav på programvara bildas på grundval av en affärsmodell).

En viktig del av affärsprocessmodellen är affärsregler eller domänregler. Typiska affärsregler är företagspolicy och statliga lagar. Affärsregler formuleras vanligtvis i ett specifikt dokument och kan återspeglas i modeller.

Sönderfall i allmän mening är det en metod som gör det möjligt att ersätta lösningen av ett stort problem med lösningen av en serie mindre problem, dela upp ett objekt i dess komponenter enligt ett specificerat kriterium. I praktiken används sönderdelning för att förfina affärsmodeller.

Etapper för att beskriva affärsprocesser:

Bestämning av beskrivningens mål.

Beskrivning av miljön, definition av inmatningar och utgångar från affärsprocessen, konstruktion av IDEF0 -diagram.

Beskrivning av funktionsstrukturen (processåtgärder), konstruktion av IDEF3 -diagram.

Beskrivning av processens flöden (material, information, ekonomi), konstruktion av DFD -diagram.

Bygga upp processens organisationsstruktur (avdelningar, deltagare, ansvariga).

IDEF0

Modellen består av diagram, textfragment och en ordlista som är kopplade till varandra. Diagram är modellens huvudkomponenter, alla funktioner och gränssnitt på dem representeras som block och bågar.

Anslutningen mellan bågen och blocket bestämmer gränssnittstypen:

Kontrollinformation kommer in i blocket högst upp.

Inmatningsinformation går in i blocket till vänster.

Resultaten kommer ut ur blocket till höger.

Mekanism (mänsklig eller automatiserat system), som utför operationen, går in i blocket underifrån.

Varje komponent i modellen kan sönderdelas (dechiffreras mer i detalj) i ett annat diagram. Det rekommenderas att du slutar modellera när modellens detaljnivå uppfyller dess syfte. Det totala antalet nivåer i modellen bör inte överstiga 5-6.

Diagrammet börjar med att representera hela systemet som ett enda block och bågar som representerar gränssnitt med funktioner utanför systemet. Sedan beskrivs blocket, som representerar systemet som en enda enhet, i ett annat diagram med flera block anslutna med gränssnittsbågar. Varje detaljerat diagram är en blocknedbrytning från diagrammet för föregående nivå. Vid varje steg i sönderdelningen kallas diagrammet för föregående nivå förälderdiagrammet för ett mer detaljerat diagram.

I sådana diagram anges varken sekvens eller tid uttryckligen. Metoden har ett antal nackdelar: uppfattningens komplexitet (ett stort antal bågar i diagrammen och ett stort antal sönderdelningsnivåer), svårigheten att länka flera processer.

IDEF3

Denna metod är utformad för att simulera sekvens av åtgärder och ömsesidiga beroende mellan dem inom processerna. IDEF3 -modeller kan användas för att gå in på IDEF0 -funktionsblock som inte har sönderdelningsdiagram.

IDEF3 -diagram visas handling i form av en rektangel. Åtgärder benämns med hjälp av verb eller verbala substantiv, varje åtgärd tilldelas ett unikt identifieringsnummer (åtgärdsnumret föregås vanligtvis av föräldernumret, till exempel 1.1.).

Alla länkar i IDEF3 är enkelriktade och är organiserade från vänster till höger.

IDEF3 -länktyper:

Temporal företräde, enkel pil. Den ursprungliga åtgärden måste slutföras innan den sista åtgärden kan börja.

Objektflöde, pil med två huvuden. Utgången från den ursprungliga åtgärden är ingången till den sista åtgärden. Den ursprungliga åtgärden måste slutföras innan den sista åtgärden kan börja. Strömmande länknamn bör tydligt identifiera objektet som förmedlas med dem.

Fuzzy Relation, streckad pil.

Slutförandet av en åtgärd kan initiera starten av utförandet av flera andra åtgärder samtidigt, eller omvänt kan en viss åtgärd kräva slutförandet av flera andra åtgärder innan dess påbörjas (processförgrening).

Förgreningen av processen reflekteras med hjälp av speciella block:

- "Och", blockera med & -tecknet.

- "Exklusiv ELLER" ("en av"), block med X -tecknet.

- "ELLER", blockera med O -tecknet.

Om åtgärderna "OCH", "ELLER" måste utföras synkront, indikeras detta med två dubbla vertikala linjer inuti blocket, asynkront - med en.
Med IDEF3 -metoden kan du sönderdela en aktivitet flera gånger och på så sätt dokumentera alternativa processflöden i en enda modell.

DFD

Syftet med denna presentation är att visa hur varje process förvandlar deras input data på helgen. Det kan återspegla inte bara informations utan även materialflöden. Liksom i andra modeller stöds sönderdelning också.

Huvudkomponenterna i dataflödesdiagram är:

Externa enheter (materialobjekt eller enskild som är källan eller mottagaren av information, till exempel kunder, personal, leverantörer, kunder, lager);

System och delsystem (till exempel ett delsystem för att arbeta med individer);

Processer (omvandling av indataströmmar till utdata i enlighet med en viss algoritm; fysiskt kan det till exempel vara en organisationsenhet (avdelning) som behandlar inmatningsdokument och utfärdar rapporter, ett program, en maskinvaruimplementerad logisk enhet, etc. .);

Datalagringsenheter (abstrakta enheter för lagring av information);

Dataströmmar (pilar i diagrammet).

Det är nödvändigt att placera på varje diagram från 3 (mindre meningslöst) till 7 (mer - inte upplevda) processer, utan att störa diagrammen med detaljer som är obetydliga på denna nivå.

Det första steget i att bygga en DFD -hierarki är att bygga sammanhangsdiagram. Vanligtvis, vid utformning av relativt enkla system, byggs ett enda kontextdiagram med en stjärntopologi, i mitten av den så kallade huvudprocessen, kopplad till sänkor och informationskällor. För komplexa system (tio eller fler externa enheter, systemets distribuerade karaktär och multifunktionalitet) byggs en hierarki av kontextdiagram. Samtidigt innehåller kontextdiagrammet på toppnivå inte en enda huvudprocess, utan en uppsättning delsystem som är anslutna med dataströmmar.

Varje process på en DFD kan detaljeras med hjälp av en DFD eller (om processen är elementär) en specifikation. Specifikationer är beskrivningar av algoritmer för uppgifter som utförs av processer. Specifikationsspråk kan sträcka sig från strukturerat naturligt språk eller pseudokod till visuella modelleringsspråk.

I modellering av affärsprocesser används dataflödesscheman (DFD) för att bygga AS-IS- och AS-TO-BE-modeller, vilket återspeglar den befintliga och föreslagna strukturen för en organisations affärsprocesser.

ARIS

För närvarande finns det en tendens till integration av olika modelleringsmetoder, vilket visar sig i form av skapandet av integrerade modelleringsverktyg. Ett av dessa verktyg är en mjukvaruprodukt som heter ARIS (Architecture of Integrated Information Systems), utvecklat av det tyska företaget IDS Scheer.

ARIS stöder fyra typer av modeller (och många typer av modeller i varje typ), vilket återspeglar olika aspekter av systemet som studeras:

Organisationsmodeller som representerar systemets struktur - hierarkin av organisatoriska enheter, positioner och specifika individer, kopplingar mellan dem, liksom den territoriella kopplingen av strukturella enheter;

Funktionella modeller som innehåller en hierarki av mål inför ledningsapparaten, med en uppsättning träd av funktioner som är nödvändiga för att uppnå målen;

Informationsmodeller som återspeglar strukturen av information som är nödvändig för genomförandet av hela uppsättningen funktioner i systemet;

Hanteringsmodeller som representerar en integrerad syn på genomförandet av affärsprocesser i systemet.

För att bygga de listade typerna av modeller används både ARIS proprietära modelleringsmetoder och olika välkända modelleringsmetoder och språk, i synnerhet UML. Du kan starta modelleringsprocessen med någon av modelltyperna.

Den huvudsakliga affärsmodellen för ARIS är eEPC (Extended Event-driven Process Chain). ARIS eEPC -notation är en förlängning av IDEF3 -notationen. En affärsprocess i eEPC -notering är ett flöde av sekventiellt utfört arbete (procedurer, funktioner), ordnade i ordningsföljd för deras utförande. Den faktiska varaktigheten av proceduren återspeglas inte visuellt i eEPC.

För att få information om processernas verkliga varaktighet är det nödvändigt att använda andra beskrivningsverktyg, till exempel MS Project.

Modeller i ARIS är diagram, vars element är olika föremål- "funktioner", "händelser", " strukturella enheter"," dokument ", etc. Mellan objekt av vissa typer kan installeras anslutningar av vissa typer ("uppfyller", "fattar ett beslut", "måste informeras om resultaten", etc.). Varje objekt motsvarar en viss uppsättning attribut som gör att du kan ange Ytterligare information om ett specifikt objekt.

Huvudobjekten för eEPC -notationen:

Fungera. Fungerar för att beskriva de funktioner (procedurer, arbeten) som utförs av företagets avdelningar / anställda. Varje funktion måste utlösas av en händelse och måste sluta med en händelse; varje funktion kan inte innehålla mer än en pil, som "startar" utförandet av funktionen och av mer än en pil, som beskriver hur funktionen har utförts.

Händelse. Fungerar för att beskriva verkliga händelser som påverkar funktionen av funktioner.

Organisationsenhet. Till exempel ledning eller avdelning.

Dokumentera. Speglar riktiga medier, till exempel pappersdokument.

Tillämpat system.

Kluster av information. Kännetecknar en uppsättning enheter och relationer mellan dem.

Kommunikation mellan objekt. Typen av relation mellan objekt, till exempel aktivering av utförandet av en funktion av någon händelse.

Logisk operatör. Operatören "AND", "OR" eller exklusiv "OR" låter dig beskriva förgreningen av en process.

Om, när man skapar en modell i eEPC, endast procedurföljd indikeras, utan att oroa sig för reflektion av styrdokument och information, kommer de resulterande modellerna att ha lågt värde ur analyssynpunkt och vidare användning.

För att lagra modeller i ARIS används ett DBMS -objekt och en ny databas skapas för varje projekt. Olika tillhandahålls, till exempel åtkomstkontroll. Databasen är en hierarkisk lagring av modeller.

Arbetet med att skapa en modell bör regleras av strikta och omfattande modelleringsavtal (standarder), ARIS stöder en mekanism av metodiska filter som tillåter användaren att endast använda en viss uppsättning scheman och objekt. Utvecklingen av sådana avtal kräver betydande tid och högkvalificerade specialister. Om ett projekt som använder ARIS börjar utan detaljerade utarbetanden av sådana avtal, är sannolikheten för att skapa affärsprocessmodeller som inte svarar på de frågor som ställs mycket stor.

Nu, efter ett allmänt förtydligande av de allmänna funktionella uppgifter som lösts av de berörda verktygen, är det nödvändigt att jämföra de funktioner som dessa verktyg ger.

I ytterligare analys kommer endast egenskaperna hos ARIS ToolSet (nedan, ARIS), BP-Win-Erwin (nedan, BP-Win) och ORG-Master (nedan, ORG-Master) att beaktas. Rational Rose -programmet, som det mest fokuserade på att bygga rent programvara, inte organisatoriska system, för att förenkla presentationen, kommer vi att utesluta från övervägande, särskilt eftersom den underliggande UML -metoden nu är implementerad i ARIS).

Funktionalitet för affärssystemmodelleringsverktyg

När man jämför olika verktyg för modellering av affärssystem är det lämpligt att överväga deras funktioner enligt följande grupper av funktionella funktioner:

• verktyg för att bygga modeller av affärssystem;
• verktyg för analys av modeller;
• medel för optimering av simulerade system enligt deras modeller;
• stöd för bibliotek av typiska modeller;
• registrering av föreskrifter och dokumentation;
• stöd för utveckling av databasmodeller och mjukvaruverktyg;
• integration med andra mjukvaruprodukter (CASE-verktyg, ERP-system, applikationsprogram).

• allmän organisation av affärsprocesser och ordningen för interaktion mellan organisatoriska enheter (artister),
• fördelning av ansvaret för genomförandet av enskilda funktioner och användningen av systemresurser,
• laddning av organisatoriska länkar, artister och instrumentella resurser i systemet,
• huvudsakliga tid- och kostnadsparametrar för det simulerade systemet,
• krav på resursförsörjning av processerna som sker i systemet.

Analys allmän organisation av affärsprocesser och ordningsföljden för interaktion mellan organisatoriska enheter i systemet utförs direkt när man studerar de konstruerade modellerna av affärsprocesser. Kvalitativ analys låter dig också identifiera dem roll, som under vissa förutsättningar kan uteslutas från processen. Vart i modellens synlighet och möjligheten att spåra de relationer som finns i systemet blir av yttersta vikt.

Anteckningar om modellernas tydlighet ges nedan. Men det bör också noteras här att ett viktigt krav för modellen är möjligheten att analysera den innan den är färdigbyggd. Om det är möjligt att identifiera interrelationer (liksom deras frånvaro) i systemet först efter att ha byggt sin kompletta modell, visar det sig vara mycket obekvämt i de inledande stadierna av arbetet, när information om egenskaperna hos processerna sker i systemet kan fortfarande vara delvis frånvarande eller felaktiga.

Här är ORG-Master i en fördelaktig position, eftersom modellen för affärsprocesser i den inte är byggd direkt i form av ett IDEF-diagram. Detta diagram kan genereras automatiskt efter att ha skapat och fyllt i klassificerare som utgör modellen (affärsfunktioner, organisationsenheter, resurser, etc.) och ställt in alla nödvändiga prognoser (relationer för resurser, artister, verktyg, regler och de faktiska länkarna mellan affärsverksamhet). Således, redan innan du får en fullständig (eller delvis) modell av en affärsprocess, är de viktigaste relationerna som bestämmer den modellerade processen redan identifierade och kan analyseras.

Till skillnad från detta tillvägagångssätt byggs affärsprocessmodellerna i ARIS och BP-Win direkt, och de befintliga relationerna mellan processkomponenterna måste förberedas för analys som ett resultat av lämpliga procedurer.

Så, till exempel, efter att ha byggt en affärsprocessmodell i BP-Win, byggs en separat datamodell med ERwin, där länkar upprättas mellan systemkomponenter (datamodellentiteter enligt metodiken). Sedan kopplas dessa modeller ihop med en mekanism som i huvudsak liknar den projektionskonstruktion som används i ORG-Master (se bilaga 1. Modellkomponenter i programvaran och metodkomplexet ORG-Master).

Med detta i åtanke, den andra av de övervägda möjligheterna för modellanalys: analys av ansvarsfördelningen för genomförandet av enskilda funktioner och användningen av systemresurser, visar sig automatiskt implementeras i processen att bygga en affärsprocessmodell i ORG-Master-systemet. Faktum är att projekteringarna från den organisatoriska länken - funktioner och funktioner - resurser, som specificeras när vi bygger modeller av affärsprocesser i ORG -Master, direkt visar de som är ansvariga för ett visst arbetsområde eller en resurs (och låter alla kombinationer av dem vara analyseras). Dessutom tillåter ORG-Master dig att exportera matrisprojektioner till MS Excel, där organisatoriska analysdiagram bildas på grundval av dem.

I ARIS och BP-Win är det för detta ändamål antingen nödvändigt att manuellt spåra alla anslutningar i affärsprocessdiagram (och datamodeller i BP-Win), eller att konstruera motsvarande listor eller rapporter med avsikt.

Fråga om att ladda artister och instrumentella resurser i systemet, liksom att få uppskattningar för det huvudsakliga parametrarna för det simulerade systemet, kan avgöras på grundval av kvantitativa data om komplexiteten (eller helt enkelt varaktigheten) för de funktioner de implementerar. För att lösa detta problem är det nödvändigt att mata in sådana data i systemet på ett eller annat sätt, samt tillhandahålla medel för att erhålla sammanfattande uppskattningar. Stöd för IDEF3-metodiken (i BP-Win), ABC-metoder i ARIS och BP-Win, samt simuleringsverktyg i ARIS (och delvis i BP-Win) ger viss behandling av dessa uppskattningar. När det gäller de faktiska initiala uppgifterna ställs de in av användaren, som därför är ansvarig för det slutliga resultatet.

Att få tillräckligt representativa uppskattningar med hjälp av statistisk (simulering / händelse) modellering (och ännu mer med hjälp av ABC -metoder när man betraktar tid som en resurs) för att ladda systemkomponenter försvåras av följande faktorer.

Moderna metoder för analys av alla processer ( arbetsflöde) dividera tidpunkten för dess genomförande med i själva verket perioden för genomförandet av operationer och tidpunkten för överföring av deras resultat. Samtidigt, i kontorsprocesser eller processer för att tillhandahålla en tjänst, tar det faktiska arbetet i genomsnitt cirka 10% av tiden, och resten av tiden läggs antingen på att fysiskt flytta resultatet av uppgiften (kräver signatur av kontraktstexten som måste tvättas igen) och väntar i kö tills nästa kommer utföraren att hitta tid att fortsätta processen. Därför ger metoder som är baserade på en enkel summering av tidpunkten för operationer för närvarande i regel inte en korrekt bild av processens tidsparametrar.

Du kan försöka få mer adekvata resultat genom att simulera systemets beteende. För tider av tjänsteförseningar måste man dock antingen göra mycket ungefärliga antaganden om lagen om deras fördelning i tid, eller genomföra ganska dyra och mödosamma tidsförfaranden och efterföljande statistisk bearbetning. Samtidigt blir tillförlitligheten för de erhållna resultaten inte för hög eller kommer att kräva betydande merkostnader. Därför verkar det rimligt att närma sig att: ”kostnaden för modelleringskostnader för att erhålla information bör inte överstiga värdet (kostnaden) för resultaten av dess användning. Dessutom bör man alltid komma ihåg Pareto -lagen, från vilken det i förhållande till det aktuella problemet följer att 20% av modelleringsinsatserna ger 80% av effekten.

Därför är det ur vår synvinkel, innan övergången till komplexa och tidskrävande och resurskrävande modelleringsmetoder associerade med kvantitativa uppskattningar av tids- och kostnadsparametrar, värt att fokusera på att få effekt av genomförandet av mer uppenbara affärsresultat modellering. Kvantitativ optimering rekommenderas att utföra med hänsyn till mätningar och analyser av verkliga processer.

ORG -Master har en funktionell analog av ABC -analysverktyg - Budgeting Wizard, som genererar ett enkelt budgeteringssystem. Ett av resultaten av arbetet med detta system är en kvantitativ bedömning av kostnaderna för att genomföra affärsprocesser (driftbudgetar), som åtminstone är jämförbart i värde med data som erhållits med hjälp av ABC-kostnadsberättigande stödverktyg.

Dessutom innehåller ORG-Master-familjen också programvarupaketet Time-Master, en av komponenterna, som säkerställer hantering av processer (arbetsflöde), möjliggör ackumulering av statistik under deras genomförande, vilket ger uppskattningar för tidsparametrarna för de processer som är nödvändiga för analysen.

• Verktyg för optimering av affärssystem (affärsprocesser) förutom möjligheterna till analys av modeller ger: ett hanteringsverktyg.
• generera en rad alternativ;
• planera;
• välja det bästa handlingssättet;
• resursfördelning;
• prioriteringar.

Som regel är implementeringen av de listade funktionerna förknippad med användning av speciella ganska komplexa eller besvärliga algoritmer för att lösa optimeringsproblem. Ett antal möjligheter av detta slag ingår i ARIS -systemet. Emellertid verkar deras genomförande i allmänhet inte lämpligt förrän i stadiet av finjustering av affärsprocessen efter att resultaten av omstruktureringen har uppnåtts med enklare metoder.

Stöd för generiska modellbibliotek låter dig använda tidigare skapade utvecklingar i processen att bygga nya modeller. Denna förmåga finns i alla tre övervägda verktygen. I synnerhet stöder ORG-Master både kompletta referensaffärsmodeller för företag, erhållna som ett resultat av verkliga projekt som utförts på ryska företag, och "bibliotek" -klassificerare som beskriver den typiska organisationen av enskilda aspekter av aktiviteter.

Dekor, i enlighet med de konstruerade modellerna, företagsregler verkar vara ett mycket viktigt tillfälle att säkerställa integriteten och konsekvensen i den dokumentära beskrivningen av affärssystemet. Betydelsen av denna komponent för affärsmodelleringsverktyg kan förstås genom att se på regelverk som ett företagshanteringsverktyg. Om ett företag är stabilt betyder det faktiskt att dess affärsprocesser är väloljade och lämpar sig för nästan formell reglering. Den interna kulturen som måste finnas i ett sådant företag gör det möjligt att vid behov snabbt bygga om systemet eller parametrarna i affärsprocesser genom att ändra arbetsföreskrifterna för relevanta avdelningar och utförare.

Förekomsten av dokumentföreskrifter om alla aspekter av företagets verksamhet är en av de grundläggande bestämmelserna i begreppet regelbunden, systemhantering... Enligt henne, i ett välorganiserat företag, fattas cirka 80% av ledningsbesluten enligt förutbestämda procedurer, och bara resten, förknippade med icke-standardiserade situationer och olika innovationer, förlitar sig på de anställdas kreativitet och hjältemod.

Organisationen av ett företag (företag) som syftar till att uppnå vissa mål regleras på modern nivå av följande standarduppsättning av grundläggande organisationsdokument:

• bestämmelsen om den organisatoriska och funktionella strukturen, som återspeglar sammansättningen av företag och funktioner som stöds i företaget, och deras distribution inom företaget;
• bestämmelser om företagets policyer (redovisning, investeringar, etc.);
• bestämmelser om organisationen av de viktigaste delsystemen för verksamhet och företagsledning, som innehåller en detaljerad beskrivning av funktioner per bransch;
• dokumenterade förfaranden - beskrivningar av affärsprocesser i en form som gör det möjligt att både presentera processen för en extern observatör och att vägledas av detta dokument till processoperatörernas utförare;
• och slutligen de traditionella "divisionsklausulerna" och " Arbetsbeskrivningar»Personal med listor över funktionella uppgifter, typer av ansvar, rättigheter och befogenheter för anställda.

Dessutom bör det vara möjligt att skapa särskilda rapporteringsformulär för att skapa dokument inom olika funktionsområden: Referensvillkor på informationssystemet för företagsledning, kvalitetsmanual (se till exempel bilaga 3) och andra specialdokument enligt ISO9000 -standarden etc.

All information som gör att du kan generera dessa dokument måste finnas i form av ett sammanhängande och konsekvent system i företagets (företagets) hela affärsmodell. Dessutom måste många av de skapade dokumenten uppfylla allmänt accepterade ryska standarder så mycket som möjligt (uppenbarligen uppfyller ARIS- och BP-Win-systemen det senare kravet i minst utsträckning).

I ORG-Master-miljön genereras sådana uttalanden och instruktioner automatiskt som textform av beskrivningar av procedurer, representerade av motsvarande klassificerare och relationsprojektioner av länkar mellan dem. Grafiska former (olika digrafer och processdiagram) är ett bra komplement till dessa dokument.

I ARIS -miljön baseras arbetsbeskrivningar och processbeskrivningar på händelseprocessdiagram och i princip kan olika textdokument försökas konstrueras genom analys av processmodeller och organisationsstrukturer. Även om bilden i större utsträckning är motsatt - systemet är främst inriktat på att skapa grafik, och funktionen att skapa dokumentföreskrifter är tydligt hjälpsam och är därför inte utvecklad.

I BP-Win finns ingen direkt möjlighet att få olika regler.

I ett förhållande projektdokumentation två sidor kan övervägas: en beskrivning av affärsprocesser och en beskrivning av ett informationssystem för att stödja affärsprocesser för dess efterföljande utveckling. Den första av dem tillhandahålls praktiskt taget lika i var och en av de övervägda miljöerna genom möjligheten att konstruera olika rapporteringsformulär enligt de konstruerade modellerna för affärsprocesser.

När det gäller dokumentation för utveckling av ett informationssystem tillhandahålls de mest traditionella möjligheterna av BP-Win / ERwin-miljön, som faktiskt skapades för detta.

ARIS-funktioner är ungefär lika: i de första versionerna av datamodellen beskrevs enhetsrelationsschemat, i senare versioner, på UML-språket. ARISToolset erbjuder dock mer avancerade utvecklingsfunktioner informationssystem.

Med ORG -Masters funktioner kan du fullt ut representera de datastrukturer som är nödvändiga för att organisera informationsstöd för modellerade affärsprocesser med sina egna universella verktyg - klassificerare och projektioner. Det finns inga formalismer som ER -diagram, även om i senaste versionerna visualisering i DFD -standarden är möjlig. Dessutom blev det möjligt att reflektera över IDEF0 -diagram interaktionen mellan funktionella block, inte bara med direkt överföring av dokument och filer, utan också genom delade databaser!

Stöd för utveckling av databasmodeller och mjukvaruverktyg brukar hänvisa till funktionerna i verktyg som CASE eller liknande verktyg för att konfigurera före(till exempel system i ERP -klassen). Sådant stöd kan ge följande funktioner:

• analys och design av arkitekturen för informationshanteringssystem,
• design av databaser och filer,
• programmering (generering av programkoder),
• stöd och omarbetning,
• projektledning.

Frågor analys och design av informationssystemarkitektur kompletteras vanligtvis genom att definiera systemkraven och relaterade specifikationer. Denna etapp, med ett systematiskt tillvägagångssätt för design, bör direkt förlita sig på modellerna för affärssystem och i själva verket detaljera dem. Därför är alla ovanstående överväganden som gäller konstruktion, analys och optimering av systemmodeller, samt utformning av föreskrifter och dokumentation, giltiga här.

Databas och fildesign(konceptuella och interna nivåer), omvandling av datamodeller, beskrivning av filformat är mest komplett i de verktyg som övervägs stöds endast i BP-Win (ERwin), eftersom denna miljö är speciellt utformad för att lösa sådana problem.

I ARIS -miljön tillhandahålls en sådan möjlighet i ARIS Toolset -paketet på nivån för projektspecifikationen och definitionen av databasparametrar.

Den metod som utvecklats i ORG-Master-miljön förutsätter (men inte nödvändigtvis) att informationssystem som redan har databaser kan användas i de modellerade affärssystemen. I detta fall behöver de inte göras om om inte systemet ska bytas ut. Men i avsaknad av informationssystem skapar ORG-Master grunden för den konceptuella datamodellen och datafilstrukturer. Denna ram representeras av beskrivningar av sammansättningen och förhållandet mellan informationsobjekt och dokument som används i affärsprocessmodeller.

Generering av programkoder för applikationer eller systemverktyg ARIS- och ORG-Master-system tillhandahålls inte, eftersom de är designverktyg för affärssystem, inte programvara. I viss utsträckning implementeras denna funktion bara i BP-Win.

Underhåll och ombyggnad... Dessa funktioner implementeras vanligtvis med hjälp av dokumentation, programanalys, omstrukturering av program och ombyggnad. Anmärkningarna ovan angående dokumentationsverktygen är fullt tillämpliga i denna diskussion.

Funktioner projektledning skapande av databaser och mjukvaruverktyg är specifika specifikt för utveckling av programvaruprodukter. De implementeras i denna form i BP-Win. Projektledning i familjen ORG-Master stöder fullt programvarupaketet Time-Master. (Även om dessa funktioner strikt taget inte krävs för klassen verktyg i fråga).

Integration med andra mjukvaruprodukter innebär en utvidgning av omfattningen av det aktuella verktyget och kan utföras både inom ramen för utvecklingen av en serie kompatibla mjukvaruverktyg (som Platinum Technologies) eller med programvara från andra utvecklare (programvara från tredje part).

Integration med tredjepartsprogramvara utförs för ett av följande syften:

• använda funktionen för den integrerade produkten för att utöka produktens omfattning,
• gör att din produkt kan ingå i en tredjepartsprodukt,
• tillhandahålla ett universellt, i någon grad, gränssnitt för din produkt, om en specifik tredje part inte är känd i förväg.

Ur funktionellt fokus, integration med:

• CASE betyder,
• ERP -system,
• applikationsprogram.

ARIS har gränssnitt med vissa CASE -verktyg och är också ett modellbyggnadsverktyg för direkt anpassning av sådana företagsledningssystem, främst SAP R / 3. Som nämnts ovan bygger systemet på sin egen notation för att representera affärsprocesser, därför använder det inbyggda simuleringsverktyg och ett verktyg kostnadsanalys vars resultat dock kan exporteras till MS Excel -format.

ORG-Master- och BP-Win-systemen stöder IDEF0-noteringssystemet för att beskriva de representerade affärsprocesserna. I princip är detta en slags länk mellan dessa verktyg och för kommunikation med andra mjukvaruprodukter med denna metodik. Men utan att här beakta frågorna om "ålder" för IDEF0 -notationen, bör det påpekas att den interna representationen av data i varje system är annorlunda, och ett standardgränssnitt som "sockets" eller klasser för IDEF0 -systemet är inte specificerad. Det finns dock ett standardiserat filformat för att representera IDEF -diagram. Därför, även om beskrivningarna som gjorts med dess hjälp inte är särskilt praktiska för både människor och datorer, är det möjligt att använda dem som ett sätt att utbyta modeller om det finns lämpliga omvandlare av detta format. En sådan omvandlare finns i följande versioner av ORG-Master.

BP-Win stöder metoder IDEF0, DFD och IDEF3 och integreras med följande mjukvaruprodukter (mestadels från samma tillverkare):

• ERwin datamodelleringsverktyg (Platinum Technology),
• projektledning och lagringssystem ModelMart (Platinum Technology),
• en specialiserad rapportgenerator för RPTwin -modellen (Platinum Technology),
• simuleringssystem BPSimulator (System Modeling Corporation),
• kostnadsanalysverktyg EasyABC (ABC Technologies).

(* Platinum Technology - sedan 1999 gick Computer Associates)

ORG-Master är initialt positionerat som ett organisatoriskt klassystem med fokus på att lösa problem med modellering och utformning av affärsprocesser och strukturer och stödja organisatoriska beslut. Det ger möjlighet att integrera med sina egna utvecklarpaket ("BIG-SPB Software"), fokuserat på att lösa olika funktionella uppgifter. I ORG-Master-systemet skapas om nödvändigt enkla exekutiva informationssystem automatiskt i MS Office-miljön:

• Budgeteringssystem (som är ett enkelt system förvaltningsredovisning, hantering av företagets lönsamhet och solvens).
• Marknadsföringssystem (ackumulering av operativ kvantitativ information om företagets marknad, samt integrering med ett eget CRM-system för att stödja kundrelationer).

Införandet av dessa applikationer i företagets verksamhet gör att du snabbt kan behärska moderna hanteringstekniker, vilket i hög grad underlättar övergången till mer komplexa exekutiva system.

Det är möjligt (och har testats i projekt) datagränssnitt genom utbytesfiler inom ramen för att bygga integrerade informationssystem med exekutiva och analytiska program från partnerföretag: 1C, A&T: Soft, Intalev, Comtech +, INEK, etc., som liksom med komplexa styrsystems företagsresurser (till exempel IPS -produktion).

Den nya versionen ger också mekanismer för att exportera beskrivningar av affärsprocesser till programvarupaketet Time-Master, som kombinerar egenskaper hos system som projektledning, WorkFlow och Personal Information System och är byggt på Internet / Intranett-teknik.

Avsnittssammanfattning:

De jämförbara instrumentens huvudsakliga funktionella funktioner presenteras i tabell 2, där uppskattningar av implementeringsgraden för funktioner eller egenskaper anges på en femgradig skala.

Som framgår av tabell 2 ger direkt summering av uppskattningarna en spridning på cirka ± 4%. Denna spridning ligger inom fel i själva uppskattningarna. Dessutom fick själva medlen, som skiljer sig åt i sin funktionella orientering, liknande uppskattningar på grund av att de olika styrkorna och svagheter olika medel, när de beräknas direkt, kompenserar varandra.

Under diskussionen om funktionella möjligheter betonades dock att individuella grupper av funktionella kapacitet har olika betydelser för att lösa problem med företagsteknik. Detta faktum återspeglas av koefficienterna i kolumnen "Vikt", tabell 2. Med hänsyn till denna faktor ser man att övergripande bedömning komplexa ORG-Master överträffar ARIS något.

Men igen, detta kan vara resultatet av olika preferenser och prioriteringar i produktens avsedda användning. Till exempel på grund av en lägre bedömning av de befintliga verktygens betydelse för kvantitativ analys av modeller (simulering och händelsemodellering), samt optimeringsverktyg, som dock är dåligt representerade i alla system som övervägs. Samtidigt uppskattas egenskaperna hos självdokumenterande modeller eller mångsidigheten att presentera olika aspekter av modellering.

I allmänhet, när man utvärderar och väljer ett modelleringsverktyg, rekommenderas det att självständigt bestämma vilka av systemverktygen som är viktigast för att lösa ett specifikt problem med dess tillämpning och följaktligen lägga ner "vikter".

Dessutom ger referensbilaga 2 en översikt över formaliseringsstandarder och verktyg för att konstruera och / eller analysera vissa modeller som används i de aktuella systemen.

Artikeln är avsedd för chefer och högsta chefer för företag som är seriösa med att bygga ett företagsledningssystem, som avser att självständigt eller med deltagande av tredjeparts specialister utforma och implementera ett företagsledningssystem baserat på en processmetod. Praktiska aspekter av design beaktas, exempel och rekommendationer ges.

Med tanke på att företag och organisationer, ett exempel som behandlas i artikeln, fortsätter framgångsrikt arbete på marknaden döljs eller ersätts specifika namn, titlar och andra detaljer i verket med de som ligger nära artikelns mening och mål. Ändå är författarna tacksamma mot sin personal för deras hjälp med att förbereda materialet.

Jag skulle vilja börja artikeln med att författarna inte på något sätt låtsas att deras arbete uppfattas som komplett handledning om detta ämne. Dessa sidor återspeglar en del av författarnas erfarenhet av det praktiska genomförandet av tillämpningen av processmetoden för drift av ledningssystem för kundföretag.

Vem behöver det

Och inte bara till vem - utan också när, och i vilket syfte. Att utforma ett kontrollsystem är en allvarlig och storskalig uppgift som kräver en betydande investering av företagsresurser och inte alltid ger en effekt som motsvarar kostnaderna. Därför, innan du påbörjar detta arbete, är det värt, åtminstone, att ställa en fråga om dess ändamålsenlighet. Så det är helt uppenbart att individuell entreprenör, som är en chef och en underordnad i en person, finns det ingen anledning att formalisera hans verksamhet så länge det gäller bara honom ensam. Ledare för småföretag är också ganska framgångsrika med verbala order, och formaliserar endast de mest nödvändiga relationerna med underordnade, till exempel anställning och avsked, eller de som krävs för "extern" rapportering. Anledningen är klar: utföraren av varje uppdrag är alltid i sikte, arbetets framsteg är tydliga och uppenbara, det finns inga komplexa tekniska kedjor och personalberoenden på varandra. Stora företag (från hundratals anställda) tillåter inte längre chefen att hålla reda på alla detaljer i det pågående arbetet - och vad större företag, ju mer det som händer på det blir en hemlighet för regissören. Vi måste dela in stora team i divisioner, utse chefer på olika nivåer och fördela ansvaret för enskilda delar av det övergripande arbetet. Med andra ord, bygg ett ledningssystem.

Så det första kriteriet är klart - storlek. Ett företag som behöver ett formaliserat ledningssystem sysselsätter minst 50 personer. Men inte alla företag är engagerade i utformningen av ett kontrollsystem eller dess modernisering - att vara nöjda med det befintliga systemet. Låt oss försöka avgöra i vilka situationer det är värt att utföra en sådan aktivitet.

● Nyetablerat företag... Till exempel är en ny fabrik under uppbyggnad. En mycket gynnsam situation för att skapa från början, från början, en idealisk ledningsstruktur. Ett sådant system kommer att vara fritt från alla traditioner och vanor - bra eller dåligt - och kommer inledningsvis att fokuseras på förväntningarna hos ägaren till det företag som byggs.

● Växande företag. På något sätt omärkligt går ditt företag från ett litet företag till ett medelstort till ett stort ... En ökning av utbudet av produkter och tjänster, en ökning av antalet anställda leder oundvikligen till en förändring av ledningssystemet, delegering av auktoritet, fördelning av ansvarsområden ... Det tidigare teamet av likasinnade är klart uppdelat i chefer och underordnade. Där det tidigare fanns samarbete finns intern konkurrens. Som ett resultat bildas ett nytt ledningssystem, och det beror bara på huvudet om det kommer att vara effektivt eller inte. Att utforma ett ledningssystem baserat på bästa praxis kan hjälpa till att undvika ledningskrisens största tillväxtsmärta.

● Behovet av att förbättra konkurrenskraften och effektiviteten. Det spelar ingen roll om företaget är en naturlig monopolist eller verkar på en mycket konkurrenskraftig marknad - förr eller senare blir det nödvändigt att sänka kostnaden för produkter eller tjänster, öka kvaliteten på tjänsterna och minska den tid det tar att ta med nya produkter till marknaden. Om det fortfarande är möjligt att minska produktionskostnaderna idag genom att välja de optimala leverantörerna, köpa modern utrustning, förbättring av tekniken, så kommer dessa möjligheter i morgon att vara uttömda, och det kommer att bli nödvändigt att hitta interna resurser. Andras prestation konkurrensfördelar endast möjligt genom att optimera företagets ledningssystem.

● Behovet av certifiering enligt internationella standarder. Oavsett orsakerna till detta behov är dess genomförande omöjlig utan att ändra och formalisera ledningssystemet.

● Avsikten är att införa ett automatiserat styrsystem. Faktum är att förvärv och installation av ett automatiserat styrsystem inte alltid leder till positiva resultat. Specialister på implementering av sådana system, oavsett produktorientering, är överens om en sak: "det är omöjligt att automatisera röran." Det mest perfekta ledningssystemet fungerar inte utan en tydlig ansvarsfördelning bland de anställda som arbetar i det. Och även om det finns ett tydligt kontrollsystem, är det värt att överväga, innan man investerar stora resurser i förvärv och implementering av ett automatiserat styrsystem, om systemet som har det innehåller några brister som inte bör åtgärdas i hård datalogik.

● Lust att öka värdet på verksamheten. I vissa fall kan affärsprocesser vara en av företagets huvudsakliga tillgångar. Ett exempel är företag som verkar på servicemarknaden. För en potentiell investerare minskar närvaron av strikta verksamhetsföreskrifter risken för att förlora sina investeringar avsevärt, även vid massavsked.

Naturligtvis kan det finnas andra skäl - eller en rad skäl till varför utformningen av ett styrsystem blir nödvändig. Viktigast av allt, när man fattar ett beslut, bör man inte glömma enkel sanning: "Om det fungerar, reparera det inte!" (Under skrivandet av artikeln hade författarna vissa meningsskiljaktigheter i tolkningen av detta ordspråk. Vi bestämde oss för detta förtydligande: det som fungerar bra idag kan bli ett problem i morgon.

Några exempel från livet

Tänk på några företag för vilka affärsprocessmodellering har blivit ett upplevt behov. Exemplen är hämtade från verkliga livet, motsvarande pressmeddelanden kan ses på Internet, men i denna artikel försökte författarna skapa en generaliserad illustrativ bild. Därför, om något exempel verkade för dig relaterat till ett specifikt företag, är det ren slump.

Ett IT-företag är ett typiskt medelstort företag. Huvudsakliga verksamhetsriktningar:

● Försäljning av affärsautomatiseringsverktyg - från försäljning av redovisning och kontorsprogram till fullskaliga automatiska styrsystem

● Implementering av affärsautomatiseringsverktyg

● Systemintegration

● Tjänster för utbildning och certifiering av kundens specialister

● Produktion och försäljning av vår egen programvara.

Ett typiskt exempel när kvantitet förvandlas till kvalitet. Med tillväxten av företagets auktoritet, ökningen av antalet kunder, utbudet av erbjudna varor och tjänster utökades. Specialiseringen av anställda ökade - och deras antal växte. Avdelningar som syftar till att lösa olika problem började dyka upp, hjälparvdelningar, många anställda började delta i varje projekt. Naturligtvis kunde ledningen inte längre kontrollera alla aktivitetsfrågor, det blev nödvändigt att organisera effektiv interaktion mellan anställda och avdelningar med varandra.

Ett annat exempel. Stort innehav. Tidigare, under sovjetiskt styre, kallades sådana företag stadsbildande - eftersom företaget, förutom gruvdrift och bearbetning av mineraler, ägnade sig åt sociala och inhemska uppgifter, hade dagis, sjukhus, lägerplatser, kantiner i sin balansräkning. . samt reparation, energi, transport och andra hjälptjänster ... Omstruktureringen ledde inte bara till en förändring av ägarna till anläggningen, runt vilken hela staden byggdes, utan också till behovet av radikala förändringar i företagets struktur. Så till exempel förenades butikernas reparationstjänster till en stor separat produktion, och dussintals enhetliga kantiner fick större självständighet, anpassade sig till specifika förhållanden och började göra vinst. Det är klart att ett sådant innehav bör hanteras annorlunda än tidigare. Att utforma ett kontrollsystem i det här fallet är inte ett infall - utan en vital nödvändighet.

Ett annat exempel. Naturlig monopolist. Hel Rysslands leverantör - återigen från sovjettiden. Uppgifterna för företaget fastställs på regeringsnivå. En av uppgifterna var framför allt implementeringen av ett kvalitetsledningssystem. I processen med att analysera problemet identifierades behovet av att gå från en funktionell affärsmodell till en modell byggd på affärsprocesser, vilket i sin tur nödvändiggjorde utformningen av ett nytt ledningssystem.

Olika exempel, olika mål och tillvägagångssätt för att lösa problem. Men alla företag har en sak gemensamt - behovet av att designa och implementera ett företagsledningssystem baserat på affärsprocesser.

Var ska man starta?

Det traditionella tillvägagångssättet innefattar beskrivningen av ett visst tillstånd "som det var", en sökning flaskhalsar och ändring av systemet, som sedan kvalificerar sig som "korrigerat det som var". En enkel och effektiv teknik för inte helt försummade fall. Bristen på fokus på vad som behövs är dock en allvarlig nackdel med detta tillvägagångssätt, särskilt när ägarens nuvarande mål är långt borta från vad företaget gör. Strategins utveckling och formalisering hjälper till att uppnå rätt riktning. Ett exempel på en strategi som formaliserats med hjälp av en strategisk karta - Figur 1.

Bild 1.

Att bygga en karta börjar med att klargöra ägarens syfte. Vad förväntar han sig av sitt företag? I det givna exemplet är målet enkelt och tydligt - att öka värdet på verksamheten under långsiktig händelsehorisont och öka vinsten på kort sikt. Andra mål är också möjliga - till exempel att öka attraktiviteten för investeringar. Huvudvillkoret är uppnåendet av målet, dess tydliga och tydliga definition (till exempel: ”Jag vill kunna sälja denna verksamhet för 10 miljoner "). Som regel genomförs målsättningen i en dialog mellan ägaren och affärsanalytiker och företagsledare, vars uppgift är att inte särskilt tydliga önskemål för specifika siffror och fakta som det är önskvärt att uppnå inom en viss tidsperiod. tid. Vid dessa möten beskrivs också metoder för att uppnå huvudmålet. I vårt exempel kan det högsta målet - att öka varumärkesvärdet - delas in i två delmål - högt varumärkesvärde för företaget och företagets varumärken- så beslutade analytikerna och studerade företagets verksamhet. De lägre nivåerna visar hur dessa värden kan ökas. Den resulterande kartan beskriver tydligt de viktigaste riktningarna att agera för att uppnå huvudmålet som anges av ägaren.

Och nu kan du agera enligt mallen ovan. Den strategiska kartan visar vilka delmål som måste uppnås för att nå det högsta målet. Med denna referenspunkt är kedjan "som den var" - "som den kommer att vara" meningsfull och styr ledningssystemets utformning för att lösa ett strategiskt problem. Varje element i det befintliga ledningssystemet kan ha en effekt på uppnåendet av något av målen för den strategiska kartan. Det är uppenbart att omarbetning endast krävs för de som är viktiga att uppnå strategiskt mål element.

Vilka element analyseras? Först och främst utbudet av varor och tjänster som erbjuds av företaget. Ett register - ett komplett paket med dessa förslag - upprättas och analyseras. Är allt vi producerar lönsamt, användbart och bidrar till uppnåendet av huvudmålen? Ska vi utöka vårt sortiment? Behöver jag minska det när det gäller olönsamma varor eller tjänster? Kan olönsamma varor eller tjänster göras lönsamma (och lönsamma - superlönsamma?). Ett lovande paket med produkter och tjänster håller på att utarbetas, för vilket affärsprocessmodellering kommer att utföras. För produktanalys kan du till exempel använda Boston Consulting Group -matrisen (figur 2).

Figur 2.

Som tillämpat på ämnet i artikeln är utformningen av affärsprocesser mest relevant för "stjärnor" (inklusive potentiella) och "kontantkor".

Det är inte alltid nödvändigt att göra en "som är" -analys av affärsprocesser. Kompetenta affärsanalytiker (eller erfarna ledare) kan vanligtvis föreslå affärsprocesser på ett ”rätt sätt”. Det finns dock situationer där ingen kan säga "hur det ska" - till exempel en helt ny typ av företag eller ett företag med ett stort antal komplexa interaktioner mellan avdelningar, som behöver öka effektiviteten i sitt arbete. Optimering av dess arbete är endast möjlig genom en grundlig analys av befintliga affärsprocesser. Samtidigt är det mycket troligt att analysen visar att intuitivt byggda kopplingar och interaktioner är optimala, och effektivitetsvinster bör sökas någon annanstans. Ändå kommer det att vara användbart för företaget att bygga upp ett driftschema över affärsprocesser - eftersom det ger möjligheter att formalisera aktiviteter och också förbereder marken för arbete vid eventuella förändringar i verksamheten.

Bristen på analys av "hur det var" bör tillskrivas särdragen i att utforma ett ledningssystem för ett nytt, bara skapat företag. Ledningssystemet är inledningsvis utformat för att uppnå företagets strategiska mål.

Team av deltagare

"Kadrer är allt!" Denna slogan, som ingen annanstans, är relevant i processen att förbättra ledningssystemet. För att lösa detta problem är det omöjligt att helt enkelt anställa professionella artister som kommer att göra allt för dig. Engagerat deltagande av nyckelpersoner i företaget är en oumbärlig förutsättning för att lösa detta problem. Å andra sidan är inbjudan från externa yrkesverksamma, även om det är önskvärt, inte nödvändig - om dina anställda tar på sig alla nödvändiga funktioner. Låt oss försöka beskriva dessa funktioner och rekrytera ett formellt team av artister, samt ange vikten av professionell kompetens för alla.

Strateg. Han är också projektledare. Den här personens uppgift i projektet är att översätta ägarens förväntningar till en strategi för att uppnå dem, samordna de andra deltagarnas handlingar och lösa konflikter i fall där en fullständig vision av situationen krävs. Strategen, om den tillämpas på militära föreningar, måste representera hela bilden av slaget - det vill säga defensiva åtgärder måste utföras. I vissa sektorer - offensiv, i andra - måste kavalleriet vid ett visst ögonblick hoppa ur bakhåll för att säkerställa ett genombrott, stridsvagnar utnyttjar dessa genombrott för att bryta igenom bakåt och besegra fienden ... Han bryr sig inte om vilken bildning stridsvagnar kommer att flytta in - det här är en lokal taktisk uppgift. Han bryr sig inte om vilken typ av transport som ska användas för att transportera ammunition - de måste bara levereras i rätt mängd. Samtidigt, om leveransavdelningen och tankbrigadens befälhavare inte kan komma överens om antalet och tidpunkten för leverans av skal, måste strategen, som känner till systemets allmänna logik, lösa konflikten mellan tjänsterna, styrd av hans åsikt om den nödvändiga balansen. En av de mest realistiska kandidaterna för denna funktion är VD (dock händer det också att VD är en ”bröllopsgeneral”, eller är för upptagen och kan anförtro funktionen som en strateg åt en ställföreträdare eller en extern konsult). Beroende på erfarenhet, arbetsbelastning, tillgång till specialkunskaper kan både suppleanter och externa konsulter (till exempel chefen eller koordinatorn för projektet från utförarens sida) involveras för att hjälpa honom. Att fatta de slutliga besluten kvarstår dock hos denna enda person, eller ibland hos företagets ägare.

Affärsanalytiker. Erfarna konsulter inom strategi och affärsprocesser med färdigheter i sin design, analys och optimering. Det är att föredra att bjuda in proffs som har fått specialundervisning och har erfarenhet av verkliga och framgångsrika projekt... Genom att tillämpa de befintliga rekommendationerna i den allmänna planen och sitt eget sunt förnuft kan företagets högsta chefer utföra dessa funktioner, åtminstone på en genomsnittlig nivå. Faktum är att finansdirektören, chefsingenjören, biträdande för utveckling och andra vakthavande chefer måste kunna analysera de strategiska och taktiska aspekterna av deras verksamhet. Det som skiljer en professionell affärsanalytiker från dem är hans erfarenhet av arbete i andra företag, förmågan att gå utöver de vanliga föreställningarna och kunskap om rekommendationer som uppenbarligen ger positiva resultat. Som exempel på sådana rekommendationer kan man nämna: parallellisera processen där det är möjligt, med hjälp av automatisering, minimera antalet affärsprocesser som utförs av olika avdelningar.

Lågnivå affärsprocessdesigners. För att förstå vilka dessa människor är, låt oss överväga uppgiften ur synvinkel för den aktuella uppgiften. För litet företag som regel utmärks 7-8 högsta affärsprocesser (till exempel produktion, försäljning, leverans, personalreproduktion etc.). Var och en av dem är uppdelad i 7-8 mindre delprocesser - mer detaljerade (till exempel "produktion av produkter" kan inkludera tillverkning av delar, montering av produkter, kvalitetskontroll) - det vill säga, som ett resultat har vi ungefär femtio affärsprocesser. I stora företag är som regel ytterligare uppdelning nödvändig - en eller två nivåer till. (Figur 3)

Figur 3. Ett exempel på att dela upp affärsprocesserna för ett medelstort företag. För stora, lägg bara till en eller två våningar ner ...

Till exempel utför en enda HR-chef på ett medelstort företag sin funktion inom en enda affärsprocess, som helt enkelt kallas ”rekrytering”. Med tanke på att han gör nästan allt arbete på egen hand, behöver du inte skriva några regler för detta arbete. En annan sak är personalavdelningen på ett stort företag, där det finns en uppdelning av olika funktioner mellan anställda. Processen att "rekrytera" i det här fallet består redan av dussintals fler enkla handlingar utförs av olika människor - och det är deras interaktion som måste beskrivas av affärsprocesserna på den lägre nivån. Den sista nivån för att dela upp affärsprocesser är en affärstransaktion - en process som är fullständigt utförd och kontrollerad av en personalenhet. Och för mycket stora företag är tusentals affärsprocesser ganska verkliga. Låt oss nu göra en tänkt projicering av bilden av affärsprocesser på diagrammet över företagets divisioner. Uppenbarligen kommer vissa affärsprocesser att passa helt inom en avdelning. Det kommer också att finnas processer för vilka två eller flera avdelningar är ansvariga (i en eller annan grad). Och de mest obehagliga situationerna är de där ansvaret för genomförandet av en affärsprocess upprepade gånger överförs från en avdelning till en annan (se framåt, låt oss säga att det rekommenderas att undvika sådana affärsprocesser, om möjligt). Figur 4 visar schematiskt affärsprocesserna för ett fiktivt produkttillverkande företag. Några av affärsprocesserna, som visas med svarta pilar, sker inom divisionerna. Den andra delen - de blå pilarna - rör sig från en enhet till en annan. Och slutligen är den tredje delen en process där flera avdelningar är involverade. Röd prickig linje.

Ris. 4. Tillhör affärsprocesser. Svarta pilar indikerar avdelningens interna affärsprocesser, färgade pilar - processer på högre nivå.

Vem är bäst att få förtroendet att modellera en affärsprocess på låg nivå för vilken en avdelning är helt (eller nästan helt) ansvarig? (Vem ska anförtros bildandet av en tankavdelning för att genomföra ett genombrott?) Svaret antyder sig själv - det här är enhetschefen (eller en extern konsult på denna nivå som arbetar med enhetens chef). Men det vore åtminstone hänsynslöst att planera samspelet mellan ryttare, tankmän och förnödenheter till chefen för en av dessa enheter - risken för att "dra täcket över dig själv" är för stor. Därför bör modellering av affärsprocesser på de övre nivåerna, processer med ett stort antal relationer mellan workshops och avdelningar, utföras direkt av strategen, som en person som är intresserad av hela företagets framgång, och inte en separat enhet. Minimikraven för designers är desamma jobbansvar namngivna anställda. Att anlita outsourcad talang kan lindra en del av bördan för chefer, och erfarenhet och yrkeskunskaper kan påskynda arbetet.

Skådespelare. De är också affärsprocesser på låg nivå och ... marsvin. Det räcker inte att utarbeta ett teoretiskt korrekt interaktionsschema. För att vinna måste du omsätta det i praktiken. Det vill säga att föra den till de vanliga artisterna och uppnå dess utförande. Det ideala alternativet är att välja en eller två av de mest aktiva och kapabla medarbetarna från antalet anställda som utför samma arbete och anförtro dem att arbeta på ett nytt sätt - tills systemet är felsökt. Ett annat alternativ är en gradvis övergång från några av de gamla processerna till nya som ersätter dem. Men i verkligheten är detta inte alltid fallet. Relationssystemet (särskilt om det inte har optimerats) kan vara så komplext att ett stort antal deltagare måste delta i tester. Någon analogi kan dras med exemplet på implementering av ett automatiserat informationssystem. Det är sällsynt när det är möjligt att ersätta enskilda delar av det gamla systemet med nya lösningar. Oftare måste medarbetarna hålla register parallellt i de gamla och nya systemen under en tid. För dessa teammedlemmar är outsourcing inte möjlig. Externa konsulter kan dock avsevärt påskynda genomförandet genom att tilldela proffs att utbilda och konsultera företagsanställda och övervaka att processerna är korrekta.

Fråga: Kan ett team endast bildas av företagets anställda, utan att involvera externa specialister, med vissa metoder och sunt förnuft, bygga och implementera ett nytt ledningssystem - från den strategiska kartan till detaljerade affärsprocesser, regler, etc.?

Svar: Det finns inga tydliga metoder för korrekt konstruktion av affärsprocesser "från och till", men det finns rekommendationer, liksom referensmodeller. På grundval av sin egen och andras erfarenhet kan en stark chef åtminstone bygga ett operativsystem. För att pressa ut maximal effektivitet ur systemet krävs förutom en stor (och helst bred) erfarenhet en hel del talang. I det här fallet har företaget en verklig chans att ”komma in bland de tio bästa”. För att bli den obestridda ledaren i sin verksamhet behöver företaget hjälp av ett sinnrikt team som leds av lämplig ledare.

Själva designen ...

Som nämnts tidigare finns det ingen enda metod för att utveckla affärsprocesser. I det här avsnittet kommer vi att försöka överväga ett antal viktiga punkter, som bör fokuseras på och som bör lämnas utanför vår uppmärksamhet.

Fullständighet och harmoni i övergripande affärsprocesser. Betydelsen av detta kriterium är lika med själva företagets betydelse. Befälhavaren måste vinna striden först i sitt eget sinne och föreställa sig hur händelser ska utvecklas på slagfältet - annars är det inte värt att ens närma sig fienden. Beroende på företagets storlek måste två eller tre nivåer kontrolleras för integritet och konsekvens.

Koncentration av insatser för att uppnå strategiska mål. Affärsprocesser som inte har någon inverkan på viktiga indikatorer utvecklas senast, eller inte utvecklas alls. Låt oss utföra den enklaste beräkningen: för ett företag som har tre nivåer av affärsprocesser (det vill säga inte ett särskilt stort enhetligt företag) har vi 7-8 processer på övre nivå, var och en uppdelad i 7-8 BP av andra nivån, samma princip för delning förblir under ... Som ett resultat har vi redan på tredje nivå mer än 350 affärsprocesser. I genomsnitt består varje affärsprocess av ett dussin verksamheter, vilket ger fyra tusen verksamheter som helhet för företaget. Och det är bara för en liten stund! Jag föreslår att beräkna den geometriska utvecklingen till den fjärde och femte nivån på egen hand. Naturligtvis kräver bara sådana monster som Gazprom eller RAO UES den femte detaljnivån, men även för den fjärde nivån är antalet operationer inte litet. Varje process, varje operation, helst, måste optimeras, regleras och revideras minst en gång om året eller när de yttre förhållandena ändras. Med tanke på antalet operationer förstår vi att idealet, som vanligt, är ouppnåeligt, och strävan efter det kommer bara att leda till en omotiverad överutgift. Du måste fatta ett sorgligt men rätt beslut - efter att ha tagit en strategisk karta, utforma endast de affärsprocesser som motsvarar de mål som anges i den. Och om städningen av det inre territoriet inte påverkar något av målen eller delmålen för den strategiska kartan, inte påverkar någon indikator från BSC, låt städarna själva reglera det. Åtminstone tills vi äntligen kom på produktion, försäljning och leverans ...

Granulariteten måste matcha våra behov. En av anledningarna till att överdriven detalj inte bör tillåtas anges ovan - en omotiverad ökning av arbetsvolymen. En annan påminner om den gamla liknelsen om tusenbenet - om enkla naturliga handlingar beskrivs för detaljerat för den anställde, kan implementeringen bli ineffektiv. Huvudkriteriet i detta fall är enkelt - om en tydlig ansvarsfördelning mellan anställda har uppnåtts och de grundläggande principerna för att utföra operationer är fastställda, är det inte nödvändigt med ytterligare detaljer. Det räcker med att ange att den anställde till exempel, vid mottagande av en ansökan, måste skriva ut motsvarande faktura och ställa in körningstiden - utan att ange vilka tangentkombinationer som ska användas för att flytta genom cellerna, spara och skriva ut filen.

Glöm inte att designa huvudparametrarna för affärsprocessen när du designar (figur 5).

Figur 5. De viktigaste parametrarna i affärsprocessen

Dessa inkluderar till exempel ledtider och kostnader. Konstruktion är i de flesta fall bara en av uppgifterna i processen med att omarbeta ett styrsystem. Förr eller senare kommer det att finnas en önskan att optimera - då kommer dessa siffror att vara till nytta. Men när optimering inte ingår i de omedelbara planerna kan du skjuta upp det ... om du inte är orolig för att det kan ta timmar eller dagar för anställda att skriva ut en faktura.

Bedömning av processens problematik och betydelse. Det låter dig också förstå vilka processer som ska utformas direkt och vilka som kan vänta. Bland de viktigaste kriterierna här kan övervägas: 1) kritik för företag. Det vill säga hur mycket fel utförande av processen kan skada företaget - öka kostnaderna, leda till förlust av en klient, försena antagandet av ett viktigt beslut ... 2) Frekvensen av upprepning av processen (sällan, ofta , regelbundet). 3) Antalet ansvarsöverföringar inom en process, till exempel från avdelning till avdelning. Sådana processer är potentiellt farliga och innebär många problem.

Ledare i alla tre kategorierna är tydliga kandidater för design och optimering.

Figur 6. Illustration av processmetoden

Det bör noteras att dessa två tillvägagångssätt sällan ses i uttalad form. Således tillhandahåller personalavdelningen i ett stort företag nästan alltid en för alla divisioners behov, samtidigt som produktionen av markant olika produkter ofta organiseras i separata delar av företaget. Således bör uppgiften att bestämma vilket tillvägagångssätt som sker i ett visst företag (och även vilket som faktiskt ska genomföras) lösas en av de allra första under arbetet med ett projekt. När allt kommer omkring, ju mer ett företag drar sig mot en funktionell struktur, desto mer förvirrade affärsprocesser, och desto mer ansvarsfull och svårare är deras design. Rekommendationen att byta till processhantering är inte alltid lämplig - trots allt, till exempel, i detta fall måste alla resurser delas in i divisioner, vilket är omöjligt i förhållande till unika resurser (till exempel en energistation), och kan visa sig vara ekonomiskt olönsamma. Ett annat exempel är en riggverkstad med tio personer som kan flytta en maskin som väger 2-3 ton. Om denna verkstad är spridd i fem brigader i olika divisioner, blir det omöjligt att flytta ihop en sådan maskin. Du kommer att behöva behålla ett team på tio personer i varje division - och det är inte ett faktum att de ständigt kommer att laddas med arbete.

Ta hänsyn till företagets anställda oundvikliga motstånd mot allt som på ett eller annat sätt kommer att förstöra det befintliga relationssystemet. Så det är osannolikt att chefen för riggavdelningen blir nöjd med en degradering till en arbetsledare och kommer att leta efter alla möjliga sätt att sabotera antagandet av ett sådant beslut. Anställda kommer att överdriva vikten av sitt arbete - och försöka minska vikten av arbetet på andra avdelningar. Divisionschefer kommer att dra av lönsamma affärsprocesser och på alla möjliga sätt neka ansvar för det nödvändiga bidraget till "andras" processer. Även om det naturligtvis finns ett mycket starkt beroende av stimulans av innovation för specifika artister (som för det mesta inte alls är intresserade av några förändringar, även om de lovar något mycket bra i framtiden, eftersom en ökning i effektivitet från deras synvinkel innebär en möjlighet att göra mer för din arbetsgivare för samma pengar).

Vad vi förväntar oss i slutändan

Slutresultatet av designen bör vara ett företag som arbetar enligt det nya schemat. En av de viktigaste slutdesignprodukterna är den nödvändiga och tillräckliga uppsättningen föreskriftsdokumentation.

Regler för affärsprocesser (åtminstone viktiga), standardiserade former av dokumentation, både externa och interna, bestämmelser om divisioner, arbetsbeskrivningar, bemanningsbord företag - detta är dess minimilista. Lika viktigt är implementeringen av systemet, genomförandet av regelverk i praktiken. Först då kan vi säga att ansträngningarna och resurserna för designen inte slösades förgäves. Det är bra om du lyckas dela upp implementeringen i små steg och sektioner (till exempel först inköpsavdelningen, sedan lagerlokaler etc.) Förutom att detta gör det möjligt att upprätthålla en säker kontroll över processen att introducera innovationer, kommer varje liten framgång att bli en bra incitamentfaktor för fortsatt arbete. Det är sant att det alltid är möjligt att dela upp implementeringen i separata oberoende sektioner. Även om det nya systemet helt undviker ansvarsfördelningen mellan avdelningarna, om strukturen i nya affärsprocesser är strikt linjär och enkel, även då är det nödvändigt att genomföra mätningar "on the fly" (vem gör det möjligt att stoppa ett lönsamt företag?) Av den nya processen påverkar dussintals gamla, som i sin tur ersätts av dussintals "nya", var och en ... (och vidare, stegvis). Därför, i de flesta fall, under implementeringen, tvingas teamet att arbeta en tid enligt det gamla systemet och simulera nya aktiviteter parallellt (de flesta av dina anställda är läskunniga människor och förstår mycket väl att de under lång tid måste gör dubbelarbete bara för att den slutliga belastningen på dem skulle öka jämfört med originalet - därav motståndet mot innovation). I de mest försummade fallen visar det sig vara lättare att bygga en ny anläggning i närheten för att implementera ett ledningssystem (detta är precis vad du måste göra, till exempel på AvtoVAZ, där absurditeterna ärvda från sovjetisk tid, multiplicerat med de förvärvades under omstruktureringsprocessen, skapade en miljö där nästan alla anställda motstår innovation.). Och slutligen är ett annat naturligt designresultat introduktionen av ett automatiserat företagsledningssystem. Det har länge bevisats att automatisering förbättrar arbetseffektiviteten. Automatisering ger en särskilt märkbar effekt i företag där det finns ett tydligt och rationellt ledningssystem, alla affärsprocesser regleras. Och tvärtom, att automatisera hanteringen utan preliminär design innebär att döma implementeringen av ACS till misslyckande (har vi redan nämnt omöjligheten att automatisera slumpmässigt uppkommande relationer på ett obestämt sätt?). Närvaron av ett strikt system av affärsprocesser kommer att göra det möjligt att närma sig implementeringen av automatiserade styrsystem ur maximal effektivitet. Nu är det redan ganska realistiskt att automatisera de mest kritiska arbetsområdena först, med de pengar som erhållits eller sparats som resultat - den näst viktigaste ... Du kan göra detta med den gradvisa resurser som tillåter eller den yttre situationen kräver.

Bedömning av resursbehov

Om du tidigare har varit inblandad i sådana aktiviteter, föreställer du dig redan hur mycket enklare ditt nuvarande konto kommer att göra design, hur många anställda du tillfälligt kommer att förlora, som fullvärdiga stridsenheter (och hur många du kommer att förlora alls). Resonemanget nedan är mer troligt för dem som planerar att starta sådant arbete för första gången - det är trots allt farligt att både överskatta och underskatta omfattningen av framtida förluster. En överskattad komplexitetsuppskattning kan leda till att projektet överges helt (tillsammans med förhoppningarna om att bli branschledande), eller till onödigt höga belopp enligt ett kontrakt med entreprenören. En underskattad uppskattning kommer att leda till att det någon gång inte kommer att finnas tillräckligt med resurser och projektet kommer att överges - vilket igen betyder förlorade pengar. Timing är lika viktigt - och av samma skäl. Praktiken visar att medelstora företag - från 500 till 1000 personer - utvecklar och implementerar ett nytt ledningssystem på ett år. Företag med 10 000 anställda tar cirka 2-3 år. Beroende på situationens komplexitet kan implementeringstiden dock öka med två eller tre gånger.

Från behovet av mänskliga resurser kan det antas för hela denna period av ett permanent team på 3-4 personer (strateg, analytiker) och behovet av att involvera anställda i företaget, vid behov, - avdelningschefer och vanliga exekutörer. Cheferna kommer att vara inblandade, i ungefär en till två månaders nettotid under hela design- och implementeringscykeln, vanliga artister - mindre, från 2 veckor till en månad. Kostnaden för dina specialister, med tanke på denna tid, kan uppskattas. Externa konsulter är dyra. Specialistens tjänster kan kosta från 1,5 till 25 tusen rubel per timme arbete.

Lite om framgångsgarantierna. Vi har redan sagt att när man utformar ett ledningssystem på egen hand har en erfaren och vettig chef med stöd av ett team av hans suppleanter en god chans att utföra detta arbete utan att involvera externa konsulter - även om naturligtvis ett sådant team inte uppnå ett idealiskt resultat första gången. Det finns fler möjligheter för ett professionellt team - och ju mer kända (och dyra) konsultföretag du bjuder in - desto närmare kommer du det perfekta ledningssystemet för din typ av verksamhet. Ett välkänt företag värderar i regel sitt rykte, sina specialister i processen med en förprojektundersökning kan dra slutsatser om effektiviteten i det kommande arbetet-eller de kan vägra om det av någon anledning är framgångsrikt designen garanteras inte. Nyligen har ett annat tillvägagångssätt dykt upp - vid implementeringstillfället anlitas huvudkonsulten av kundföretaget som toppchef - en direktör eller ställföreträdare. Naturligtvis måste konsultföretagets rykte vara mycket högt för detta, men du kan vara säker på att få resultatet Hög kvalitet, med en märkbar besparing av nervceller. Ett lite känt företag kan vara billigare - men resultatet är långt ifrån garanterat.

Fråga: Är det möjligt att sänka kostnaden för att utforma ett styrsystem?

Svar: Det är möjligt och nödvändigt. Sättet att minska behovet av resurser är att använda specialiserade mjukvaruprodukter.

● Den första anledningen till att designautomation verkligen är användbar är möjligheten att spara och redigera varje steg. Som det är, skapade och sparade affärsprocesser gör det mycket lättare att modellera befintliga processer-redigering är enklare än att skapa på nytt.

● Den andra anledningen har sin grund i förståelsen av effektivitetsgrunderna. Ofta är repetitiva processer avgörande för hela processen - trots deras enkelhet och rutin är deras bidrag till de totala arbetskostnaderna mycket betydande. I utformningen av affärsprocesser finns det många mallar, repetitiva åtgärder, som när handgjorda, kommer att ta bort lejonparten av hela utvecklingstiden. Naturligtvis underlättar användningen av CTRL-C-CTRL-V-metoder betydligt arbetet i WORD eller Excel när du anger dem, men specialiserad programvara ger en ännu bekvämare designmiljö.

● Den tredje anledningen är sammankopplingen av alla objekt - från avdelningar och anställda till processer på olika nivåer och strategiska mål. I ett välbyggt system bör allt vara föremål för ett enda strategiskt målsystem. Specialiserad programvara tillhandahåller sådan sammankoppling, hjälper till att undvika irriterande felberäkningar från slarv vid inmatning av information.

● Den fjärde anledningen är möjligheten till optimering. Även om det idag inte finns något program som självständigt kan utforma den optimala versionen av en affärsprocess (annars skulle behovet av chefer och affärsanalytiker försvinna av sig själv, en dator är billigare) - men simulera hundratals cykler av var och en av tusentals affärsprocesser i dussintals varianter av deras interaktion ... Prova med Excel! Och i det här fallet kan du inte klara dig utan statistisk bearbetning - trots allt kommer systemet att fungera i den verkliga världen, där allt händer.

● Den femte (och för många, den viktigaste) anledningen är automatiseringen av resultatet från resultatet. Även det mest utmärkta ledningssystemet kommer att förbli bara ett projekt tills affärsprocesser förvandlas till regelverk och arbetsbeskrivningar. Ett system som automatiskt kan generera alla dessa hundratals och tusentals regleringsdokument, och till och med föra dem till varje anställd, kommer att spara chefen en mycket stor del av hans mycket dyra tid. Naturligtvis, när du korrigerar affärsprocesser (och de rekommenderas helt enkelt att kontrolleras för vitalitet minst årligen), kommer det automatiska systemet inte att glömma att göra ändringar i alla dokument som påverkas av ändringarna - och återigen ta med de nya spelreglerna till de anställda. Vi får inte glömma att automatiskt genererade bestämmelser är konsekventa och konsekventa (om affärsprocesser naturligtvis är utformade korrekt) och anställda inte längre kommer att kunna använda "hålen" i din interna lagstiftning.

● Sjätte anledningen. Ganska viktigt för nybörjare. Instruktionen för specialiserad programvara är i sig ett uttalande om grunderna i modellering av affärsprocesser. Nybörjaren arbetar enligt det mönster som beskrivs i programvaran och kommer inte att göra några irriterande misstag, systemet tillåter inte att missa några viktiga åtgärder eller steg, på grund av vilka chanserna för designframgång ökar avsevärt.

• Skaffa en helhetsbild av organisationens liv, komma överens om olika synpunkter på ett ständigt utvecklande och förändrat företag.
• Säkerställa ömsesidig förståelse på alla nivåer i organisationen, överbrygga klyftan mellan de ledande och utförande parterna.
• Säkerställa minskning av produktionskostnaderna och en höjning av kvalitet och service.

I processen med affärsmodellering sker en övergång från begreppet "vad" ska göras till begreppet "hur" ska göras. Resultatet av simuleringen bör vara ett dokument som ger utvecklingsteamet en tydlig förståelse för projektgränserna, samt klientens programvara och hårdvara. De erhållna uppgifterna återspeglas i projektspecifikationen, som kan innehålla följande avsnitt:

• en beskrivning av applikationsdatas huvudsakliga enheter;
• en formell beskrivning av ansökningsspecifikationen;
• affärslogik och affärsregler;
• funktionella krav;
• icke-funktionella krav;
• ansökningsblankett / sidmallar;
• en omröstning eller en lista med förkortningar;
• hjälpdiagram.

Verktygsmodelleringsverktyg och deras utveckling

För att skapa affärsmodeller används informationssystems designverktyg och motsvarande beskrivningsspråk (det mest kända bland dem är UML - Unified Modeling Language). Med hjälp av sådana språk byggs grafiska modeller och diagram som visar strukturen i organisationens affärsprocesser, organisationen av interaktionen mellan människor och de nödvändiga förändringarna för att förbättra organisationens prestanda som helhet. Verktygsmodelleringsverktyg utvecklas ständigt. Inledningsvis var det med hjälp av sådana verktyg möjligt att endast beskriva företagets affärsfunktioner (arbete) och förflyttning av data under genomförandet. Samtidigt, om samma affärsfunktion användes vid olika typer av arbete, var det svårt att förstå om det innebar samma affärsfunktion eller en annan. Oförmågan att uttryckligen definiera hierarkin för affärsprocesser (till exempel "värdekedja", "affärsprocess", "delprocess", "arbete", "funktion") skapade problem vid användning av sådana beskrivningar. Själva beskrivningarna var bara en samling bilder. Senare började det dyka upp verktyg som låter dig beskriva organisationen inte bara från affärsfunktionernas sida utan också från andra sidor. Så det blev möjligt att skapa separata diagram som reflekterar organisationsstruktur företag, dataflöden i en organisation, sekvensen för att utföra affärsfunktioner som utgör en enda affärsprocess, med möjlighet att använda logiska symboler, etc. På grund av de ständigt ökande kraven på affärsmodelleringsverktyg har fler och fler diagram börjat verkar beskriva olika aspekter av verksamhetsorganisationer, vilket gjorde skapandet av modellen allt svårare. I detta avseende är nästa viktiga steg i utvecklingen av affärsmodelleringsverktyg förknippat med tanken på att använda ett enda arkiv (lagring) av objekt och tanken på en eventuell återanvändning av objekt i olika diagram. Vilket verktyg som än väljs, krävs det för att säkerställa interaktionen mellan lokala informationssystem med varandra. Idag är BPEL (Business Process Execution Language) den mest moderna och samtidigt allmänt accepterade standarden för att organisera affärsprocesshantering. På grundval av denna produkt kan du skapa en enda integrationsplattform för alla applikationer som används. Efter modellering av processerna använder ett av modelleringsverktygen speciella översättare för att föra modellen till BPEL.

Exempel på affärsmodellering och dess resultat

• Minska kostnader. Affärsmodellen ger insikt om var onödiga kostnader kan undvikas och hur man optimerar resursanvändningen. Baserat på affärsmodellen utförs en funktionell kostnadsanalys för att beräkna kostnaden för en produkt eller tjänst, och ett budgethanteringssystem byggs som låter dig kontrollera kostnaderna för ett företag.
• Ökad effektivitet. Möjligheten att minska kostnaderna för anpassning och personalutbildning. Regleringsdokumentation baserad på den förberedda affärsmodellen motsvarar organisationens nuvarande situation, fördelar ansvar, bygger ett hierarkiskt system för karriärtillväxt.
• Utvidgning av inflytande, expansion av nätverket, organisation av filialer. Närvaron av en affärsmodell kommer att minska kostnaderna och göra det möjligt att beskriva strukturen för arrangemanget av nya grenar av företaget.
• Tillräcklig investering. Med hjälp av affärsmodellering är det möjligt att bestämma mängden investeringar med tillräcklig noggrannhet, minska risker och ekonomiska förluster vid startskedet av ett nytt projekt.
• Implementering av EDMS. Företagets affärsmodell standardiserar sammansättningen av företagets dokument och fastställer vägarna för förflyttning av dokument.
• Automatisering och implementering av ERP, SCM, CRM eller andra mjukvarusystem. Baserat på affärsmodellen kan du formulera högre kvalitetskrav för systemet och hitta en lösning som är optimal vad gäller kostnad och funktionalitet.
• Certifiering av kvalitetsledningssystem. Utvecklingen av ett företags affärsmodell kan avsevärt minska tid och kostnader för utveckling, implementering och certifiering av ett kvalitetsledningssystem och få en uppsättning nödvändiga dokument för framgångsrik certifiering, minska kostnaderna för att upprätthålla ett kvalitetsledningssystem.

Funktioner i affärsmodellering

Att skapa, implementera och stödja en affärsmodell är ett dyrt investeringsprojekt. Och liksom alla projekt bör skapandet av en affärsmodell föregås av en analys av genomförbarheten och genomförbarheten. Stora projekt kräver kraftfulla affärsmodelleringsverktyg med välutvecklad funktionalitet: med möjlighet att lagra information i ett enda arkiv, lagarbete på ett modelleringsprojekt och kontrollera den skapade modellen för integritet, halvautomatisk generering av diagram, integration med annan programvara, analys och dokumentation av modellen - medan det på små projekt av kostnadsskäl skulle vara klokare att använda mindre kraftfulla verktyg. För analys av verksamheten, utvecklingen av den befintliga strukturen, bör en lämplig affärsmodell först byggas. Det vill säga, inledningsvis teorin, och först efter - dess genomförande.

Lösningar

Idag finns det ett stort antal mjukvaruprodukter som är utformade för att beskriva en organisations arkitektur. Enligt rapporter från analysföretaget Gartner kan följande företag tillskrivas ledarna för detta segment.