Bygga IDEF0-modellen

I början av skapandet av en IP är det nödvändigt att förstå hur den organisation som ska automatiseras fungerar. Chefen känner till jobbet i allmänhet, men kan inte gräva i detaljerna i arbetet för varje vanlig anställd. En vanlig anställd vet väl vad som händer på sin arbetsplats, men kanske inte vet hur kollegor fungerar. För att beskriva ett företags arbete är det därför nödvändigt att bygga en modell som är lämplig för ämnesområdet och innehåller kunskapen från alla deltagare i organisationens affärsprocesser.

Det bekvämaste språket för modellering av affärsprocesser är IDEF0, där systemet representeras som en uppsättning interagerande aktiviteter eller funktioner. Denna rent funktionella orientering är grundläggande - systemets funktioner analyseras oberoende av de objekt som de arbetar med. Detta gör att du tydligare kan modellera logiken och interaktionen mellan organisationens processer.

Processen med att modellera ett system i IDEF0 börjar med att skapa ett kontextdiagram - ett diagram över den mest abstrakta nivån för att beskriva systemet som en helhet, innehållande definitionen av ämnet modellering, mål och syn på modellen .

Ämnet förstås som själva systemet, medan det är nödvändigt att fastställa exakt vad som ingår i systemet och vad som ligger utanför det, med andra ord, för att bestämma vad som ytterligare kommer att betraktas som komponenter i systemet och vad som ett externt inflytande. Definitionen av systemets ämne kommer att påverkas avsevärt av positionen från vilket systemet ses, och syftet med modellering är de frågor som den konstruerade modellen ska svara på. Med andra ord måste du först definiera modelleringsområdet. Beskrivningen av området för både systemet som helhet och dess komponenter är grunden för att bygga modellen. Även om det antas att området kan justeras under simuleringen, bör det huvudsakligen formuleras initialt, eftersom det är området som bestämmer riktningen för modelleringen. När du formulerar ett område finns det två komponenter att tänka på - bredd och djup. Latitude innebär att man definierar modellens gränser - vad som kommer att betraktas inuti systemet och vad som kommer att vara utanför. Djupet avgör vid vilken detaljnivå modellen är komplett. När du bestämmer systemets djup är det nödvändigt att komma ihåg tidsbegränsningar - komplexiteten i att bygga en modell växer exponentiellt med en ökning av nedbrytningsdjupet. Efter att ha definierat modellens gränser antas det att nya objekt inte bör införas i det modellerade systemet.

Syfte med modellering

Målet med simuleringen bestäms genom att svara på följande frågor:

• Varför ska denna process modelleras?
• Vad ska modellen visa?
• Vad kan en klient få?

Synpunkt.

Synvinkeln avser perspektivet från vilket systemet observerades när man byggde modellen. Även om olika människors åsikter tas med i beräkningen när de bygger modellen, bör de alla följa samma syn på modellen. Syftet bör vara förenligt med simuleringens syfte och gränser. Som regel väljs synpunkten för den person som ansvarar för det simulerade arbetet som helhet.

IDEF0-modellen antar närvaron av ett klart formulerat mål, ett enda modelleringsämne och en synvinkel. För att komma in i området, målet och synvinkeln i IDEF0-modellen i BPwin, välj menyalternativet Model / Model Properties, som kallar dialogrutan Model Properties (Fig. A2.3). På fliken Syfte anger du mål och synvinkel, och på fliken Definition, modelldefinition och omfångsbeskrivning.

Ris. A2.3. Dialog för inställning av modellegenskaper

På fliken Status i samma dialogruta kan du beskriva modellens status (utkast, arbete, slutlig, etc.), tidpunkten för skapande och senaste redigering (spåras automatiskt senare av systemdatumet). Fliken Källa beskriver informationskällorna för att bygga modellen (till exempel "Intervjua domenexperter och analysera dokumentation"). Fliken Allmänt används för att ange projektets namn och modellen, författarens namn och initialer och modellens tidsram - AS-IS och TO-BE.

AS-IS och TO-BE-modeller. Vanligtvis byggs först en modell av den befintliga arbetsorganisationen - AS-IS (som den är). Analysen av den funktionella modellen gör att du kan förstå var de svagaste punkterna är, vilka fördelar det kommer med nya affärsprocesser och hur djupt den befintliga strukturen i affärsorganisationen kommer att genomgå förändringar. Granulariteten i affärsprocesser gör det möjligt att identifiera bristerna i organisationen, även där funktionaliteten verkar uppenbar vid första anblicken. Bristerna i AS-IS-modellen kan åtgärdas genom att skapa en TO-BE-modell (som den kommer att bli) - en modell för en ny organisation av affärsprocesser.

IS-designtekniken innebär först skapandet av en AS-IS-modell, dess analys och förbättring av affärsprocesser, det vill säga skapandet av en TO-BE-modell, och endast på grundval av TO-BE-modellen en datamodell, en prototyp och sedan byggs den slutliga versionen av IS.

Ibland skiljer sig nuvarande AS-IS och framtida TO-BE-modeller mycket, så att övergången från initial till slutlig status blir oklar. I det här fallet behövs en tredje modell som beskriver övergångsprocessen från systemets initiala till det slutliga tillståndet, eftersom en sådan övergång också är en affärsprocess.

Resultatet av beskrivningen av modellen kan erhållas i modellrapporten. Dialogrutan för att skapa en modellrapport anropas från menyalternativet Verktyg / Rapporter / Modellrapport.

Välj önskade fält i inställningsdialogrutan och ordningsföljden för informationsutmatning till rapporten visas automatiskt (Bild A2.4).

Ris. A2.4. Dialogruta för att skapa en rapport om modellen

I fig. A2.5 presenterar en rapport genererad av ovanstående fält.

Ris. A2.5. Rapportera förhandsgranskning

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

Modellen kan innehålla fyra typer av diagram:

• sammanhangsdiagram (varje modell kan bara ha ett sammanhangsdiagram);
• sönderdelningsdiagram;
• nodträdsdiagram;
• endast exponeringsdiagram (FEO).

Kontextdiagrammet är toppen av diagramträdstrukturen och representerar den mest allmänna beskrivningen av systemet och dess interaktion med den yttre miljön. Efter att ha beskrivit systemet som helhet är det uppdelat i stora fragment. Denna process kallas funktionell nedbrytning, och diagrammen som beskriver varje fragment och interaktionen mellan fragmenten kallas sönderdelningsdiagram. Efter nedbrytning av kontextdiagrammet sönderdelas varje stort fragment av systemet i mindre, och så vidare, tills den önskade beskrivningsnivån har uppnåtts. Efter varje nedbrytningssession hålls undersökningssessioner - experter på ämnesområden anger korrespondensen mellan verkliga affärsprocesser och de skapade diagrammen. De hittade inkonsekvenserna korrigeras, och först efter att ha klarat undersökningen utan kommentarer kan du gå vidare till nästa nedbrytningssession. Så här matchar modellen de verkliga affärsprocesserna på alla nivåer i modellen. Syntaxen för att beskriva systemet som helhet och vart och ett av dess fragment är detsamma i hela modellen.

Ett nodträddiagram visar det hierarkiska förhållandet mellan aktiviteter, men inte förhållandet mellan aktiviteter. Det kan finnas godtyckligt många diagram för nodträd i modellen, eftersom trädet kan byggas till ett godtyckligt djup och inte nödvändigtvis från roten.

exponeringsdiagram (FEO) är konstruerade för att illustrera enskilda delar av modellen, för att illustrera en alternativ synvinkel eller för speciella ändamål.

Arbete (Aktivitet) beteckna namngivna processer, funktioner eller uppgifter som uppstår över tiden och har igenkännliga resultat. Verken avbildas som rektanglar. Allt arbete måste namnges och definieras. Namnet på jobbet måste uttryckas med ett verbalt substantiv som anger en åtgärd (till exempel "Företagsaktivitet", "Beställa", etc.). Arbetet "Företagsaktiviteter" kan till exempel ha följande definition: "Detta är en inlärningsmodell som beskriver företagets aktiviteter." När du skapar en ny modell (Arkiv / Ny meny) skapas ett kontextdiagram automatiskt med ett enda verk som visar systemet som helhet (Bild A2.6).

Ris. A2.6. Exempel på ett sammanhangsdiagram

För att ange ett namn för ett jobb, högerklicka på jobbet, välj Namnredigerare i menyn och ange namnet på jobbet i dialogrutan som visas. Dialogrutan Aktivitetsegenskaper används för att beskriva andra arbetsegenskaper (Bild A2.7).

Ris. P2.P2. Redigerare för jobbegenskaper

Sönderdelningsdiagram innehåller relaterade aktiviteter, det vill säga barnaktiviteter som har en gemensam överordnad aktivitet. För att skapa ett sönderdelningsdiagram, klicka på knappen i verktygsfältet.

Dialogrutan Aktivitetsruta räknas (Bild A2.8), där du ska ange notationen för det nya diagrammet och antalet arbeten på det. Låt oss stanna vid IDEF0-notationen för tillfället och klicka på OK. Ett sönderdelningsdiagram visas (fig. A2.9). Det tillåtna intervallet för antalet jobb är 2-8. Det är ingen mening att sönderdela ett jobb till ett jobb: diagram med mer än åtta jobb visar sig vara övermättade och dåligt läsbara. För att ge tydlighet och bättre förståelse för de simulerade processerna rekommenderas att man använder tre till sex block i ett diagram.

Ris. A2.8. Dialog för antalet aktivitetsrutor

Ris. A2.9. Nedbrytningsdiagram exempel

Om det visar sig att antalet jobb inte är tillräckligt kan jobbet läggas till i diagrammet genom att först klicka på knappen i verktygspaletten och sedan på ledigt utrymme i diagrammet.

Arbete i sönderdelningsdiagram är vanligtvis ordnat diagonalt från det övre vänstra hörnet till det nedre högra hörnet.

Denna ordning kallas dominansordningen. Enligt denna lokaliseringsprincip placeras det viktigaste arbetet eller det arbete som utförs först i tiden i det övre vänstra hörnet. Längre ner till höger är mindre viktigt eller senare arbete. Denna placering gör diagrammen lättare att läsa och ger också en grund för begreppet arbetsrelationer (se nedan).

Var och en av aktiviteterna i nedbrytningsdiagrammet kan sönderdelas i tur och ordning. I fördelningsdiagrammet numreras jobb automatiskt från vänster till höger. Jobbnumret visas i det nedre högra hörnet. I det övre vänstra hörnet finns en liten diagonal linje som indikerar att detta arbete inte har sönderdelats. Så i fig. A2.9 alla jobb har ännu inte sönderdelats.

Pilar (pil) beskriver interaktionen mellan verk och representerar någon form av information uttryckt i substantiv. (Till exempel "Kundsamtal", "Regler och procedurer", "Redovisningssystem".)

IDEF0 skiljer mellan fem typer av pilar:

ingång(Inmatning) - material eller information som används eller omvandlas av arbete för att få ett resultat (output). Det antas att arbetet kanske inte har några inmatningspilar. Varje piltyp går till eller från en specifik sida av arbetsrektangeln. Inmatningspilen ritas när den går in på verkets vänstra sida. När man beskriver tekniska processer (för detta uppfanns IDEF0) finns det inga problem med att definiera ingångar. Faktum är att "kundsamtal" i fig. P2.6 är något som bearbetas i processen "Företagsaktivitet" för att få ett resultat. När man modellerar IS, när pilarna inte är fysiska objekt utan data, är inte allt så uppenbart. Till exempel, när "Admitting a patient" kan patientjournalen vara både vid ingången och vid utgången, under tiden kvaliteten på dessa data ändras. Med andra ord, i vårt exempel, för att motivera dess syfte, måste in- och utgångspilarna definieras exakt för att indikera att uppgifterna verkligen har bearbetats (till exempel är utgången "Färdig patientjournal"). Det är ofta svårt att avgöra om data matas in eller kontrolleras. I det här fallet kan information om huruvida data bearbetas / ändras under drift eller inte fungera som en ledtråd. Om de ändras, är det troligtvis en ingång, om inte, det är en kontroll.

Kontrollera(Kontrollera) - de regler, strategier, förfaranden eller standarder som styr arbetet. Varje jobb måste ha minst en kontrollpil. Kontrollpilen ritas när den går in i verkets övre yta. I fig. A2.6 pil "Regler och förfaranden" - ledning för arbetet "Företagets aktiviteter". Ledningen påverkar arbetet men förändras inte av arbetet. Om målet med arbetet är att ändra ett förfarande eller en strategi kommer en sådan procedur eller strategi att vara insatsen för arbetet. Vid osäkerhet i pilens status (kontroll eller inmatning) rekommenderas att rita kontrollpilen.

Utgång(Produktion) - material eller information som produceras av verket. Varje jobb måste ha minst en utgångspil. Att arbeta utan resultat är meningslöst och ska inte modelleras. Utgångspilen ritas som när den kommer från verkets högra kant. I fig. A2.6-pilar "Marknadsföringsmaterial" och "Sålda produkter" är resultatet för arbetet "Företagets aktiviteter".

Mekanism(Mekanism) - resurser som utför arbete, till exempel företagspersonal, maskiner, apparater etc. Mekanismens pil ritas som inkluderad i arbetets nedre kant. I fig. A2.6 pil "Redovisningssystem" är en mekanism för att driva "Företagets aktiviteter". Enligt analytikerns bedömning kanske mekanismens pilar inte visas i modellen.

Ringa upp(Ringa upp) - en speciell pil som pekar på en annan arbetsmodell. Samtalspilen ritas som från verkets nedre kant. I fig. A2.10 pil "En annan arbetsmodell" är en kallelse för arbete "Tillverkning av en produkt". Anropspilen används för att indikera att en del arbete utförs utanför det simulerade systemet. I BPwin används anropspilar i modellfusion och splitmotor.

Ris. A2.10. Ringpil som visas när man delar upp en modell

Gräns pilar. Pilarna i sammanhangsdiagrammet används för att beskriva systemets interaktion med omvärlden. De kan börja vid diagrammets kant och sluta på arbetet, eller tvärtom. Dessa pilar kallas gränspilar.

För att komma in i entréens gränspil bör du:

Pilar för kontroll, inträde, mekanism och utgång visas på samma sätt. Namnen på de nyligen tillagda pilarna (Bild A2.11) matas automatiskt in i Arrow Dictionary.

Ris. A2.11. IDEF0 Dialog för pilegenskaper

ICOM-koder... Sönderdelningsdiagrammet är avsett för detaljarbete. Till skillnad från modeller som visar strukturen i en organisation är det inte en kontroll för underordnade aktiviteter att arbeta i ett toppdiagram i IDEF0. Lågnivåjobb är desamma som högnivåjobb, men mer detaljerat. Som en konsekvens är gränserna för toppnivåarbetet desamma som gränserna för sönderdelningsdiagrammet. ICOM (akronym för Input, Control, Output and Mechanism) är koder utformade för att identifiera gränspilar. ICOM-koden innehåller ett prefix som motsvarar typen av pil (I, C, O eller M) och ett sekvensnummer.

BPwin fyller i ICOM-koder automatiskt. För att visa ICOM-koder aktiverar du ICOM-kodalternativet på fliken Display i dialogrutan Model Properties (Model / Model Properties) (Fig. A2.12).

Ordförråd skytt redigeras med hjälp av en specialredigerare Arrow Dictionary Editor, där pilen definieras och en kommentar relaterad till den läggs till (Fig. A2.13). Pilordboken löser ett mycket viktigt problem. Diagram skapas av analytikern för att genomföra en undersökningssession, det vill säga diskutera diagrammet med en ämnesspecialist. Inom vilket ämnesområde som helst bildas professionellt jargong och ofta har jargonguttryck en suddig mening och uppfattas av olika specialister på olika sätt. Samtidigt bör analytikern - författaren till diagrammen använda de uttryck som är mest förståliga för experterna. Eftersom formella definitioner ofta är svåra att förstå, tvingas analytikern att använda professionell jargong, och för att undvika tvetydiga tolkningar kan varje koncept ges en utvidgad och vid behov formell definition i ordlistan med pilar.

Ris. A2.12. Aktivera alternativet ICOM-koder på fliken Display

Ris. A2.13. Redigera pilordboken

Innehållet i pilordboken kan skrivas ut som en rapport (meny Verktyg / Rapport / Pilrapport ...) och få en förklarande ordlista över de domäntermer som används i modellen.

Obundet gräns pilar (okopplad gränspil)... När ett verk sönderdelas visas pilarna som går in i och lämnar det (förutom samtalspilen) automatiskt på sönderdelningsdiagrammet (pilmigrering), men de rör inte på verken. Dessa pilar kallas obundna pilar och behandlas som ett syntaxfel av BPwin.

I fig. A2.14 visar ett fragment av ett sönderdelningsdiagram med okopplade pilar, genererade av BPwin under arbetsnedbrytning "Bygga stationära datorer"(se bild A2.9). För att länka pilarna på ingången, kontrollen eller mekanismen måste du gå till pilarnas redigeringsläge, klicka på pilspetsen och sedan på motsvarande arbetssegment. För att länka utgångspilen måste du gå till pilredigeringsläget, klicka på arbetsutgångssegmentet och sedan på pilen.

Ris. A2.14. Ett exempel på obundna pilar

Inre pilar. Interna pilar används för att ansluta arbetet till varandra, det vill säga pilar som inte rör vid diagrammets kant, börjar vid ena och slutar vid andra arbetet.

För att rita den inre pilen, i pilritningsläget, klicka på ett segment (till exempel en utgång) för ett jobb och sedan på ett segment (till exempel en ingång) för ett annat. IDEF0 skiljer mellan fem typer av arbetsrelationer.

Ingångskommunikation(utgångsingång), när pilen på utgången för arbetet på högre nivå (hädanefter helt enkelt utgången) riktas till ingången till arbetet på lägre nivå (till exempel i figur A2.15 pilen "Assembled Computers" ansluter verk och "Leverans och kvitto").

Ris. A2.15. Ingångskommunikation

Ledningskommunikation(utgångskontroll) när utdata från ett högre jobb skickas till styrningen av ett jobb på lägre nivå. Ledningslänken visar det överlägsna arbetets dominans. Data eller utmatningsobjekt för ett jobb på högre nivå ändras inte i det lägre jobbet. I fig. P2.16 pil "Kundorder" ansluter verk "Försäljning och marknadsföring" och "Montera och testa datorer".

Ris. A2.16. Ledningskommunikation

Ingångsfeedback(återkoppling för utgångsingång) när utdata från ett jobb på lägre nivå dirigeras till inmatningen på ett jobb på högre nivå. Detta förhållande används vanligtvis för att beskriva loopar. I fig. A2.17-pilen "Testresultat" ansluter verk "Testa datorer" och Schemalägg spårning och bygga och testhantering.

Ris. P2.1P2. Ingångsfeedback

Ledningens feedback(feedback för utgångskontroll), när utgången från arbetet på lägre nivå riktas till styrningen av den högre nivån (pil "Resultat av montering och testning", fig. A2.18). Ledningens feedback är ofta ett tecken på effektiviteten i affärsprocessen. I fig. A2.18 försäljningsvolym kan ökas genom att direkt reglera processerna för montering och testning av datorer (utdata) i arbetet "Montering och testning av datorer".

Ris. A2.18. Ledningens feedback

Kommunikation med utgångsmekanism(utgångsmekanism), när produktionen från ett verk riktas till ett annat mekanism. Denna relation används mindre ofta än andra och visar att ett jobb förbereder de resurser som behövs för att utföra ett annat jobb (Fig. A2.19).

Ris. A2.19. Kommunikation med utgångsmekanism

Explicit pilar. En tydlig pil har ett enda jobb som källa och ett enda jobb som destination.

Gafflar och sammanslagning pilar. Samma data eller objekt som genereras av ett jobb kan användas i flera andra jobb samtidigt. Å andra sidan kan pilar som genereras i olika verk representera samma eller homogena data eller objekt som senare används eller bearbetas på ett ställe. För att simulera dessa situationer använder IDEF0 förgrenings- och sammanslagningspilar. För att förgrena pilen, i pilredigeringsläget, klicka på pilfragmentet och på motsvarande arbetssegment. För att slå samman två utgångspilar, i pilens redigeringsläge, klicka först på arbetsutgångens segment och sedan på motsvarande fragment av pilen.

Betydelsen av förgrening och sammanslagning av pilar förmedlas genom namngivning av varje gren av pilar. Det finns vissa regler för att namnge sådana pilar. Låt oss överväga dem på exemplet med grenpilar. Om pilen heter före gaffeln och ingen av grenarna heter efter gaffeln antas det att varje gren modellerar samma data eller objekt som grenen före gaffeln (fig. A2.20).

Ris. A2.20.

Om pilen är namngiven före förgreningen och efter förgreningen någon av grenarna också heter, antas det att dessa grenar motsvarar namngivningen. Om samtidigt en gren förblir namngiven efter förgrening, antas det att den modellerar samma data eller objekt som förgreningen före förgrening (Bild A2.21).

Ris. A2.21. Exempel på namngivning av en förgreningspil

Situationen är oacceptabel när pilen inte namnges före grenen och efter att grenen inte heter någon av grenarna. BPwin definierar den här pilen som ett syntaxfel.

Namnreglerna för att slå samman pilar är helt lika - ett fel betraktas som en pil som inte är uppkallad efter sammanslagningen, och innan sammanslagningen namngavs inte någon av dess grenar. För att namnge en separat gren av förgrenings- och sammanslagningspilar, välj endast en gren i diagrammet, ring sedan namnredigeraren och tilldela pilen ett namn. Det här namnet matchar endast den valda grenen.

Tunnelpilar... Nyinförda gränspilar i nedre nedbrytningsdiagrammet visas inom hakparenteser och visas inte automatiskt i det övre nivådiagrammet (fig. A2.22).

Ris. A2.22. Olöst pil

För att "dra" upp dem, högerklicka på de hakparenteserna på gränspilen och välj kommandot Arrow Tunnel från snabbmenyn (Bild A2.23).

Ris. A2.23. Välja ett kommando från snabbmenyn

Dialogrutan Border Ar Editor (Bild A2.24) visas.

Om du klickar på knappen Lös gränspilen kommer pilen att migrera till toppnivådiagrammet. Om du klickar på knappen Ändra till tunnel kommer pilen att tunnlas och faller inte på ett annat diagram. Tunnelpilen är avbildad med parenteser i slutet (Bild A2.25).

Ris. A2.24. Border Arrow Editor Dialog

Ris. A2.25. Tunnling av pilar

Tunnling kan användas för att skildra obetydliga pilar. Om det på något diagram av den lägre nivån är nödvändigt att avbilda obetydliga data eller objekt som inte bearbetas eller används av verken på den aktuella nivån, måste de skickas till en högre nivå (till överordnat diagram). Om denna information inte används i moderdiagrammet, måste den riktas ännu högre osv. Som ett resultat visas en obetydlig pil på alla nivåer och gör det svårt att läsa alla diagrammen där det finns närvarande. Utgången är tunnelpilen på lägsta nivå. Denna tunnel kallas "inte-i-förälder-diagram".

Ett annat exempel på tunnling kan vara situationen när mekanismens pil migrerar från den övre nivån till den nedre, och på den nedre nivån används denna mekanism på samma sätt i alla verk utan undantag. (Det antas att du inte behöver specificera mekanismens pil, det vill säga mekanismens pil på barnarbetet heter före gaffeln, och efter gaffeln har grenarna inte sitt eget namn). I det här fallet kan pilen på mekanismen på den nedre nivån raderas, varefter den kan tunnlas på överordnat diagram, och i kommentaren till pilen eller i ordboken kan du ange att mekanismen kommer att användas i alla verk i nedbrytningsdiagrammet för barn. Denna tunnel kallas inte-i-barn-arbete (Figur A2.25).

Numrering av verk och diagram... Alla modeller av modellen är numrerade. Numret består av ett prefix och ett nummer. Ett prefix av vilken längd som helst kan användas, men vanligtvis används prefixet A. Trädets sammanhangsarbete (root) är numrerat A0. Verken i av sönderdelningen A0 har siffrorna A1, A2, A3, etc. Arbeten med sönderdelningen på lägre nivå har numret på det överordnade arbetet och nästa serienummer, till exempel kommer arbetet med sönderdelning A3 att ha siffrorna A31, A32, AZZ, A34, etc. Arbeten bildar en hierarki där varje jobb kan ha en förälder och flera barnjobb och bilda ett träd. Ett sådant träd kallas ett träd av noder, och ovanstående numrering kallas en numrering av noder. IDEF0-diagram är dubbla numrerade. Först är diagrammen numrerade efter nod. Kontextdiagrammet har alltid siffran A-0, nedbrytningen av kontextdiagrammet är numret A0, resten av nedbrytningsdiagrammen är siffror med motsvarande nod (till exempel A1, A2, A21, A213, etc.). BPwin upprätthåller automatiskt numreringen efter noder, det vill säga under nedbrytningen skapas ett nytt diagram och motsvarande nummer tilldelas det automatiskt. Som ett resultat av undersökningen kan diagrammen förfinas och ändras, därför kan olika versioner av samma (ur synvinkeln för dess placering i trädet) bildas nedbrytningsdiagram. BPwin låter dig bara ha ett sönderdelningsdiagram i en modell vid en given nod. Äldre versioner av diagrammet kan lagras som en papperskopia eller som ett FEO-diagram. (Tyvärr finns det inget återställningsalternativ när du skapar FEO-diagram, det vill säga att du kan få FEO-sönderdelningar från diagrammet, men inte tvärtom.) I vilket fall som helst bör du skilja mellan olika versioner av samma diagram. För detta finns ett särskilt nummer - C-nummer, som måste tilldelas manuellt av modellens författare. C-nummer är en godtycklig sträng, men det rekommenderas att följa standarden när numret består av ett alfabetiskt prefix och ett sekvensnummer, med initialerna till författaren till diagrammet som prefix, och sekvensnumret är manuellt spåras av författaren, till exempel MCB00021.