IDEF0. Bekanta dig med notationen och ett exempel på hur den används. BPwin (AllFusion Process Modeler) datormodelleringsprogramvara idef0 modellutvecklingsprogram

Känd idag, inte bara i trånga cirklar, är förkortningen IDEF0 den första metoden för att standardisera arbetet med affärsprocesser. Det utvecklades i mitten av förra seklet som en del av ett flyg- och rymdprojekt i USA och efter att ha visat sin effektivitet blev det federal standard... I vårt land år 2000 utarbetades ett dokument " Funktionell modelleringsmetodik IDEF0. Vägledning Funktionell modelleringsmetodik IDEF0 Vägledande dokument. Officiell utgåva. Gosstandart of Russia RD IDEF0 - 2000. Utvecklat av Research Center CALS - Technologies "Applied Logistics". Antogs och genomfördes genom resolutionen från Gosstandart of Russia 2000, Moskva”, Men som standard godkändes den aldrig. Även om detta inte hindrade denna metod från att bli ett av de mest populära verktygen för grafisk modellering av affärsprocesser i vårt land. I den här artikeln inbjuder jag dig att granska IDEF0 -modellen och bedöma den aktuella relevansen av detta tillvägagångssätt.

Grundläggande begrepp och förkortningar

Låt oss förstå lite om namnen på metodens nyckelelement. Den grafiska standarden IDEF0 är en del av SADT (Structured Analysis and Design Technique) metodik. IDEF är en förkortning för ICAM Definition, och ICAM härrör från Integrated Computer Aided Manufacturing, som översätts som integrerad datorisering av produktionen. SADT-metoden är en hel familj med 15 olika modeller, som tillsammans skulle kunna studera strukturen, parametrarna och egenskaperna hos produktionstekniska och organisationsekonomiska system.

IDEF0 är en funktionell modell, som är kärnan i alla andra strukturer, den kopplar samman information och materialflöden, organisationsstruktur, kontrollåtgärder och själva företagets aktivitet. Den grafiska standarden för modelleringsprocesser kallas också notation. Det vill säga notation är ett system med krav och regler för att konstruera en aktivitetsmodell i en eller annan form. Därför är det lämpligt att kalla IDEF0 en notation som är en del av SADT -metoden.

IDEF0 -notering är en ganska rigorös teknik som ursprungligen utvecklades, som tekniska designstandarder, för manuell modellering. Därför innehåller den krav på placering av pilar, format för alla element, innehållet i informationsramen för IDEF0-diagrammet, etc. Eftersom företagets aktiviteter är ett komplext system med flera nivåer, finns det alltid många scheman, och en entydig systematisering och navigering genom alla element i modellen krävs. Nu görs detta främst av datorsystem som stöder modellering i denna notation. På Rysslands territorium är de mest kända och tillgängliga systemen idag AllFusion Process Modeler och Business Studio. Jag tänker ägna separata artiklar åt granskningen av dessa system.

Funktionsblock

Det centrala elementet i IDEF0 -modellen är funktionen, som visas på diagrammet som funktionsblock- en rektangel, inuti vilken handlingen indikeras i form av ett verbalt substantiv. Åtgärden kan vara mycket olika i skala - från företagets verksamhet i allmänhet och till specifik manipulation i synnerhet. Exempel: "Tillverkning och försäljning av keramiska porslin" och "Ritning på en produkt".

Obligatoriska funktionsblockelement i IDEF0

Oavsett åtgärdens omfattning visas alla funktioner enhetligt och innehåller nödvändigtvis fyra nyckelströmmar som är strikt tilldelade sidorna av funktionsblocket:

  • till vänster - ingångar eller resurser som används för att utföra funktionen;
  • till höger - utdata eller resultat av funktionen;
  • ovanpå - kontrollåtgärder som avgör hur och hur många resultat som måste produceras;
  • nedan - mekanismer som återspeglar vem och med hjälp av vad som ska göra detta arbete.

Detta tillvägagångssätt låter dig spara lite på förklaringar i diagrammen och uppnå otvetydighet i visningen av flöden, vilket gör hela modellen smal.

För att bygga en funktionell modell kräver IDEF0 -metoden följande regler.

  1. Ingångar är resurser som överför sitt värde till output helt, det vill säga de spenderas på att skapa ett resultat i sin helhet, och mekanismer är resurser som överför sitt värde endast delvis (utrustning genom avskrivningar och människor genom löner).
  2. Hantering är en nödvändig del av modellen, eftersom den knyter alla åtgärder till företagets regelsystem, vilket tydligt anger vilka regler och krav som måste följas vid utförandet av funktionen. Ofta behandlas detta flöde formellt, men schemat förlorar sin noggrannhet och ibland även mening.
  3. Varje funktionsblock måste ha minst en pil på varje sida (eftersom det inte kan utföras arbete utan resurser eller resultat, och en instruktion utan en exekutör eller instruktion kommer att vara ofullständig).

Det planerade systemet är en "byggsten" för IDEF0 -metoden. Funktionell modellering innebär en gradvis övergång från det allmänna till det särskilda genom sönderdelning. Sönderdelning "fördjupas" i den funktion som övervägs och delar den i mindre funktioner. När funktionen på högsta nivå presenteras på ett generellt sätt och efter att den har sönderdelats är det dessutom lämpligt att kalla det en process.

Kontextdiagram

På högsta nivå presenteras företaget som en "svart låda" där en del aktiviteter äger rum som översätter ingångar till utgångar. Denna nivå brukar kallas "", det vill säga ett diagram som beskriver sammanhanget i företagets verksamhet. Dessutom visar kontextdiagrammet de viktigaste egenskaperna för hela modellen.

  1. Målet är en specifik formulering av modellens syfte, genom vilken modellens konstruktion kan kontrolleras i framtiden.
  2. Synvinkel - på vars ansikte modellen är byggd, eftersom modellen alltid är beroende av dess författare och fokus av uppmärksamhet. Om vi ​​bygger en allmän modell av ett företag, presenteras det vanligtvis från dess chefs synvinkel.
  3. Modelltypen är en indikation på vilken information som visas på diagrammen. Det kan finnas två huvudalternativ: SOM ÄR ("som det är") eller ATT VARA ("som det kommer att vara"). Denna separation är nödvändig, eftersom vi kan bygga modeller både för analys av aktiviteter och för att transformera dem. Vi måste vara klart medvetna om vad vi gör och även förmedla denna information till andra.

Således innehåller kontextdiagrammet i den mest generaliserade formen en beskrivning av företagets verksamhet, som genomsyras av flöden som förbinder företaget med omvärlden. Jag tycker att vi också borde stanna mer detaljerat på dem.

Huvudströmmar

Erfarenheten har visat att det, trots den enkla och formella verkningen av denna nivå, ofta är nödvändigt att stanna kvar länge, eftersom alla resultat som är viktiga för ägaren och marknaden bör återspeglas här. Ett fel kan leda till skapandet av modeller som inte uppfyller affärsmålen. För att verifiera att betydande flöden återspeglas, se till att alla fyra huvudflödetyper finns i diagrammet.

  1. Material: material och komponenter vid entrén och färdiga produkter vid utgången.
  2. Kund: en potentiell kund som kommer in och en nöjd kund.
  3. Ekonomiskt: vid ingången är det vanligtvis investeringar, kundbetalningar (intäkter), lån och andra intäkter; produktionen är betalningar till leverantörer, skatter, lånebetalningar och vinster.
  4. Informativt: vid ingången är detta alla informationsflöden om den yttre miljön (marknadsförhållanden, konkurrenters beteende, teknisk innovation etc.), och resultatet är det informationsflöde som företaget kommunicerar om sig själv till världen (all reklaminformation, liksom alla typer av rapportering till tillsynsmyndigheter).

Observera att företaget är öppna system, och ingenting uppstår eller försvinner i det. Ett företag kan bara omvandla inkommande flöden till utgående, och om det gör det bra visas ett ytterligare kassaflöde (vinst), vilket på något sätt återspeglar kvaliteten på hela systemet.

(Klicka för att förstora)

Det är bra om du markerar var och en av dessa typer av flöden med din egen färg så att du enkelt kan skilja resursernas rörelse och inte missar viktiga punkter. Till exempel är det ofta möjligt att observera frånvaro av en klient i företagets flöden, därför är arbetet med honom baserat på en överbliven princip - klienten känns ofta som ett hinder för företagets anställda, vars uppgifter är inriktade på att behandla flöde av dokument.

Kontrollpilar kan representeras av endast en typ av flöde - informationsflöde, som kan delas in i 2 underarter. Det första är dokument som:

  • lagar och förordningar;
  • order, order;
  • instruktioner och föreskrifter;
  • planer;
  • konstruktionsdokumentation etc.

Den andra är papperslös information, som oftast innehåller ägarnas krav.

Och slutligen mekanismer - det finns bara två typer av flöden: utrustning (material) och artister (avdelningar och människor). Det kan inte finnas några dokument här, precis som det inte kan finnas några personer på kontrollpilarna!

Modellen tillhandahåller kontinuerlig numrering för navigering. Kontextdiagrammet är numrerat "A-0". I framtiden får varje funktionsblock sitt eget nummer, oavsett hur djup sönderdelningen är.

Sönderfall

Efter att ha räknat ut flödena i kontextdiagrammet kan vi gå vidare till sönderdelning. När vi flyttar till en nivå nedan, som om vi öppnar en "svart låda", ser vi först ett tomt ark med pilar som har fästs på funktionsblocket.

(Klicka för att förstora)

Och här börjar den faktiska funktionella modelleringen - vi måste förstå vilken uppsättning åtgärder som kan ansluta dessa flöden och se till att alla krav är uppfyllda. Svårigheten ligger i det faktum att det finns många åtgärder i företaget, och på diagrammet har vi rätt att visa högst 9 funktioner, annars blir diagrammet oläsligt och följaktligen värdelöst.

Det är inte alltid lätt att ordna komplexa aktiviteter på ett sådant sätt att de förblir visuella, läsbara och samtidigt kompletta. Oftast använder de sig av att dela in hela processen i stora stora block, av vilka de viktigaste är följande.

  1. Skapande av en produkt (resultat).
  2. Marknadsföring och försäljning - arbeta med kundflöde.
  3. Stöd för produktskapande aktiviteter är sekundära processer som är nödvändiga för att följa statliga krav eller för att säkerställa bekvämligheten i arbetet (personal och bokföring, transporttjänster, städning av lokaler etc.).
  4. Skapande av ledningsflöden - aktiviteten att utveckla ledningslösningar som bestämmer kraven för alla processer i företaget.

Figuren nedan visar sönderdelningsdiagrammet i vårt exempel.

(Klicka för att förstora)

I diagrammet bör processerna ordnas diagonalt - detta kallas dominansprincip, vilket innebär att funktionella block placeras från vänster till höger och uppifrån och ner - i viktordning eller i kronologisk ordning. Blocknumreringen är densamma.

Ytterligare arbete med modellen liknar det första steget - varje funktionsblock på den första nivån sönderdelas. Blocknumreringen innehåller numret på den första nivån: A1.1 ... A1n, A2.1 ... A2.n, etc.

Slutsatser om notationens relevans

Inom ramen för denna artikel var det möjligt att bara visa grundbegreppen för IDEF0 -notering med hjälp av ett kort exempel på IDEF0, vilket naturligtvis är svårt att bedöma metodiken som helhet. Men ganska mycket erfarenhet av att använda denna notation i praktiken gör att jag kan dra följande slutsatser.

  1. Modellen har god visualiseringspotential, men enligt min mening är dess större betydelse den disciplinerande effekten. De regler och begränsningar som ingår i metodiken tvingar oss att utveckla en systematisk och strikt inställning till modellerna, vilket har en mycket god effekt på kvaliteten på det slutliga resultatet.
  2. Modellen låter dig bygga kommunikationsflöden mellan till synes inte starkt sammankopplade saker: att ansluta front- och backoffice -undersystemen till management, vilket är mycket värre för andra notationer.
  3. Tillvägagångssättet är enkelt och begripligt för de flesta av projektdeltagarna. Att bygga och läsa diagram i denna notation begränsas endast av viljan att fördjupa sig i affärsflödenas invecklingar.

Några av ovanstående argument får en att tro att detta tillvägagångssätt är det bästa och enda för en komplett modellering av aktiviteter. Men glöm inte att den funktionella modellen endast är utformad för den övre modelleringsnivån. Användningen av IDEF0 -notationen för konstruktion av arbete på artistnivå leder till att diagrammen är rent illustrativa och på grundval av dem är det omöjligt att bygga en vettig reglering, eftersom de inte innehåller:

  • konkretisera händelserna för att starta och stoppa processen;
  • förutsättningar för övergången från en åtgärd till en annan;
  • möjligheten att visuellt visa alla resurser och artister utan att överbelasta diagrammet med pilar.

Därför, om du använder den här notationen för de uppgifter som den är avsedd för (strukturera aktiviteten på högsta nivå), är IDEF0 praktiskt taget den enda notationen för idag som gör att du kan göra detta meningsfullt och exakt.

V projektledning denna modelleringsstandard är mest tillämplig där du behöver länka olika projekt eller processer med visuella flöden. Samtidigt kommer den grafiska modellen att göra det möjligt att mer rationellt fördela ansvar och resurser på uppgifter. Logiken i projektets uppgifter, som återspeglas i diagrammen, hjälper till att förbereda en bättre kvalitet kalenderplan i form av ett Gantt -diagram.

Lär dig att se och förstå ditt företags funktionella struktur!

För närvarande, i Ryssland, har intresset för de allmänt accepterade ledningsstandarderna i väst ökat kraftigt, men i verklig förvaltningspraxis finns det ett mycket vägledande ögonblick. Många ledare kan fortfarande förbluffas av den direkta frågan om organisationsstruktur företag eller om upplägget för befintliga affärsprocesser. De mest avancerade cheferna som regelbundet läser ekonomiska tidskrifter börjar som regel rita hierarkiska diagram som bara är begripliga för dem, men i denna process kommer de vanligtvis snabbt till en återvändsgränd. Detsamma gäller anställda och chefer för olika tjänster och funktionella enheter. I de flesta fall är den enda uppsättning regler som anges i enlighet med vilka ett företag ska fungera en uppsättning individuella bestämmelser och Arbetsbeskrivningar... Oftast upprättades dessa dokument för mer än ett år sedan, är dåligt strukturerade och inte sammankopplade och samlar som ett resultat helt enkelt damm på hyllorna. För närvarande var ett sådant tillvägagångssätt motiverat, eftersom begreppet konkurrens praktiskt taget saknades under bildandet av den ryska marknadsekonomin och det inte fanns något särskilt behov av att överväga kostnader - vinsten var gigantisk. Som ett resultat har vi under de senaste två åren sett en ganska begriplig bild: stora företag som växte i början av 90 -talet tappar gradvis sina positioner fram till deras fullständiga utträde från marknaden. Detta beror delvis på att företaget inte implementerade ledningsstandarder, konceptet med en funktionell modell för aktivitet och uppdrag var helt frånvarande. Med hjälp av modellering av olika verksamhetsområden är det möjligt att effektivt analysera flaskhalsar i ledningen och optimera det övergripande affärssystemet. Men, som du vet, i alla företag är det bara de projekt som direkt ger vinst är högst prioritet, därför är det vanligtvis bara under en påtaglig kris i företagets ledning som vi talar om undersökningen av aktiviteter och dess omorganisering.

I slutet av 90 -talet, när marknaden var tillräckligt konkurrenskraftig och företagens lönsamhet började minska kraftigt, kände chefer enorma svårigheter att försöka optimera kostnaderna så att produkterna förblev både lönsamma och konkurrenskraftiga. Det var vid detta ögonblick som behovet av att ha framför dig en modell av företagets verksamhet som skulle återspegla alla mekanismer och principer för sammankoppling av olika delsystem inom ramen för ett företag tydligt uppenbarades.

Själva begreppet "modellering av affärsprocesser" kom in i de flesta analytikers vardag samtidigt som komplexet uppträdde på marknaden programvaruprodukter utformad för komplex automatisering av företagsledning. Sådana system innebär alltid en djup förprojektundersökning av företagets verksamhet. Resultatet av denna undersökning är ett expertutlåtande, där rekommendationer för eliminering görs av separata punkter. " flaskhalsar”I ledningen av verksamheten. På grundval av denna slutsats, omedelbart före implementeringen av automatiseringssystemet, genomförs den så kallade omorganisationen av affärsprocesser, ibland ganska allvarlig och smärtsam för företaget. Detta, och naturligtvis, ett team som har utvecklats genom åren är alltid svårt att tvinga "att tänka på ett nytt sätt". Sådana komplexa undersökningar av företag är alltid komplexa och mycket olika uppgifter från fall till fall. Det finns väl beprövade metoder och standarder för att lösa sådana problem med modellering av komplexa system. Dessa standarder inkluderar metoderna för IDEF -familjen. Med deras hjälp är det möjligt att effektivt visa och analysera modellerna för aktiviteten hos ett brett spektrum av komplexa system i olika sektioner. Samtidigt bestäms bredden och djupet av undersökningen av processerna i systemet av utvecklaren själv, vilket gör det möjligt att inte överbelasta den skapade modellen med onödiga data. V för närvarande följande standarder kan tillskrivas IDEF -familjen:

IDEF0 är en funktionell modelleringsmetodik. Med hjälp av det visuella grafiska språket IDEF0 visas systemet som studeras för utvecklare och analytiker i form av en uppsättning sammanhängande funktioner (funktionsblock - i termer av IDEF0). Typiskt är IDEF0 -modellering det första steget i att lära sig om något system;

IDEF1 - en metod för modellering av informationsflöden i systemet, som låter dig visa och analysera deras struktur och relationer;

IDEF1X (IDEF1 Extended) är en metod för att bygga relationsstrukturer. IDEF1X tillhör typen av metoder "Entity-relation" (ER-Entity-Relation) och används som regel för att modellera relationsdatabaser relaterade till systemet i fråga;

IDEF2 är en metod för dynamisk modellering av systemutveckling. På grund av de mycket allvarliga svårigheterna att analysera dynamiska system övergavs denna standard praktiskt taget och dess utveckling avbröts i det allra första skedet. För närvarande finns det dock algoritmer och deras datorimplementeringar som gör det möjligt att omvandla en uppsättning statiska IDEF0 -diagram till dynamiska modeller baserade på ”färgade petrinappar” (CPN - Color Petri Nets);

IDEF3 är en metod för att dokumentera de processer som förekommer i systemet, som till exempel används för att studera tekniska processer i företag. IDEF3 beskriver scenariot och arbetsflödet för varje process. IDEF3 har ett direkt samband med IDEF0 -metoden - varje funktion (funktionsblock) kan representeras som en separat process med hjälp av IDEF3;

IDEF4 är en metod för att bygga objektorienterade system. IDEF4-verktyg låter dig visuellt visa strukturen för objekt och de underliggande principerna för deras interaktion, vilket gör att du kan analysera och optimera komplexa objektorienterade system;

IDEF5 är en metod för ontologisk studie av komplexa system. Med hjälp av IDEF5 -metoden kan ett systems ontologi beskrivas med hjälp av ett specifikt ordförråd med termer och regler, på grundval av vilka tillförlitliga uttalanden om tillståndet i systemet som övervägs vid en viss tidpunkt kan bildas. Baserat på dessa påståenden dras slutsatser om ytterligare utveckling systemet och dess optimering utförs.
I den här artikeln kommer vi att titta på den mest använda funktionella modelleringsmetoden IDEF0.

Historien om IDEF0 -standarden

IDEF0-metoden kan betraktas som nästa steg i utvecklingen av det välkända grafiska språket för att beskriva funktionella system SADT (Structured Analysis and Design Teqnique). För flera år sedan publicerades en liten upplaga av boken med samma namn i Ryssland, som ägnades åt att beskriva de grundläggande principerna för att konstruera SADT -diagram. Historiskt sett utvecklades IDEF0 som standard 1981 som en del av ett omfattande automatiseringsprogram industriföretag, som bar beteckningen ICAM (Integrated Computer Aided Manufacturing) och föreslogs av US Air Force. IDEF -familjen av standarder själv ärvde sin beteckning från namnet på detta program (IDEF = ICAM DEFinition). I processen med praktisk implementering mötte deltagarna i ICAM -programmet behovet av att utveckla nya metoder för att analysera interaktionsprocesser i industrisystem. Samtidigt, förutom en förbättrad uppsättning funktioner för beskrivning av affärsprocesser, var ett av kraven för den nya standarden tillgången på en effektiv metod för interaktion inom ramen för ”analytiker-specialist”. Med andra ord var den nya metoden tänkt att ge grupparbete om skapandet av modellen, med direkt deltagande av alla analytiker och specialister som är involverade i projektet.

Som ett resultat av sökandet efter lämpliga lösningar föddes IDEF0 funktionell modelleringsmetodik. Sedan 1981 har IDEF0 -standarden genomgått flera mindre förändringar, mestadels av begränsande karaktär, och den senaste revisionen släpptes i december 1993 av US National Institute for Standards and Technology (NIST).

Grundläggande element och begrepp för IDEF0

Det grafiska språket IDEF0 är förvånansvärt enkelt och harmoniskt. Metoden bygger på fyra huvudbegrepp.

Det första är konceptet med en Aktivitetslåda. Ett funktionsblock visas grafiskt i form av en rektangel (se fig. 1) och personifierar någon specifik funktion inom ramen för det system som övervägs. Enligt kraven i standarden måste namnet på varje funktionsblock formuleras i verbstämning (till exempel "producera tjänster", inte "produktion av tjänster").

Var och en av de fyra sidorna av ett funktionsblock har sin egen specifika betydelse (roll), medan:

  • Den övre sidan är Control;
  • Den vänstra sidan är inställd på "Inmatning";
  • Höger sida är inställd på “Output”;
  • Undersidan är "Mekanism".

    • Varje funktionsblock inom ramen för ett enda övervägt system måste ha sitt eget unika identifieringsnummer.

    Figur 1. Funktionsblock.

    Den andra "valen" i IDEF0 -metoden är konceptet med en gränssnittsbåge (pil). Gränssnittsbågar kallas också ofta strömmar eller pilar. Gränssnittsbågen visar ett systemelement som bearbetas av ett funktionsblock eller på annat sätt påverkar funktionen som visas av detta funktionsblock.

    Den grafiska visningen av gränssnittsbågen är en enriktad pil. Varje gränssnittsbåge måste ha sitt eget unika namn (piletikett). Som krävs av standarden måste namnet vara en substantivomsättning.

    Med hjälp av gränssnittsbågar visas olika objekt som i en eller annan grad bestämmer processerna som sker i systemet. Sådana objekt kan vara element i den verkliga världen (delar, bilar, anställda, etc.) eller dataströmmar och information (dokument, data, instruktioner etc.).

    Beroende på vilken av sidorna som denna gränssnittsbåge är lämplig för kallas den "inbound", "outbound" eller "control". Dessutom kan endast funktionella block vara "källan" (början) och "sjunka" (slutet) för varje funktionsbåge, medan "källan" bara kan vara utgångssidan av blocket och "sjunken" kan vara valfri av de tre återstående.

    Det bör noteras att varje funktionsblock, enligt kraven i standarden, måste ha minst en styrgränssnittsbåge och en utgående. Detta är förståeligt - varje process måste följa vissa regler (visas av kontrollbågen) och måste ge något resultat (utgående båge), annars är det ingen mening att överväga det.

    När man konstruerar IDEF0 - diagram är det viktigt att korrekt skilja de inkommande gränssnittsbågarna från kontrollerna, vilket ofta inte är lätt. Till exempel visar figur 2 funktionsblocket ”Process arbetsstycke”.

    I en verklig process får arbetaren som utför behandlingen ett arbetsstycke och tekniska instruktioner för bearbetning (eller säkerhetsregler vid arbete med maskinen). Det kan vara ett misstag att tro att både arbetsstycket och dokumentet med tekniska instruktioner är inkommande objekt, men så är det inte. Faktum är att i denna process bearbetas arbetsstycket enligt reglerna som återspeglas i de tekniska instruktionerna, som bör visas av kontrollgränssnittets båge.


    Figur 2.

    En annan sak är när tekniska instruktioner bearbetas av chefsteknologen och ändringar görs i dem (bild 3). I detta fall visas de som en redan inkommande gränssnittsbåge, och kontrollobjektet är till exempel nya industriella standarder, baserade på vilka dessa ändringar görs.


    Figur 3.

    Ovanstående exempel betonar den till synes liknande karaktären hos inkommande och utgående gränssnittsbågar, men det finns alltid vissa skillnader för system av samma klass. Till exempel, när det gäller att överväga företag och organisationer, finns det fem huvudtyper av objekt: materialflöden (delar, varor, råvaror etc.), finansiella flöden (kontanter och icke-kontanter, investeringar, etc.), dokument flöden (kommersiella, finansiella och organisatoriska dokument), informationsflöden (information, avsiktsdata, muntliga instruktioner etc.) och resurser (anställda, maskiner, maskiner etc.). I detta fall, i olika fall, kan alla typer av objekt visas med inkommande och utgående gränssnittsbågar, som endast styr de som är relaterade till flöden av dokument och information, och endast resurser kan visas med bågmekanismer.

    Den obligatoriska förekomsten av kontrollgränssnittsbågar är en av de viktigaste skillnaderna i IDEF0 -standarden från andra metoder i DFD (Data Flow Diagram) och WFD (Work Flow Diagram) klasser.

    Det tredje grundbegreppet för IDEF0 -standarden är sönderdelning. Nedbrytningsprincipen används när en komplex process bryts ner i dess beståndsdelar. I det här fallet bestäms detaljnivån för processen direkt av modellutvecklaren.

    Nedbrytning låter dig gradvis och strukturerad representera systemmodellen i form av en hierarkisk struktur av enskilda diagram, vilket gör den mindre överbelastad och lättsmält.

    IDEF0 -modellen börjar alltid med presentationen av systemet som helhet - ett enda funktionellt block med gränssnittsbågar som sträcker sig utanför det övervägda området. Ett sådant diagram med ett funktionsblock kallas ett kontextdiagram och betecknas med identifieraren "A-0".

    Den förklarande texten för sammanhangsdiagrammet måste ange syftet med att bygga diagrammet i form av en kort beskrivning och fixa synvinkeln (Viewpoint).

    Definiera och formalisera utvecklingsmålet för IDEF0 - modellen är extremt viktig poäng... Faktum är att målet identifierar de relevanta områdena i systemet som studeras som först bör fokuseras på. Till exempel, om vi modellerar ett företags verksamhet för att bygga ett informationssystem utifrån denna modell i framtiden, så kommer denna modell att skilja sig väsentligt från den som vi skulle utveckla för samma företag, men med syftet optimera leveranskedjor.

    Synspunkten definierar modellens huvudsakliga utvecklingsriktning och detaljnivån som krävs. En tydlig fixering av synvinkel gör att du kan ladda ur modellen, vägra att detaljera och studera enskilda element som inte är nödvändiga, baserat på den valda synvinkel på systemet. Till exempel kommer samma företags funktionella modeller ur chefsteknologens och finansdirektörens synvinkel att skilja sig avsevärt åt i detaljriktningen. Detta beror på att CFO i slutändan inte är intresserad av aspekterna av bearbetning av råvaror på produktionsmaskiner och chefsteknologen inte behöver ritade diagram. ekonomiska flöden... Rätt val av synvinkel minskar avsevärt den tid det tar att bygga den slutliga modellen.

    I nedbrytningsprocessen borras funktionsblocket, som i kontextdiagrammet visar systemet som helhet, i ett annat diagram. Det resulterande diagrammet för den andra nivån innehåller funktionsblock som visar de huvudsakliga underfunktionerna i funktionsblocket i kontextdiagrammet och kallas ett barndiagram i förhållande till det (var och en av de funktionsblock som tillhör barndiagrammet kallas respektive en barnlåda ). I sin tur kallas det överordnade funktionsblocket förälderblocket i förhållande till barndiagrammet (överordnad låda), och diagrammet som det tillhör kallas förälderdiagrammet (förälderdiagram). Var och en av underfunktionerna i barndiagrammet kan ytterligare detaljeras genom en liknande sönderdelning av motsvarande funktionsblock. Det är viktigt att notera att i varje fall av sönderdelning av ett funktionsblock är alla gränssnittsbågar som ingår i detta block eller utgående från det fixerade i barndiagrammet. Detta uppnår IDEF0 -modellens strukturella integritet. Nedbrytningsprincipen visas tydligt i figur 4. Du bör vara uppmärksam på förhållandet mellan numreringen av funktionella block och diagram - varje block har sitt eget unika serienummer på diagrammet (siffran i rektangelns nedre högra hörn) , och beteckningen i rätt vinkel indikerar numret på barndiagrammet för detta block ... Frånvaron av denna beteckning innebär att det inte finns någon sönderdelning för detta block.

    Det finns ofta fall där enskilda gränssnittsbågar inte är meningsfulla att fortsätta beaktas i barnscheman under en viss nivå i hierarkin, eller vice versa - enskilda bågar har ingen praktisk betydelse över en viss nivå. Till exempel en gränssnittsbåge som visar en "detalj" vid ingången till funktionsblocket "Process on svarv”Det är inte vettigt att reflektera över diagrammen över högre nivåer - det kommer bara att överbelasta diagrammen och göra dem svåra att förstå. Å andra sidan finns det ett behov av att bli av med separata "konceptuella" gränssnittsbågar och inte detaljera dem djupare än en viss nivå. För att lösa sådana problem föreskriver IDEF0 -standarden begreppet tunneldragning. Arbetstunnelbeteckningen i form av två parenteser runt början av gränssnittsbågen anger att denna båge inte ärvdes från det funktionella överordnade blocket och visades (från "tunneln") endast i detta diagram. I sin tur betyder samma beteckning runt änden (pilen) av gränssnittsbågen i omedelbar närhet av mottagarblocket det faktum att denna barns båge inte kommer att visas och inte kommer att beaktas i barndiagrammet för detta block. Oftast händer det att enskilda objekt och deras motsvarande gränssnittsbågar inte beaktas på vissa mellannivåer i hierarkin - i det här fallet "störtar de in i tunneln" och sedan, om det behövs, "återvänder från tunneln".

    Det slutliga konceptet i IDEF0 är ordlistan. För vart och ett av IDEF0 -elementen: diagram, funktionsblock, gränssnittsbågar, innebär den befintliga standarden skapande och underhåll av en uppsättning relevanta definitioner, nyckelord, berättelser etc. som kännetecknar objektet som visas av detta element. Denna uppsättning kallas en ordlista och är en beskrivning av essensen i detta element. Till exempel, för en kontrollgränssnittsbåge "betalningsorder", kan ordlistan innehålla en lista över fält i dokumentet som motsvarar bågen, den obligatoriska uppsättningen visum etc. Ordlistan kompletterar harmoniskt det grafiska språket och ger diagrammen nödvändig ytterligare information.


    Figur 4. Sönderdelning av funktionella block.

    Principer för att begränsa komplexiteten i IDEF0 -diagram

    Normalt bär IDEF0 -modeller komplex och koncentrerad information, och för att begränsa deras trängsel och göra dem läsbara antas motsvarande komplexitetsgränser i motsvarande standard:

    Begränsa antalet funktionella block i diagrammet till tre till sex. Den övre gränsen (sex) tvingar designern att använda hierarkier när de beskriver komplexa objekt, och den nedre gränsen (tre) säkerställer att det finns tillräckligt med detaljer på motsvarande diagram för att motivera dess skapande;

    Begränsa antalet gränssnittsbågar som är lämpliga för ett funktionsblock (lämnar ett funktionsblock) till fyra.
    Naturligtvis är det inte alls nödvändigt att strikt följa dessa begränsningar, men som erfarenhet visar är de mycket praktiska i verkligt arbete.

    Disciplin för grupparbete kring utvecklingen av IDEF0-modellen

    IDEF0 -standarden innehåller en uppsättning procedurer som gör att en stor grupp människor från olika delar av det modellerade systemet kan utveckla och komma överens om en modell. Vanligtvis är utvecklingsprocessen iterativ och består av följande villkorliga steg:

    Skapande av en modell av en grupp specialister relaterade till olika områden i företaget. Denna grupp kallas Authors i termer av IDEF0. Att bygga en initial modell är en dynamisk process under vilken författare frågar kompetenta personer om strukturen i olika processer. Baserat på befintliga bestämmelser, dokument och undersökningsresultat skapas ett modellutkast av modellen.

    Fördelning av utkastet för granskning, godkännande och kommentarer. I detta skede diskuteras modellen med ett brett spektrum av kompetenta personer (när det gäller IDEF0 -läsare) i företaget. Samtidigt kritiseras och kommenteras var och en av diagrammen för utkastsmodellen skriftligt och överförs sedan till författaren. Författaren instämmer i sin tur också skriftligt i kritiken eller avvisar den, redogör för logik i beslutsfattandet och returnerar det reviderade utkastet för vidare behandling. Denna cykel fortsätter tills författarna och läsarna kommer överens.

    Modellgodkännande. Den godkända modellen godkänns av arbetsgruppens chef om modellförfattarna och läsarna inte har några meningsskiljaktigheter om dess lämplighet. Den slutliga modellen är en konsekvent syn på företaget (systemet) från en given synvinkel och för ett givet syfte.
    Synligheten av det IDEF0 grafiska språket gör modellen ganska läsbar för dem som inte deltog i projektet för dess skapande, liksom effektiv för att hålla shower och presentationer. I framtiden, på grundval av den konstruerade modellen, kan nya projekt organiseras för att göra ändringar i företaget (i systemet).

    Funktioner i den nationella praxisen att använda funktionell modellering med hjälp av IDEF0

    V senaste åren intresset för IDEF -familjens metoder ökar stadigt i Ryssland. Jag observerar detta hela tiden och tittar på statistiken över samtal till min personliga webbsida (http://www.vernikov.ru), som kort beskriver de grundläggande principerna för dessa standarder. Samtidigt skulle jag kalla intresse för sådana standarder som IDEF3-5 teoretiska och för IDEF0 ganska praktiskt motiverade. Faktum är att de första Case-verktygen för att bygga DFD- och IDEF0-diagram dök upp på den ryska marknaden redan 1996, samtidigt som den populära boken om modelleringsprinciperna i SADT-standarderna släpptes.

    De flesta chefer betraktar dock fortfarande den praktiska tillämpningen av modellering i IDEF -standarder som ett modeuttalande snarare än en effektiv optimeringsväg. det befintliga systemet företagsledning. Mest troligt beror detta på en uttalad brist på information om den praktiska tillämpningen av dessa metoder och med den oumbärliga mjukvarubiasen hos de allra flesta publikationer.

    Det är ingen hemlighet att nästan alla projekt för undersökning och analys av finansiella och ekonomisk aktivitet företag som nu är i Ryssland är på ett eller annat sätt associerade med konstruktion av automatiska styrsystem. På grund av detta har IDEF -standarderna, i majoritetsförståelse, blivit villkorligt oskiljaktiga från implementeringen av informationsteknik, även om det med deras hjälp ibland är möjligt att effektivt lösa även små lokala problem, bokstavligen med hjälp av en penna och papper.

    När du genomför komplexa företagsundersökningsprojekt låter utvecklingen av modeller i IDEF0 -standarden dig visuellt och effektivt visa hela mekanismen för företagsaktivitet i önskat sammanhang. Viktigast är dock det samarbete som IDEF0 tillhandahåller. I min praxis fanns det en hel del fall då konstruktionen av modellen utfördes med direkt hjälp av anställda på olika avdelningar. Samtidigt förklarade konsulten på ganska kort tid för dem de grundläggande principerna för IDEF0 och lärde dem att arbeta med motsvarande tillämpade programvara... Som ett resultat skapade anställda på olika avdelningar IDEF -diagram över deras funktionella enhets aktiviteter, som skulle svara på följande frågor:

    Vad går till enheten "vid ingången"?

    Vilka funktioner och i vilken sekvens utförs inom enheten?

    Vem är ansvarig för var och en av funktionerna?

    Vad styr exekutören av när varje funktion utförs?

    Vad är resultatet av enhetens arbete (output)?

    Efter att ha kommit överens om utkast till diagram inom varje specifik avdelning, sammanställs de av konsulten till en utkast till företagsmodell, där alla ingångs- och utmatningselement är länkade. I detta skede registreras alla avvikelser mellan enskilda diagram och deras kontroversiella platser. Vidare passerar denna modell igen genom de funktionella avdelningarna för ytterligare samordning och nödvändiga justeringar. Som ett resultat, på en ganska kort tid och med inblandning av ett minimum av personalresurser från ett konsultföretag (och dessa resurser, som du vet, är mycket dyra), erhålls en IDEF0-modell av ett företag enligt " Som det är ”-principen, och, vilket är viktigt, representerar det ett företag med positioner för anställda som arbetar i det och grundligt känner till alla nyanser, inklusive informella. I framtiden kommer denna modell att överföras för analys och bearbetning till affärsanalytiker som kommer att leta efter flaskhalsar i företagsledningen och optimera viktiga processer, vilket omvandlar "Som är" -modellen till motsvarande "Som borde vara" -vy. Baserat på dessa förändringar görs en slutlig slutsats, som innehåller rekommendationer för omorganisation av ledningssystemet.

    Naturligtvis kräver ett sådant tillvägagångssätt ett antal organisatoriska åtgärder, främst från ledningen av det undersökta företaget. Detta beror på att denna teknik innebär att vissa anställda tilldelas ytterligare ansvar om utveckling och praktisk tillämpning av nya metoder. Men i slutändan lönar det sig, eftersom ytterligare en eller två timmars arbete för enskilda anställda under flera dagar kan avsevärt spara pengar på att betala för konsulttjänster till ett tredjepartsföretag (vilket i alla fall kommer att riva av arbetet av samma anställda med frågeformulär och frågor). När det gäller företagets anställda själva, på ett eller annat sätt, har jag inte mött något uttalat motstånd från deras sida.

    Slutsatsen av allt detta kan göras enligt följande: det är inte alls nödvändigt att komma med lösningar för standardproblem varje gång. Närhelst du ställs inför behovet av att analysera ett visst funktionellt system (från ett rymdfarkostdesignsystem till processen att förbereda en komplex middag), använd metoder som har testats och testats genom åren. En av dessa metoder är IDEF0, som låter dig lösa komplexa livsproblem med hjälp av sina enkla och begripliga verktyg.

    IDEF0 -diagram är byggda med BPWin -programmet. De är avsedda för grafisk modellering av pågående affärsprocesser.

    Om IDEF0 metodik

    IDEF0-metoden används i stor utsträckning på grund av dess enkla och lättförståliga grafiska notation, vilket är mycket bekvämt för att bygga en modell. Huvudplatsen i metodiken ges till diagram. Diagrammen visar systemets funktioner med hjälp av geometriska rektanglar, liksom befintliga anslutningar mellan funktioner och den yttre miljön. Länkar visas med pilar. Du kan verifiera detta genom att se vad IDEF0 -diagrammet erbjuder, exempel på som finns i den här artikeln.

    Det faktum att endast två grafiska primitiver används i modellering gör att du snabbt kan förklara de nuvarande reglerna för IDEF0 -interaktioner för de människor som inte har någon aning om det. Med IDEF0 -diagram utförs kundens koppling till de pågående processerna snabbare tack vare användningen av ett visuellt grafiskt språk. Du kan se vad IDEF0 -diagrammet erbjuder, exempel på som presenteras nedan.

    Element som används för IDEF0

    Som redan nämnts används 2 typer av geometriska primitiv: rektanglar och pilar. Rektanglar representerar vissa processer, funktioner, arbete eller uppgifter som har mål och leder till det angivna resultatet. Interaktionen mellan processer med varandra och den yttre miljön indikeras med pilar. IDEF0 skiljer 5 olika typer av pilar.


    Möjligheter att använda IDEF0

    IDEF0 -metoden kan tillämpas för att beskriva den funktionella aspekten av alla informationssystem.


    Typer av länkar mellan IDEF0 -processer

    Det ligger i modellens intresse att skapa sådana förbindelser av strukturer så att interna förbindelser är så starka som möjligt och externa - så svaga som möjligt. den stark sida modellering med IDEF0. Du kan se exempel på diagram för dig själv och vara övertygad om riktigheten i dessa ord. För att underlätta upprättandet av anslutningar ansluts dessa till moduler. Externa länkar upprättas mellan modulerna och interna länkar etableras inuti modulerna. Det finns flera typer av länkar.

    1. Hierarkisk ("del" - "hel") relation.

    2. Chef (reglerande, underordnad):

    2) feedbackkontroll.

    3. Funktionellt eller tekniskt:

    2) omvänd ingång.

    3) konsument;

    4) logiskt;

    5) metodisk eller kollegial;

    6) resurs;

    7) informativ;

    8) tillfällig;

    9) slumpmässigt.

    Byggstenar och länkar i diagram

    IDEF0 -metoden ger ett antal regler och riktlinjer för dess användning och förbättring av kvaliteten. Så diagrammet visar ett block där du kan ange namnet på systemet, dess syfte. 2-5 pilar leder till eller från blocket. Mer eller mindre kan vara möjligt, men minst två pilar behövs för att komma in / ut och resten för extra arbete och deras indikationer i diagrammet. Om pilarna är fler än 5, bör du tänka på hur optimalt det är att bygga modellen och om det är möjligt att göra den ännu mer detaljerad.

    Byggstenar i sönderdelningsdiagram

    Antalet block som kommer att finnas på ett diagram rekommenderas i antalet 3-6. Om det finns färre av dem, är det osannolikt att sådana diagram bär en semantisk belastning. Om antalet block är stort kommer det att vara mycket svårt att läsa ett sådant diagram, med tanke på närvaron av ytterligare pilar. För att förbättra uppfattningen av information rekommenderas att placera block uppifrån och ner och från vänster till höger. Detta arrangemang återspeglar logiken i utförandet av processekvensen. Och även pilar kommer att skapa mindre förvirring, med ett minsta antal korsningar med varandra.

    Om lanseringen av en viss funktion inte styrs på något sätt, och processen kan startas vid ett godtyckligt ögonblick, indikeras en sådan situation av frånvaron av pilar som indikerar kontroll och inmatning. Men närvaron av en sådan situation kan berätta för potentiella partners om en viss instabilitet och behovet av att titta närmare på den potentiella partnern.

    Ett block som bara har en ingångspil indikerar att processen mottar ingångsparametrar, men ingen kontroll eller justering sker vid körning. Ett block som bara har en kontrollpil används för att ange jobb som endast anropas efter särskild ordning i styrsystemet. De kontrolleras och justeras i alla sina skeden.

    Men ett exempel på att bygga ett IDEF0 -diagram kan övertyga att den mest fullständiga och omfattande typen är diagrammet med inmatnings- och kontrollpilar.

    Namngivning

    För att förbättra den visuella upplevelsen bör varje block och varje pil ha sitt eget namn, vilket gör att du kan identifiera dem bland många andra block och pilar. Så här ser provdiagrammen ut i IDEF0. Informationssystem, byggd med hjälp av dem, låter dig förstå alla brister och komplexitet i modellerna.

    Sammanfogade pilar används ofta och frågor uppstår om deras namn. Men sammanslagning är endast möjlig vid överföring av homogen data, så separata namn behövs inte, även om de kan specificeras i BPWin. Om det finns en avvikelse mellan pilarna kan de namnges separat för att förstå vad som är ansvarigt för vad.

    Om det inte finns något namn efter grenen, anses namnet vara exakt som det var före grenen. Detta kan vara fallet om två block kräver samma information. IDEF0 -kontextdiagrammet, ett exempel som finns i den här artikeln, kommer att bekräfta dessa ord.

    Pilinformation

    Pilar som går in och lämnar samma block när du bygger ett kompositionsdiagram bör visas på det. Namnen på de geometriska former som överförs till diagrammet måste exakt upprepa informationen från den högsta nivån. Om två pilar är parallella i förhållande till den andras bågar (dvs de börjar vid kanten av en process och slutar båda vid ena kanten av den andra processen), kanske de ska kombineras för att optimera modellen och välja ett lämpligt namn, vilket visas perfekt i IDEF0 (exempel på diagram i Visio kan ses).

    Ett exempel på implementering av IDEF0 -metoden på en specifik modell

    Du har redan lärt dig vad ett IDEF0 -diagram är, du har delvis sett exempel och regler för att konstruera sådana diagram. Nu ska vi vända oss till träningen. För en bättre förståelse kommer förklaringen inte att baseras på någon "allmän" modell, utan på ett specifikt exempel som gör att du bättre och mer fullt ut kan förstå funktionerna i att arbeta med IDEF0 i BPWin -programmet.

    Som ett exempel, tågets hastighet från punkt A till punkt B. Det bör beaktas att tåget inte kan utvecklas mer än den tillåtna hastigheten. Denna linje etableras på grundval av driftserfarenhet och tågens inflytande på järnvägsspåret. Det bör förstås att syftet med tåget är att leverera passagerare, som i sin tur betalade för att säkert och bekvämt nå sitt mål. Ett IDEF0 -diagram är till hjälp, exempel på detta finns i den här artikeln.

    Den första informationen är:

    1. spårledningsdata;
    2. pass på hela sträckan;
    3. vägplan.

    Kontrolldata:

    1. Chefen, chefen för spårtjänsten.
    2. Information om det befintliga flödet av tågrörelser.
    3. Information om planerade reparationer, rekonstruktion och byte av spår.

    Resultatet av modellen är:

    1. Begränsning av tillåtna hastigheter med angivande av orsaken till begränsningen.
    2. Tillåtna hastigheter vid körning på separata punkter och under tågkörning.

    När kontextdiagrammet är byggt måste det vara detaljerat och sedan skapas det sammansatta diagrammet, vilket blir det första nivådiagrammet. Det kommer att visa alla systemets huvudfunktioner. IDEF0 -metoden och diagrammet för vilket sönderdelningen görs kallas föräldern. IDEF0 -sönderdelningen kallas en barns sönderdelning.

    Slutsats

    Efter sönderdelningen på den första nivån utförs sönderdelningen av den andra nivån - och så vidare tills ytterligare sönderdelning förlorar sin mening. Allt detta görs för att få det mest detaljerade grafiska diagrammet över pågående och planerade processer. den redo exempel IDEF0 -diagram som du kan navigera med just nu.

    Beskrivning av affärsprocessdiagrammen "Redovisning av företagets datorutrustning"

    Beskrivning av IDEF0 -diagram

    För att bygga en affärsprocess användes ett IDEF0 -diagram. IDEF0 -metoden föreskriver konstruktion av ett hierarkiskt diagramsystem - enstaka beskrivningar av systemfragment. Först utförs en beskrivning av systemet som helhet och dess interaktion med omvärlden (kontextdiagram). Tre nivåer av diagrammet byggdes:

    1. Kontextuell

    2. Funktionell sönderdelning

    Figur 1 - sammanhangsdiagram "Redovisning för företags datorutrustning"

    Figur 1 visar ett kontextdiagram över affärsprocessen "Redovisning för datorutrustning för företag". Det visar systemet som helhet och dess interaktion med de viktigaste externa informationsflödena.

    Pilar anges i sammanhangsdiagrammet.

    Piltyper:

    Ingång (inmatningsmaterial: datorer och tillbehör)

    Output (output är en rapport)

    Kontrollpilar är dokument och chefer

    Mekanismernas pilar är anställda och utrustning

    Inmatningsinformation för bearbetning:

    Datorer - datorer (persondatorer) som finns i företaget

    Komponenter - material som krävs för uppgradering av datorer (grafikkort, moderkort, processorer, fodral, nätaggregat, minnesmoduler)

    Utdataströmmar:

    Rapport - en färdig rapport om redovisning av företagets datorutrustning

    Ingångskontroller:

    Regler - villkor som måste uppfyllas för att nå målet.

    Beställningar - den uppgift som tilldelats företaget (att föra register över datorutrustning på företaget med hjälp av vissa informationssystem)

    Chefer är företagsledare och generaldirektörer.

    Inmatningsresurser:

    PC - datorer med hjälp av vilka redovisning utförs.

    Anställda är specialister som utför instruktioner som tilldelats av ledningen. Efter att ha konstruerat en konceptuell modell genomfördes en funktionell sönderdelning - systemet är uppdelat i delsystem och varje delsystem beskrivs separat (sönderdelningsdiagram).

    Figur 2 visar en funktionell sönderdelning av fyra jobb.


    Figur 2 - Funktionell sönderdelning "Redovisning för datorutrustning för företag"

    Följande typer av arbete identifierades:

    1) Registrering av leveranser - processen där id tilldelas produkten, skickas till lagring, till lagret och information om produkten matas in i programmet.

    Arbetet Registrering av leveranser inkluderar sju gränspilar (ingång, kontroll, mekanism) och en intern pilblad (anslutning vid ingång).

    Pilkommunikation vid ingången mellan verken Registrering av leveranser och underhåll av datorn (datorn);

    In-, ut- och kontrollpilar upprepas i efterföljande arbeten.

    2) Datorunderhåll - processen där montering, reparation och modernisering av datorer sker.

    Datorunderhållsarbetet innehåller fyra gränspilar (ingång, kontroll, mekanism, utgång) och flera interna pilar (ingångskommunikation, ingångsåterkoppling).

    Pilkontroll - regler, order, ledare;

    Pilanslutning vid ingången mellan jobben Datorunderhåll och placering (inmatning av data i databasen), mellan jobben Datorunderhåll och rapportering (inmatning av data i databasen);

    3) Placering - processen i vilken placering av datorer på kontor (kontor) sker.

    Pilar kontroll - regler, order, ledare;

    Pilmekanism - anställda;

    Pillänk på inmatning mellan spridning och rapportering (tilldelning av ett id);

    4) Upprättande av en rapport - det sista steget i redovisningsprocessen, som består av att sammanfatta totalsumma som erhållits genom att utföra tidigare data för den aktuella bokföringen.

    Sedan delas varje delsystem upp i mindre sönderdelningar och så vidare tills önskad detaljgrad uppnås.


    Figur 3 är ett diagram som visar upphandlingsarbetet mer detaljerat.

    Som ett resultat av detaljeringen belystes huvudfunktionerna. Avsnittet "Registrering av leveranser" innehåller sju huvudpilar (in-, utgång, kontroll, mekanism).

    Pilinmatning - datorer och tillbehör;

    Kontrollpilar är regler, order och en ledare. Gaffelpilar;

    Mekanismpilar, förgreningar - PC, anställda;

    Inmatningspilar, kontroll, mekanismer upprepas i alla verk.

    1) Tilldelning av nummer - tilldelning av individuella nummer till datorer och tillbehör.

    Entry pilar - datorer och tillbehör. Pildatorer upprepas i efterföljande verk, med undantag för sammanställningen av rapporten;

    Kontrollpilar - regler, order och ledare;

    Mekanismpilar - PC och anställda;

    Pillänk vid ingången mellan verken Tilldela ett nummer och Skicka varor till lagret (överföring), mellan Tilldela ett nummer och Balansera (gå in i basen);

    2) Skicka varor till lagret - skicka varorna med det tilldelade numret till lagret.

    Avsluta pil - dator;

    Kontrollpilar - regler, order och ledare.

    Pillänk vid ingången mellan verken "Skicka varor till lagret" och "Balansera" (kvantitet);

    3) Balansering - mata in information i en dator.

    Kontrollpilar - regler, order och ledare;

    Mekanismpilar - PC och anställda;


    Figur 4 är ett diagram som beskriver datorunderhåll mer detaljerat.

    Som ett resultat av detaljeringen belystes de viktigaste funktionerna som utfördes i processen för datorunderhåll.

    Datorunderhållsarbetet inkluderar 4 gränspilar (ingång, utgång, kontroll, mekanism). Interna pilar (input feedback, ingångskommunikation).

    1) Montering av datorer - konfiguration av datorer för individuella beställningar av chefer.

    Inloggningspil - datorer;

    Kontrollpilar - regler, order och ledare;

    Mekanismpilar - Anställda;

    Pillänk vid ingången mellan verken: "Montering av datorer" och "Reparation av datorer" (dator);

    2) Datorreparation - montering av datorer godkända för förbättring.

    Inloggningspil - datorer;

    Avsluta pil - inträde i basen;

    Kontrollpilar - regler, order och ledare;

    Mekanismpilar - Anställda;

    Pilar för in-, utgång, kontroll, mekanism förgrenar sig;

    Pillänk vid ingången mellan verken: "Datorreparation" och "Uppgradering" (tillbehör);

    3) Uppgradering - förbättring, förbättring, uppgradering av datorn.

    Avsluta pil - inträde i basen;

    Kontrollpilar - regler, order och ledare;

    Mekanismpilar - Anställda;

    Kontrollpilar, mekanismen förgrenar sig;


    Figur 5 visar rapporteringsschemat mer detaljerat. Arbetets sönderdelning. Rapportering inkluderar 4 gränspilar (ingång, utgång, kontroll, mekanismer). Interna pilar (input feedback, ingångskommunikation).

    Som ett resultat av arbetet härleddes följande funktioner:

    1) Datainsamling - insamling av information för analys och beslutsfattande.

    Ange pil - tilldela id;

    Kontrollpilar - regler, order och ledare;

    Ingångspilar, kontroll, mekanism förgrenar sig;

    Pillänk vid ingången mellan jobb: Datainsamling och datavalidering (poster);

    2) Datakontroll - verifiering av information och skicka den till upprättandet av en rapport.

    Inloggningspil - tilldela ett id, mata in data i databasen;

    Avsluta pil - Rapportera;

    Kontrollpilar - regler, order och ledare;

    Mekanismpilar - Anställda, PC;

    Inmatningspilar (tilldelning av id), kontroll, mekanism gafflar;

    Mata in feedbackpilen från "Datakontroll" till "Datainsamling" (upprepad kontroll).

    Beskrivning av DFD -diagram

    Nedbrytningen av datorunderhållsarbetet Figur 1 definierar fyra interna aktiviteter, två externa enheter och två datalager.


    Figur 1 - Datorunderhåll

    1) Datormontering - processen att montera en dator från befintliga komponenter.

    2) Upprätta en rapport - en process som består i att sammanfatta de slutliga indikatorerna som erhålls genom att utföra arbetet med den löpande bokföringen.

    3) Diagnostik - prestandakontroll

    4) Uppgradering - förbättring, förbättring, uppgradering av datorn.

    Externa enheter: datorer och komponenter

    Datalagrar:

    1) Lager - en plats där sammansatta och uppgraderade datorer lagras.

    2) DB - en databas som lagrar alla rapporter och all information om utfört arbete.

    Vi samlar in information om datorn och väljer komponenter för dess montering. Sedan monterar vi datorn och skickar den till lagret för lagring, men förutom det kan vi först skicka den för diagnostik, kontrollera om den fungerar och sedan bara till lagret. Efter diagnos av den monterade datorn skickar vi data för att sammanställa en rapport om det utförda arbetet och mata in informationen i databasen.

    Vi har också en annan extern enhet, det här är en dator. Vi skickar det för modernisering, varefter det är för diagnostik att kontrollera dess funktionsduglighet, sedan upprättar vi en rapport och anger information om det arbete som utförts i databasen. Eller, efter moderniseringen, skickar vi varorna till lagret, och sedan utför vi diagnostik, upprättar en rapport och skriver in informationen i databasen.

    Arbetsnedbrytningen "Rapportering" Figur 2 definierar tre interna aktiviteter, tre externa enheter och två datalager.

    1) Datainsamling - insamling av information om datorer och komponenter.

    2) Validering - kontroll av data för noggrannhet.

    3) Rapport - skriva en rapport om det utförda arbetet.

    Externa enheter: komponenter, datorer, chef.

    Datalager - Data om datorer och komponenter, rapportdata.


    Samlar in information om datorer och tillbehör och skickar dem sedan till lagring. Därefter kontrollerar vi data för riktighet, upprättar en rapport och skickar tillbaka dem för lagring till det första datalagret (figur 2), eller skickar rapportdata till det andra datalagret (figur 2) och skickar det sedan till chef för verifiering.

    Chefen kontrollerar, gör anteckningar, korrigerar och skickar för återkontroll. Därefter skickas rapporten för lagring tills chefen kontrolleras igen.

    Beskrivning av IDEF3 -diagram

    I arbetsnedbrytningen Datorunderhåll (fig. 1) definieras flera korsningar som förbinder ett eller flera jobb, flera interna jobb.


    1) Reparation - montering av datorn med prefabricerade komponenter

    2) Montering - återställa datorn till det normala

    3) Uppgradering - datoruppgradering

    4) Datorer - en produkt efter montering och modernisering

    5) Skicka till lager - skicka till lagring efter förbättring (montering)

    6) Diagnostik - prestandakontroll.

    7) Rapport - information om utfört arbete.

    Korsningar - Anslutningar:

    1) J2 - alla åtgärder startar samtidigt.

    2) J6 - Confluence Junction. En nod som samlar många pilar i en, vilket indikerar behovet av villkoret för att slutföra arbetskällorna för pilar för att fortsätta processen.

    3) J7 - det visas att dessa villkor inte samtidigt kan uppfyllas.

    4) J9 - dessa åtgärder slutar samtidigt, varefter en rapport upprättas om det utförda arbetet.

    IDEF3 -diagrammet visar att J2 -korsningen har två förgreningspilar för arbete (bygg och uppgradering) som startar samtidigt. Först efter att dessa arbeten har slutförts kommer den färdiga produkten (datorn) ut, ansluter J6 -korsningen. Sedan finns det en anslutning vid korsningen J7, som visar att två jobb (att skicka varor till lagret och diagnostik) inte kan utföras samtidigt. Efter att ha avslutat det tidigare arbetet pågår processen med att upprätta en rapport om arbetet, som är förbunden med korsningen J9.

    Öppna projektet där du vill skapa modellen. Om du inte har skapat några projekt än kan du använda DEMO -projektet, som är tillgängligt direkt efter installation av Cradle, eller skapa ditt eget projekt.

    För att ange DEMO projektanvändning Användarnamn — CHEF, lösenord - MANAGER

    Hur du skapar ditt projekt visas i detalj i den här videon.

    Efter att ha skapat ett nytt projekt kan du också använda för att logga in Användarnamn — MANAGER och lösenord - MANAGER

    Modellskapande

    För att skapa IDEF0 -modellen inkluderar Projektpanel och gå till modellavsnittet Viktig domän

    Notera : På samma sätt kan du skapa modeller i avsnittet Implementation Domain i modelleringen, liksom i alla sektioner som konfigurerats av användaren. Modelleringsdelen är faktiskt ett namnutrymme inom vilket strömmar kan återanvändas.

    För att skapa IDEF0-kontextmodellen, högerklicka på IDEF0-sektionen och välj menyalternativen Nytt-> Element

    Observera att detta är namnet på hela modellen som helhet, inte ett funktionsblock på A0.

    Därefter öppnas ritområdet och du kan börja skapa kontextmodellen.

    Funktionsblock skapas

    För att göra detta, välj funktionsblocksymbolen på paletten

    och klicka en gång på arbetsområdet där du vill skapa funktionsblocket.

    En dialogruta visas där du måste ange namnet på funktionsblocket och klicka sedan på OK.

    Som ett resultat skapas ett funktionsblock med det namn du angav.

    Du kan välja blockets gräns och ändra dess skala

    Skapa strömmar

    För att skapa strömmar, välj en strömmingssymbol från paletten (ingen tunneling eller tunneling)

    klicka sedan på sidan av funktionsblocket från vilket du vill skapa ett flöde och klicka på valfritt område i funktionsblocket

    då visas en dialogruta för att ange namnet på strömmen. Stiga på kort titel strömma och klicka på OK

    Notera: Du kommer att kunna ange en detaljerad beskrivning av strömmen senare i dess specifikation.

    Därefter kan du analogt skapa alla nödvändiga strömmar

    Spara modellen genom att klicka på diskettknappen eller CTRL + S. När du sparar genereras symbolspecifikationer som du kan redigera för att ge en mer detaljerad beskrivning av modellelementen.

    När du har sparat modellen kommer du att kunna se de skapade specifikationerna i projektpanelen i samma avsnitt som du skapade modellen. Två typer av specifikationer kommer att genereras - funktion och flöde.

    Nedbrytning av modellen

    i dialogrutan som visas, lämna standardinställningarna och klicka på OK

    Därefter skapas ett barnschema A1 och alla flöden från diagram A0 överförs till det.

    Nu kan du byta namn på den skapade funktionsblockmallen (med en fråga istället för ett namn) och skapa ytterligare sådana, på samma sätt som vi skapade dem tidigare.

    Om du vill byta namn på ett förinställt funktionsblock väljer du det och väljer Byt namn på snabbmenyn

    och ange önskat namn

    Genom analogi, skapa andra funktionsblock som motsvarar denna nivå av sönderdelning.

    För att skapa flöden mellan dessa funktionella block måste du först klicka på källan, sedan på mellanpunkten för att skapa en böjning och sedan på diskbänken, till exempel så här:

    Resultatet är ett flöde med två böjningar.

    Du kan korrigera böjarnas position genom att välja flödet och dra böjpunkterna till önskad plats

    Titta på videoklippet för att se det dynamiskt

    För att ta bort (eller lägga till) en böjningspunkt, tryck på SKIFT -tangenten på tangentbordet och klicka på den punkt du vill ta bort eller i flödet där du vill skapa den.

    Spara diagrammet och kontrollera att lämpliga specifikationer har genererats

    I analogi kan du sönderdela funktionella block A1.

    Liknande publikationer