Vykresľovanie diagramov idef3 (a idef0) – aký program robiť? Popis štandardu IDEF0 Obrázok v idef0 výber alternatívnych riešení

Workshop o použití IDEF0 na funkčný popis CAD softvéru

Workshop o použití IDEF0 na funkčný popis softvéru
Časť 1.

Ak analyzujete inzeráty na nábor zamestnancov firiem zaoberajúcich sa vývojom softvéru, v poslednom čase je akútny nedostatok projektových manažérov, ktorí dokážu kompetentne vykonávať zadávanie úloh. Problém nie je v tom, že nevedia sformulovať úlohu, ale v tom, že nedokážu správne vypracovať dokumentáciu zohľadňujúcu moderné konštrukčné štandardy. Už pre zákazníkanestačí dať pár listov napísaných vo Worde. Chce dokumentáciu vo formáte BPWin, ErWin, S-Designer, Power Designer, Rational Rose atď. Za každým z týchto nástrojov CASE je štandard. Tento článok je venovaný jednému z nich – IDEF0.

Úvod. Pri tvorbe dokumentácie si každý projektový manažér považuje za česť prísť s niečím „svojím“ – vlastným „superformátom“ na prezentáciu svojich nápadov. Zložitosť projektov rastie, objem dokumentácie k projektu rastie, dokumentácia presahuje rámec pracovnej skupiny ... a vtedy je jasné, že dokumentácia nevyhovuje zákazníkovi alebo skupine developerov, ktorí projekt finalizujú a podporovať to.

Väčšinou je projektovým manažérom buď triedny programátor (vedúci programátor témy – projektu), alebo človek, ktorý plynule ovláda cudzí jazyk a vyzná sa v programovaní. Toto sú hlavné výberové kritériá na pozíciu projektového manažéra. Toto je koreň problému. Môžete byť skvelý programátor alebo len dobrý zamestnanec, ale to nemá nič spoločné s návrhom dokumentácie.

Typicky sa špecifikácia pre každý typ manažéra posúva buď na popis modelu samotného programu (architektúra modulov, tried, DLL, štruktúra databázy a jej použitie atď.) alebo na popis užívateľa. -definované funkcie (čo majú robiť, aké formuláre majú byť v programe atď.).

Ideálne, keď si úlohu zadá klient. V tomto prípade môžete žiť podľa princípu „zákazník chce“, a pokiaľ je spokojný, dostávate od zákazníka peniaze. Ale stále viac projektov vzniká v hĺbke organizácie a následne sú ponúkané zákazníkovi. A v tomto prípade vystupuje do popredia kvalita dokumentácie, čo ste urobili a čo máte v úmysle urobiť. O všetkom v tomto prípade rozhoduje dokumentácia...

Štandard IDEF0 (Integrated Definition Function Modeling) je určený na funkčné modelovanie a je prijatý ako federálny štandard v USA. Štandard IDEF0 je jedným zo skupiny štandardov, ktoré sa bežne používajú na popis akéhokoľvek obchodného procesu. Jeho použitie na popis softvérových projektov je veľmi mladý smer, ale použitie IDEF0 zaručuje, že vás vaši partneri budú brať vážne ...

Skutočnou podmienkou pre získanie štatútu organizácie, ktorá spĺňa ISO9000, ISO9001 je použitie skupinových štandardov IDEF (IDEF0, IDEF1 atď.). Tieto štandardy sú pre organizáciu príležitosťou na zvýšenie predaja produktov, príležitosťou dokázať, že je „na hrebeni vlny“.

Mnoho programátorov vo veľkej miere používa CASE ErWin bez toho, aby vedeli, že je založený na štandarde IDEF1. Nie je to len niečo, čo máte radi alebo máte radi svojich zákazníkov. Toto je štandard - a to hovorí za všetko.

Stručné základné pojmy štandardu IDEF0.Štandard IDEF0 je založený na koncepte funkcie. Funkcia je riadená akcia na vstupe, ktorá vedie k výstupu pomocou nejakého mechanizmu, prostredníctvom ktorého sa táto akcia vykonáva.

Štandard IDEF0 je založený na troch základných princípoch:

1.princíp funkčného rozkladu - ľubovoľnú funkciu možno rozložiť (detailne, rozčleniť) na jednoduchšie funkcie;

2. princíp obmedzenia zložitosti - počet blokov na diagrame by mal byť 2 ... 6 (podmienka čitateľnosti);

3. princíp kontextu - modelovanie obchodného procesu začína vytvorením kontextového diagramu, ktorý zobrazuje iba jeden blok - hlavná funkcia modelovacieho systému, ktorá obmedzuje oblasť hranice modelovacieho systému (reguluje počiatočnú fázu pri zostavovaní modelu).

Diagramy IDEF0 sú zostavené pomocou blokov. Každý blok popisuje kompletnú akciu (funkciu).

Štyri strany bloku majú rôzne účely. Vstupné údaje sú zobrazené vľavo, výstupné údaje sú vpravo, ovládanie je hore a mechanizmus je dole.

Vstupné údaje - počiatočné zdroje pre funkciu opísanú blokom (počiatočné informácie, materiály).

Výstupné dáta - výsledné zdroje získané ako výsledok vykonania funkcie opísanej blokom (výstupné informácie, spracované podklady).

Ovládanie je to, čo ovplyvňuje proces vykonávania funkcie opísanej blokom a umožňuje ovplyvňovať výsledok vykonania akcie (ovládacie prvky, senzory, osoby).

Mechanizmus je to, čo sa daná činnosť vykonáva (stroje, zariadenia, ľudské zdroje, softvér).

Interakcia medzi blokmi je zobrazená ako oblúky (šípky). Niekedy sa strany bloku nazývajú smery a šípky sa nazývajú toky. Šípky sa dajú podpísať. Podpisy sú spojené s príslušnou šípkou pomocou cikcaku (blesku).

Celkový pohľad na implementáciu bloku diagramu IDEF0 je na obr.

Obr. Implementácia bloku použitého v diagramoch IDEF0.

Pri rozklade (detailovaní) funkcie novovygenerovaný diagram zobrazuje všetky prichádzajúce a odchádzajúce šípky (oblúky, toky) spojené s rozdeľovanou funkciou. Počet šípok na akejkoľvek úrovni diagramu a v akomkoľvek smere nie je obmedzený. Diagram sa nazýva blok (funkcia), ktorý sa delí. Iba názov kontextového diagramu (DK) sa zhoduje s názvom funkcie obsiahnutej v diagrame.

Vo svojej podstate diagramy tvoria strom. Akýkoľvek diagram funguje ako DC vo vzťahu k tým základným.

Ako príklad zvážte nejakú abstraktnú funkciu. Táto funkcia má vstupné dáta, dva heterogénne typy výstupných dát, je riadená vonkajším vplyvom a je realizovaná mechanizmami A a B. Príklad hlavného kontextového diagramu je na obr. 2 a detailná (rozložená) verzia táto funkcia pozostávajúca z dvoch funkcií (elementárnejších akcií) je znázornená na obr. Funkcie 1 a 2 je možné tiež podrobne rozložiť (rozložiť).

Obr. Príklad základného diagramu.

Obr. Príklad rozkladu hlavnej funkcie.

Diagram je umiestnený na špeciálnom formulári, ktorý obsahuje názov funkcie, jej grafický obrázok, označenie diagramu s úrovňou vnorenia, prepojenia s ďalšími funkciami, špeciálne informácie o autorovi, organizácii a popisovanom projekte.

Spojenia.Šípky alebo oblúky ukazujú vzťahy medzi blokmi. Šípky sa zvyčajne podpisujú. Podpisy šípok sú vybrané ako podstatné mená. Pre pohodlie sú šípky spojené s podpismi pomocou blesku. Pre čitateľnosť diagramu IDEF0 sa odporúča umiestniť štítky buď nad šípku alebo napravo od šípky.

Smerovanie vodičov zvyčajne začína údajmi. Vstupné údaje sú údaje potrebné na vykonanie funkcie. S týmto smerom sa otázky vynárajú len zriedka. Výstupné dáta sú dáta, ktoré sú výsledkom vykonania funkcie. Najjednoduchšia situácia je, keď je výstup vstupom do iného bloku. Je to tak vždy? Ak funkcia, spracúvajúca vstupné informácie, tvorí riadiaci príkaz, ide o riadenie. Situácia je približne rovnaká, keď funkcia tvorí formát údajov. Dátový formát je mechanizmus na prenos informácií.

Hlavné typy väzieb medzi blokmi v diagrame, vytvorených na základe výstupných informácií, sú znázornené na obr.

Obr. Typy prepojení medzi blokmi v diagrame. Podľa toho a) dátová komunikácia, b) riadiaca komunikácia, c) komunikácia mechanizmu, d) spätná väzba.

Spätná väzba je prepojenie, ktoré tvorí kruh medzi blokmi údajov, ovládacích prvkov alebo formátu. Príklad takéhoto spojenia je znázornený na obr. 2.d. Keď sa objaví tento vzťah, skontrolujte, či sa váš diagram scvrkáva na vývojový diagram. Prítomnosť takéhoto spojenia nie je znakom chyby.

Priorita bloku a číslovanie. Všetky bloky majú prednosť. Priorita blokov závisí od poradia ich vykonávania. Bloky vľavo a hore majú najvyššiu prioritu. Dominantné postavenie je horizontálne.

Číslovanie blokov (index blokov v diagrame) v diagrame je určené na základe priority. Číslovanie začína od jednotky. Kód grafu pozostáva z písmena „A“ a čísla. DC má kód A-0. Písmeno „A“ znamená aktívnu činnosť (z angl. Active). Diagram, ktorý je rozloženou verziou DC, bude mať kód A0. Každá položka v diagrame A0 bude kódovaná od A1 do A6 podľa priority. Na druhej strane, keď je jeden z blokov A1 ... A6 rozložený, kódy blokov novo rozloženého diagramu budú pozostávať z kódu rozloženého diagramu plus indexu zvoleného bloku. Kódy blokov grafu sa neopakujú v celom grafe.

Podľa počtu číslic v kóde diagramu môžete určiť úroveň diagramu - úroveň rozkladu DC. Je zvykom považovať DC za hlavnú úroveň a všetky ostatné sú z prvej úrovne rozkladu a vyššie.

Typy postupnosti akcií. Dáta môžu byť spracované postupne alebo paralelne.

Príkladom sekvenčného spracovania je napĺňanie adresára (doňho predsa nemôžete zapisovať dve adresy súčasne). Každý blok spracováva vždy iba jednu kópiu údajov, ktorá sa po každom spracovaní postupne mení. Bloky sú umiestnené buď postupne vodorovne, alebo šikmo z ľavého horného rohu do pravého dolného rohu.

Príklad paralelného spracovania – môžete sledovať televíziu a súčasne jesť jablko. V tomto prípade sa vykonajú dve akcie súčasne. Tieto akcie spolu nesúvisia. Takéto bloky sú v diagrame naskladané vertikálne na seba.

Na diagrame sa často nachádza skupina akcií (blokov), z ktorých sa v závislosti od určitej podmienky vykoná iba jedna. Takéto akcie sa nazývajú alternatívne akcie. Podmienka by mala byť aplikovaná na takéto bloky ako kontrolná akcia (výber akcie). Do diagramu sa odporúča zaviesť špeciálny blok, ktorý spracuje podmienky pre výber alternatívnej akcie (bloku). Tento blok generuje samostatné voliteľné príkazy pre každý blok.

Úloha ľudí v diagramoch IDEF0. Je to kontrola alebo mechanizmus? Vy rozhodujete, aké funkcie osoba vykonáva v opísanej úlohe. Ak je činnosť obsiahnutá v bloku riadená osobou, potom ovládajte. Ak akciu vykonáva osoba, potom mechanizmus. Všetko závisí od stupňa abstrakcie prezentácie vašej úlohy.

Existujú prípady, keď osoba (vrátane tej istej osoby) bude pôsobiť ako mechanizmus a kontrola pre jeden blok. TO SA STÁVA. Napríklad osoba napíše list. Je napísaný touto osobou a tá istá osoba kontroluje obsah tohto listu.

Kontrolné údaje. Manažment je tím. Ak príkaz obsahuje informatívnu časť (názvy, podmienky, termíny a pod.), tak informatívnou časťou príkazu sú vstupné dáta.

Najjednoduchším riešením je rozdeliť pôvodnú šípku na dve časti: ovládanie a údaje. Tieto šípky vedú na zodpovedajúce strany bloku. Obe oddelené šípky by mali byť zodpovedajúcim spôsobom označené.

Sergej Sokolov (Minsk, BSUIR)
E-mail:

Gennadij Vernikov

V súčasnosti v Rusku prudko vzrástol záujem o všeobecne uznávané štandardy riadenia na Západe, avšak v reálnej manažérskej praxi existuje jeden veľmi indikatívny moment. Mnohých vedúcich pracovníkov môže ešte stále zmiasť priama otázka na organizačnú štruktúru spoločnosti alebo návrh existujúcich obchodných procesov. Najpokročilejší manažéri, ktorí pravidelne čítajú ekonomické periodiká, spravidla začínajú kresliť hierarchické diagramy, ktoré sú zrozumiteľné len im, ale aj v tomto procese sa zvyčajne rýchlo dostanú do slepej uličky. To isté platí pre zamestnancov a manažérov rôznych služieb a funkčných celkov. Vo väčšine prípadov je jediným súborom pravidiel, podľa ktorých musí podnik fungovať, súbor individuálnych predpisov a popisov práce. Najčastejšie boli tieto dokumenty vypracované pred viac ako rokom, sú zle štruktúrované a neprepojené a v dôsledku toho sa na regáloch jednoducho hromadí prach. V súčasnosti bol takýto prístup opodstatnený, pretože počas formovania ruského trhového hospodárstva prakticky chýbal koncept konkurencie a nebolo potrebné brať do úvahy náklady - zisk bol obrovský. V dôsledku toho sme za posledné dva roky videli úplne zrozumiteľný obraz: veľké spoločnosti, ktoré rástli začiatkom 90. rokov, postupne strácajú svoje pozície, až sa úplne stiahnu z trhu. Čiastočne je to spôsobené tým, že podnik nezaviedol štandardy riadenia, úplne absentoval koncept funkčného modelu činnosti a poslania. Pomocou modelovania rôznych oblastí činnosti je možné efektívne analyzovať „úzke miesta“ v riadení a optimalizovať celkovú obchodnú schému. Ako však viete, v každom podniku majú najvyššiu prioritu len tie projekty, ktoré priamo prinášajú zisk, preto sa o prehľade činností a ich činnosti zvyčajne bavíme až počas citeľnej krízy vo vedení spoločnosti. reorganizácia.

Koncom 90-tych rokov, keď bol trh dostatočne konkurencieschopný a ziskovosť podnikov začala prudko klesať, pociťovali manažéri obrovské ťažkosti pri optimalizácii nákladov tak, aby produkty zostali ziskové a konkurencieschopné. Práve v tejto chvíli sa jednoznačne prejavila potreba mať pred očami model činnosti podniku, ktorý by odrážal všetky mechanizmy a princípy prepojenia rôznych subsystémov v rámci jedného podnikania.

Rovnaký koncept „modelovania podnikových procesov“ sa dostal do každodenného života väčšiny analytikov súčasne s tým, ako sa na trhu objavili komplexné softvérové produkty určené na komplexnú automatizáciu podnikového manažmentu. Takéto systémy vždy zahŕňajú hlboký predprojektový prieskum aktivít spoločnosti. Výsledkom tohto prieskumu je odborný posudok, v ktorom sú v jednotlivých odsekoch uvedené odporúčania na odstránenie „úzkych miest“ v riadení činností. Na základe tohto záveru sa bezprostredne pred implementáciou automatizačného systému vykonáva takzvaná reorganizácia podnikových procesov, niekedy dosť závažná a pre spoločnosť bolestivá. Tento, a prirodzene, rokmi vybudovaný tím, je vždy ťažké prinútiť „myslieť novým spôsobom“. Takéto komplexné prieskumy podnikov sú vždy zložité a výrazne sa líšia od prípadu k prípadu. Na riešenie takýchto problémov modelovania zložitých systémov existujú osvedčené metodiky a štandardy. Tieto štandardy zahŕňajú metodológie rodiny IDEF. S ich pomocou je možné efektívne zobrazovať a analyzovať modely činnosti širokého spektra komplexných systémov v rôznych sekciách. Zároveň si šírku a hĺbku skúmania procesov v systéme určuje samotný vývojár, čo umožňuje nepreťažovať vytvorený model zbytočnými dátami. V súčasnosti možno rodine IDEF priradiť tieto štandardy:

IDEF0 je metodológia funkčného modelovania. Pomocou vizuálneho grafického jazyka IDEF0 sa skúmaný systém javí vývojárom a analytikom vo forme súboru vzájomne súvisiacich funkcií (funkčných blokov – v zmysle IDEF0). Typicky je modelovanie IDEF0 prvým krokom pri učení sa o akomkoľvek systéme;

IDEF1 je metodika modelovania informačných tokov v rámci systému, ktorá umožňuje zobraziť a analyzovať ich štruktúru a vzťahy;

IDEF1X (IDEF1 Extended) je metodika pre budovanie relačných štruktúr. IDEF1X je typ metodológie Entity-Relationship (ER) a zvyčajne sa používa na modelovanie relačných databáz relevantných pre daný systém;

IDEF2 je metodika pre dynamické modelovanie vývoja systémov. Kvôli veľmi vážnym ťažkostiam pri analýze dynamických systémov sa od tohto štandardu prakticky upustilo a jeho vývoj bol pozastavený už v počiatočnom štádiu. V súčasnosti však existujú algoritmy a ich počítačové implementácie, ktoré umožňujú zmeniť množinu statických diagramov IDEF0 na dynamické modely založené na "farebných Petriho sieťach" (CPN - Color Petri Networks);

IDEF3 je metodika dokumentácie procesov prebiehajúcich v systéme, ktorá sa využíva napríklad pri štúdiu technologických procesov v podnikoch. IDEF3 popisuje scenár a pracovný postup pre každý proces. IDEF3 má priamy vzťah s metodikou IDEF0 - každá funkcia (funkčný blok) môže byť reprezentovaná ako samostatný proces pomocou IDEF3;

IDEF4 je metodika pre budovanie objektovo orientovaných systémov. Nástroje IDEF4 vám umožňujú vizuálne zobraziť štruktúru objektov a základné princípy ich interakcie, čím vám umožňujú analyzovať a optimalizovať komplexné objektovo orientované systémy;

IDEF5 je metodológia pre ontologické štúdium zložitých systémov. Pomocou metodiky IDEF5 možno ontológiu systému opísať pomocou špecifického slovníka pojmov a pravidiel, na základe ktorých možno vytvárať spoľahlivé výpovede o stave posudzovaného systému v určitom časovom bode. Na základe týchto vyjadrení sa tvoria závery o ďalšom vývoji systému a vykonáva sa jeho optimalizácia.
V tomto článku sa pozrieme na najčastejšie používanú metodiku funkčného modelovania IDEF0.

História štandardu IDEF0

Metodiku IDEF0 možno považovať za ďalšiu etapu vo vývoji známeho grafického jazyka na popis funkčných systémov SADT (Structured Analysis and Design Teqnique). Pred niekoľkými rokmi vyšlo v Rusku malé vydanie knihy s rovnakým názvom, ktorá bola venovaná popisu základných princípov konštrukcie diagramov SADT. Historicky bol IDEF0 ako štandard vyvinutý v roku 1981 ako súčasť rozsiahleho programu priemyselnej automatizácie s názvom ICAM (Integrated Computer Aided Manufacturing) a bol navrhnutý americkým letectvom. Samotná rodina štandardov IDEF zdedila svoje označenie z názvu tohto programu (IDEF = ICAM DEFinition). V procese praktickej implementácie čelili účastníci programu ICAM potrebe vyvinúť nové metódy na analýzu interakčných procesov v priemyselných systémoch. Zároveň okrem vylepšenej sady funkcií na popis obchodných procesov bola jednou z požiadaviek nového štandardu aj dostupnosť efektívnej metodiky interakcie v rámci „analytika-špecialistu“. Inými slovami, nová metóda mala zabezpečiť skupinovú prácu na tvorbe modelu s priamou účasťou všetkých analytikov a špecialistov zapojených do projektu.

Výsledkom hľadania vhodných riešení sa zrodila metodika funkčného modelovania IDEF0. Od roku 1981 prešiel štandard IDEF0 niekoľkými menšími zmenami, väčšinou obmedzujúceho charakteru a jeho posledná revízia bola vydaná v decembri 1993 americkým Národným inštitútom pre štandardy a technológie (NIST).

Základné prvky a koncepty IDEF0

Grafický jazyk IDEF0 je prekvapivo jednoduchý a harmonický. Metodika je založená na štyroch hlavných konceptoch.

Prvým je koncept Activity Box. Funkčný blok je graficky znázornený vo forme obdĺžnika (pozri obr. 1) a zosobňuje určitú špecifickú funkciu v rámci uvažovaného systému. Podľa požiadaviek normy musí byť názov každého funkčného bloku formulovaný v slovesnom duchu (napríklad „vyrábať služby“, nie „výroba služieb“).

Každá zo štyroch strán funkčného bloku má svoj špecifický význam (úlohu), pričom:

Horná strana je ovládanie;

Ľavá strana je nastavená na Vstup;

Pravá strana je nastavená na Výstup;

Spodná strana je nastavená na Mechanizmus.

Každý funkčný blok v rámci jedného uvažovaného systému musí mať svoje jedinečné identifikačné číslo.

Obrázok 1. Funkčný blok.

Druhou „veľrybou“ metodiky IDEF0 je koncept oblúka rozhrania (Arrow). Oblúky rozhrania sa tiež často nazývajú prúdy alebo šípky. Oblúk rozhrania zobrazuje prvok systému, ktorý je spracovaný funkčným blokom alebo inak ovplyvňuje funkciu zobrazenú týmto funkčným blokom.

Grafické zobrazenie oblúka rozhrania je jednosmerná šípka. Každý oblúk rozhrania musí mať svoj vlastný jedinečný názov (štípka šípky). Ako vyžaduje norma, názov musí byť podstatným menom obrat.

Pomocou oblúkov rozhrania sa zobrazujú rôzne objekty, ktoré do tej či onej miery určujú procesy prebiehajúce v systéme. Takýmito objektmi môžu byť prvky reálneho sveta (súčiastky, autá, zamestnanci atď.) alebo toky údajov a informácií (dokumenty, údaje, pokyny atď.).

V závislosti od toho, na ktorú zo strán sa tento oblúk rozhrania hodí, sa nazýva „prichádzajúce“, „odchádzajúce“ alebo „kontrola“. Okrem toho iba funkčné bloky môžu byť „zdrojom“ (začiatok) a „výlevkou“ (koncom) každého funkčného oblúka, pričom „zdrojom“ môže byť iba výstupná strana bloku a „výlevka“ môže byť ľubovoľná z troch zostávajúcich.

Je potrebné poznamenať, že každý funkčný blok musí mať podľa požiadaviek normy aspoň jeden oblúk ovládacieho rozhrania a jeden výstupný. Je to pochopiteľné – každý proces musí dodržiavať nejaké pravidlá (zobrazené ovládacím oblúkom) a musí priniesť nejaký výsledok (odchádzajúci oblúk), inak nemá zmysel o ňom uvažovať.

Pri konštrukcii IDEF0 - diagramov je dôležité správne oddeliť vstupné oblúky rozhrania od riadiacich, čo často nie je jednoduché. Napríklad obrázok 2 zobrazuje funkčný blok "Spracovanie obrobku".

V reálnom procese dostane pracovník vykonávajúci spracovanie obrobok a technologické pokyny na spracovanie (prípadne bezpečnostné pravidlá pri práci so strojom). Môže sa mylne zdať, že obrobok aj dokument s technologickými pokynmi sú prichádzajúce predmety, ale nie je to tak. V skutočnosti sa v tomto procese obrobok spracováva podľa pravidiel uvedených v technologických pokynoch, ktoré by mali byť zobrazené na oblúku ovládacieho rozhrania.

Obrázok 2

Iná vec je, keď technologické pokyny spracováva hlavný technológ a robí v nich zmeny (obr. 3). V tomto prípade sa zobrazujú ako už prichádzajúci oblúk rozhrania a objektom riadenia sú napríklad nové priemyselné normy, na základe ktorých sa tieto zmeny vykonávajú.

Obrázok 3.

Vyššie uvedené príklady zdôrazňujú zdanlivo podobnú povahu prichádzajúcich a odchádzajúcich oblúkov rozhrania, ale vždy existujú určité rozdiely pre systémy rovnakej triedy. Napríklad v prípade podnikov a organizácií existuje päť hlavných typov objektov: materiálové toky (súčiastky, tovar, suroviny atď.), finančné toky (peňažné a bezhotovostné, investície atď.), doklad toky (obchodné, finančné a organizačné dokumenty), informačné toky (informácie, zámer, ústne pokyny a pod.) a zdroje (zamestnanci, stroje, stroje a pod.). Zároveň v rôznych prípadoch môžu byť všetky typy objektov zobrazené pomocou prichádzajúcich a odchádzajúcich oblúkov rozhrania, ktoré riadia iba tie, ktoré súvisia s tokmi dokumentov a informácií, a pomocou oblúkov-mechanizmov možno zobraziť iba zdroje.

Povinná prítomnosť oblúkov ovládacieho rozhrania je jedným z hlavných rozdielov štandardu IDEF0 od ostatných metodík tried DFD (Data Flow Diagram) a WFD (Work Flow Diagram).

Tretím základným konceptom štandardu IDEF0 je rozklad. Princíp rozkladu sa používa pri rozdeľovaní zložitého procesu na jednotlivé funkcie. V tomto prípade úroveň podrobnosti procesu určuje priamo vývojár modelu.

Dekompozícia umožňuje postupne a štruktúrovane reprezentovať model systému vo forme hierarchickej štruktúry jednotlivých diagramov, vďaka čomu je menej preťažený a ľahko stráviteľný.

Model IDEF0 vždy začína prezentáciou systému ako celku – jedného funkčného bloku s oblúkmi rozhrania presahujúcimi uvažovanú oblasť. Takýto diagram s jedným funkčným blokom sa nazýva kontextový diagram a označuje sa identifikátorom "A-0".

Vysvetľujúci text pre kontextový diagram musí vo forme stručného popisu uvádzať Účel zostavenia diagramu a fixovať uhol pohľadu (Pohľad).

Stanovenie a formalizácia cieľa vývoja modelu IDEF0 je mimoriadne dôležitým bodom. V skutočnosti tento cieľ identifikuje relevantné oblasti v skúmanom systéme, na ktoré by sa malo zamerať ako prvé. Ak napríklad modelujeme činnosť podniku, aby sme na základe tohto modelu v budúcnosti vybudovali informačný systém, potom sa tento model bude výrazne líšiť od toho, ktorý by sme vyvinuli pre ten istý podnik, ale s cieľom optimalizácie dodávateľských reťazcov.

Hľadisko definuje hlavný smer vývoja modelu a úroveň požadovaných detailov. Jasná fixácia pohľadu vám umožňuje vyložiť model, odmietnuť detaily a študovať jednotlivé prvky, ktoré nie sú potrebné, na základe zvoleného pohľadu na systém. Napríklad funkčné modely toho istého podniku z pohľadu hlavného technológa a finančného riaditeľa sa budú výrazne líšiť v smere ich detailovania. Je to spôsobené tým, že finančného riaditeľa v konečnom dôsledku nezaujímajú aspekty spracovania surovín na výrobných strojoch a hlavný technológ nepotrebuje nakreslené schémy finančných tokov. Správna voľba uhla pohľadu výrazne skracuje čas strávený stavbou finálneho modelu.

V procese rozkladu je funkčný blok, ktorý v kontextovom diagrame zobrazuje systém ako celok, prevŕtaný do iného diagramu. Výsledný diagram druhej úrovne obsahuje funkčné bloky, ktoré zobrazujú hlavné podfunkcie funkčného bloku kontextového diagramu a vo vzťahu k nemu sa nazýva Child diagram (každý z funkčných blokov patriacich do podradeného diagramu sa v tomto poradí nazýva Child Box). . Rodičovský funkčný blok sa nazýva rodičovský blok vo vzťahu k podradenému diagramu (Parent Box) a diagram, ku ktorému patrí, sa nazýva rodičovský diagram (Parent Diagram). Každá z podfunkcií podradeného diagramu môže byť ďalej podrobne rozpísaná podobným rozkladom zodpovedajúceho funkčného bloku. Je dôležité poznamenať, že v každom prípade rozkladu funkčného bloku sú všetky oblúky rozhrania zahrnuté v tomto bloku alebo z neho vychádzajúce v podradenom diagrame. Tým sa dosiahne štrukturálna integrita modelu IDEF0. Princíp rozkladu je názorne znázornený na obrázku 4. Pozor si treba dať na vzťah medzi číslovaním funkčných blokov a diagramami – každý blok má na diagrame svoje jedinečné sériové číslo (číslo v pravom dolnom rohu obdĺžnika), a označenie v pravom uhle označuje číslo podradeného diagramu pre tento blok ... Neprítomnosť tohto označenia znamená, že pre tento blok nedochádza k rozkladu.

Často sa vyskytujú prípady, keď jednotlivé oblúky rozhrania nemá zmysel ďalej brať do úvahy v podriadených diagramoch pod určitou úrovňou v hierarchii, alebo naopak - jednotlivé oblúky nad určitou úrovňou nemajú praktický význam. Napríklad nemá zmysel odrážať oblúk rozhrania predstavujúci "detail" na vstupe do funkčného bloku "Zapnite sústruh" na diagramoch vyšších úrovní - to len preťaží diagramy a sťaží ich pochopenie. Na druhej strane je potrebné zbaviť sa jednotlivých „koncepčných“ oblúkov rozhrania a nedetailovať ich hlbšie, ako je určitá úroveň. Na vyriešenie takýchto problémov štandard IDEF0 poskytuje koncepciu tunelovania. Zápis „Arrow Tunnel“ vo forme dvoch zátvoriek okolo začiatku oblúka rozhrania označuje, že tento oblúk nebol zdedený z funkčného nadradeného bloku a objavil sa (z „tunela“) iba v tomto diagrame. Na druhej strane, rovnaké označenie okolo konca (šípka) oblúka rozhrania v bezprostrednej blízkosti bloku prijímača znamená skutočnosť, že tento oblúk je zobrazený a nebude sa brať do úvahy v podradenom diagrame tohto bloku. Najčastejšie sa stáva, že jednotlivé objekty a im zodpovedajúce oblúky rozhrania sa na niektorých medzistupňoch hierarchie neberú do úvahy – v tomto prípade sa najskôr „vrhnú do tunela“ a potom sa v prípade potreby „vrátia z tunela“.

Posledným konceptom v IDEF0 je Glosár. Pre každý z prvkov IDEF0: diagramy, funkčné bloky, oblúky rozhrania existujúci štandard predpokladá vytvorenie a udržiavanie súboru relevantných definícií, kľúčových slov, naratívov atď., ktoré charakterizujú objekt zobrazený týmto prvkom. Tento súbor sa nazýva slovník a je popisom podstaty tohto prvku. Napríklad pre oblúk ovládacieho rozhrania „platobný príkaz“ môže slovník obsahovať zoznam polí dokumentu zodpovedajúcich oblúku, požadovaný súbor víz atď. Slovník pojmov harmonicky dopĺňa grafický jazyk a poskytuje diagramom potrebné dodatočné informácie.

Obrázok 4. Rozklad funkčných blokov.

Princípy obmedzenia zložitosti diagramov IDEF0

Modely IDEF0 zvyčajne nesú komplexné a koncentrované informácie a aby sa obmedzilo ich preťaženie a aby boli čitateľné, v zodpovedajúcom štandarde sú prijaté zodpovedajúce limity zložitosti:

Obmedzenie počtu funkčných blokov na diagrame na tri až šesť. Horná hranica (šesť) núti dizajnéra používať hierarchie pri popise zložitých položiek a dolná hranica (tri) zaisťuje, že na príslušnom diagrame je dostatok podrobností na odôvodnenie jeho vytvorenia;

Obmedzenie počtu oblúkov rozhrania vhodných pre jeden funkčný blok (ponechávajúc jeden funkčný blok) na štyri.
Samozrejme, nie je vôbec potrebné prísne dodržiavať tieto obmedzenia, ale ako ukazujú skúsenosti, sú veľmi praktické v reálnej práci.

Disciplína skupinovej práce na vývoji modelu IDEF0

Štandard IDEF0 obsahuje súbor postupov, ktoré umožňujú veľkej skupine ľudí z rôznych oblastí modelovaného systému vyvinúť a dohodnúť sa na modeli. Proces vývoja je zvyčajne iteratívny a pozostáva z nasledujúcich podmienených fáz:

Vytvorenie modelu skupinou odborníkov z rôznych oblastí podniku. Táto skupina sa v zmysle IDEF0 nazýva Autori. Budovanie počiatočného modelu je dynamický proces, počas ktorého sa autori pýtajú kompetentných ľudí na štruktúru rôznych procesov. Na základe existujúcich ustanovení, dokumentov a výsledkov prieskumu je vytvorený Modelový návrh modelu.

Distribúcia návrhu na posúdenie, schválenie a pripomienkovanie. V tejto fáze prebieha diskusia o návrhu modelu so širokým okruhom kompetentných osôb (v zmysle čitateľov IDEF0) v podniku. Zároveň je každý z diagramov návrhu modelu písomne kritizovaný a pripomienkovaný a následne odovzdaný autorovi. Autor sa zas s kritikou stotožní aj písomne alebo ju s načrtnutím logiky rozhodovania zamietne a prepracovaný návrh vráti na ďalšie posúdenie. Tento cyklus pokračuje, kým autori a čitatelia nedospejú ku konsenzu.

Schválenie modelu. Schválenie dohodnutého vzoru nastáva vedúcim pracovnej skupiny v prípade, že autori vzoru a čitatelia nebudú mať nezhody o jeho primeranosti. Finálny model je konzistentný pohľad na podnik (systém) z daného uhla pohľadu a za daným účelom.
Viditeľnosť grafického jazyka IDEF0 robí model dobre čitateľným pre osoby, ktoré sa nezúčastnili projektu jeho tvorby, ako aj efektívnym na organizovanie výstav a prezentácií. V budúcnosti je možné na základe vytvoreného modelu organizovať nové projekty zamerané na uskutočnenie zmien v podniku (v systéme).

Vlastnosti národnej praxe používania funkčného modelovania pomocou IDEF0

V posledných rokoch záujem o metodiky rodiny IDEF v Rusku neustále rastie. Neustále to pozorujem a pozerám sa na štatistiky hovorov na moju osobnú webovú stránku (http://www.vernikov.ru), ktorá stručne popisuje základné princípy týchto noriem. Zároveň by som záujem o štandardy ako IDEF3-5 označil za teoretický a v IDEF0 celkom prakticky opodstatnený. V skutočnosti sa prvé Case-tools umožňujúce zostaviť diagramy DFD a IDEF0 objavili na ruskom trhu už v roku 1996, súčasne s vydaním populárnej knihy o princípoch modelovania v štandardoch SADT.

Napriek tomu väčšina vedúcich pracovníkov stále považuje praktickú aplikáciu modelovania v štandardoch IDEF skôr za módny prejav než za efektívny spôsob optimalizácie existujúceho systému riadenia podniku. S najväčšou pravdepodobnosťou je to spôsobené výrazným nedostatkom informácií o praktickej aplikácii týchto metodológií a nevyhnutnou softvérovou zaujatosťou veľkej väčšiny publikácií.

Nie je žiadnym tajomstvom, že takmer všetky projekty na prieskum a analýzu finančných a ekonomických aktivít podnikov v súčasnosti v Rusku sú tak či onak spojené s výstavbou automatizovaných riadiacich systémov. Vďaka tomu sa štandardy IDEF v ponímaní väčšiny stali podmienečne neoddeliteľné od implementácie informačných technológií, hoci s ich pomocou je niekedy možné efektívne riešiť aj malé lokálne problémy, doslova pomocou ceruzky a papier.

Pri realizácii zložitých projektov podnikových prieskumov vám vývoj modelov v štandarde IDEF0 umožňuje vizuálne a efektívne zobraziť celý mechanizmus podnikovej činnosti v požadovanom kontexte. Najdôležitejšia je však spolupráca, ktorú IDEF0 poskytuje. V mojej praxi sa vyskytlo nemálo prípadov, keď stavba modelu prebiehala za priamej pomoci pracovníkov rôznych oddelení. Konzultant im zároveň v pomerne krátkom čase vysvetlil základné princípy IDEF0 a naučil ich pracovať s príslušným aplikačným softvérom. Výsledkom bolo, že pracovníci rôznych oddelení vytvorili IDEF diagramy činnosti ich funkčného celku, ktoré mali zodpovedať nasledujúce otázky:

Čo ide na jednotku „na vchode“?

Aké funkcie a v akom poradí sa vykonávajú v rámci jednotky?

Kto je zodpovedný za jednotlivé funkcie?

Čím sa riadi vykonávateľ pri výkone jednotlivých funkcií?

Aký je výsledok práce jednotky (výkon)?

Po odsúhlasení návrhov diagramov v rámci každého konkrétneho oddelenia ich konzultant zostaví do návrhu podnikového modelu, v ktorom sú prepojené všetky vstupné a výstupné prvky. V tejto fáze sa zaznamenávajú všetky nezrovnalosti jednotlivých diagramov a ich kontroverzné miesta. Ďalej tento model opäť prechádza cez funkčné oddelenia na ďalšie odsúhlasenie a vykonanie potrebných úprav. Výsledkom je, že v pomerne krátkom čase a so zapojením minima ľudských zdrojov z poradenskej spoločnosti (a tieto zdroje, ako viete, sú veľmi drahé), sa získa model podniku IDEF0 podľa „ „Ako je“, a čo je dôležitejšie, predstavuje podnik s pozíciami zamestnancov, ktorí v ňom pracujú a dôkladne poznajú všetky nuansy, vrátane neformálnych. V budúcnosti bude tento model prenesený na analýzu a spracovanie k podnikovým analytikom, ktorí budú hľadať úzke miesta v riadení spoločnosti a optimalizovať hlavné procesy, transformujúc model „Ako je“ na zodpovedajúci pohľad „Ako by mal byť“. Na základe týchto zmien sa robí konečný záver, ktorý obsahuje odporúčania na reorganizáciu systému riadenia.

Samozrejme, takýto prístup si vyžaduje množstvo organizačných opatrení predovšetkým zo strany vedenia skúmaného podniku. Je to spôsobené tým, že táto technika znamená pridelenie dodatočných zodpovedností niektorým zamestnancom pri osvojovaní a praktickom uplatňovaní nových metodík. To sa však v konečnom dôsledku vypláca, keďže jedna až dve hodiny práce jednotlivých zamestnancov počas niekoľkých dní navyše môžu výrazne ušetriť na platbe poradenských služieb tretej spoločnosti (čo v každom prípade odtrhne od prácu tých istých zamestnancov s dotazníkmi a otázkami). Čo sa týka samotných zamestnancov podniku, tak či onak som sa z ich strany nestretol so žiadnym vyjadreným odporom.

Záver z toho všetkého možno urobiť takto: nie je vôbec potrebné zakaždým vymýšľať riešenia štandardných problémov. Kedykoľvek stojíte pred potrebou analyzovať konkrétny funkčný systém (od systému návrhu kozmickej lode až po proces prípravy komplexnej večere), použite rokmi overené metódy. Jednou z týchto metód je IDEF0, ktorá vám pomocou jednoduchých a zrozumiteľných nástrojov umožňuje riešiť zložité životné problémy.

Skratka IDEF0, ktorá je dnes známa nielen v úzkych kruhoch, je prvou metodikou na štandardizáciu práce na podnikových procesoch. Bol vyvinutý v polovici minulého storočia ako súčasť leteckého projektu v Spojených štátoch a po preukázaní jeho účinnosti sa stal federálnym štandardom. V našej krajine bol v roku 2000 pripravený dokument „ Metodika funkčného modelovania IDEF0. Usmerňovací dokument Metodika funkčného modelovania IDEF0 Usmerňovací dokument. Oficiálne vydanie. Gosstandart Ruska RD IDEF0 - 2000. Vyvinutý Výskumným centrom CALS - Technologies "Applied Logistics". Prijaté a uvedené do platnosti dekrétom Gosstandartu Ruska z roku 2000, Moskva“ Ale ako štandard to nebolo nikdy schválené. Aj keď to nezabránilo tomu, aby sa táto metodika stala jedným z najpopulárnejších nástrojov na grafické modelovanie podnikových procesov u nás. V tomto článku vás pozývam, aby ste si prezreli model IDEF0 a zhodnotili aktuálnu relevantnosť tohto prístupu.

Základné pojmy a skratky

Poďme si to trochu priblížiť názvami kľúčových prvkov metodiky. Grafický štandard IDEF0 je súčasťou metodiky SADT (Structured Analysis and Design Technique). IDEF je skratka pre definíciu ICAM a ICAM je odvodený od Integrated Computer Aided Manufacturing, čo sa prekladá ako integrovaná počítačová automatizácia výroby. Metodika SADT je celá rodina 15 rôznych modelov, ktoré spolu mali umožniť štúdium štruktúry, parametrov a charakteristík výrobno-technických a organizačno-ekonomických systémov.

IDEF0 je funkčný model, ktorý je jadrom všetkých ostatných štruktúr, spája informačné a materiálové toky, organizačnú štruktúru, kontrolné akcie a samotnú činnosť spoločnosti. Grafický štandard pre modelovanie procesov sa nazýva aj notácia. To znamená, že notácia je systém požiadaviek a pravidiel na zostavenie modelu činnosti v tej či onej forme. Preto je vhodné nazývať IDEF0 zápis, ktorý je súčasťou metodiky SADT.

Notácia IDEF0 je pomerne prísna technika, ktorá bola pôvodne vyvinutá, podobne ako štandardy technického dizajnu, pre ručné modelovanie. Obsahuje teda požiadavky na umiestnenie šípok, formát všetkých prvkov, obsah informačného rámca pre diagram IDEF0 a pod.. Keďže činnosť firmy je zložitým viacúrovňovým systémom akcií, schém je vždy veľa, napr. a vyžaduje sa jednoznačná systematizácia a navigácia všetkými prvkami modelu. Teraz to robia hlavne počítačové systémy, ktoré podporujú modelovanie v tomto zápise. Na území Ruska sú dnes najznámejšie a dostupné systémy AllFusion Process Modeler a Business Studio. Recenzii týchto systémov plánujem venovať samostatné články.

Funkčný blok

Ústredným prvkom modelu IDEF0 je funkcia, ktorá je na schéme zobrazená ako funkčný blok- obdĺžnik, vo vnútri ktorého je dej označený vo forme slovesného podstatného mena. Akcia môže byť veľmi rôzna v rozsahu – od aktivít spoločnosti vo všeobecnosti až po špecifickú manipuláciu. Príklady: „Výroba a predaj keramického riadu“ a „Kresba na výrobku“.

Povinné prvky funkčného bloku v IDEF0

Bez ohľadu na rozsah akcií sú všetky funkcie zobrazené jednotne a nevyhnutne obsahujú 4 kľúčové prúdy, ktoré sú pevne priradené po stranách funkčného bloku:

vľavo - vstupy alebo zdroje použité na vykonávanie funkcie;
vpravo - výstupy alebo výsledky vykonania funkcie;
navrchu – kontrolné činnosti, ktoré určujú, ako a koľko výsledkov je potrebné dosiahnuť;
nižšie - mechanizmy, ktoré odrážajú, kto as pomocou čoho by mal túto prácu vykonávať.

Tento prístup vám umožňuje trochu ušetriť na vysvetleniach v diagramoch a dosiahnuť jednoznačnosť v zobrazení tokov, čo robí celý model štíhlym.

Na vytvorenie funkčného modelu vyžaduje metodika IDEF0 dodržiavanie nasledujúcich pravidiel.

Vstupy sú zdroje, ktoré úplne prenášajú svoju hodnotu na výstupy, to znamená, že sa vynakladajú na vytvorenie výsledku v plnej miere, a mechanizmy sú zdroje, ktoré prenášajú svoju hodnotu len čiastočne (zariadenia prostredníctvom odpisov a ľudia prostredníctvom miezd).
Manažment je nevyhnutným prvkom modelu, pretože viaže všetky činnosti na systém podnikových predpisov, jasne uvádza, ktoré pravidlá a požiadavky je potrebné dodržiavať v procese výkonu funkcie. Často sa s týmto tokom zaobchádza formálne, ale schéma stráca svoju prísnosť a niekedy aj zmysel.
Každý funkčný blok musí mať na každej strane aspoň jednu šípku (keďže žiadna práca nemôže existovať bez zdrojov alebo výsledkov a pokyn bez vykonávateľa alebo pokynu bude neúplný).

Uvažovaná schéma je „stavebným kameňom“ prístupu IDEF0. Funkčné modelovanie zahŕňa postupný prechod od všeobecného ku konkrétnemu prostredníctvom rozkladu. Dekompozícia je „prehĺbenie“ do uvažovanej funkcie, jej rozdelenie na menšie funkcie. Navyše, keď je funkcia najvyššej úrovne prezentovaná zovšeobecneným spôsobom a po jej rozklade, je vhodné ju nazvať procesom.

Kontextový diagram

Na úplne najvyššej úrovni je firma prezentovaná ako „čierna skrinka“, v ktorej prebieha nejaká činnosť, prenášajúca vjazdy na východy. Táto úroveň sa zvyčajne nazýva "", to znamená diagram popisujúci kontext aktivít spoločnosti. Kontextový diagram navyše zobrazuje kľúčové charakteristiky celého modelu.

Cieľom je konkrétna formulácia účelu modelu, pomocou ktorej možno v budúcnosti kontrolovať presnosť konštrukcie modelu.
Uhol pohľadu – na koho tvári je model postavený, keďže model je vždy závislý od svojho autora a zamerania pozornosti. Ak staviame všeobecný model podniku, potom sa zvyčajne prezentuje z pohľadu jeho riaditeľa.
Typ modelu je údaj o tom, aké informácie sú zobrazené na diagramoch. Môžu existovať 2 hlavné možnosti: AKO JE ("ako je") alebo BYŤ ("ako bude"). Toto oddelenie je nevyhnutné, pretože môžeme zostaviť modely pre analýzu aktivity a jej transformáciu. Musíme si byť jasne vedomí toho, čo robíme, a tiež túto informáciu sprostredkovať ostatným.

Kontextový diagram teda obsahuje v čo najzovšeobecnenejšej podobe popis činnosti podniku, ktorým prenikajú toky spájajúce podnik s vonkajším svetom. Myslím si, že by sme sa im mali venovať aj podrobnejšie.

Hlavné prúdy

Prax ukázala, že aj napriek zdanlivej jednoduchosti a formálnosti tejto úrovne je často potrebné na nej zotrvať pridlho, keďže by sa tu mali prejaviť všetky výsledky, ktoré sú pre majiteľa a trh významné. Chyba môže viesť k vytvoreniu modelov, ktoré nespĺňajú úlohy stanovené pre podnikanie. Ak chcete overiť, či sa odrážajú významné toky, uistite sa, že vo vašom diagrame sú prítomné všetky 4 hlavné typy tokov.

Materiál: materiály a komponenty na vstupe a hotové výrobky na výstupe.
Klientská strana: potenciálny klient pri vstupe a spokojný pri výstupe.
Finančné: na vstupe sú to zvyčajne investície, platby zákazníkov (výnosy), pôžičky a iné príjmy; výstupom sú platby dodávateľom, dane, splátky úverov a zisky.
Informačné: na vstupe sú to všetky toky informácií o vonkajšom prostredí (podmienky na trhu, správanie konkurentov, technologické inovácie a pod.) a na výstupe ide o toky informácií, ktoré o sebe spoločnosť komunikuje svete (všetky reklamné informácie, ako aj všetky druhy podávania správ pred regulačnými orgánmi).

Upozorňujeme, že spoločnosť je otvorený systém a nič neprichádza ani neodchádza. Firma je schopná transformovať len prichádzajúce toky na odchádzajúce, a ak to robí dobre, tak vzniká dodatočný cash flow (zisk), ktorý v istom zmysle odráža kvalitu celého systému.

(klikni na zväčšenie)

Je dobré, ak každý z týchto typov tokov zvýrazníte vlastnou farbou, aby ste ľahko rozlíšili pohyb zdrojov a neprehliadli dôležité body. Často je napríklad možné pozorovať absenciu klienta v tokoch spoločnosti, preto je práca s ním založená na zvyškovom princípe – klient sa často cíti ako prekážka pre zamestnancov spoločnosti, ktorých úlohy sú zamerané na spracovanie tok dokumentov.

Kontrolné šípky môžu byť reprezentované len 1 typom toku - informačného toku, ktorý možno rozdeliť na 2 poddruhy. Prvým sú dokumenty ako:

zákony a predpisy;
objednávky, objednávky;
pokyny a predpisy;
plány;
projektová dokumentácia a pod.

Druhou sú nezdokumentované informácie, ktoré najčastejšie zahŕňajú požiadavky vlastníkov.

A nakoniec mechanizmy - existujú iba 2 typy tokov: vybavenie (materiál) a umelci (oddelenia a ľudia). Nesmú tu byť žiadne doklady, rovnako ako na kontrolných bodoch nemôžu byť žiadni ľudia!

Model poskytuje priebežné číslovanie pre navigáciu. Kontextový diagram má číslo "A-0". V budúcnosti dostane každý funkčný blok svoje vlastné číslo, bez ohľadu na to, aký hlboký je rozklad.

Rozklad

Po vypracovaní tokov kontextového diagramu môžeme pristúpiť k rozkladu. Keď sa presunieme o úroveň nižšie, ako keby ste otvorili „čiernu skrinku“, najskôr vidíme prázdny hárok so šípkami, ktoré boli pripevnené k funkčnému bloku.

(klikni na zväčšenie)

A tu začína skutočné funkčné modelovanie – musíme pochopiť, aký súbor akcií môže tieto toky prepojiť a zabezpečiť, aby boli splnené všetky požiadavky. Obtiažnosť spočíva v tom, že v spoločnosti je veľa akcií a na diagrame máme právo zobraziť nie viac ako 9 funkcií, inak sa diagram stane nečitateľným, a teda zbytočným.

Nie je vždy jednoduché zariadiť komplexné aktivity tak, aby zostali vizuálne, čitateľné a zároveň úplné. Najčastejšie sa uchyľujú k rozdeleniu celej škály procesov do hlavných veľkých blokov, z ktorých najvýznamnejšie sú nasledujúce.

Vytvorenie produktu (výsledku).
Propagácia a predaj – práca s tokom zákazníkov.
Podpora činností pri vytváraní produktov sú sekundárne procesy, ktoré sú potrebné na splnenie požiadaviek vlády alebo na zabezpečenie pohodlia práce (personál a účtovníctvo, dopravné služby, upratovanie priestorov a pod.).
Tvorba manažérskych tokov – činnosť vývoja manažérskych riešení, ktoré budú určovať požiadavky na všetky procesy podniku.

Obrázok nižšie ukazuje diagram rozkladu nášho príkladu.

(klikni na zväčšenie)

V diagrame by procesy mali byť usporiadané diagonálne - to sa nazýva princíp dominancie, čo znamená usporiadanie funkčných blokov zľava doprava a zhora nadol - v poradí dôležitosti alebo v chronologickom poradí. Číslovanie blokov je rovnaké.

Ďalšia práca na modeli je podobná ako v prvom kroku - každý funkčný blok prvej úrovne je rozložený. Číslovanie blokov bude obsahovať číslo prvej úrovne: A1.1… A1n, A2.1… A2.n atď.

Závery o relevantnosti notácie

V rámci tohto článku bolo možné zobraziť len základné pojmy IDEF0-notácie na krátkej ukážke IDEF0, podľa čoho je samozrejme ťažké posúdiť metodiku ako celok. Ale dosť veľa skúseností s používaním tohto zápisu v praxi mi umožňuje vyvodiť nasledujúce závery.

Model má dobrý vizualizačný potenciál, no väčší význam má podľa mňa v disciplinovanosti. Pravidlá a obmedzenia zapracované do metodiky nás nútia k systematickému a prísnemu prístupu k modelom, čo má veľmi dobrý vplyv na kvalitu konečného výsledku.
Model umožňuje budovať komunikačné toky medzi zdanlivo nie silne prepojenými vecami: prepojiť front a back-office subsystémy s riadením, čo je oveľa horšie pre iné zápisy.
Tento prístup je jednoduchý a zrozumiteľný pre väčšinu účastníkov projektu. Vytváranie a čítanie diagramov v tomto zápise je obmedzené iba túžbou ponoriť sa do zložitosti obchodných tokov.

Niektoré z vyššie uvedených argumentov vedú k názoru, že tento prístup je najlepší a jediný na úplné modelovanie aktivít. Nezabudnite však, že funkčný model je určený len pre vyššiu úroveň modelovania. Použitie notácie IDEF0 pre dizajn diela na úrovni výkonných umelcov vedie k tomu, že schémy sú čisto ilustratívne a na ich základe nie je možné postaviť rozumnú reguláciu, keďže neobsahujú:

konkretizácia udalostí spustenia a zastavenia procesu;
podmienky prechodu z jednej akcie na druhú;
schopnosť vizuálne zobraziť všetky zdroje a interpretov bez preťaženia diagramu šípkami.

Ak teda tento zápis použijete na úlohy, na ktoré je určený (štrukturovanie činností na najvyššej úrovni), tak IDEF0 je pre dnešok prakticky jediný zápis, ktorý vám to umožňuje robiť zmysluplne a presne.

V projektovom manažmente je tento štandard modelovania najviac použiteľný tam, kde je potrebné prepojiť rôzne projekty alebo procesy s vizuálnymi tokmi. Grafický model zároveň umožní racionálnejšie rozdeľovať zodpovednosť a zdroje podľa úloh. Logika projektových úloh, premietnutá do diagramov, pomôže pripraviť lepší harmonogram vo forme Ganttovho diagramu.

Cieľ:

štúdium základných princípov metodiky IDEF0,
vytvorenie nového projektu v BPWin,
vytvorenie kontextového diagramu,
vytváranie spojení.

Opis systému pomocou IDEF0 sa nazýva funkčný model. Funkčný model je určený na popis existujúcich obchodných procesov, v ktorých sa používajú prirodzené aj grafické jazyky. Na sprostredkovanie informácií o konkrétnom systéme je zdrojom grafického jazyka samotná metodika IDEF0.

metodika IDEF0 predpisuje konštrukciu hierarchického systému diagramov - jednotlivých popisov systémových fragmentov. Najprv je opísaný systém ako celok a jeho interakcia s vonkajším svetom (kontextový diagram), potom sa uskutoční funkčný rozklad - systém sa rozdelí na podsystémy a každý podsystém sa opíše samostatne (dekompozičné diagramy). Potom sa každý podsystém rozdelí na menšie a tak ďalej, kým sa nedosiahne požadovaná úroveň detailov.

Každý IDEF0-grafy a obsahuje bloky a oblúky. Bloky predstavujú funkcie simulovaného systému. Oblúky spájajú bloky dohromady a predstavujú interakcie a vzťahy medzi nimi.

Funkčné bloky (práca) v diagramoch sú reprezentované obdĺžnikmi reprezentujúcimi pomenované procesy, funkcie alebo úlohy, ktoré sa vyskytujú v priebehu času a majú rozpoznateľné výsledky. Názov práce musí byť vyjadrený slovným podstatným menom označujúcim činnosť.

IDEF0 vyžaduje, aby diagram mal aspoň tri a nie viac ako šesť blokov. Tieto obmedzenia udržiavajú zložitosť diagramov a modelov na úrovni, ktorá je čitateľná, zrozumiteľná a použiteľná.

Každá strana bloku má špecifický, presne definovaný účel. Ľavá strana bloku je pre vstupy, horná pre ovládanie, pravá pre výstupy a spodná pre mechanizmy. Toto označenie odráža určité systémové princípy: vstupy sa premieňajú na výstupy, kontrolujú limity alebo predpisujú podmienky na vykonávanie konverzií, mechanizmy ukazujú, čo a ako funkcia vykonáva.

Bloky v IDEF0 sú usporiadané podľa dôležitosti, ako to chápe autor diagramu. Toto relatívne poradie sa nazýva dominancia. Dominancia sa chápe ako vplyv, ktorý má jeden blok na ostatné bloky v diagrame. Napríklad najdominantnejší blok diagramu môže byť buď prvý z požadovanej postupnosti funkcií, alebo plánovacia alebo kontrolná funkcia, ktorá ovplyvňuje všetky ostatné.

Najdominantnejší blok sa zvyčajne nachádza v ľavom hornom rohu grafu a najmenej dominantný v pravom rohu.

Usporiadanie blokov na stránke odráža autorovu definíciu dominancie. Topológia diagramu teda ukazuje, ktoré vlastnosti majú najväčší vplyv na ostatné. Aby sa to zdôraznilo, analytik môže prečíslovať bloky podľa poradia ich dominancie. Poradie dominancie môže byť označené číslom umiestneným v pravom dolnom rohu každého obdĺžnika: 1 označuje najväčšiu dominanciu, 2 označuje nasledujúcu atď.

Interakcia diel s vonkajším svetom a medzi sebou navzájom je opísaná vo forme šípok, znázornených jednotlivými čiarami so šípkami na koncoch. Šípky predstavujú nejaký druh informácií a sú pomenované podstatnými menami.

Typy šípok

IDEF0 rozlišuje päť typov šípok.

vchod- predmety používané a premieňané prácou na získanie výsledku (výstupu). Predpokladá sa, že dielo nemusí mať žiadne vstupné šípky. Vstupná šípka je nakreslená ako vstup na ľavú stranu diela.

Kontrola- informácie upravujúce činnosti pracovného miesta. Kontrolné šípky zvyčajne nesú informácie, ktoré naznačujú, že úloha sa má vykonať. Každá úloha musí mať aspoň jednu ovládaciu šípku, ktorá je znázornená ako vstup do hornej strany úlohy.

Východ- objekty, na ktoré sa konvertujú vstupy. Každá úloha musí mať aspoň jednu výstupnú šípku, ktorá je nakreslená ako vychádzajúca z pravého okraja úlohy.

Mechanizmus- zdroje, ktoré vykonávajú prácu. Šípka mechanizmu je nakreslená ako vstup do spodného okraja diela. Podľa uváženia analytika sa na modeli nemusia objaviť šípky mechanizmu.

Zavolajte- špeciálna šípka ukazujúca na iný model práce. Šípka volania je nakreslená ako vychádzajúca zo spodnej časti diela a používa sa na označenie toho, že nejaká práca sa vykonáva mimo simulovaného systému.

Ryža. 2.1 Typy šípok

V metodológii IDEF0 je potrebných iba päť typov interakcií medzi blokmi na opísanie ich vzťahov: riadenie, vstup, spätná väzba riadenia, spätná väzba vstupu, výstup-mechanizmus. Ovládacie a vstupné odkazy sú najjednoduchšie, pretože odrážajú priame akcie, ktoré sú intuitívne a veľmi jednoduché.

Ryža. 2.2. Ukončite komunikáciu

Ryža. 2.3. Komunikácia manažmentu

Riadiaci vzťah nastane, keď výstup jedného bloku priamo ovplyvňuje menej dominantný blok.

Spätná väzba riadenia a spätná väzba vstupu sú zložitejšie, pretože ide o iteráciu alebo rekurziu. Totiž výstupy z jedného zamestnania ovplyvňujú budúci výkon iných zamestnaní, ktoré následne ovplyvnia pôvodné zamestnanie.

Vtedy dochádza k spätnej väzbe manažmentu; keď výstup nejakého bloku ovplyvňuje blok s veľkou dominanciou.

Vzťahy výstupného mechanizmu sú zriedkavé. Odrážajú situáciu, v ktorej sa výstup jednej funkcie stáva prostriedkom na dosiahnutie cieľa inej.

Ryža. 2.4. Vstupná spätná väzba

Ryža. 2.5. Spätná väzba manažmentu

Vzťahy výstupného mechanizmu sú bežné pri prideľovaní zdrojov (napr. požadované nástroje, vyškolený personál, fyzický priestor, vybavenie, financovanie, materiály).

V IDEF0 oblúk zriedka zobrazuje jeden objekt. Zvyčajne symbolizuje zbierku predmetov. Keďže oblúky predstavujú kolekciu prvkov, môžu mať viacero počiatočných bodov (zdrojov) a koncových bodov (cieľov). Preto sa oblúky môžu rozvetvovať a spájať rôznymi spôsobmi. Celý oblúk alebo jeho časť môže vychádzať z jedného alebo viacerých blokov a končiť jedným alebo viacerými blokmi.

Rozvetvené oblúky, zobrazené ako rozbiehajúce sa čiary, znamenajú, že celý obsah oblúkov alebo ich časť sa môže objaviť v každej vetve. Oblúk je vždy označený pred rozvetvením, aby sa dal názov celej zostave. Okrem toho môže byť každá vetva oblúka označená alebo neoznačená podľa nasledujúcich pravidiel:

neoznačené vetvy obsahujú hmotnosť predmetov špecifikovaných v štítku oblúka pred vetvou;
vetvy označené za bodom rozdvojenia obsahujú všetky alebo časť objektov špecifikovaných v označení oblúka pred rozvetvením.

Zlúčenie oblúkov v IDEFO, znázornené ako zbiehajúce sa čiary, znamená, že obsah každej vetvy vytvorí označenie pre oblúk, ktorý je výsledkom zlúčenia pôvodných oblúkov. Po zlúčení je výsledný oblúk vždy označený príznakom, ktorý označuje novú množinu prvkov po zlúčení. Okrem toho každá pobočka môže alebo nemusí byť označená pred zlúčením podľa nasledujúcich pravidiel:

Ryža. 2.6. Komunikácia výstup-mechanizmus

neoznačené vetvy obsahujú váhu objektov špecifikovaných v zdieľanom štítku po zlúčení;
vetvy označené pred zlúčením obsahujú všetky alebo niektoré objekty uvedené vo všeobecnej značke po zlúčení,

Kvantitatívna analýza grafov

Na vykonanie kvantitatívnej analýzy diagramov uvádzame ukazovatele modelu:

počet blokov v diagrame - N;
úroveň rozkladu grafu - L;
bilančný diagram - V;
počet šípok spájajúcich sa s blokom - A

Tento súbor faktorov platí pre každý diagram v modeli. Odporúčania pre požadované hodnoty faktorov grafu budú uvedené nižšie.

Je potrebné usilovať sa o to, aby počet blokov v diagramoch nižších úrovní bol nižší ako počet blokov v nadradených diagramoch, to znamená, že so zvýšením úrovne rozkladu by sa koeficient znižoval. Pokles tohto koeficientu tomu teda nasvedčuje. že ako sa model rozloží, funkcie by sa mali zjednodušiť, preto by sa mal počet blokov zmenšiť.

Grafy musia byť vyvážené. To znamená, že v rámci jedného diagramu je situácia znázornená na obr. 2.7: práca 1 má podstatne viac prichádzajúcich a ovládacích šípok ako odchádzajúcich. Je potrebné poznamenať, že toto odporúčanie sa nemusí dodržiavať v modeloch popisujúcich výrobné procesy. Napríklad pri popise postupu montáže môže blok obsahovať veľa šípok popisujúcich komponenty výrobku a jedna šípka môže ísť von – hotový výrobok.

Ryža. 2.7. Príklad nevyváženého grafu

Uveďme faktor rovnováhy diagramu

Je potrebné sa snažiť Kh bol minimálny pre graf.

Okrem analýzy grafických prvkov diagramu je potrebné zvážiť aj názvy blokov. Na vyhodnotenie názvov je zostavený slovník elementárnych (triviálnych) funkcií modelovaného systému. V skutočnosti by sa do tohto slovníka mali dostať funkcie nižšej úrovne rozkladu diagramov. Napríklad pre databázový model môžu byť základné funkcie „nájsť záznam“, „pridať záznam do databázy“, zatiaľ čo funkcia „registrácia používateľa“ vyžaduje ďalší popis.

Po vytvorení slovnej zásoby a zostavení balíka systémových diagramov je potrebné zvážiť nižšiu úroveň modelu. Ak sú na ňom zhody názvov blokov diagramov a slov zo slovníka, znamená to, že sa dosiahla dostatočná úroveň rozkladu. Koeficient, ktorý kvantitatívne odráža toto kritérium, možno zapísať ako L * C - súčin úrovne modelu počtom zhôd názvov blokov so slovami zo slovníka. Čím nižšia úroveň modelu (vyššie L), tým hodnotnejšie sú náhody.

BPWin Toolkit

Po spustení BPWin sa predvolene zobrazí hlavný panel nástrojov, paleta nástrojov a Prieskumník modelov.

Pri vytváraní nového modelu sa zobrazí dialógové okno, v ktorom uveďte, či sa model vytvorí nanovo, alebo sa otvorí z úložiska ModelMart, zadajte názov modelu a vyberte metodiku, v ktorej sa model vytvorí ( Obr. 2.8).

Obrázok 2.8 Dialóg na vytvorenie modelu

BPWin podporuje tri metodológie – IDEF0, IDEF3 a DFD. V BPWin je možné zostaviť zmiešané modely, to znamená, že model môže súčasne obsahovať diagramy IDEF0 a IDEF3 a DFD. Zloženie palety nástrojov sa automaticky zmení pri prechode z jedného zápisu na druhý.

Model v BPWin je vnímaný ako súbor činností, z ktorých každá funguje na určitom súbore údajov. Ak kliknete na ľubovoľný objekt modelu ľavým tlačidlom myši, zobrazí sa kontextové menu, ktorého každá položka zodpovedá editoru vlastnosti objektu.

Príklad

Vytvorenie modelu systému by malo začať preskúmaním všetkých dokumentov popisujúcich jeho funkčnosť. Jedným z týchto dokumentov sú zadávacie podmienky, a to časti „Účel rozvoja“, „Ciele a ciele systému“ a „Funkčná charakteristika systému“.

Po preštudovaní zdrojových dokumentov a rozhovoroch so zákazníkmi a používateľmi systému je potrebné sformulovať cieľ modelovania a určiť uhol pohľadu na model. Uvažujme o technológii jeho výstavby na príklade systému „Služba zamestnanosti v rámci univerzity“, ktorého hlavné možnosti boli popísané v laboratórnej práci č.

Sformulujme si cieľ modelovania: popísať fungovanie systému, ktoré by bolo zrozumiteľné pre jeho používateľa, bez toho, aby sme zachádzali do detailov súvisiacich s implementáciou. Model postavíme z pohľadu používateľov (študent, učiteľ, správca, dekanát, firma).

Začnime vytvorením kontextového diagramu IDEF0 - Podľa popisu systému je hlavnou funkciou slúžiť svojim zákazníkom spracovaním požiadaviek od nich. Definujme teda jedinú prácu kontextového diagramu ako „Obsluhovať klienta systému“. Ďalej definujeme vstupné a výstupné dáta, ako aj mechanizmy a ovládacie prvky.

Pre obsluhu klienta je potrebné ho zaregistrovať v systéme, otvoriť mu prístup do databázy a spracovať jeho požiadavku. Vstupnými údajmi budú „meno klienta“, „heslo klienta“, „zdrojová databáza“, „požiadavka klienta“. Vykonanie dotazu vedie buď k získaniu informácií zo systému, alebo k zmene obsahu databázy (napr. pri vypracovaní odborných posudkov), preto budú výstupnými dátami „reportáže“ a „upravená databáza“. Proces spracovania požiadaviek bude vykonávať monitor systému pod kontrolou správcu.

Kontextový diagram

Definujeme teda kontextový diagram systému (obr. 2.9).

Obr 2.9. Kontextový diagram systému

Rozložme kontextový diagram popisujúci postupnosť zákazníckeho servisu:

Určenie úrovne prístupu do systému.
Výber podsystému.
Prístup k subsystému.
Zmena databázy (ak je to potrebné).

Získame schému znázornenú na obr. 2.10.

Po dokončení rozkladu kontextového diagramu prejdite na rozklad diagramu ďalšej úrovne. Pri pohľade na tretiu a nižšiu úroveň sa modely zvyčajne vrátia k nadradeným diagramom a upravia ich.

Ryža. 2.10. Rozklad práce "Služba, klient systému"

Všetky bloky výsledného diagramu rozložíme postupne. Prvým krokom pri určovaní úrovne prístupu do systému je určenie kategórie používateľa. Meno klienta sa vyhľadá v užívateľskej databáze, čím sa definuje jeho kategória. Podľa určitej kategórie sa objasňuje oprávnenie udelené používateľovi systému. Ďalej sa vykoná postup prístupu do systému, pričom sa skontroluje prístupové meno a heslo. Kombináciou informácií o oprávnení a úrovni prístupu do systému sa pre používateľa vytvorí súbor povolených akcií. Definícia úrovne prístupu do systému teda bude vyzerať tak, ako je znázornené na obr. 2.11.

Ryža. 2.11. Dekompozícia práce "Určenie úrovne prístupu do systému"

Po prejdení procedúry pre prístup do systému monitor analyzuje požiadavku klienta a vyberie subsystém, ktorý požiadavku spracuje. Dekompozícia práce „Addressing a Subsystem“ nezodpovedá účelu a pohľadu modelu. Používateľa systému nezaujímajú interné algoritmy jeho fungovania. V tomto prípade je pre neho dôležité, že výber subsystému prebehne automaticky, bez jeho zásahu, preto dekompozícia volania do subsystému model len skomplikuje.

Poďme si rozložiť prácu „Spracovanie požiadaviek klienta“ vykonávanú subsystémom spracovania požiadaviek, pričom definujeme kategórie používateľov a oprávnenia. Pred hľadaním odpovede na požiadavku musíte otvoriť databázu (pripojiť sa k nej). Vo všeobecnosti môže byť databáza umiestnená na vzdialenom serveri, takže môže byť potrebné vytvoriť k nej spojenie. Definujme postupnosť prác:

Otvorenie databázy.
Vykonanie žiadosti.
Generovanie správ.

Po otvorení databázy je potrebné informovať systém o nadviazaní spojenia s databázou, následne vykonať požiadavku a vygenerovať reporty pre užívateľa (obr. 2.12).

Je potrebné poznamenať, že "Vykonanie požiadavky" zahŕňa prácu rôznych podsystémov. Napríklad, ak požiadavka obsahuje testovanie, potom bude vykonaná subsystémom odborných a psychologických testov. Vo fáze vykonávania dotazu môže byť potrebné zmeniť obsah databázy, napríklad pri vypracovaní odborných posudkov. Diagram preto musí poskytovať takúto možnosť.

Ryža. 2.12.

Úprava grafu

Pri analýze výsledného diagramu vyvstáva otázka, aké sú pravidlá pre generovanie reportov? Je potrebné mať vopred vytvorené šablóny, podľa ktorých sa uskutoční výber z databázy, pričom tieto šablóny musia zodpovedať požiadavkám a musia byť vopred určené. Okrem toho by klient mal dostať možnosť vybrať si formu správy.

Opravme diagram tak, že k nemu pridáme šípky „Šablóny výkazov“ a „Žiadosti o zmenu databázy“ a šípku tunela „Systémový klient“. Tunelovanie "System Client" sa používa preto, aby sa šípka neumiestnila na hornom diagrame, pretože funkcia výberu formulára správy nie je natoľko dôležitá, aby sa zobrazila na nadradenom diagrame.

Zmena diagramu povedie k úprave všetkých rodičovských diagramov (obr. 2.13 - 2.15).

Prácu "Vykonanie dotazu" je vhodné dekomponovať pomocou DFD diagramu (laboratórna práca č. 3), keďže metodika IDEF0 považuje systém za súbor vzájomne prepojených prác, čo slabo odráža procesy spracovania informácií.

Ryža. 2.13. Dekompozícia práce "Spracovanie požiadavky klienta"

Ryža. 2.14. Rozklad práce „Systémová klientská služba“ (možnosť 2)

Ryža. 2.15. Diagram kontextu systému (možnosť 2)

Prejdime k rozkladu posledného bloku „Zmena databázy“. Z pohľadu klienta sú tieto systémy umiestnené v jednej databáze. V systéme je v skutočnosti šesť databáz:

Databáza používateľov,
DB študentov, (možnosť 2)
DB voľných pracovných miest,
Databáza výkonu,
DB testov,
DB odborných posudkov,
DB súhrn.

Podľa účelu modelovania je dôležité, aby klient pochopil, že prijaté dáta nie sú v systéme okamžite aktualizované, ale prechádzajú dodatočnou fázou spracovania a kontroly. Algoritmus zmeny môže byť formulovaný takto:

Je určená databáza, v ktorej sa budú informácie meniť.
Prevádzkovateľ vytvorí dočasný súbor údajov a poskytne ich správcovi.
Správca kontroluje údaje a vkladá ich do databázy.

Tento model je možné implementovať iným spôsobom, pričom poskytuje možnosť aktualizovať databázu priamo na požiadanie, čím sa obíde proces kontroly údajov. V tomto prípade je potrebné zabezpečiť kontrolu integrity databázy, aby nedošlo k jej poškodeniu. V tomto prípade bude diagram vyzerať takto (obr. 2.17).

Ryža. 2.16. Dekompozícia práce "Zmena databázy"

Ryža. 2.17. Dekompozícia práce „Zmena databázy“ (možnosť 2) Pre prvú možnosť, znázornenú na obr. 2.12

Uskutočnenie ďalšej dekompozície "Zmien databázy" skomplikuje model a vysvetlí, ako sa vykonáva fyzická zmena databázy v systéme. V tomto prípade používateľ nedostane žiadne ďalšie informácie o práci systému služieb zamestnanosti. Túto prácu je vhodné rozložiť v procese návrhu databázového systému vo fáze vytvárania logického databázového modelu.

V ďalšom laboratóriu sa vykoná dekompozícia práce vykonania dotazu, ktorá ilustruje použitie diagramov DFD na popis procesov spracovania informácií.

Urobme kvantitatívnu analýzu modelov znázornených na obr. 2.12 a 2.13 podľa vyššie uvedeného postupu. Uvažujme správanie sa koeficientu ^ pre tieto modely. Nadradený diagram „Spracovanie požiadavky klienta“ má koeficient 4/2 = 2 a diagram rozkladu je 3/3 = 1. Hodnota koeficientu klesá, čo naznačuje zjednodušenie popisu funkcií so znížením úroveň modelu.

Zvážte zmenu koeficientu K b v dvoch modelových variantoch.

pre druhú možnosť

Koeficient K b nemení svoju hodnotu, preto sa vyváženie diagramu nemení.

Budeme predpokladať, že úroveň rozkladu uvažovaných diagramov je dostatočná na to, aby odrážala účel modelovania, a elementárne funkcie (z pohľadu používateľa systému) sa používajú ako názvy prác na diagramoch nižšej úrovne. .

Ak zhrnieme uvažovaný príklad, je potrebné poznamenať, že pri modelovaní systému je dôležité zvážiť niekoľko možností diagramov. Takéto varianty môžu vzniknúť pri úprave diagramov, ako to bolo pri „Spracovaní požiadavky klienta“ alebo pri vytváraní alternatívnych implementácií systémových funkcií (rozklad práce „Úprava databázy“). Zváženie možností vám umožňuje vybrať si tú najlepšiu a zahrnúť ju do balíka diagramov na ďalšie zváženie.

Kontrolné otázky

Zoznam Testovacie otázky:

Čo je to model v zápise IDEF0?
Čo znamenajú pracovné miesta IDEF0?
Aké je poradie prác na pomenovaní?
Koľko úloh by malo byť na jednom diagrame?
Čo sa nazýva poradie dominancie?
Ako sú diela usporiadané podľa princípu dominancie?
Aký je účel strán pracovných obdĺžnikov v diagramoch?
Uveďte typy šípok.
Aké sú typy vzťahov.
Čo sú hraničné šípky?
Vysvetlite konvenciu pomenovania pre vetvenie a zlúčenie šípok.
Aké metodiky podporuje BPWin?
Uveďte hlavné prvky hlavného okna BPWin.
Popíšte proces vytvárania nového modelu v BPWin.
Ako vytvoriť spojenie medzi dielami?
Ako nastaviť názov úlohy.
Popíšte proces rozdelenia práce.
Ako pridám prácu do diagramu?
Ako vyriešiť tunelované šípky?
Môže model BPWin obsahovať diagramy viacerých metodík?

Naučte sa vidieť a pochopiť funkčnú štruktúru svojho podnikania!

V súčasnosti v Rusku prudko vzrástol záujem o všeobecne uznávané štandardy riadenia na Západe, avšak v reálnej manažérskej praxi existuje jeden veľmi indikatívny moment. Mnohých vedúcich pracovníkov môže ešte stále zmiasť priama otázka na organizačnú štruktúru spoločnosti alebo návrh existujúcich obchodných procesov. Najpokročilejší manažéri, ktorí pravidelne čítajú ekonomické periodiká, spravidla začínajú kresliť hierarchické diagramy, ktoré sú zrozumiteľné len im, ale aj v tomto procese sa zvyčajne rýchlo dostanú do slepej uličky. To isté platí pre zamestnancov a manažérov rôznych služieb a funkčných celkov. Vo väčšine prípadov je jediným súborom pravidiel, podľa ktorých musí podnik fungovať, súbor individuálnych predpisov a popisov práce. Najčastejšie boli tieto dokumenty vypracované pred viac ako rokom, sú zle štruktúrované a neprepojené a v dôsledku toho sa na regáloch jednoducho hromadí prach. V súčasnosti bol takýto prístup opodstatnený, pretože počas formovania ruského trhového hospodárstva prakticky chýbal koncept konkurencie a nebolo potrebné brať do úvahy náklady - zisk bol obrovský. V dôsledku toho sme za posledné dva roky videli úplne zrozumiteľný obraz: veľké spoločnosti, ktoré rástli začiatkom 90. rokov, postupne strácajú svoje pozície, až sa úplne stiahnu z trhu. Čiastočne je to spôsobené tým, že podnik nezaviedol štandardy riadenia, úplne absentoval koncept funkčného modelu činnosti a poslania. Pomocou modelovania rôznych oblastí činnosti je možné efektívne analyzovať úzke miesta v riadení a optimalizovať celkovú obchodnú schému. Ako však viete, v každom podniku majú najvyššiu prioritu len tie projekty, ktoré priamo prinášajú zisk, preto sa o prehľade činností a ich činnosti zvyčajne bavíme až počas citeľnej krízy vo vedení spoločnosti. reorganizácia.

Samotný pojem „modelovanie obchodných procesov“ sa dostal do každodenného života väčšiny analytikov súčasne s tým, ako sa na trhu objavili komplexné softvérové produkty určené pre komplexnú automatizáciu podnikového riadenia. Takéto systémy vždy zahŕňajú hlboký predprojektový prieskum aktivít spoločnosti. Výsledkom tohto prieskumu je odborný posudok, v ktorom sú v jednotlivých odsekoch uvedené odporúčania na odstránenie „úzkych miest“ v riadení činností. Na základe tohto záveru sa bezprostredne pred implementáciou automatizačného systému vykonáva takzvaná reorganizácia podnikových procesov, niekedy dosť závažná a pre spoločnosť bolestivá. Tento a prirodzene tím, ktorý sa rokmi vyvinul, je vždy ťažké prinútiť „myslieť novým spôsobom“. Takéto komplexné prieskumy podnikov sú vždy zložité a výrazne sa líšia od prípadu k prípadu. Na riešenie takýchto problémov modelovania zložitých systémov existujú osvedčené metodiky a štandardy. Tieto štandardy zahŕňajú metodológie rodiny IDEF. S ich pomocou je možné efektívne zobrazovať a analyzovať modely činnosti širokého spektra komplexných systémov v rôznych sekciách. Zároveň si šírku a hĺbku skúmania procesov v systéme určuje samotný vývojár, čo umožňuje nepreťažovať vytvorený model zbytočnými dátami. V súčasnosti možno rodine IDEF priradiť tieto štandardy:

IDEF1 je metodika modelovania informačných tokov v rámci systému, ktorá umožňuje zobraziť a analyzovať ich štruktúru a vzťahy;

IDEF1X (IDEF1 Extended) je metodika pre budovanie relačných štruktúr. IDEF1X patrí do typu metodík "Entity-Relationship" (ER - Entity-Relationship) a spravidla sa používa na modelovanie relačných databáz súvisiacich s uvažovaným systémom;

IDEF2 je metodika pre dynamické modelovanie vývoja systémov. Kvôli veľmi vážnym ťažkostiam pri analýze dynamických systémov sa od tohto štandardu prakticky upustilo a jeho vývoj bol pozastavený už v počiatočnom štádiu. V súčasnosti však existujú algoritmy a ich počítačové implementácie, ktoré umožňujú transformovať súbor statických diagramov IDEF0 na dynamické modely založené na „farebných Petriho sieťach“ (CPN - Color Petri Networks);

História štandardu IDEF0

Metodiku IDEF0 možno považovať za ďalšiu etapu vo vývoji známeho grafického jazyka na popis funkčných systémov SADT (Structured Analysis and Design Teqnique). Pred niekoľkými rokmi vyšlo v Rusku malé vydanie knihy s rovnakým názvom, ktorá bola venovaná popisu základných princípov konštrukcie diagramov SADT. Historicky bol IDEF0 ako štandard vyvinutý v roku 1981 ako súčasť rozsiahleho programu priemyselnej automatizácie s názvom ICAM (Integrated Computer Aided Manufacturing) a bol navrhnutý americkým letectvom. Samotná rodina štandardov IDEF zdedila svoje označenie z názvu tohto programu (IDEF = ICAM DEFinition). V procese praktickej implementácie čelili účastníci programu ICAM potrebe vyvinúť nové metódy na analýzu interakčných procesov v priemyselných systémoch. Zároveň, okrem vylepšenej sady funkcií na popis obchodných procesov, bola jednou z požiadaviek nového štandardu aj dostupnosť efektívnej metodiky interakcie v rámci „analytika-špecialistu“. Inými slovami, nová metóda mala zabezpečiť skupinovú prácu na tvorbe modelu s priamou účasťou všetkých analytikov a špecialistov zapojených do projektu.

Základné prvky a koncepty IDEF0

Grafický jazyk IDEF0 je prekvapivo jednoduchý a harmonický. Metodika je založená na štyroch hlavných konceptoch.

Každá zo štyroch strán funkčného bloku má svoj špecifický význam (úlohu), pričom:

Horná strana je ovládanie;

Ľavá strana je nastavená na „Input“;

Pravá strana je nastavená na „Výstup“;

Spodná strana je „Mechanizmus“.

Každý funkčný blok v rámci jedného uvažovaného systému musí mať svoje jedinečné identifikačné číslo.

Obrázok 1. Funkčný blok.

V závislosti od toho, pre ktorú zo strán je tento oblúk rozhrania vhodný, sa nazýva „prichádzajúce“, „odchádzajúce“ alebo „kontrola“. Okrem toho iba funkčné bloky môžu byť „zdrojom“ (začiatkom) a „výlevkou“ (koncom) každého funkčného oblúka, zatiaľ čo „zdrojom“ môže byť iba výstupná strana bloku a „výlevka“ môže byť ľubovoľná. z troch zostávajúcich.

Obrázok 2

Obrázok 3.

Povinná prítomnosť oblúkov ovládacieho rozhrania je jedným z hlavných rozdielov štandardu IDEF0 od ostatných metodík tried DFD (Data Flow Diagram) a WFD (Work Flow Diagram).

Vysvetľujúci text pre kontextový diagram musí vo forme stručného popisu uvádzať Účel zostavenia diagramu a fixovať uhol pohľadu (Pohľad).

V procese rozkladu je funkčný blok, ktorý v kontextovom diagrame zobrazuje systém ako celok, prevŕtaný do iného diagramu. Výsledný diagram druhej úrovne obsahuje funkčné bloky, ktoré zobrazujú hlavné čiastkové funkcie funkčného bloku kontextového diagramu a vo vzťahu k nemu sa nazýva Child diagram (každý z funkčných blokov patriacich do podradeného diagramu sa nazýva Detská schránka). Rodičovský funkčný blok sa nazýva rodičovský blok vo vzťahu k podradenému diagramu (Parent Box) a diagram, ku ktorému patrí, sa nazýva rodičovský diagram (Parent Diagram). Každá z podfunkcií podradeného diagramu môže byť ďalej podrobne rozpísaná podobným rozkladom zodpovedajúceho funkčného bloku. Je dôležité poznamenať, že v každom prípade rozkladu funkčného bloku sú všetky oblúky rozhrania zahrnuté v tomto bloku alebo z neho vychádzajúce v podradenom diagrame. Tým sa dosiahne štrukturálna integrita modelu IDEF0. Princíp rozkladu je názorne znázornený na obrázku 4. Pozor si treba dať na vzťah medzi číslovaním funkčných blokov a diagramami – každý blok má na diagrame svoje jedinečné sériové číslo (číslo v pravom dolnom rohu obdĺžnika), a označenie v pravom uhle označuje číslo podradeného diagramu pre tento blok ... Neprítomnosť tohto označenia znamená, že pre tento blok nedochádza k rozkladu.

Často sa vyskytujú prípady, keď jednotlivé oblúky rozhrania nemá zmysel ďalej brať do úvahy v podriadených diagramoch pod určitou úrovňou v hierarchii, alebo naopak - jednotlivé oblúky nad určitou úrovňou nemajú praktický význam. Napríklad nemá zmysel odrážať oblúk rozhrania znázorňujúci „detail“ na vstupe do funkčného bloku „Zapnite sústruh“ na diagramoch vyšších úrovní - to len preťaží diagramy a sťaží ich pochopenie. Na druhej strane je potrebné zbaviť sa samostatných „koncepčných“ oblúkov rozhrania a nedetailovať ich hlbšie, než je určitá úroveň. Na vyriešenie takýchto problémov štandard IDEF0 poskytuje koncepciu tunelovania. Označenie Arrow Tunnel vo forme dvoch zátvoriek okolo začiatku oblúka rozhrania označuje, že tento oblúk nebol zdedený z funkčného nadradeného bloku a objavil sa (z „tunela“) iba v tomto diagrame. Na druhej strane, rovnaké označenie okolo konca (šípka) oblúka rozhrania v bezprostrednej blízkosti bloku prijímača znamená skutočnosť, že tento oblúk je zobrazený a nebude sa brať do úvahy v podradenom diagrame tohto bloku. Najčastejšie sa stáva, že jednotlivé objekty a im zodpovedajúce oblúky rozhrania sa na niektorých medzistupňoch hierarchie neberú do úvahy - v tomto prípade sú najskôr „ponorené do tunela“ a potom, ak je to potrebné, „vrátené z tunela“.

Obrázok 4. Rozklad funkčných blokov.

Princípy obmedzenia zložitosti diagramov IDEF0

Disciplína skupinovej práce na vývoji modelu IDEF0

Vlastnosti národnej praxe používania funkčného modelovania pomocou IDEF0

Čo patrí jednotke „pri vchode“?

Aké funkcie a v akom poradí sa vykonávajú v rámci jednotky?

Kto je zodpovedný za jednotlivé funkcie?

Čím sa riadi vykonávateľ pri výkone jednotlivých funkcií?

Aký je výsledok práce jednotky (výkon)?

Po odsúhlasení návrhov diagramov v rámci každého konkrétneho oddelenia ich konzultant zostaví do návrhu podnikového modelu, v ktorom sú prepojené všetky vstupné a výstupné prvky. V tejto fáze sa zaznamenávajú všetky nezrovnalosti jednotlivých diagramov a ich kontroverzné miesta. Ďalej tento model opäť prechádza cez funkčné oddelenia na ďalšie odsúhlasenie a vykonanie potrebných úprav. Výsledkom je, že v pomerne krátkom čase a so zapojením minima ľudských zdrojov z poradenskej spoločnosti (a tieto zdroje, ako viete, sú veľmi drahé), sa získa model podniku IDEF0 podľa „ „Ako je“, a čo je dôležité, predstavuje podnik s pozíciami zamestnancov, ktorí v ňom pracujú a dôkladne poznajú všetky nuansy, vrátane neformálnych. V budúcnosti bude tento model prenesený na analýzu a spracovanie k podnikovým analytikom, ktorí budú hľadať úzke miesta v riadení spoločnosti a optimalizovať kľúčové procesy, transformujúc model „Ako je“ na zodpovedajúci pohľad „Ako by mal byť“. Na základe týchto zmien sa robí konečný záver, ktorý obsahuje odporúčania na reorganizáciu systému riadenia.