De viktigaste metoderna för undersökning av organisationer. IDEF0 standard.

Lär dig se och förstå den funktionella strukturen i ditt företag!

För närvarande har intresset för ledningsstandarder som allmänt accepteras i väst ökat kraftigt i Ryssland, men i verklig förvaltningspraxis finns det ett mycket viktigt ögonblick. Många chefer kan fortfarande förbryllas av en direkt fråga om företagets organisationsstruktur eller om systemet för befintliga affärsprocesser. De mest avancerade och regelbundet läsande ekonomiska periodiska cheferna börjar som regel rita hierarkiska diagram som bara är förståeliga för dem ensamma, men i denna process stannar de vanligtvis snabbt. Detsamma gäller anställda och chefer för olika tjänster och funktionsenheter. I de flesta fall är den enda uppsättningen angivna regler som ett företag måste verka enligt en uppsättning separata regler och arbetsbeskrivningar. Oftast sammanställdes dessa dokument för mer än ett år sedan, de är dåligt strukturerade och inte relaterade till varandra och som ett resultat samlar de helt enkelt damm på hyllorna. För närvarande var ett sådant tillvägagångssätt motiverat, eftersom konkurrensbegreppet praktiskt taget var frånvarande under bildandet av den ryska marknadsekonomin, och det fanns inget särskilt behov av att beräkna kostnaderna - vinsten var gigantisk. Som ett resultat har vi under de senaste två åren sett en ganska förståelig bild: stora företag som växte upp i början av 90-talet tappar gradvis mark, upp till ett fullständigt tillbakadragande från marknaden. Detta beror delvis på det faktum att ledningsstandarder inte infördes på företaget, konceptet med en funktionell modell för verksamhet och uppdrag var helt frånvarande. Genom att modellera olika verksamhetsområden är det möjligt att effektivt analysera "flaskhalsar" i ledningen och optimera det övergripande affärssystemet. Men, som ni vet, i alla företag är det bara de projekt som direkt ger vinst som har högsta prioritet, så det är vanligtvis en fråga om att undersöka verksamheten och omorganisera den endast under en påtaglig kris i företagets ledning.

I slutet av 1990-talet, när marknaden började bli mer konkurrenskraftig och företagens lönsamhet började sjunka kraftigt, kände cheferna stora svårigheter med att försöka optimera kostnaderna så att produkterna förblev både lönsamma och konkurrenskraftiga. Just i det ögonblicket manifesterade sig tydligt behovet av att ha en modell av företagets verksamhet framför våra ögon, som skulle återspegla alla mekanismer och principer för sammankopplingen av olika delsystem inom en verksamhet.

Själva konceptet "affärsprocessmodellering" kom in i livet för de flesta analytiker samtidigt som komplexa mjukvaruprodukter kom fram på marknaden för komplex automatisering av företagsledning. Sådana system innebär alltid en djupgående förprojektöversikt av företagets verksamhet. Resultatet av denna undersökning är ett expertutlåtande, där rekommendationer ges i separata stycken för att eliminera "flaskhalsar" i hanteringen av aktiviteter. Baserat på denna slutsats, omedelbart före implementeringen av automationssystemet, genomförs den så kallade omorganisationen av affärsprocesser, ibland ganska allvarlig och smärtsam för företaget. Detta är naturligtvis ett team som har utvecklats under åren som alltid är svårt att få "tänka på ett nytt sätt". Sådana omfattande undersökningar av företag är alltid komplexa och skiljer sig avsevärt från fall till fall. Det finns väletablerade metoder och standarder för att lösa sådana problem med att modellera komplexa system. Dessa standarder inkluderar IDEF-familjen av metoder. Med deras hjälp kan du effektivt visa och analysera aktivitetsmodellerna för ett brett utbud av komplexa system i olika sektioner. Samtidigt bestäms bredden och djupet av undersökningen av processer i systemet av utvecklaren själv, vilket gör det möjligt att inte överbelasta den skapade modellen med onödiga data. För närvarande kan följande standarder tillskrivas IDEF-familjen:

IDEF0 är en funktionell modelleringsmetod. Med hjälp av ett visuellt grafiskt språk IDEF0 framstår systemet som studeras för utvecklare och analytiker som en uppsättning sammanhängande funktioner (funktionella block - i termer av IDEF0). Typiskt är IDEF0-modellering det första steget i att lära sig något system;
IDEF1 - en metod för att modellera informationsflöden inom ett system som låter dig visa och analysera deras struktur och relationer;
IDEF1X (IDEF1 Extended) är en metodik för att bygga relationsstrukturer. IDEF1X tillhör typen av Entity-Relationship (ER)-metoder och används vanligtvis för att modellera relationsdatabaser som är relevanta för det aktuella systemet;
IDEF2 är en metod för dynamisk modellering av systemutveckling. I samband med de mycket allvarliga svårigheterna i analysen av dynamiska system övergavs denna standard praktiskt taget, och dess utveckling avbröts i det allra första skedet. Men för närvarande finns det algoritmer och deras datorimplementationer som gör det möjligt att förvandla en uppsättning IDEF0 statiska diagram till dynamiska modeller byggda på basis av "färgade Petri nät" (CPN – Color Petri Nets);
IDEF3 är en metodik för att dokumentera processer som sker i ett system, som används till exempel för att studera tekniska processer i företag. IDEF3 beskriver scenariot och operationssekvensen för varje process. IDEF3 har en direkt relation med IDEF0-metoden - varje funktion (funktionsblock) kan representeras som en separat process med IDEF3-verktyg;
IDEF4 är en metod för att bygga objektorienterade system. IDEF4-verktyg låter dig visuellt visa strukturen hos objekt och de underliggande principerna för deras interaktion, vilket gör att du kan analysera och optimera komplexa objektorienterade system;
IDEF5 är en metodik för ontologisk studie av komplexa system. Med hjälp av IDEF5-metoden kan systemontologin beskrivas med hjälp av en viss vokabulär av termer och regler, på basis av vilken tillförlitliga uttalanden om tillståndet för det aktuella systemet vid någon tidpunkt kan bildas. Baserat på dessa påståenden dras slutsatser om vidareutvecklingen av systemet och dess optimering genomförs.

Inom ramen för denna artikel kommer vi att överväga den mest använda IDEF0 funktionsmodelleringsmetodiken.

IDEF0-standardens historia

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 några år sedan publicerades en liten upplaga av en bok med samma namn i Ryssland, tillägnad 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 industriell automationsprogram, som bar beteckningen ICAM (Integrated Computer Aided Manufacturing) och föreslogs av US Air Force Department. IDEF-familjen av standarder har själv ärvt sin beteckning från namnet på detta program (IDEF=ICAM DEFinition). I den praktiska implementeringsprocessen stod deltagarna i ICAM-programmet inför behovet av att utveckla nya metoder för att analysera interaktionsprocesser i industriella system. Samtidigt, förutom en förbättrad uppsättning funktioner för att beskriva affärsprocesser, var ett av kraven för den nya standarden tillgången på en effektiv metodik för interaktion inom ”analytikerspecialisten”. Den nya metoden var med andra ord tänkt att ge grupparbete med 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. Sedan 1981 har IDEF0-standarden genomgått flera mindre ändringar, mestadels restriktiva, och dess senaste revidering släpptes i december 1993 av US National Institute of Standards and Technology (NIST).

Grundläggande element och koncept för IDEF0

Det grafiska språket IDEF0 är anmärkningsvärt enkelt och harmoniskt. Metodiken bygger på fyra huvudkoncept:

Den första av dessa är konceptet funktionsblock (Aktivitetsruta). Det funktionella blocket är grafiskt avbildat som en rektangel (se fig. 1) och representerar någon specifik funktion inom det betraktade systemet. Enligt kraven i standarden måste namnet på varje funktionsblock formuleras i den verbala stämningen (till exempel "att producera tjänster" och inte "att producera tjänster").

Var och en av de fyra sidorna av det funktionella blocket har sin egen specifika betydelse (roll), medan:

Den övre sidan är "Kontroll";
Den vänstra sidan är "Input";
Den högra sidan är inställd på "Output";
Undersidan har betydelsen "Mechanism" (Mechanism).

Varje funktionell enhet inom det enskilda systemet i fråga måste ha sitt eget unika identifikationsnummer.

Figur 1. Funktionsblock.

Den andra "valen" i IDEF0-metoden är konceptet gränssnittsbåge (pil). Dessutom kallas gränssnittsbågar ofta för flöden eller pilar. En gränssnittsbåge representerar 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 enkelriktad pil. Varje gränssnittsbåge måste ha sitt eget unika namn (Arrow Label). Enligt standarden ska namnet vara en omsättning av ett substantiv.

Med hjälp av gränssnittsbågar visas olika objekt som i en eller annan grad bestämmer de processer som sker i systemet. Sådana objekt kan vara delar av den verkliga världen (delar, vagnar, anställda, etc.) eller data- och informationsflöden (dokument, data, instruktioner etc.).

Beroende på vilken av sidorna detta gränssnittsbåge närmar sig kallas det "inkommande", "utgående" eller "kontrollerande". Dessutom kan "källan" (början) och "mottagaren" (slutet) för varje funktionsbåge endast vara funktionella block, medan "källan" bara kan vara utgångssidan av blocket, och "mottagaren" kan vara någon av de återstående tre.

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 ske enligt vissa regler (visas av kontrollbågen) och måste producera något resultat (utgående båge), annars är dess övervägande inte meningsfullt.

När man konstruerar IDEF0-diagram är det viktigt att korrekt separera inkommande gränssnittsbågar från kontrollbågar, vilket ofta inte är lätt. Till exempel visar figur 2 funktionsblocket "Bearbeta arbetsstycket".

I en verklig process får arbetaren som utför bearbetningen ett arbetsstycke och tekniska instruktioner för bearbetning (eller säkerhetsföreskrifter vid arbete med maskinen). Det kan av misstag verka som att både arbetsstycket och dokumentet med tekniska instruktioner är inmatningsobjekt, men så är inte fallet. I själva verket, i denna process, bearbetas arbetsstycket enligt reglerna som återspeglas i de tekniska instruktionerna, som respektive ska avbildas av styrgränssnittsbågen.

Figur 2.

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

Figur 3

Exemplen ovan betonar den till synes liknande karaktären hos inkommande och styrande gränssnittsbågar, men det finns alltid vissa skillnader för system av samma klass. Till exempel, när det gäller 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.), dokumentflöden (kommersiella, finansiella och organisatoriska dokument), informationsflöden (information, data om avsikter, muntliga instruktioner, etc.) och resurser (anställda, maskiner, etc.). I det här fallet, i olika fall, kan inkommande och utgående gränssnittsbågar visa alla typer av objekt som endast hanterar de som är relaterade till flödet av dokument och information, och endast resurser kan visas som bågar-mekanismer.

Den obligatoriska närvaron av styrgränssnittsbågar är en av huvudskillnaderna mellan IDEF0-standarden och andra metoder för klasserna DFD (Data Flow Diagram) och WFD (Work Flow Diagram).

Det tredje kärnkonceptet i IDEF0-standarden är sönderfall. Principen om nedbrytning tillämpas när en komplex process bryts ner i dess ingående funktioner. I det här fallet bestäms processens detaljnivå direkt av utvecklaren av modellen.

Nedbrytning gör att du gradvis och strukturerat kan representera systemmodellen i form av en hierarkisk struktur av individuella diagram, vilket gör den mindre överbelastad och lättsmält.

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

I den förklarande texten till kontextdiagrammet bör syftet (Syftet) med att konstruera diagrammet i form av en kort beskrivning anges och fastställas synpunkt(synpunkt).

Att bestämma och formalisera syftet med att utveckla en IDEF0-modell är en extremt viktig punkt. Faktum är att målet avgör de relevanta områdena i det studerade systemet, som måste fokuseras först. Om vi till exempel modellerar ett företags verksamhet för att bygga ett informationssystem baserat på denna modell i framtiden, kommer denna modell att skilja sig väsentligt från den som vi skulle utveckla för samma företag, men med syftet att optimera leveranskedjorna.

Synvinkeln bestämmer huvudriktningen för utvecklingen av modellen och vilken detaljnivå som krävs. En tydlig fixering av synvinkeln 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 synvinkeln på systemet. Till exempel kommer funktionella modeller för samma företag från chefsteknologens och finanschefens synvinkel att skilja sig avsevärt i riktningen för deras detaljering. Detta beror på det faktum att finansdirektören i slutändan inte är intresserad av aspekterna av bearbetning av råvaror på produktionsmaskiner, och chefsteknologen är inte intresserad av de ritade planerna för finansiella flöden. Rätt val av synvinkel minskar avsevärt tiden som läggs på att bygga den slutliga modellen.

Under nedbrytningsprocessen beskrivs 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 huvudunderfunktionerna i funktionsblocket i kontextdiagrammet och kallas ett underordnat diagram (Barndiagram) i förhållande till det (vart och ett av funktionsblocken som hör till underdiagrammet kallas respektive ett underordnat block - Child Box). I sin tur det funktionella blocket - förfadern kallas föräldrablocket i förhållande till underordnat diagram (Parent Box), och diagrammet som det tillhör kallas förälderdiagrammet (Prent Diagram). Var och en av underfunktionerna i barndiagrammet kan detaljeras ytterligare genom en liknande uppdelning av dess motsvarande funktionsblock. Det är viktigt att notera att i varje fall av nedbrytning av ett funktionsblock är alla gränssnittsbågar som ingår i detta block eller utgående från det fixerade på barndiagrammet. Detta uppnår IDEF0-modellens strukturella integritet. Principen för nedbrytning visas tydligt i figur 4. Du bör vara uppmärksam på förhållandet mellan numreringen av funktionsblock och diagram - varje block har sitt eget unika serienummer på diagrammet (numret i det nedre högra hörnet av rektangeln), och beteckningen i det högra hörnet indikerar numret på barndiagrammet för detta block. Frånvaron av denna beteckning indikerar att det inte finns någon sönderdelning för detta block.

Ofta finns det fall då det inte är meningsfullt att fortsätta att överväga individuella gränssnittsbågar i underordnade diagram under en viss nivå i hierarkin, eller vice versa - individuella bågar är inte praktiskt vettiga över en viss nivå. Till exempel är en gränssnittsbåge som visar en "detalj" vid ingången till funktionsblocket "Bearbetning på en svarv" inte meningsfullt att reflektera över diagram på högre nivåer - detta kommer bara att överbelasta diagrammen och göra dem svåra att läsa. Å andra sidan finns det ett behov av att bli av med separata "konceptuella" gränssnittsbågar och att inte detaljera dem djupare än en viss nivå. För att lösa sådana problem tillhandahåller IDEF0-standarden konceptet tunneldrivning. Beteckningen "tunneln" (Arrow Tunnel) i form av två parenteser runt början av gränssnittsbågen betyder att denna båge inte ärvdes från det funktionella föräldrablocket och förekom (från "tunneln") endast på detta diagram. I sin tur betyder samma beteckning runt änden (pilen) av gränssnittsbågen i omedelbar närhet av mottagarblocket att denna båge inte kommer att visas och kommer inte att beaktas i det underordnade diagrammet för detta block. Oftast händer det att enskilda objekt och deras motsvarande gränssnittsbågar inte beaktas på vissa mellanliggande nivåer i hierarkin - i det här fallet "kastar de först in i tunneln" och sedan, om nödvändigt, "återvänder de från tunneln".

Det sista av IDEF0-koncepten är ordlista. För vart och ett av IDEF0-elementen: diagram, funktionsblock, gränssnittsbågar, innebär den befintliga standarden skapandet och underhållet av en uppsättning lämpliga definitioner, nyckelord, narrativa uttalanden, etc., som karakteriserar objektet som visas av detta element. Denna uppsättning kallas en ordlista och är en beskrivning av essensen av detta element. Till exempel, för kontrollgränssnittsbågen "betalningsorder", kan ordlistan innehålla en lista med fält som motsvarar dokumentets båge, den erforderliga uppsättningen visum etc. Ordlistan kompletterar harmoniskt det visuella grafiska språket och förser diagrammen med nödvändig ytterligare information.

Figur 4. Nedbrytning av funktionsblock.

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

Typiskt har IDEF0-modeller komplex och koncentrerad information, och för att begränsa deras överbelastning och göra dem läsbara, antas motsvarande komplexitetsbegränsningar i motsvarande standard:

Begränsning av antalet funktionsblock i diagrammet till tre till sex. Den övre gränsen (sex) tvingar designern att använda hierarkier när han beskriver komplexa ämnen, och den nedre gränsen (tre) säkerställer att motsvarande diagram har tillräckligt med detaljer för att motivera dess skapande;
Begränsning av antalet gränssnittsbågar som närmar sig 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 erfarenheten visar är de mycket praktiska i verkligt arbete.

Disciplinen grupparbete om utveckling av en IDEF0-modell

IDEF0-standarden innehåller en uppsättning procedurer som tillåter utveckling och godkännande av en modell av en stor grupp människor som tillhör olika verksamhetsområden i systemet som modelleras. Vanligtvis är utvecklingsprocessen iterativ och består av följande villkorade steg:

Skapande av en modell av en grupp specialister relaterade till olika delar av företaget. Denna grupp kallas författare i IDEF0-termer. Att bygga den initiala modellen är en dynamisk process där författarna frågar kompetenta personer om strukturen i olika processer. Utifrån befintliga bestämmelser, dokument och undersökningsresultat skapas ett utkast (Model Draft) av modellen.
Distribuering av utkastet för behandling, godkännanden och synpunkter. I detta skede diskuteras utkastet till modellen med ett brett spektrum av kompetenta personer (i termer av IDEF0-läsare) i företaget. Samtidigt kritiseras och kommenteras vart och ett av diagrammen i modellutkastet skriftligen och överförs sedan till författaren. Författaren i sin tur instämmer också i kritiken skriftligen eller avvisar den med en redogörelse för beslutets logik och återsänder det korrigerade utkastet för vidare övervägande. Denna cykel fortsätter tills författare och läsare når enighet.
Modellgodkännande. Den godkända modellen godkänns av arbetsgruppens chef för det fall att modellens författare och läsare inte är oense om dess adekvathet. 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 grafiska språket IDEF0 gör modellen ganska läsbar för människor som inte deltog i projektet för dess skapelse, samt effektiv för demonstrationer och presentationer. I framtiden, på basis av den konstruerade modellen, kan nya projekt organiseras som syftar till att göra förändringar i företaget (i systemet).

Funktioner i den nationella praxisen att använda funktionell modellering med IDEF0-verktyg

Under de senaste åren har intresset i Ryssland för IDEF-familjens metoder stadigt ökat. Jag observerar ständigt detta när jag tittar på statistiken över träffar på min personliga webbsida (http://consulting.psi.ru), som kort beskriver de grundläggande principerna för dessa standarder. Samtidigt skulle jag kalla intresset för sådana standarder som IDEF3-5 för teoretiskt, och i IDEF0 är det ganska praktiskt motiverat. Faktum är att de första Case-verktygen som gör det möjligt att bygga DFD- och IDEF0-diagram dök upp på den ryska marknaden redan 1996, samtidigt med lanseringen av en populär bok om principerna för modellering i SADT-standarder.

Men de flesta chefer ser fortfarande den praktiska tillämpningen av modellering i IDEF-standarder mer som en hyllning till mode än som ett effektivt sätt att optimera det befintliga affärsledningssystemet. Troligtvis beror detta på en uttalad brist på information om den praktiska tillämpningen av dessa metoder och med den oumbärliga mjukvarufördomen hos de allra flesta publikationer.

Det är ingen hemlighet att nästan alla projekt för undersökning och analys av den finansiella och ekonomiska verksamheten för företag i Ryssland nu på ett eller annat sätt är kopplade till konstruktionen av automatiserade kontrollsystem. På grund av detta har IDEF-standarderna i förståelsen av majoriteten blivit villkorligt oskiljaktiga från introduktionen av informationsteknologi, även om det med deras hjälp ibland är möjligt att effektivt lösa även små lokala problem, bokstavligen med en penna och papper.

När du genomför komplexa företagsundersökningsprojekt tillåter utvecklingen av modeller i IDEF0-standarden dig att visuellt och effektivt visa hela mekanismen för ett företags aktiviteter i rätt sammanhang. Viktigast är dock den samarbetsförmåga som IDEF0 tillhandahåller. I min praktik fanns det en hel del fall när 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 hur man arbetar med motsvarande applikationsprogramvara. Som ett resultat skapade anställda vid olika avdelningar IDEF-diagram över verksamheten i deras funktionella enhet, som skulle svara på följande frågor:

Vad kommer in i enheten "vid entrén"?
Vilka funktioner och i vilken ordning utförs inom enheten?
Vem ansvarar för respektive funktion?
Vad vägleder utföraren i utförandet av var och en av funktionerna?
Vad blir resultatet av enhetens arbete (output)?

Efter att ha samordnat utkast till diagram inom varje specifik enhet, sätts de samman av en konsult till ett utkast till företagsmodell, där alla input- och outputelement är sammanlänkade. I detta skede är alla inkonsekvenser av individuella diagram och deras kontroversiella platser fixade. Vidare passerar denna modell återigen genom de funktionella avdelningarna för ytterligare samordning och för att göra nödvändiga justeringar. Som ett resultat, på ganska kort tid och med inblandning av ett minimum av mänskliga resurser från konsultföretaget (och dessa resurser, som du vet, är mycket dyra), erhålls en IDEF0-modell av ett företag enligt principen "I befintligt skick", och, viktigare, den representerar företaget från positionen för anställda som arbetar i det och känner till alla nyanser, inklusive informella. I framtiden kommer denna modell att lämnas in för analys och bearbetning till affärsanalytiker som kommer att söka efter "flaskhalsar" i företagets ledning och optimera huvudprocesserna, och omvandla "I befintligt skick"-modellen till motsvarande representation "Som den ska vara". Utifrån dessa förändringar görs en slutlig slutsats som innehåller rekommendationer för omorganisation av ledningssystemet.

Ett sådant tillvägagångssätt kräver givetvis ett antal organisatoriska åtgärder, i första hand från ledningen för det undersökta företaget. Detta beror på det faktum att denna teknik innebär att vissa anställda åläggs ytterligare ansvar för utveckling och praktisk tillämpning av nya metoder. Men i slutändan motiverar detta sig självt, eftersom ytterligare en eller två timmars arbete av enskilda anställda under flera dagar avsevärt kan spara pengar på att betala för konsulttjänster från ett tredjepartsföretag (vilket i alla fall kommer att avbryta arbetet för samma anställda med frågeformulär och frågor). När det gäller de anställda på företaget själva har jag på ett eller annat sätt inte mött något uttryckt motstånd från dem i min praktik.

Slutsatsen av allt detta kan dras som följer: det är absolut inte nödvändigt att komma med lösningar på standardproblem varje gång. Närhelst du står inför behovet av att analysera ett visst funktionellt system (från rymdfarkostdesignsystemet till processen att förbereda en komplex middag), använd beprövade och inkörda metoder genom åren. En av dessa metoder är IDEF0, som gör det möjligt att använda sin enkla och begripliga verktygslåda för att lösa komplexa livsproblem.