Hur man skapar idef0 -diagram. Kursarbete: Utveckla en växthusföretagsmodell med IDEF0, DFD och IDEF3 designmetoder. Sönderdelningsdiagram A3

Ofta uppmanas utvecklare inte bara att identifiera och lösa ett problem i företagets arbete, utan också att avgöra vilken roll det spelar i företagets struktur. För det är mycket viktigare att förstå hur en felaktig enhet interagerar med andra än att bara förstå varför den inte fungerar korrekt. Därför börjar identifiering av eventuella problem med att studera företagets arbete och utarbeta dess funktionella modell.

Ofta uppmanas utvecklare inte bara att identifiera och lösa ett problem i företagets arbete, utan också att avgöra vilken roll det spelar i företagets struktur. För det är mycket viktigare att förstå hur en felaktig enhet interagerar med andra än att bara förstå varför den inte fungerar korrekt. Därför börjar identifieringen av eventuella problem med att studera företagets arbete och utarbeta dess funktionella modell.

Du kommer att säga att chefen ska ha en funktionell modell av företaget, oavsett vilken typ av företag vi pratar om. Men som praktiken visar är denna modell i de flesta fall frånvarande.

Grafisk fördel

Vad är IDEF0 -modeller? Grafiska scheman med sina egna egenskaper och reglerna för deras konstruktion. Varför grafik? För det är effektivt. Detta kan ses i flera exempel.

Låt oss föreställa oss att den militära planen för militära operationer förklarades med ord, och inte med hjälp av kartor med grafiska symboler applicerade på dem. Nu verkar det omöjligt, men fram till andra hälften av 1800 -talet var det precis så. Grafik hjälper till att förstå vad man ska förklara och följaktligen att förstå vad som är svårt nog.

Det är samma sak med affärsprocesser: många tekniska uppdrag kan köras i form av grafiska notationer, vilket kommer att förenkla uppgiften för utvecklare mycket och spara pengar för kunder.

Fördelar med IDEF0 förDEN-specialister

Utvecklarnas aktiviteter, det vill säga till exempel att installera CRM eller skapa ett effektivt ERP, är förknippat med att göra ändringar i ett redan etablerat system. Och för att göra det rätt måste du först studera hur detta system fungerar. Efter att ha studerat det skriver utvecklaren ett kommersiellt förslag där han beskriver sin vision om situationen, de åtgärder som krävs för att lösa problemet, liksom det förväntade resultatet. Ett sådant dokument kan ta mer än ett dussin sidor. Detta är å ena sidan bra, eftersom klienten får maximal information som han är intresserad av. Å andra sidan tar det tid att studera en lång text. framgångsrik affärsman ofta inte.

Så hur är det möjligt att förmedla essensen utan att tillgripa omfattande texter? Grafik! Det är hon som låter dig förkorta det som skrivs och tydligt visa nödvändig information. När allt kommer omkring kan en bild ersätta hundratals ord. Och i förhållande till användningen av grafik för att beskriva affärsprocesser är detta 100% sant.

Låt oss först förstå vad notation och IDEF0 är och vad de är till för.

Notering för att beskriva affärsprocesser: vad är det

Notation är ett format där affärsprocesser representeras i form av grafiska objekt som används i modellering och direkt modelleringsregler. Notation är ett slags grafiskt språk som låter dig representera ett företags funktion, vilket visar sambandet mellan avdelningar och divisioner. Det vill säga att notationen kan betraktas som ett slags programmeringsspråk i business intelligence.

IDEF0 är ...

IDEF0 är en funktionell modelleringsmetod och grafisk notering som används för att beskriva och formalisera affärsprocesser. Det säregna med IDEF0 är att denna metod är inriktad på underordning av objekt. IDEF0 utvecklades för företagsautomatisering redan 1981 i USA.

Funktionell modell för företaget

Den funktionella modellen IDEF0 är block, var och en med flera ingångar och utgångar. Varje block har kontroller och mekanismer som är detaljerade till önskad nivå. Den viktigaste funktionen finns i det övre vänstra hörnet. Den ansluter till resten av pilarna och funktionsblockbeskrivningar. Varje pil eller aktivitet har sin egen betydelse. På grund av detta används en sådan modell för att beskriva alla administrativa och organisatoriska processer.

Piltyper

Inkommande uppgifter ställs in.

Utgående visa resultatet av aktiviteten.

Chefer(pilar uppifrån och ner) är kontrollmekanismer.

Mekanismer(pilar från botten till toppen) används för att utföra det nödvändiga arbetet.

När du arbetar med en funktionell modell antas följande regler. Till exempel namnges pilar med substantiv (regler, plan, etc.), block - med verb (spara poster, ingå ett avtal).

IDEF0 låter dig utbyta information, medan utbytesdeltagarna på grund av dess mångsidighet och synlighet lätt kommer att förstå varandra. IDEF0 har noggrant utvecklats och förbättrats, du kan arbeta med IDEF0 med hjälp av olika verktyg, till exempel ERWIN, VISIO, Bussines studio.

IDEF0 har också en obestridlig fördel. Denna teknik utvecklades relativt länge sedan, och i över tre decennier har den genomgått grundlig slipning och justering. Därför är det möjligt att snabbt och med en minimal sannolikhet för fel skapa en funktionell modell av ett företag.

Naturligtvis finns det andra metoder, så varför rekommenderar vi IDEF0? Du kan skära av en bit metallrör med en bågfil, men du ser att det är mycket lättare att göra detta med en slipmaskin. Så är det med IDEF0: det finns inget mer funktionellt verktyg för modellering, med det kan du enkelt och snabbt få det resultat du behöver.

Hur en funktionell modell skapas

Låt oss analysera skapandet av en funktionell modell med exemplet att skriva en artikel.

Huvudenhet kommer att kallas "artikelskrivning".

Vad som behövs för att skriva en artikel återspeglas i inkommande pilar- "Erfarenhet", "Ytterligare läsning".

Kontrollpilar för att skriva en artikel - "Kontur av artikeln", "Krav för registrering", "Ryska språksregler".

Mekanismer är direkt författaren själv, copywriter, redaktör, programvara. Hur är dessa mekanismer organiserade? Författaren skapar texten genom att spela in dess ljudversion. Textförfattaren överför texten till textformat, med fokus på publiceringsplanen, med beaktande av förlagets krav och reglerna för det ryska språket. Sedan är redaktören kopplad till verket, som kontrollerar artikeln, korrigerar tal-, stavnings- och skiljeteckenfel. Programvara är de program och verktyg som deltagarna i processen använde för att skapa artikeln.

Allt ovanstående är bara ett generellt arbetsschema, så det måste vara detaljerat.

Låt oss gå tillbaka till vår modell och bryta ner det gemensamma blocket i flera relaterade element.

Så hela processen med att skriva en artikel kan delas in i fyra steg:

  1. Förbered en ljudversion.
  2. Förbered tryckt text.
  3. Redigera och förbereda text för utskrift.
  4. Publicering av artikeln.

Diagrammet återspeglar information om vilka kontroller och mekanismer som är inblandade i vilket skede. Till exempel, för att skapa en kvalitetstext, använder författaren sin egen erfarenhet och kunskap, eftersom en guide använder publiceringsplanen och utgivarens krav. Textförfattaren, som skapar en tryckt version av texten, och redaktören, när de korrigerar den, använder reglerna för det ryska språket. För att publicera en artikel, till exempel i en onlinepublikation, krävs speciell programvara.

Vid utarbetandet av en funktionell modell styrs artisten av syftet med dess skapande och hans synvinkel.

Funktionell modellering används effektivt för att fatta olika ledningsbeslut. I vårt exempel på artikelskrivningsprocessen finns det två specialister - en copywriter och en redaktör. Och med den nödvändiga optimeringen av projektfinansiering enligt schemat är det inte svårt att avgöra hur man gör detta. Copywriter och korrekturläsare har liknande arbetsmetoder, så allt arbete kan erbjudas copywriter, eftersom han arbetar direkt med ljudtexten, vilket redaktören inte kan göra. I detta fall kan copywriter erbjudas att göra detta arbete för hälften av det belopp som var avsett för redaktören. Ja, detta kan leda till en förlust av textkvalitet, men optimeringsuppgiften slutfördes framgångsrikt. Och det skulle vara svårare att göra detta utan ett visuellt diagram.

Skapa process för noteringIDEF0

Det finns många program för att skapa anteckningar. Vissa är utformade för att skapa funktionella modeller, medan andra låter dig arbeta med alla grafiska objekt. Och för någon räcker det i ett första skede med ett papper, en penna och ett suddgummi.

Innan vi fortsätter med beskrivningen av företagets arbete, det vill säga direkt till skapandet av notering av affärsprocesser, bör man studera principerna för företagets funktion. För detta genomförs en intervju av en specialist från tredje part. Först och främst svarar företagets chef på frågan, sedan de specialister som övervakar andra arbetsfaser.

Den första etappen av arbetet resulterar i två noteringar. Man kommer att återspegla affärsprocesserna i sin ursprungliga form. Denna notering kommer att skapas baserat på resultaten av intervjun, och varje detalj måste komma överens med företagets chef och dess anställda. Det är absolut nödvändigt att din förståelse av de befintliga affärsprocesserna i företaget sammanfaller med verkligheten, detta kräver bekräftelse på alla nivåer.

Den andra notationen kan kallas "Som den ska vara". Det skapas på grundval av det första med ändringar som görs i enlighet med uppgiften.

IDEF0 -standarden och dess krav

Vi pratade om de grundläggande kraven för IDEF0 strax ovan.

  1. Huvudelementet finns i det övre vänstra hörnet.
  2. Varje element måste ha inkommande och utgående pilar. Dessutom är de inkommande pilarna till vänster, till höger - de utgående.
  3. Kontrollelement är placerade överst, mekanismer längst ner.
  4. När du placerar flera block på ett ark eller skärm, placeras efterföljande längst ned till höger om det föregående.
  5. Scheman bör skapas så att pilarna skär det minsta antalet gånger.
Naturligtvis har IDEF0 -standarden allmänt accepterade normer, krav och beteckningar. Vi kommer inte att fördjupa oss i dem i detalj, om du vill är denna information lätt att hitta.

Fel vid arbete med IDEF0

Som med all aktivitet uppstår fel vid funktionell modellering. Låt oss analysera de mest typiska.

Använda flera färger

Det är viktigt att komma ihåg att i funktionell modellering är alla element viktiga, det finns inga viktigare eller mindre viktiga. Vid modellering på papper eller i någon av datorprogram användare försöker göra diagrammet mer visuellt genom att färga block och pilar i olika färger... Men i praktiken gör detta inte bara diagrammet mer visuellt, utan det leder tvärtom till förvirring och till att uppfattningen om det som avbildas förvrängs.

Därför är det idealiska alternativet ett svartvitt schema utan att använda ytterligare färgalternativ. Detta hjälper inte bara till att eliminera missförstånd, utan disciplinerar också modellens skapare, vilket påverkar läsbarheten och tydligheten av modellen positivt.

Stort antal block

När de skriver en funktionell modell av ett företags arbete försöker dess författare ofta spegla allt, även de minsta detaljerna. Det visar sig ett diagram med ett stort antal block och pilar. Som ett resultat minskar dess läsbarhet och tydlighet.

För att undvika detta fel, använd den detalj som räcker för att förstå problemet. Detaljerade detaljer är bara förberedda om det verkligen behövs för att lösa en viktig fråga.

Byte av struktur när fel åtgärdas

När du skapar ett diagram är det viktigt att mer än en process inte lämnas utan inkommande, utgående eller andra viktiga element. Om du till exempel vill ta bort en författare från schemat måste du ta bort alla element och pilar som är direkt relaterade till honom. Om de förblir i systemet kommer det att finnas missförstånd och förvirring, eftersom de under detaljeringen kommer att leda till att ingen vet vart.

Samma situation uppstår med tillägg av ett block. Om du behöver fylla i någon information, kontrollera om du har angett de nödvändiga attributen. Detta bör övervakas noggrant, eftersom vid modellering av komplexa affärsprocesser kommer även en liten förändring i en del att medföra förändringar i en annan.

Namn på block och kontroller

Reglerna för namngivning av modellelement är ganska enkla, men det är oerhört viktigt att komma ihåg dem: kontrollpilar kallas substantiv, block kallas verb. Denna regel är skriven i IDEF0 -standarden och hjälper till att undvika förvirring och fel.

Fördelar med att använda IDEF0

Synlighet. Genom att skildra företagets arbete i form av ett diagram blir det tydligt hur företaget fungerar, var problem kan uppstå och hur man förhindrar dem.

Ömsesidig förståelse, uteslutning av möjligheten till misstolkning av systemet. Den funktionella modellens synlighet och tillgänglighet, som representerar företagets arbete i form av block och kontrollelement, hjälper dig när du diskuterar med ledningen för deras företags funktion. Förresten, om det behövs, skapas en ordlista för den funktionella modellen, som innehåller alla termer och konventioner. Därmed minimeras risken för missförstånd mellan dig och chefen, företagets anställda.

Enkelhet och tidsbesparing när du skapar en modell. Naturligtvis tar det mycket tid att bli bra på funktionell modellering. Först och främst måste du lära dig att presentera en enorm mängd information i form av ett lakoniskt schema, d.v.s. kunna filtrera och komprimera originaldata. Men den tid och ansträngning som läggs på att träna mer än att löna sig senare. Det kommer trots allt inte att ta mycket tid att skapa en funktionell modell och presentera den på ett tillgängligt sätt.

Minsta sannolikhet för fel. Att arbeta enligt IDEF0 -standarden kräver strikt efterlevnad av dess regler. Detta disciplinerar utövaren och eliminerar risken för fel. Dessutom märks omedelbart bristande efterlevnad av standarden.

Och slutligen

För två affärsanalytiker kan funktionella modeller bara vara desamma om företagets struktur är extremt enkel. I andra fall kommer modellerna att skilja sig från varandra. Detta är naturligt, eftersom varje analytiker har sin egen vissa erfarenhet, sin egen förståelse för företagets funktion, sin egen syn på hur man löser de uppgifter som tilldelas honom. En affärsanalytiker utvecklar en funktionell modell ur en chefs synvinkel, föreställer sig hur han skulle lösa de tilldelade uppgifterna.

Enligt vår uppfattning kommer IDEF0 -verktyget att vara användbart inte bara för professionella affärsanalytiker, utan också för dem som direkt analyserar sin verksamhet och strävar efter att bygga ett effektivt ledningssystem.


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 helt begriplig bild: stora företag som växte i början av 90 -talet tappar gradvis sina positioner ända 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 företagets verksamhet. Resultatet av denna undersökning är ett expertutlåtande, där enskilda punkter görs rekommendationer för eliminering " 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 hänvisar till typen av metod "Entity-relation" (ER-Entity-Relation) och används som regel för att modellera relationsdatabaser relaterade till det aktuella systemet;

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. Med IDEF4-verktyg kan du 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 industriellt automatiseringsprogram som kallades 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 metodik 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 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 som en hierarkisk struktur för 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).

    Att bestämma och formalisera målet med att utveckla en IDEF0 - modell är en oerhört viktig punkt. 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 aktiviteter för att bygga i framtiden utifrån denna modell informationssystem, då kommer denna modell att skilja sig väsentligt från den som vi skulle utveckla för samma företag, men i syfte att optimera leveranskedjor.

    Synspunkten bestämmer modellens huvudsakliga utvecklingsriktning och detaljnivån som krävs. En tydlig fixering av synvinkel gör att du kan ladda ur modellen, överge detaljeringen och undersökningen av 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 väsentligt å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 viktigaste delfunktionerna i funktionsblocket i kontextdiagrammet och kallas ett barndiagram (barndiagram) i förhållande till det (var och en av de funktionsblock som tillhör ett barndiagram är respektive kallas ett barnblock - 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 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örts de in i tunneln" och sedan, om det behövs, "returneras från tunneln".

    Det slutliga konceptet i IDEF0 är ordlistan. För var och en 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 utkast (modellutkast) till 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 och beskriver 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.

    Men de flesta chefer betraktar fortfarande den praktiska tillämpningen av modellering i IDEF -standarder som ett modeuttalande snarare än ett effektivt sätt att optimera det befintliga affärsledningssystemet. Mest troligt beror detta på en uttalad brist på information om den praktiska tillämpningen av dessa metoder och med den oumbärliga programvarubestånden 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 nu i Ryssland är på ett eller annat sätt relaterade till konstruktionen automatiserade system förvaltning. Tack vare detta har IDEF -standarderna i majoritetens förståelse blivit villkorligt oskiljaktiga från genomförandet 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 för dem grundprinciperna för IDEF0 på ganska kort tid och lärde dem att arbeta med motsvarande applikationsprogram. 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 i 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å 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 de viktigaste processerna och omvandla "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 bort från samma anställdas arbete 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.

    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. Den utvecklades i mitten av förra seklet som en del av ett flyg- och rymdprojekt i USA och har, efter att ha visat sin effektivitet, blivit en 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 notationen 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 på 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 - utgångar eller resultat av funktionsexekvering;
    • ovanpå - kontrollåtgärder som avgör hur och hur många resultat som ska 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 binder 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. Nedbrytning "fördjupas" i den funktion som övervägs och delar den i mindre funktioner. Samtidigt, när funktionen på högsta nivå presenteras på ett generellt sätt och efter att den har sönderdelats, är det lämpligt att kalla det en process.

    Kontextdiagram

    På högsta nivå presenteras företaget som en "svart låda" där en del aktivitet ä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, trots den enkla och formella verkningen av denna nivå, är det ofta nödvändigt att stanna kvar länge, eftersom alla resultat som är viktiga för ägaren och marknaden måste återspeglas här. Ett fel kan leda till att modeller skapas som inte uppfyller de uppgifter som ställs för verksamheten. 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 informationsflödet som företaget kommunicerar om sig själv till världen (all reklaminformation, liksom alla typer av rapportering till tillsynsmyndigheter).

    Observera att ett företag är ett öppet system, och ingenting visas eller försvinner i det. Ett företag kan bara omvandla inkommande strömmar till utgående strömmar, och om det gör det bra, då ytterligare pengaflö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 missa viktiga punkter... Till exempel kan du ofta observera frånvaron av en kund i företagets flöden, därför arbetar med honom utifrån en överbliven princip - klienten känns ofta som ett hinder för företagets anställda, vars uppgifter är inriktade på att bearbeta flödet 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 går 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 alla processer 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 redovisning, transporttjänster, städning av lokaler etc.).
    4. Skapandet av ledningsflöden är 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 de grundläggande begreppen 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 anslutna 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 enkelt 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 denna notation för de uppgifter som den är avsedd för (strukturera aktiviteter på högsta nivå), så är IDEF0 praktiskt taget den enda notationen idag som gör att du kan göra detta meningsfullt och korrekt.

    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.

    6.2. Syfte och sammansättning av SADT -metoden (IDEF0)

    SADT -metodik (Strukturerad analys och designteknik - metodik för strukturanalys och design) är en uppsättning metoder, regler och procedurer som är utformade för att bygga en funktionell modell av ett system.

    Utvecklingen av denna metod initierades av Douglas Ross (USA) i mitten av 60-talet. XX -talet Sedan dess har systemanalytiker från SofTech, Inc. förbättrade SADT och använde den för att lösa ett brett spektrum av problem. Telefonnätverksprogramvara, diagnostik, långsiktig och strategisk planering, automatiserad produktion och design, datorsystemkonfiguration, personalutbildning, ekonomi- och upphandlingshantering är några av de områden där SADT kan användas effektivt. Det stora utbudet av områden indikerar mångsidigheten och kraften i SADT -metodiken. I programmet "Integration av dator och industriell teknik Det amerikanska försvarsdepartementets integrerade datorstödda tillverkning (ICAM) har erkänts som användbart av SADT. Detta ledde till att en del av den publicerades 1981 kallad IDEF0 (Icam DEFinition), som federal standard att utveckla programvara... Under detta namn har SADT använts av tusentals yrkesverksamma inom militära och industriella organisationer. Den senaste revisionen av IDEF0 -standarden släpptes i december 1993. National Institute of Standards and Technology (NIST).

    Denna metodik konkurrerar med dataflödesorienterade (DFD) metoder för att beskriva den funktionella aspekten av ett informationssystem. Däremot tillåter IDEF0:

    Beskriv alla system, inte bara informationssystem (DFD är avsett att beskriva programvara);

    Skapa en beskrivning av systemet och dess externa miljö innan du definierar de slutliga kraven för det. Med andra ord, med hjälp av denna metodik kan man gradvis bygga och analysera systemet även när det fortfarande är svårt att föreställa sig dess implementering.

    Således kan IDEF0 tillämpas i de tidiga stadierna av att bygga ett brett spektrum av system. Samtidigt kan den användas för att analysera funktioner befintliga system och utveckla lösningar för deras förbättring.

    Grunden för IDEF0 -metoden är ett grafiskt språk för att beskriva processer. En modell i IDEF0 -notering är en samling hierarkiskt ordnade och sammankopplade diagram. Varje diagram är en enhet för systembeskrivning och finns på ett separat blad.

    Modell (AS-IS, TO-BE eller BÖR-BE) kan innehålla 4 typer av diagram [ , ]:

    Kontextdiagram;

    Sönderdelningsdiagram;

    Nodträdsdiagram;

    Endast för exponeringsdiagram (FEO).

    Kontextdiagram (toppdiagram), som är toppen av diagramkonstruktionens trädstruktur, visar syftet med systemet (huvudfunktionen) och dess interaktion med den yttre miljön. Varje modell kan bara ha ett sammanhangsdiagram. Efter beskrivningen av huvudfunktionen utförs funktionell sönderdelning, det vill säga de funktioner som utgör den huvudsakliga bestäms.

    Vidare är funktionerna indelade i underfunktioner, och så vidare tills den erforderliga detaljnivån för det undersökta systemet har uppnåtts. Diagrammen som beskriver varje sådant fragment av systemet kallas sönderdelningsdiagram ... Efter varje sönderdelningssession hålls undersökningssessioner - experter på ämnesområden indikerar riktiga processers överensstämmelse med de skapade diagrammen. De konstaterade inkonsekvenserna elimineras, varefter de går vidare till ytterligare detaljer i processerna.

    Nodträdsdiagram visar hierarkiskt beroende av funktioner (verk), men inte förhållandet mellan dem. Det kan finnas flera av dem, eftersom trädet kan byggas till ett godtyckligt djup och från en godtycklig nod.

    Exponeringstabeller är byggda för att illustrera enskilda fragment av modellen för att visa en alternativ synvinkel på processerna som sker i systemet (till exempel ur organisationens ledning).

    6.3. Delar av den grafiska notationen IDEF0

    IDEF0 -metoden har funnit utbredd acceptans och tillämpning, främst på grund av den enkla grafiska notationen som används för att bygga modellen. Modellens huvudkomponenter är diagram. De visar systemets funktioner i form av rektanglar, liksom förbindelserna mellan dem och den yttre miljön med hjälp av pilar. Med bara två grafiska primitiv (rektangel och pil) kan du snabbt förklara reglerna och principerna för att bygga IDEF0 -diagram för personer som inte är bekanta med denna metod. Denna fördel gör att du kan ansluta och aktivera kundens aktivitet för att beskriva affärsprocesser med ett formellt och visuellt grafiskt språk.

    Följande bild visar de grundläggande elementen i den grafiska IDEF0 -notationen.

    Ris. 6.1. Delar av den grafiska notationen IDEF0

    Rektangeln representerar arbete (process, aktivitet, funktion eller uppgift) , som har ett fast mål och leder till något slutresultat. Verkets namn måste uttrycka åtgärden (till exempel "Tillverkning av en del", "Beräkning av tillåtna hastigheter", "Bildande av listan över det centraliserade husnummer 3").

    Samverkan mellan verk mellan sig själva och omvärlden beskrivs i form av pilar. IDEF0 skiljer 5 typer av pilar :

    - ingång (Engelsk ingång) - material eller information som används och omvandlas av arbete för att få ett resultat (utdata). Inloggningen svarar på frågan "Vad ska bearbetas?" Ingången kan antingen vara ett materialobjekt (råvaror, en del, en provbiljett) eller en som inte har tydliga fysiska konturer (en fråga till databasen, en fråga från en lärare). Det antas att verket inte får ha några inmatningspilar. Inmatningspilarna ritas alltid som in på vänster sida av verket;

    - kontrollera (Engelsk kontroll) - kontroll-, reglerings- och regleringsdata som styr arbetet. Institutionen svarar på frågan "I enlighet med vad görs arbetet?" Ledningen påverkar arbetet, men omvandlas inte av det, d.v.s. fungerar som en begränsning. Som ledning kan det finnas regler, standarder, föreskrifter, priser, muntliga instruktioner. Kontrollpilar ritas som en del av verkets övre yta. Om frågan om hur man ritar en pil uppifrån eller till vänster uppstår när man bygger ett diagram, rekommenderas att man ritar den som en ingång (pil till vänster);

    - produktion (Engelsk utdata) - material eller information som representerar resultatet av arbetet. Utgången svarar på frågan "Vad är resultatet av arbetet?" Utmatningen kan antingen vara ett materialobjekt (del, bil, betalningsdokument, ett uttalande) eller en immateriell (hämta data från en databas, svara på en fråga, verbal indikation). Utgångspilarna dras ut från höger sida av verket;

    - mekanism (eng. mekanism) - resurser som utför arbete. Mekanismen svarar på frågan "Vem gör arbetet eller på vilket sätt?" Mekanismen kan vara företagets personal, studenten, maskinen, utrustningen, programmet. Mekanismens pilar ritas när de kommer in i verkets nedre kant;

    - ring upp (Engelska samtal) - pilen indikerar att en del av arbetet utförs utanför det aktuella blocket. Utgångspilarna ritas från den nedre kanten av verket.

    6.4. Typer av länkar mellan jobb

    Efter att ha bestämt sammansättningen av funktioner och relationerna mellan dem uppstår frågan om deras korrekta sammansättning (associering) till moduler (delsystem). Detta innebär att varje separat funktion måste lösa en, strikt en specifik uppgift... Annars krävs ytterligare sönderdelning eller separering av funktioner.

    När man kombinerar funktioner till delsystem är det nödvändigt att sträva efter att den interna anslutningen (mellan funktioner inom en modul) ska vara så stark som möjligt och extern (mellan funktioner som ingår i olika moduler) så svag som möjligt. Baserat på semantiken i metodlänkarna introducerar vi en klassificering av länkar mellan funktioner (verk). Denna klassificering är en förlängning. Typerna av obligationer listas i ordning efter minskande betydelse (bindningsstyrka). I de citerade exemplen markerar förtjockade linjer funktionerna mellan vilka den övervägda typen av anslutning finns.

    1. Hierarkiskt förhållande (relation "del" - "hel") sker mellan funktionen och de underfunktioner som den består av.

    Ris. 6.2. Hierarkiskt förhållande

    2. Regulatorisk (kontroll, underordnad) kommunikation återspeglar beroende av en funktion på en annan, när utmatningen från ett jobb skickas för att styra en annan. Funktionen från vilken kontrollen lämnar bör betraktas som reglerande eller kontrollerande, och till vilken den går in - underordnad. Skilja på direktkontrollänk när kontrollen överförs från ett högre arbete till ett lägre nivå (Fig.6.3), och ledningens feedback när kontrollen överförs från nedströms till uppströms (Fig. 6.4).

    3. Funktionell (teknisk) kommunikation inträffar när utgången från en funktion fungerar som ingång till nästa funktion. Ur flödet av materialobjekt visar detta förhållande tekniken (arbetssekvensen) för att bearbeta dessa objekt. Skilja på direkt anslutning vid entrén när utmatningen överförs från det högre arbetet till det lägre nivået (fig.6.5), och input feedback när utmatningen överförs från nedströms till uppströms (figur 6.6).
    Ris. 6.5. Direkt anslutning vid entrén Ris. 6.6. Inmatningsfeedback

    4. Konsumentkommunikation inträffar när utsignalen från en funktion fungerar som mekanismen för nästa funktion. Således förbrukar en funktion resurserna som genereras av den andra.

    Ris. 6.7. Konsumentkommunikation

    5. Logisk länk observeras mellan logiskt homogena funktioner. Sådana funktioner utför i regel samma arbete, men på olika (alternativa) sätt eller med olika initialdata (material).

    Ris. 6.8. Logisk länk

    6. Kollegial (metodisk) kommunikation sker mellan funktioner vars operationsalgoritm bestäms av samma kontroll. En analog av sådan kommunikation är det gemensamma arbetet för anställda på en avdelning (kollegor), underordnade chefen, som ger instruktioner och order (styrsignaler). En sådan koppling uppstår också när algoritmerna för driften av dessa funktioner bestäms av samma metodiska stöd (SNIP, GOST, officiellt regleringsmaterial, etc.), som fungerar som en ledning.

    Ris. 6.9. Metodisk anslutning

    7. Resurslänk uppstår mellan funktioner som använder samma resurser för sitt arbete. Resursberoende funktioner kan i allmänhet inte köras samtidigt.

    Ris. 6.10. Resurslänk

    8. Informationskommunikation sker mellan funktioner med samma information som input.

    Ris. 6.11. Informationskommunikation

    9. Tillfällig anslutning sker mellan funktioner som måste köras samtidigt före eller samtidigt efter en annan funktion.

    Förutom de fall som anges i figuren sker denna koppling också mellan andra kombinationer av styrning, ingång och mekanism som går in i en funktion.

    Ris. 6.12. Tillfällig anslutning

    10. Slumpmässig anslutning uppstår när det finns liten eller ingen specifik koppling mellan funktionerna.

    Ris. 6.13. Slumpmässig anslutning

    Av ovanstående typer av länkar är den starkaste den hierarkiska länken, som faktiskt bestämmer kombinationen av funktioner till moduler (delsystem). Reglerande, funktionella och konsumentband är något svagare. Funktioner med dessa länkar implementeras vanligtvis i ett delsystem. Logiska, kollegiala, resurs- och informationsanslutningar är bland de svagaste. Funktioner som har dem, är som regel implementerade i olika delsystem, med undantag för logiskt homogena funktioner (funktioner anslutna med en logisk anslutning). Tillfällig anslutning indikerar ett svagt beroende av funktioner från varandra och kräver deras implementering i separata moduler.

    Således, när man kombinerar funktioner till moduler, är de första fem typerna av länkar mest önskvärda. Funktionerna för de fem senaste länkarna är bäst implementerade i separata moduler.

    IDEF0 har konventioner (regler och riktlinjer) för att skapa diagram för att göra det lättare att läsa och granska [,] modellen. Vissa av dessa regler stöds automatiskt av CASE, andra måste tillämpas manuellt.

    1. Innan du bygger en modell är det nödvändigt att avgöra vilken eller vilka modeller av systemet som ska byggas. Detta innebär att man definierar dess typ AS-IS, TO-BE eller SHOULD-BE, liksom att definiera positionen ur den synvinkel som modellen är byggd på. Det är bäst att föreställa sig en "synvinkel" som en plats (position) för en person eller ett objekt, där man måste stå för att se systemet i funktion. Till exempel, när du bygger en modell för driften av en livsmedelsbutik, kan du välja en säljare, kassör, ​​revisor eller direktör bland de möjliga sökande ur den synvinkel som systemet överväger. Vanligtvis väljs en synvinkel, som mest täcker alla nyanser av systemets drift, och om det behövs byggs FEO -diagram för vissa sönderdelningsdiagram, som visar en alternativ synvinkel.

    2. Kontextdiagrammet visar ett block som visar systemets syfte. Det rekommenderas att den visar 2–4 pilar som går in och ut från varje sida.

    3. Antalet block i sönderdelningsdiagrammen rekommenderas inom intervallet 3–6. Om det finns två block i sönderdelningsdiagrammet, brukar det inte vara meningsfullt. Med ett stort antal block blir diagrammet övermättat och svårt att läsa.

    4. Block på sönderdelningsdiagrammet bör ordnas från vänster till höger och uppifrån och ner. Detta arrangemang låter dig tydligare återspegla logiken och arbetssekvensen. Dessutom blir pilvägarna mindre förvirrande och har ett minimalt antal korsningar.

    5. Frånvaro av både kontroll- och ingångspilar för funktionen är inte tillåten. Detta innebär att lanseringen av denna funktion inte kontrolleras och kan ske vid godtyckligt ögonblick i tid eller aldrig alls.

    Ris. 6.14. Funktion utan kontroll och ingång

    Ett block med endast kontroll kan ses som ett samtal i ett program med en funktion (procedur) utan parametrar. Om blocket har en ingång motsvarar det att anropa en funktion med parametrar i programmet. Således är ett block utan kontroll och ingång ekvivalent med en funktion som aldrig kallas för körning i programmet.

    I fig. 6.7–6.12, som visar fragment av IDEF0 -diagram, det finns block utan inmatning och kontroll. Detta ska inte ses som ett fel, eftersom det innebär att en av dessa pilar måste vara.

    6. Varje block måste ha minst ett uttag.

    Ris. 6.15. Ingen avslutningsfunktion

    Verk utan resultat är meningslösa och ska inte modelleras. Ett undantag är arbetet som visas i AS-IS-modellen. Deras närvaro indikerar ineffektivitet och ofullkomlighet av tekniska processer. I TO-BE-modellen bör dessa verk saknas.

    7. När du konstruerar diagram bör du minimera antalet korsningar, slingor och pilar.

    8. Återkopplingar och iterationer (cykliska handlingar) kan avbildas med bakåtbågar. Återkoppling på ingången dras av den "nedre" slingan, återkopplingen på kontrollen - av den "övre" (se fig. 6.4 och 6.6).

    9. Varje block och varje pil i diagrammen måste ha ett namn. Det är tillåtet att använda förgrenings- (sönderdelning) eller sammanslagning (sammansättning) pilar. Detta beror på att samma data eller objekt som genereras av ett jobb kan användas i flera andra jobb samtidigt. Omvänt kan samma eller homogena data och objekt som genereras av olika verk användas på ett ställe.

    Ris. 6.16. Grenande pilar

    I det här fallet är det tillåtet att tilldela kvalificerade namn till olika grenar av pilen efter förgrening (före sammanslagning). Om någon gren efter grenen inte heter, anses dess namn motsvara pilnamnet som spelades in före grenen.

    Så i fig. 6.16 kontroller som ingår i blocken "Tillverkning av delar" och "Montering av produkten" har klargörande betydelser och är del av Mer allmän förvaltning"Ritningar". Alla ritningar används för driften av blocket "Kvalitetskontroll".

    Det är inte tillåtet att rita pilar i diagrammet när de inte är namngivna före och efter förgrening. I fig. 6.17 pilen i blocket "Generering av standardlistor" har inget namn före och efter förgrening, vilket är ett fel.

    Ris. 6.17. Felaktig pilnamn

    10. Vid konstruktion av diagram för bättre läsbarhet kan piltunnelmekanismen användas. Till exempel, för att inte röra upp diagrammen för de övre nivåerna (förälder) med onödiga detaljer, placeras bågens början i tunneln i sönderdelningsdiagram.

    Ris. 6.18. Tunnelpilar

    V detta exempel när man bygger en modell för ledning Nyårsfest mekanismen "två axlar" visas inte på diagrammen för de övre nivåerna när man läser vilken rättvis fråga kan uppstå: "Varför behöver vi två axlar på nyårsfesten?"

    På samma sätt kan du tunnla med motsatt mål - så att pilen inte visas på diagram på lägre nivå. I detta fall placeras parenteser i slutet av pilen. På kontextdiagrammet (se fig. 6.21) tunnlas "Path Service Engineer" -mekanismen, som ingår i blocket "Bestämning av tillåtna hastigheter". Detta beslut togs eftersom ingenjören är direkt involverad i allt arbete som visas på sönderdelningsdiagrammet för detta block (se fig. 6.22). För att inte visa denna koppling och för att inte störa sönderdelningsschemat, tunnlades pilen.

    11. Alla pilar som kommer in och ut ur blocket, när de bygger ett sönderdelningsdiagram för det, ska visas på det. Undantaget är tunnlade pilar. Namnen på pilarna som dras in på sönderdelningsdiagrammet måste matcha namnen som visas på diagrammet på översta nivån.

    12. Om två pilar löper parallellt (starta från samma aspekt av ett jobb och slutar med samma aspekt av det andra jobbet), bör de om möjligt kombineras och kallas en enda term.

    Ris. 6.19. Slå samman länkar

    13. Varje block i diagrammen måste ha sitt eget nummer. För att ange positionen för ett diagram eller block i hierarkin används diagramnummer. Blocket på diagrammet på översta nivån markeras med 0, blocken på diagrammen på andra nivån - med siffror från 1 till 9 (1, 2, ..., 9), blocken på den tredje nivån - med två nummer varav den första indikerar numret på det detaljerade blocket från det överordnade diagrammet och det andra blocknumret i ordning på det aktuella diagrammet (11, 12, 25, 63) etc. Kontextdiagrammet har beteckningen "A - 0 ", den första nivån nedbrytningsdiagrammet är" A0 ", sönderdelningsdiagrammen för de nästa nivåerna består av bokstaven" A "följt av numret på blocket som ska sönderdelas (till exempel" A11 "," A12 "," A25 "," A63 "). Figuren visar ett typiskt diagramträd (nodträddiagram) med numrering.

    Ris. 6.20. Hierarki av diagram

    I moderna CASE-verktyg stöds arbetsnumreringsmekanismer automatiskt. CASE -verktyg tillhandahåller också automatisk konstruktion av nodträddiagram som endast innehåller hierarkiska länkar. Överst på ett sådant diagram kan vara vilken nod som helst (block), och den kan ritas till vilket djup som helst.

    6.6. Ett exempel på att bygga en IDEF0 -modell för ett system för att bestämma tillåtna hastigheter

    Att beräkna tillåtna tåghastigheter är en mödosam teknikuppgift. När ett tåg passerar någon sektion verklig hastighet tågets rörelse får inte överstiga den högsta tillåtna. Denna högsta tillåtna hastighet fastställs baserat på arbetserfarenhet och speciellt genomförda tester på rörelsedynamiken och påverkan på den rullande materielens spår. Att inte överskrida denna hastighet garanterar tågtrafikens säkerhet, bekväma förhållanden för passagerare, etc. De bestäms beroende på typ av rullande materiel (lokomärke och vagnstyp), överbyggnadens parametrar (såsom räls, ballast, sliprar ) och plan (radiekurvor, övergångskurvor, höjd av ytterskenan, etc.). För att fastställa de tillåtna hastigheterna är det som regel nödvändigt att bestämma minst två (på raka linjer) och fem (i kurvor) varifrån den slutliga tillåtna hastigheten väljs, som den lägsta av alla beräknade. Beräkningen av dessa hastigheter regleras av Order of the Ministry of Railways of Russian No. 41 den 12 november 2001 "Standarder för tillåtna hastigheter för rullande materiel på 1520 (1524) mm gauge järnvägsspår av Federal Railway Transport".

    Som nämnts börjar byggandet av IDEF0 -modellen med att representera hela systemet som en enkel komponent (kontextdiagram). Detta diagram visar systemets syfte (huvudfunktion) och erforderliga in- och utdata, kontroll- och regleringsinformation och mekanismer.

    Kontextdiagrammet för problemet med att bestämma de tillåtna varvtalen visas i figur 6.21. För att bygga modellen användes BPwin 4.0 -produkten från Computer Associates.


    Ris. 6.21. Kontextdiagram över systemet för bestämning av tillåtna hastigheter (metodik IDEF0)

    Som bakgrundsinformation, på grundval av vilka bestämningen av tillåtna hastigheter utförs, används:

    Uppgifter om projektet för en ny linje eller ett rekonstruktionsprojekt (innehåller all nödvändig information för projektets genomförande, nämligen körsträckan, axlar för separata punkter, linjeplan, etc.);

    Detaljerad längsgående profil (innehåller information liknande den som diskuterats ovan);

    Pass för spåravståndet (innehåller information liknande den som diskuterats ovan, liksom information om spårets övre struktur (VSP));

    Data om resultaten av undersökningen av banplanen av spårmätbilen;

    Lista över höjden av den yttre skenan i kurvor (innehåller information om banans plan).

    En del av den ursprungliga informationen kan hämtas från olika källor... I synnerhet kan information om planen (parametrar för kurvor) tas från projektet med en ny linje eller ett rekonstruktionsprojekt, en detaljerad längsgående profil, ett pass för spåravståndet etc.

    Kontrolldataär:

    Instruktioner från chefen för spårtjänsten på vägen eller avdelningen för spår och strukturer på ryska järnvägar för beräkningen;

    Beställning nr 41, som innehåller normativ och referensinformation, procedur och formler för att bestämma tillåtna hastigheter;

    Information om den aktuella eller planerade tågtrafiken (data om varumärkena för de lok som cirkulerar och vilka typer av bilar som används);

    Information om planerade reparationer av banan, rekonstruktion och omorganisation av strukturer och anordningar.

    Resultatet systemdrift bör vara:

    Ark med tillåtna hastigheter, som innehåller alla typer av beräknade hastigheter och låter dig fastställa orsaken till deras begränsning;

    Bulletin of the Order of the road head om fastställande av tillåtna hastigheter på spåren och separata punkter (order "N") i enlighet med den form som antagits på vägen. Den godkända ordern "N" fastställer officiellt de tillåtna tåghastigheterna.

    Standardformulär nr 1, 1a och 2, som innehåller de planerade tillåtna hastigheterna för utvecklingen av tågschemat.

    Hastigheterna i order "H" och standardformulär kan skilja sig från de som beräknats och visas i de tillåtna hastighetsbladen. Detta beror på det faktum att de återspeglar hastighetsbegränsningarna, inte bara genom konstruktionen av rullande materiel, VSP -parametrar och kurvor, utan också av enheter och strukturer (deformation av vägbanan, snedställning av kontaktnätets stöd, etc. .). Dessutom justeras de med hänsyn till de planerade banreparationerna, rekonstruktion och omorganisation av strukturer och anordningar etc.

    När det väl är byggt är sammanhangsdiagrammet detaljerat med hjälp av ett sönderdelningsdiagram på första nivån. Detta diagram visar systemets funktioner som måste implementeras inom huvudfunktionen. Diagrammet för vilket sönderdelningen utförs, i förhållande till diagrammen som beskriver det, kallas förälder ... Sönderdelningsdiagrammet i förhållande till föräldern kallas dotterföretag .

    Nedbrytningsschemat för den första nivån för det problem som behandlas visas i figur 6.22. Som regel, när man konstruerar ett sönderdelningsdiagram, är den ursprungliga funktionen (som ska sönderdelas) uppdelad i 3–8 underfunktioner (block). I det här fallet rekommenderas blocken på sönderdelningsdiagrammet att placeras från vänster till höger, uppifrån och ner, så att sekvensen och logiken för interaktion av subfunktioner blir bättre synlig.


    Ris. 6.22. Nivå 1 sönderdelningsdiagram (IDEF0 metodik)

    Sekvensen för att utföra funktioner för att lösa problemet som övervägs är följande:

    Inmatning och korrigering av referensinformation och data om vägavsnitt (block 1 och 2);

    Förberedelse av ett uppdrag för beräkning (block 3). Den anger för vilken sektion och spår, liksom lokets märke och typ av vagnar, beräkningen ska utföras;

    Beräkning av tillåtna varvtal i enlighet med proceduren och formlerna som anges i beställning nr 41 (block 4). Den initiala informationen är data längs sektionens väg (plan, spårets övre struktur, etc.) och de standarder som valts utifrån uppgiften för beräkningen;

    Bildning av listor över tillåtna hastigheter (block 5). Baserat på beräkningsresultaten skapas flera typer av utmatningsdokument, som å ena sidan gör det möjligt att identifiera orsaken till hastighetsbegränsningarna, å andra sidan fungerar som grunden för utarbetandet av reglerade dokument;

    Bildande och förberedelse av utkastet till beställning "N" och standardblad (block 6 och 7).

    Efter nedbrytningsdiagrammet på första nivån byggs separata diagram (sönderdelningsdiagram på andra nivå) för de funktioner som anges på det. Sedan fortsätter nedbrytningsprocessen (byggdiagram) tills ytterligare detaljering av funktioner förlorar sin mening. För varje atomfunktion som beskriver en elementär operation (det vill säga en funktion som inte har ett sönderdelningsdiagram) upprättas en detaljerad specifikation som definierar dess funktioner och implementeringsalgoritm. Flödesscheman för algoritmer kan användas för att komplettera specifikationen. Således består processen med funktionell modellering i att gradvis bygga en hierarki av funktioner.

    6.7. ICOM -koder

    Pilarna som går in och ut ur blocket i diagrammet på översta nivån är desamma som pilarna som går in och ut från diagrammet på lägre nivå, eftersom blocket och diagrammet representerar samma del av systemet (se fig. Och ). Som en konsekvens är gränserna för toppnivåfunktionen desamma som gränserna för sönderdelningsdiagrammet.

    ICOM -koder (förkortning för Input, Control, Output och Mechanism) är för identifiering av gränspilar. ICOM -koden innehåller ett prefix som motsvarar pilens typ (I, C, O eller M) och ett sekvensnummer (se figur).

    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 datorutrustning för företag"

    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 modernisering 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 totalsummor 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-, ut-, 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) Tilldela ett nummer - tilldela ett individuellt 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 till 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 ansluten med korsningen J9.

    Liknande publikationer