Nyissa meg azt a projektet, amelyben létre kívánja hozni a modellt. Ha még nem hozott létre projektet, használhatja a DEMO projektet, amely a Cradle telepítése után azonnal elérhető, vagy létrehozhatja saját projektjét.

A belépéshez a DEMÓ projekthasználat Felhasználónév — MENEDZSER, jelszó - MANAGER

Ebben a videóban részletesen bemutatjuk a projekt létrehozásának módját

Új projekt létrehozása után bejelentkezhet a segítségével is Felhasználónév — VEZETŐ és jelszó - MANAGER

Modellalkotás

IDEF0 modell létrehozásához engedélyezze Projekt Panelés menjen a szimulációs részhez Essential Domain

jegyzet : Hasonlóképpen modelleket hozhat létre a Megvalósítási tartomány modellezése részben, valamint a felhasználó által konfigurált bármely szakaszban. A modellezési rész valójában egy névtér, amelyben a szálak újra felhasználhatók.

IDEF0 kontextusmodell létrehozásához kattintson jobb gombbal az IDEF0 szakaszra, és válassza az Új->Elem lehetőséget

Kérjük, vegye figyelembe, hogy ez a teljes modell neve, nem az A0-n lévő funkcióblokk.

Ez megnyitja a rajzterületet, és megkezdheti a kontextusmodell létrehozását.

Funkcióblokk létrehozása

Ehhez válassza ki a funkcióblokk szimbólumát a palettán

és kattintson egyszer arra a munkaterületre, ahol létre kívánja hozni a funkcióblokkot.

Megjelenik egy párbeszédpanel, amelyben meg kell adnia a funkcióblokk nevét, majd kattintson az OK gombra.

Ennek eredményeként létrejön egy funkcióblokk az Ön által megadott névvel.

Kiválaszthatja egy blokk szegélyét, és módosíthatja a léptékét

Szálak létrehozása

Folyamatok létrehozásához válassza ki a folyam szimbólumot a palettáról (alagút nélkül vagy alagúttal)

majd kattintson a funkcióblokk azon oldalára, amellyel folyamatot szeretne létrehozni, és kattintson a funkcióblokk bármely területére

Ezt követően megjelenik egy párbeszédpanel a folyam nevének megadásához. Adjon meg egy rövid adatfolyamnevet, majd kattintson az OK gombra

Jegyzet: Az áramlás részletes leírását később a specifikációjában adhatja meg.

Ezután analógia útján létrehozhatja az összes szükséges áramlást

Mentse el a modellt a hajlékonylemez gomb megnyomásával vagy a CTRL+S billentyűkombinációval. Mentéskor szimbólumspecifikációk jönnek létre, amelyeket szerkeszthet, hogy részletesebb leírást adjon a modellelemekről.

A modell mentése után a létrehozott specifikációkat ugyanabban a szakaszban láthatja a projekt panelen, ahol a modellt létrehozta. Kétféle specifikáció jön létre – Function és Flow.

Modellbontás

a megjelenő párbeszédpanelen hagyja meg az alapértelmezett beállításokat, és kattintson az OK gombra

Ezt követően létrejön egy A1 gyermekdiagram, és az A0 diagramból származó összes folyam átkerül oda.

Most már átnevezheti a létrehozott funkcióblokkot üresen (név helyett kérdéssel), és továbbiakat is létrehozhat, ugyanúgy, ahogy korábban létrehoztuk.

Egy funkcióblokk előre beállított átnevezéséhez jelölje ki, majd a helyi menüből válassza az Átnevezés lehetőséget

és írja be a kívánt nevet

Hasonló módon hozzon létre más funkcióblokkokat, amelyek megfelelnek ennek a felbontási szintnek

A funkcionális blokkok közötti áramlások létrehozásához először a forrásra, majd a közbülső pontra kell kattintania egy kanyar létrehozásához, majd a célpontra, például így:

Ennek eredményeként két kanyarral áramlást kap.

Beállíthatja a hajlítások helyzetét az áramlás kiválasztásával és a hajlítási pontok kívánt helyre húzásával

Nézze meg a videoklipet, hogy lássa működés közben

Hajlítási pont eltávolításához (vagy hozzáadásához) nyomja meg a SHIFT billentyűt a billentyűzeten, és kattintson az eltávolítani kívánt pontra vagy a folyamatban arra a helyre, ahol létre szeretné hozni.

Mentse el a diagramot, és győződjön meg arról, hogy a megfelelő specifikációk elkészültek

Analógia útján lehetséges az A1 funkcionális blokkok bontása.

Az Orosz Föderáció Oktatási és Tudományos Minisztériuma

Szövetségi Oktatási Ügynökség

Állapot oktatási intézmény felsőfokú szakmai végzettség

Tanfolyami munka

"Rendszermodellezés"

„Vállalkozási modell kidolgozása üvegházi gazdálkodás IDEF0, DFD és IDEF3 tervezési módszerekkel"

1. A munka célja

2. Elméleti bevezetés

3. A tárgykör leírása

4. A BPwin leírása

4.1 Az IDEF0 modell felépítésének elve

4.2 A DFD modell felépítésének elve

4.3 IDEF3 modellépítési elve

5. Szimuláció

5.1 Üvegház modell

5.2 Matematikai modell

6. Benchmarking

6.1 Módszertan

6.2 A szerszámok összehasonlítása

Irodalom

1. A munka célja

Ennek a kurzusnak a céljai a következők voltak:

a vállalkozás projekt előtti felmérésének módszereinek alkalmazása;

a kapott anyagok elemzése a későbbi modellezéshez;

folyamatmodell fejlesztése az IDEF0 szabványban;

munkafolyamat és információfeldolgozás leírása a DFD szabványban;

folyamatok leírása az IDEF3 szabványban;

vegyes folyamatleíró modell kidolgozása IDEFO, DFD és IDEF3 szabványok alapján.

forgatókönyvek készítése a vállalkozás működéséhez;

a vállalkozás szerkezeti sémájának felépítése;

matematikai modell létrehozása ezt a vállalkozást.

összehasonlító elemzés

2. Elméleti bevezetés

A fejlesztés során automatizált rendszerek A kódolás és a tesztelés szakaszában történő kezelés során nagyszámú hiba tárul fel, amelyek kijavítása az egész fejlesztés alatt álló rendszer alapvető változását vonja maga után. Az ilyen hibákat a modellezés és a létrehozott projektek mélyreható, részletes elemzése során figyelembe veszik. A modellezés lehetővé teszi a projekt "látását" a fejlesztési folyamatban, és előfeltételeket teremt a rendszer viselkedésének elemzéséhez a kezdeti feltételek függvényében.

A szimulált irányítási rendszerben lezajló folyamatok megfelelő koordinációjához szükséges egy struktúra kialakítása, pl. racionalizálja a folyamatokat. Munka szimuláció tájékoztatási rendszer különösen fontos létrehozásának korai szakaszában. Mivel az ebben a szakaszban elkövetett hibák kijavítása a legdrágább, a problémaelemzés és a megoldására szolgáló logikai modell kidolgozásának szakaszában az előnyök jelentősek.

Ebben a vonatkozásban szükséges a tantárgy, nevezetesen az üvegházhatású ipar munkájának tanulmányozása és fejlesztése. Ehhez meg kell értenie ennek a területnek a terminológiáját, össze kell gyűjtenie a szükséges szabályozási és jogi dokumentumokat, tanulmányoznia kell a vállalkozás dokumentumainak mintáit, és nyomon kell követnie mozgásukat mind a vállalkozáson belül, mind azon kívül.

A fejlesztés következő szakasza a tervezési szakasz. Mielőtt elkezdené a tervezést és a megvalósítást, pontosan és részletesen magas szinten kell ismernie a követelményeket. Ezen kívül nagyon hasznos egy követelménystruktúra, amely bemenetként használható a rendszer kialakításához. Mindezt elemzéssel és modellezéssel érik el.

A modellezési és tervezési szakaszban végzett munka során be kell szerezni egy rendszerprojektet, amely elegendő információt tartalmaz a megvalósításhoz. Szükséges továbbá elemezni az üvegházhatást okozó ipar munkáját, melynek eredményeként meg lehet ítélni, hogy az egyes részlegek leterheltségi foka, mit és milyen eszközökkel kell elsősorban automatizálni.

A modellezés fő céljai a projektek fejlesztése során:

a vállalkozás tevékenységeinek és az abban alkalmazott technológiáknak a diagramok hierarchiájában történő ábrázolása, amely biztosítja azok megjelenítésének láthatóságát és teljességét;

kialakítása a szervezeti és vezetői struktúra átszervezésére vonatkozó javaslatok elemzése alapján;

az információáramlás egyszerűsítése (beleértve a munkafolyamatot is) a vállalaton belül;

vállalati információs rendszerek követelményeinek elemzése és specifikációinak tervezése.

3. A tárgykör leírása

Megfontolásra ebben lejáratú papírok vették alapul az üvegházak munkájához. Ez a vállalkozás mezőgazdasági növények termesztésére specializálódott. A termékek értékesítése a vevő kérésére történik.

A munka megszervezése a következő séma szerint történik:

Ez a diagram a vállalkozás részlegeit, azok funkcióit és összefüggéseit mutatja be. Néhány részleg automatizálható.

Az egész vállalkozás élén a vezetőség áll, amelyet a főnök és helyettese képvisel. Fő funkciójuk a vállalkozás tevékenységének ellenőrzése.

Munkavédelmi szolgálat, melynek fő feladata a személyzet képzése;

A számviteli osztály dokumentumkezeléssel foglalkozik;

A gyártásellenőrzési szolgáltatás teljes ellenőrzést végez a gyártás minden szakaszában;

Ágazat Karbantartás javítási munkákkal foglalkozik.

A vállalkozás részlegeit, szolgáltatásait és munkahelyeit az 1. számú táblázat tartalmazza:

1. számú táblázat

Üvegháziparunk feladatait és funkcióit a 2. számú táblázat tartalmazza:

2. számú táblázat

A dokumentációt a 3. számú táblázat tartalmazza:

3. számú táblázat

A szervezetek névjegyzékét a 4. számú táblázat tartalmazza:

4. számú táblázat

Az alábbi diagram leírja a vállalkozás forgatókönyvét az egyes szakaszokra vonatkozó következtetésekkel: a vevő kérelmet kap bizonyos üvegházhatású termékek szállítására az értékesítési vezetőhöz. Az értékesítési vezető feldolgozza ezt a kérelmet és meghozza a döntést. Ezzel párhuzamosan a könyvelő kiszámítja a szolgáltatásnyújtás költségeit. Miután mindezen szakaszok befejeződtek, megkezdődik a szerződéskötés folyamata. Az értékesítési vezető megbeszéli a vevővel a szerződés feltételeit és megköti azt. Ezt követően az ügyfél fizet. A kifizetés ellenőrzése a számviteli osztály feladata. A könyvelő kivonatot kap a banktól, és megbízást ad a megbízás teljesítésének megkezdésére, amelyet átad a technológusnak. A technológus viszont tervet készít - a munka ütemezését, és nyilvántartást vezet a szükséges pénzeszközökről. A terv elkészítése után - a munka ütemezése, a kertész utasítást kap a földmunkák elvégzésére. A kertész földmunkát és betakarítást végez. A betakarított termést elküldik a vevőnek. A teljes termelési ciklus során a vállalkozás vezetője jelentést kap az értékesítési vezető, a könyvelő és a technológus tevékenységéről. A vezető irányítja a vállalkozás teljes folyamatát, és szükség esetén észrevételeket tesz munkatársai munkájáról a termelési folyamat és az egész vállalkozás munkájának javítása érdekében.

A vállalkozás forgatókönyvének vázlata

4. A BPwin leírása

A BPwin egy kis integrált modellező eszköz, amely többféle modellt és módszert támogat.

Az üzleti folyamatok elemzéséhez és átszervezéséhez a Logic Works egy felső szintű CASE eszközt kínál – a BPwint, amely támogatja az IDEF0 (funkcionális modell), IDEF3 (WorkFlow Diagram) és DFD (DataFlow Diagram) módszertant. A három módszer közül a fő az IDEF0. A BPwin meglehetősen egyszerű és intuitív felhasználói felülettel rendelkezik, amely lehetővé teszi az elemző számára, hogy minimális erőfeszítéssel összetett modelleket hozzon létre.

A BPwin automatizálja az épületfejlesztési modellekkel kapcsolatos feladatokat, biztosítva a megfelelő és következetes eredmények biztosításához szükséges szemantikai szigorúságot. Ez a következő módszerekkel érhető el a BPwin-ben: IDEF0, DFD és IDEF3.

De mielőtt belevágnánk ebbe az összetettebb feladatba, valóban szükséges legalább az üzlet minden elemét "újraszámolni", vagyis megalkotni a cég szervezeti struktúráját. Következő lépésként megpróbáljuk grafikusan ábrázolni a korábban meghatározott struktúra különböző elemei közötti kapcsolatokat.

A BPwin-ben lehetőség van vegyes modellek felépítésére, azaz egy modell egyszerre tartalmazhat IDEFO, IDEF3 és DFD diagramokat is. A BPwin modelljei tevékenységek halmazának tekinthetők, amelyek mindegyike valamilyen adatkészleten működik. A munka téglalapként, az adatok nyilakként jelennek meg.

A modell minden munkája számozott. A szám egy előtagból és egy számból áll. Bármilyen hosszúságú előtag használható, de általában az A előtagot használják A fa kontextus (gyökér) művelete A0 számozású. Az A0 bontási munka Al, A2, A3 stb. A dekompozíció működik alacsonyabb szinten legyen az anyamű száma és a következő sorszám, például az A3 bontás alkotásai A3.1 A3.2, AZ.3, A3.4 stb.

A diagramok, IDEFO diagramok, DFD és IDEF3 hozzáadásával egy vegyes modell hozható létre, amely a legjobban leírja a vállalkozás minden aspektusát. A vegyes modellfeladat-hierarchia a Model Explorer ablakban látható. Az IDEFO jelölésű művek zöld, a DFD kék színnel vannak ábrázolva.

A BPwin, valamint a helyi integrált rendszerek gyakorlatilag nem teszik lehetővé a rendszerek átfogó elemzését, amely többé-kevésbé szükséges a kis, közepes és nagy PMIS létrehozásához. Segítségükkel helyi információs rendszert vagy kis alrendszereket fejleszthet, amelyek az egyes üzleti láncok automatizálására szolgálnak, vagyis amikor nincs szükség a vállalkozás átfogó elemzésére. A kis integrált eszközök használatának jellemző területe a vállalkozás úgynevezett „darabonkénti” automatizálásának problémáinak megoldása.

4.1 Az IDEFO modell felépítésének elve

Az IDEFO módszertan alapja egy grafikus nyelv az üzleti folyamatok leírására. Az IDEFO jelölésű modell hierarchikusan rendezett és összekapcsolt diagramok gyűjteménye. Minden diagram a rendszerleírás egysége, és külön lapon található.

Az IDEFO modell egyetlen modellezési alany és egy nézőpont világosan meghatározott céljának jelenlétét feltételezi.

Egy modell négyféle diagramot tartalmazhat:

kontextusdiagram (minden modellnek csak egy kontextusdiagramja lehet);

bomlási diagramok;

csomópontfa diagramok;

csak expozíciós diagramok (FEO).

A kontextusdiagram a diagramok fastruktúrájának teteje, és a rendszer és a külső környezettel való interakciójának legáltalánosabb leírása.

Ezt a folyamatot funkcionális dekompozíciónak nevezzük, az egyes fragmentumokat és a fragmentumok kölcsönhatását leíró diagramokat pedig dekompozíciós diagramoknak nevezzük.

Az IDEF0 jelölés és módszertan a "blokk" fogalmán alapul, vagyis egy téglalapon, amely valamilyen üzleti funkciót fejez ki. Mint tudod, a téglalapnak négy oldala van. Az IDEF0-ban minden fél szerepe (funkcionális jelentése) eltérő:

a felső oldal jelentése „vezérlés”;

balra - "bejárat";

jobbra - "kilépés";

alsó - "mechanizmus".

A módszertan és a jelölés második eleme a "folyam" (a szabványban "interfész ív") - egy olyan elem, amely leírja az adatokat, az informális vezérlést vagy bármi mást, ami "befolyásolja" a blokk által képviselt funkciót. Attól függően, hogy a blokk melyik oldalára irányul az áramlás, azt "bemenetnek", "kimenetnek", "vezérlésnek" nevezik.

Az „áramlást” jelképező ikonikus elem egy nyíl.

Menedzsment - ez az, ami az iroda tevékenységét irányítja, ebben a kidolgozás alatt álló modellben - ezek az egyes PU-ra vonatkozó törvények.

Az „input” nyilak a bemeneti adatok funkcióit mutatják be, a kontextus diagramban ezek a munkavállaló személyes adatai.

Nyilak "kilépés" - kimeneti adatok. A kontextusdiagramban ez az Orosz Föderáció Nyugdíjalapjához benyújtott különféle információk.

A „mechanizmus” nyíl a folyamatokat befolyásoló adatok. Az ábrán ezek a személyzet és a PC.

A kontextusdiagram felbontása után a rendszer minden nagy töredéke kisebbekre bomlik, minden töredéknek nevet adunk, és így tovább, amíg a leírás kívánt szintjét el nem érjük.

Minden dekompozíció után vizsgaüléseket tartanak - a téma szakértői jelzik a valós üzleti folyamatok megfelelését a létrehozott diagramoknak.

A talált inkonzisztenciákat kijavítjuk, és csak azután, hogy megjegyzés nélkül letette a vizsgát, folytathatja a következő bontási munkamenetet. Így érhető el a megfelelőség.

A diagramon szereplő összes metszéspont számozott, minden számnak J előtagja van.A metszéspont tulajdonságait a Definíciószerkesztő párbeszédablakban szerkesztheti.

4.2 A DFD modell felépítésének elve

Az adatfolyam-diagramok (DFD-k) a tervezés alatt álló rendszer funkcionális követelményeinek modellezésének elsődleges eszközei. Segítségükkel ezeket a követelményeket funkcionális komponensekre (folyamatokra) bontják, és adatfolyamokkal összekapcsolt hálózatként jelenítik meg. Az ilyen eszközök fő célja annak bemutatása, hogy az egyes folyamatok hogyan alakítják át bemeneteiket outputokká, valamint feltárják e folyamatok közötti kapcsolatokat.

Hagyományosan két különböző jelölést használnak a DFD-k ábrázolására: Yodan (Yourdon) és Gane-Sarson (Gane-Sarson). Továbbá a példák készítésekor Yodan jelölést használunk, minden kivétel előzetesen meg lesz határozva.

Ez a módszertan (Gane/Sarson módszertan) az elemzett IS - tervezett vagy ténylegesen létező - modelljének felépítésén alapul. A módszertannak megfelelően a rendszermodellt adatfolyam-diagramok (DFD vagy DFD) hierarchiájaként határozzák meg, amelyek leírják az információ átalakítása aszinkron folyamatát a rendszerbe történő beviteltől a felhasználónak történő kiadásig. A hierarchia felső szintjének diagramjai (kontextus diagramok) határozzák meg az IS fő folyamatait vagy alrendszereit külső bemenetekkel és kimenetekkel. Ezek részletezése alacsonyabb szintű diagramok segítségével történik. Ez a dekompozíció folytatódik, létrehozva a diagramok többszintű hierarchiáját, amíg el nem éri a dekompozíciónak azt a szintjét, amelyen a folyamatok elemivé válnak, és nem lehet tovább részletezni őket.

Az információforrások (külső entitások) információáramlásokat (adatfolyamokat) generálnak, amelyek információkat továbbítanak alrendszerekbe vagy folyamatokba. Ezek viszont átalakítják az információkat és új áramlásokat generálnak, amelyek információt továbbítanak más folyamatoknak vagy alrendszereknek, adattárolóknak vagy külső entitásoknak – információfogyasztóknak. Így az adatfolyamdiagramok fő összetevői a következők:

külső entitások;

rendszerek/alrendszerek;

folyamatok;

adattároló eszközök;

adatfolyamok.

4.3 IDEF3 modellépítési elve

Az IDEF3 folyamat létrehozási módszerként is használható. Az IDEF3 kiegészíti az IDEFO-t, és mindent tartalmaz, amire szüksége van a modellek felépítéséhez, amelyeket később szimulációs elemzéshez lehet használni.

Az IDEF3 minden feladata egy üzleti folyamat forgatókönyvét írja le, és része lehet egy másik jobnak. Mivel a forgatókönyv a modell célját és hatókörét írja le, fontos, hogy a művekre a cselekvés folyamatát jelző verbális főnévvel, vagy ilyen főnevet tartalmazó kifejezéssel hivatkozzanak.

A modell nézőpontját dokumentálni kell. Általában ez a munka egészéért felelős személy álláspontja. Dokumentálni kell a modell célját is – azokat a kérdéseket, amelyekre a modell választ kíván adni.

Kereszteződés. Egy feladat befejezése több munka megkezdését is jelezheti, vagy egy munka több feladat befejezését is megvárhatja. A kereszteződések arra szolgálnak, hogy megjelenítsék a nyilak egymásra hatásának logikáját egyesítéskor és elágazáskor, vagy olyan események halmazát jelenítsék meg, amelyeket be lehet vagy kell fejezni a következő feladat megkezdése előtt. A kereszteződések típusait a táblázat tartalmazza:

A kereszteződés típusai

A diagramon szereplő összes metszéspont számozott, minden számnak J előtagja van.A metszéspont tulajdonságait a Definíciószerkesztő párbeszédablakban szerkesztheti. Az IDEFO-val és a DFD-vel ellentétben az IDEF3-ban a nyilak csak metszéspontokon keresztül egyesülhetnek és elágazhatnak.

Link objektum. Az IDEF3 hivatkozásobjektuma olyan ötletet, koncepciót vagy adatot fejez ki, amely nem társítható nyílhoz, metszésponthoz vagy feladathoz. Hivatkozási objektum hozzáadásához használja az |R|-t – (referencia objektum hozzáadása a diagramhoz - Referens) az eszközpalettán. A hivatkozás objektum a feladat téglalapjához hasonló téglalapként rajzolódik ki. A hivatkozási objektum nevét a Referencia párbeszédablakban (névszerkesztő előugró menüelem) állíthatjuk be, névként használhatjuk más diagramok valamelyik nyilak nevét, vagy az adatmodellből egy entitás nevét. A referenciaobjektumokat szaggatott vonalakkal kell munkaegységekhez vagy metszéspontokhoz kapcsolni. A hivatalos IDEF3 specifikáció a referenciaobjektumok három stílusát különbözteti meg: feltétel nélküli, szinkron és aszinkron. A BPwin csak a feltétel nélküli linkobjektumokat támogatja. Az objektumállapot-átmenet diagramokban használt szinkron és aszinkron referenciaobjektumok nem támogatottak.

5. Szimuláció

5.1 Üvegház modell

Model Navigator - Model Explorer

Kontextus diagram:

A0 bontási diagram:

A1 bontási diagram:

IDEF3 A11.1 diagram:

A12 adatfolyam diagram:

A2 bontási diagram:

IDEF3 A21.1 diagram:

A3 bontási diagram:

A4-es bontási diagram:

A5 bontási diagram:

A6 bontási diagram:

A63 adatfolyam diagram:

5.2 Matematikai modell

Az üvegházhatású gazdaság működésének részletesebb leírásához szükséges egy matematikai modell elkészítése a vállalkozás tevékenységének termékére.

Ez a matematikai modell az áruegységenkénti ár kiszámítását írja le különböző feltételek mellett.

e - a gyártó által meghatározott áruegység költsége, magában foglalja az áruegység előállításához kapcsolódó összes költséget, ennek a számnak a fő része a vetőmag vételára;

v - a vetőmag beszerzési ára, ez az az ár, amelyen a vállalkozás vetőmagot vásárolt a szállítótól ("vetőmag vásárlás" szakasz);

a - munkaerőköltség bérés a vállalkozáson belüli egyéb költségek);

g - üzemanyagok és kenőanyagok (üzemanyag és kenőanyagok);

n - az adókat (fogyasztói részt) az állam állapítja meg, és fix kulcsú;

k - ÁFA, általános forgalmi adó, szintén fix kulcsú;

r - kiskereskedelmi ár, ez az a pénzösszeg, amelyért a gyártó a termékének egy egységét eladja a piacon, a kiskereskedelmi árat általában az önköltségi ár határozza meg, bizonyos százalékos felárral;

s - a vállalat áruegységenkénti felára, általában minden vállalkozó egyénileg határozza meg annak összegét, ebben az esetben ez a költség 40% -a, azaz (e * 40) / 100

o - nagykereskedelmi ár, ez az egységnyi árura kínált pénzösszeg, 100 darabtól való vásárlás esetén ebben az esetben 10% kedvezmény jár a kiskereskedelmi árból;

os – kedvezmény tömeges vásárlás esetén (os

Matematikai modell a megtermelt termék egységenkénti költségének kiszámításához:

Matematikai modell az iparcikk egységnyi kiskereskedelmi árának kiszámításához:

Matematikai modell az iparcikk egységnyi nagykereskedelmi árának kiszámításához:

o=v+a+g+n+k+s - os

o=r - (r*10)/100

A termékek költségének kiszámítását az "Üvegházgazdaság" vállalkozásnál a számviteli osztály végzi, amely ellenőrzi a bizonylatok áramlását, figyelembe veszi a vállalkozás bevételeit és kiadásait, számviteli könyveket vezet, és igazolásokat állít ki. A vállalkozás matematikai modelljében kapott képletek alapján a könyvelő ki tudja számítani az áruk árát, mind a kis-, mind a nagykereskedelmet.

6. Benchmarking

Vállalkozásunk modellezéséhez 5 módszert használtunk: Dragon, UML, IDEF0, IDEF3, DFD. Vállalkozásunk modelljének bemutatására véleményünk szerint az UML módszertan a legjobb módja, mivel az üvegházhatású ipar főbb aspektusait jobban és pontosabban tükrözi.

Az UML diagramok viszonylag könnyen olvashatók.

Például a "Használati eset" diagram, amelyet az Üvegház megvalósítási rendszer tervezése eredményeként használtak, lehetővé teszi, hogy az ügyfél, a végfelhasználó és a fejlesztő közösen megvitassák a rendszer funkcionalitását és viselkedését. Az „Osztálydiagram” lehetővé teszi a rendszer felépítésének leírását, megmutatja a rendszer osztályait, azok attribútumait, metódusait és az osztályok közötti függőségeket, amely részletesen feltárhatja a vállalkozás forgatókönyvét és szervezetét.

A Dragon módszertan is nagyon világos felépítésű, de nem rendelkezik ilyen széles lehetőségekkel a különféle rendszerek modellezésére.

A Visio a legegyszerűbb és leginkább hozzáférhető folyamatmodellező eszköz. Ez a termék szabványos, minden vezérlőpanel számára ismerős az MS Office stílusában, és könnyen integrálható a csomag bármely alkalmazásával, ami megkönnyíti a vele való munkát a tapasztalatlan felhasználók számára. Az idő- vagy költségelemzés azonban riportok kidolgozását igényli, ami nagymértékben megnehezíti a termék használatát. A tipikus jelentések nyilvánvalóan nem elegendőek az üzleti folyamatok elemzéséhez. Ennek ellenére a Visio általános eszköz az üzleti folyamatok leírására Oroszországban és külföldön egyaránt. A Visio támogatja az IDEF és UML formátumokat az üzleti folyamatok leírásához. Lehetőség van formátumok önálló fejlesztésére is.

BPWIN - egy köztes helyet foglal el, amelyet egyszerűsége és nagyszerű elemzési képességei különböztetnek meg. A BPWIN funkciója nem csak diagramok rajzolása, hanem a modell integritásának és konzisztenciájának ellenőrzése is. A BPWIN logikai egyértelműséget biztosít a diagramelemek meghatározásában és leírásában, valamint a diagramok közötti kapcsolatok integritásának ellenőrzését. Az eszköz a modellezés leggyakoribb hibáit javítja. Ezenkívül a BPWIN támogatja a diagramelemekre alkalmazott egyéni tulajdonságokat az adott elemre jellemző tulajdonságok leírására. Ennek a rendszernek a fő korlátja az alapjául szolgáló IDEF szabvány, amelyben szigorú korlátozások vannak a modellek építésekor. Ez leegyszerűsíti az egyszerű eljárások leírását, de bonyolítja a nagy folyamatok leírását. Az 1DEF sémák az összetett folyamatok leírásakor számtalan, egymáshoz kapcsolódó, külsőre nagyon hasonló sémát kezdenek bemutatni, ami megnehezíti a folyamat egészének megértését.

7. Következtetés:

A tanfolyami munka során minden célunkat elértük.

Ennek kapcsán tanulmányoztuk a fejlesztés alatt álló tárgykört, nevezetesen az üvegházipar munkáját. Ehhez meg kellett érteni ennek a területnek a terminológiáját, össze kellett gyűjteni a szükséges szabályozási és jogi dokumentumokat, tanulmányozni kellett vállalkozásunk dokumentummintáit és nyomon követni azok mozgását a vállalkozáson belül és azon kívül egyaránt.

Ezen események eredményeként olyan információk is megszerzésre kerültek, amelyek alapján egy kezdeti elemzést végeztek, és elkészítették a tervezett modell vázlatát.

A fejlesztés következő szakasza a tervezési szakasz. Mielőtt elkezdené a tervezést és a megvalósítást, pontosan és részletesen magas szinten kell ismernie a követelményeket. Ezen kívül nagyon hasznos egy követelménystruktúra, amely bemenetként használható a rendszer kialakításához. Mindezt elemzéssel és modellezéssel érik el. Az elemzés és modellezés elvégzésével a feladatok szétválasztását értük el, amelyeket a projekt előtti állapotban előkészítettünk és egyszerűsítettünk a későbbi tervezési és kivitelezési tevékenységekhez. Különbséget teszünk a megoldandó problémák és a meghozandó döntések között, hogy megbirkózzunk velük.

A modellezési és tervezési szakaszban végzett munka eredményeként megkaptuk a megvalósításhoz elegendő információt tartalmazó rendszerprojektet.

Az üvegházipar munkáját elemezve megítélhetjük, hogy az egyes részlegek mekkora leterheltsége, mit és milyen eszközökkel kell elsősorban automatizálni.

A munka megkönnyítése érdekében lehetőség van új technológiák bevezetésére, amelyek megkönnyítik a munkát gazdaságunkban.

Irodalom:

Rogozov Yu.I., Stukotiy L.N., Sviridov A.S. "Rendszermodellezés" TRTU, 2004.

S.V. Maklakov „CASE-eszközök információs rendszerek fejlesztéséhez. BPwin és Erwin "-M.: DialogMifi, 2001.

Maklakov S. "A strukturális és az objektum megközelítés kombinálása a Computer Associates CASE-eszközök új generációjában" // Képzési és Tanácsadó Központ. 2002.

Egy kép többet ér ezer szónál

népi bölcsesség

Természetesen elméletileg a vezetőnek rendelkeznie kell egy funkcionális modellel a cég munkájáról, és teljesen mindegy, hogy a raktár vagy az informatikai rendszer felépítéséről beszélünk (az elvezetéstől a kérésig). De a valóságban ez szinte soha nem derül ki, ezért az ügyfél által kitűzött feladatra való tanulmányozás és megoldás keresése során elkészítem a vállalat vagy egy bizonyos folyamat (funkció) funkcionális modelljét is. saját.

Néhány szó a grafika előnyeiről

Mint tudják, az IDEF0 funkcionális modellek mindig grafikus diagramok. Megvannak a saját jellemzőik és az összeállítás szabályai. Erről egy kicsit később beszélünk. És most szeretnék néhány példát hozni a grafika hatékonyságára. Miért fókuszálok erre? Valószínűleg a vállalati munka funkcionális modelljének szükségességéről szóló kijelentésem után sokan úgy gondolták, hogy erre nincs szükség, és szavakkal el lehetett magyarázni, hogyan működik ez vagy az a funkció a cégben. Erről szeretnék beszélni.

És kezdésként tegyünk egy rövid kitérőt a történelembe. Térjünk vissza a távoli 1877-be, az orosz-török ​​háború idején. A Sytin nyomtató ekkor használt először grafikát a katonai műveletek leírására. Most mindez ismerős számunkra, bármilyen csata leírásakor nyilakkal ellátott kártyák jelennek meg a szemünk előtt, amelyek egyértelműen mutatják a csata menetét. És akkoriban a katonai műveleteket szavakkal írták le. Minden harchoz - sok-sok szó. És nagyon nehéz volt a végén megérteni, mi történik.

Ezért volt Sytin ötlete valóban forradalmi – elkezdte nyomtatni a térképek litográfiai másolatait az erődítmények és a katonai egységek helyszíneinek megjelölésével. Ezeket a kártyákat „Újságolvasóknak. Haszon". Az ötlet annyira aktuálisnak bizonyult, hogy a „Súgó” legelső példányszáma azonnal elfogyott. És akkor az ilyen alkalmazásokra nagy volt a kereslet. Az ok nyilvánvaló. A grafika segített megérteni azt, amit szinte lehetetlen kitalálni pusztán szavak segítségével.

A verbális leírások tehetetlenségére a saját gyakorlatomból is tudok hasonló példát felhozni. Egyik ügyfelem megkért, hogy vállaljam el az ERM rendszer bevezetését a cégénél. Arra a kérdésre, hogy van-e valamilyen technikai feladatuk, azt a választ kaptam: „Igen, van. De 400 oldala van." Ugyanakkor az ügyfél nagyon panaszkodott, hogy kollégáim, akikkel korábban megkeresett, vagy teljesen visszautasították a projektet, vagy egyértelműen felfújt árakat neveztek. Miután láttam, hogy a feladatkör valóban 400 oldalas, és kizárólag szöveges leírásból áll, megértettem a fejlesztők viselkedésének okait. Egy ilyen kötetnyi szöveg elolvasása, elmélyülése, minden árnyalat megértése csak a feladat megértéséhez és az ár megnevezéséhez valóban nagyon nehéz.

Felajánlottam ennek az ügyfélnek egy alternatív lehetőséget - mindent, ami lehetséges, grafikusan leírni jelölések formájában. Példákat mutatott neki a modellkedésre. Ennek eredményeként most újragondolják kívánságaikat és a feladatmeghatározás kialakítását.

Sok más példát is tudok arra, amikor az üzleti folyamatok grafikus modellezése mind kollégáimnak, üzleti tanácsadóknak és fejlesztőknek, mind maguknak az üzletembereknek segített.

Miért fontos ez a munkám szempontjából

Munkám mindig a meglévő rendszer módosításához kapcsolódik. És ahhoz, hogy változtatásokat hajtson végre, és elérje a kívánt eredményt, tanulmányoznia kell a már meglévőket. És nem mindegy, hogy pontosan mit csinálunk – a CRM rendszert a nulláról állítjuk be vagy telepítjük, hatékony ERP rendszert hozunk létre, különféle rendszereket integrálunk, hogy általánosságban növeljük a munka automatizálását. Mindenesetre először meg kell ismerni a meglévő munkarendszert, és csak ezt követően lehet javasolni néhány változtatást, és át kell gondolni a feladat megoldásának lehetőségeit.

A jelenlegi helyzet tanulmányozása után, mint bármely más külső szakértő, kereskedelmi ajánlatot készítek, amelyben a lehető legrészletesebben feltárom a jelenlegi helyzetről alkotott elképzelésemet, valamint a szükséges lépéseket. megoldja a feladatot, és természetesen a várt eredményt.

Az ilyen munkafelmérési jelentések terjedelmesek, több oldalt is elfoglalnak, ami egyrészt szükséges, másrészt megnehezíti az észlelést. Eleinte, mint sokan mások, arra gondoltam, hogy jó a terjedelmes beszámoló, mert az ember fizet a munkáért, és minél részletesebb tájékoztatást kell adni neki.

Valójában nem a hangerőt kell biztosítani, hanem a lényeget a lehető leggyorsabban és teljesebben átadni. A nagy mennyiségű szöveghez idő kell, ami az üzletembereknek gyakran nagyon kevés. A grafika pedig lehetővé teszi, hogy csökkentsem javaslatom terjedelmét, és világosan, érthető formában mutassam be a megoldást. Ennek eredményeként javaslataim jelentősen csökkentek, grafikák jelentek meg bennük, és gyorsabban kezdtek meghozni az együttműködés megkezdésével kapcsolatos döntéseket.

Ez az oka annak, hogy vizuális modelleket használok. Mint tudod, egy kép többet ér ezer szónál. Az üzleti folyamatok és egy vállalkozás munkájának korszerűsítési lehetőségeinek leírása esetében pedig ez igaz. És az IDEF0 jelölések nagyon jól használhatók itt.

De először ismerjük meg az alapfogalmakat, hogy mik a jelölések, miért van szükség rájuk, mi az IDEF0, mik a jellemzői és előnyei ennek a módszernek.

Mi az üzleti folyamatleíró jelölés

A jelölés egy üzleti folyamat leírására szolgáló formátum, amely a modellezésben használt grafikus objektumok, valamint a modellezési szabályok halmaza.

Valójában a jelölések egy speciális grafikai nyelv, amely lehetővé teszi egy vállalat munkájának leírását, vizuálisan bemutatja a különböző részlegek közötti interakciót, pl. leírni az üzleti folyamatokat. A jelölések felhasználhatók folyamat- vagy funkcionális modellezéshez.

Általánosságban elmondható, hogy a jelöléseket az üzleti elemzésben programozási nyelvnek nevezhetjük.

Mi az IDEF0?

Az IDEF0 egy funkcionális modellezési módszertan és grafikus jelölés, amely az üzleti folyamatok formalizálására és leírására szolgál. Az IDEF0 megkülönböztető jellemzője az objektum alárendeltségre helyezett hangsúly. Az IDEF0 a jobok közötti logikai kapcsolatokat veszi figyelembe, nem pedig azok időbeli sorrendjét (munkafolyamat). Wikipédia

Az IDEF0 szabványt 1981-ben az Egyesült Államok Légierejének Minisztériuma dolgozta ki ipari automatizálás céljából. A szoftverfejlesztés során a fejlesztők szembesülnek azzal, hogy új módszereket kell kidolgozniuk az üzleti folyamatok elemzésére. Ennek eredményeként megjelent az IDEF0 funkcionális modellezési módszertan, amelyben speciális IDEF0 jelöléseket használnak az elemzéshez.

A vállalat funkcionális modellje

Az IDEF0 funkcionális modell blokkok halmaza, amelyek mindegyike egy "fekete doboz" bemenetekkel és kimenetekkel, vezérlőkkel és mechanizmusokkal, amelyek a szükséges szintre vannak részletezve (bontva). A legfontosabb funkció a bal felső sarokban található. A funkciókat pedig nyilak és funkcionális blokkok leírása segítségével kapcsoljuk össze. Ezenkívül minden nyíltípusnak vagy tevékenységnek megvan a maga jelentése. Ez a modell lehetővé teszi az összes főbb folyamattípus leírását, mind adminisztratív, mind pedig szervezeti.

A nyilak lehetnek:

• Beérkezett üzenetek - bevezető, amely meghatározott feladatot.
• Kimenő - a tevékenység eredményének megjelenítése.
• Menedzserek (fentről lefelé) - ellenőrzési mechanizmusok (pozíciók, utasítások stb.).
• Mechanizmusok (alulról felfelé) - mit használnak a szükséges munka elvégzéséhez.

Pontosabb lenne a bejövő és kimenő nyilakat bemenetnek és kimenetnek nevezni, mivel angolul Input és Output néven szerepelnek. De a fordítás sajátosságai és a megszokott nevek már úgy néznek ki, mint amilyenek. És mégis, a kifejezések helyes megértéséhez fontos megjegyezni a jelentésüket ebben az esetben. Ezt erősíti az is, hogy ez a jelölés elsősorban szoftverfejlesztésre készült, és ebből a szempontból helyesebb a kifejezéseket lefordítani.

A nyilakat főnevekkel (tapasztalat, terv, szabályok), a blokkokat pedig igékkel írjuk alá, pl. leírják az elvégzett műveleteket (termék létrehozása, szerződéskötés, szállítmányozás).

Az IDEF0 egy nagyon egyszerű és egyben vizuális nyelv az üzleti folyamatok leírására. Ennek a szabványnak a segítségével lehetséges az információátadás a fejlesztők, tanácsadók és felhasználók között. A szabványt nagyon gondosan fejlesztették ki, kényelmes a tervezéshez, univerzális. Számos eszköz használható vele, például VISIO, BPWIN, ERWIN, Bussines studio stb.

Emellett az IDEF0 használata üzleti modellek létrehozására nemcsak kényelmes, hanem helyes is. Ezt az eszközt üzleti intelligencia céljára tervezték, hosszú és alapos hibakeresésen és polírozáson esett át. Ezért az IDEF0 használatával hibamentes funkcionális modellt létrehozni sokkal könnyebb, mint e szabvány használata nélkül.

Mint tudják, a szögeket a legjobb kalapáccsal kalapálni. Természetesen más eszközöket is használhatunk ehhez, de a kalapács a legfunkcionálisabb, és ezzel a legegyszerűbb egy szöget szépen és pontosan beütni. Tehát az IDEF0 használatával - ez az eszköz funkcionális modellezésre jött létre, és segítségével sokkal gyorsabban és pontosabban érheti el a kívánt eredményt.

Példa IDEF0 funkcionális modell létrehozására

Annak érdekében, hogy megértsük, hogyan kell dolgozni a funkcionális modellezéssel, adok egy példát a cikk írásának folyamatára.

A fő blokk a „Cikket írjon”.

Bejövő nyilak - "Tapasztalat", "Információ harmadik féltől származó forrásokból". Ezekre a bemenetekre van szükség a kezdéshez.

A cikk írásának útmutatói a „Kiadási terv”, „Kiadói követelmények”, „Az orosz nyelv szabályai”.

A „Mechanizmusok” szerepében pedig a szerző, a szövegíró, a lektor és a szoftver áll. Ebben az esetben a szerző hanganyagot készít, amelyben összegyűjti az összes gondolatot és ötletet, amelyet a cikkben tükröznie kell. Szövegíró az a személy, aki ezen anyag alapján a kiadó követelményei, a közzétételi terv és az orosz nyelv szabályai alapján elkészíti a cikk kész szövegét. A lektor ellenőrzi az anyagot, hogy nincs-e benne hiba. A szoftver pedig azok az eszközök, amelyeket a folyamat minden résztvevője használ munkája során.

Így beállítom a folyamat főbb paramétereit, bemenetét, kimenetét, valamint mindent, ami a folyamat sikeres megvalósításához szükséges. De ez csak a folyamat alapvető kerete. Ez leírja a vállalat egészének általános felépítését.

Valójában egy cikk létrehozásának folyamatát, mint minden üzleti folyamatot, lehet és kell is részletezni. Ehhez az általános „cikk írása” blokkot összefüggő elemekre bontom.

A mi esetünkben a munka 4 fő szakaszra oszlik:

1. Hang előkészítése.
2. Készítsen szöveget
3. Szöveg előkészítése közzétételre.
4. Helyezzen el egy cikket egy kiadványban.

A diagramon jól látható, hogy melyik szakaszban mely vezérlőelemek és mechanizmusok érintettek.

A hanganyag elkészítésekor tehát a szerző tudását és tapasztalatát használja fel, miközben a publikációs terv és a kiadó követelményei vezérlik. A szövegíró bemenetként egy hangfelvételt kap, amelyből az orosz nyelv szabályai szerint szöveget hoz létre. A lektor megkapja a szöveget és ellenőrzi, az orosz nyelv szabályai szerint is. Egy cikk publikációban való elhelyezéséhez speciális szoftverre van szükség.

A funkcionális modell létrehozásakor a legfontosabb paraméterek a cél és a nézőpont. Ezek alapján ugyanazon folyamatok modellezése némileg eltérően nézhet ki. Például az én esetemben a cél az, hogy "egy cikkírás folyamatáról beszéljek". A szövegíró álláspontja pedig az, hogy "a folyamatmenedzser szemszögéből írja meg és publikálja a cikket".

Tehát, ha ugyanazt a folyamatot egy szövegíró szemszögéből írnák le, akkor a bemenet egy élmény és egy hangfájl lenne a szerzőtől. Ráadásul ebben az esetben az Experience egy szövegíró tapasztalatát jelentené, de nem vezető vagy szerző tapasztalatát. Ezért az üzleti folyamatmodell létrehozásakor az első dolog, amit meg kell határozni, a nézőpont kiválasztása és a cél világos megfogalmazása.

Az ilyen modellezés nem csak vizuális, hanem nagyon kényelmes is a hatékony vezetői döntések meghozatalához. Például a fent leírt üzleti folyamatban két külön szakember van - egy szövegíró és egy lektor. Ha a projektfinanszírozás optimalizálását tűzöm ki feladatul, akkor a konstrukciónak köszönhetően azonnal látni fogom, hogy hol van és hogyan lehet ezt megtenni. Tehát a szövegíró és a lektor megközelítőleg ugyanazokat a szabályokat használja, de a szövegíró hangot fogad, és szöveg formájában adja meg az eredményt, míg a lektor elfogad és szöveget is ad. És ezért ha kell, mondjuk a lektori munkadíj feléért ajánlhatok szövegírót. Így pénzt és időt spórolok a különböző szakemberek interakciójával. Természetesen megértem a lektorok minden érdemét és azt, hogy miért jobb az egyes szakemberekkel dolgozni. De emlékeztetlek, hogy van egy feladatom: a költségoptimalizálás.

Ilyen vizuális eszköz nélkül nehezebb lenne meghatározni, hogy a blokkok közül melyiket lehet eltávolítani, és így optimalizálni a munkát.

IDEF0 jelölések létrehozása

Számos különböző szoftvertermék használható jelölések létrehozására. Néhányat kifejezetten funkcionális modellezésre terveztek, mások bármilyen grafikai elemekkel végzett munkához készültek. Hogy hol és hogyan építi meg ezeket a modelleket, az Önön múlik.

Személy szerint úgy gondolom, hogy az első szakaszban semmi sem jobb, mint egy sima papír, egy egyszerű ceruza és egy radír, amivel hiba esetén kiigazíthat.

A meglévő üzleti folyamatok jelölésének létrehozása érdekében, pl. ahhoz, hogy leírjuk, hogyan működik a vállalat jelenleg, tanulmányozni kell a munkaelveket. Ehhez egy külső szakértő (tanácsadó, fejlesztő) készít interjút. Az első szakaszban a cégvezető válaszol a kérdésekre, majd a jelölés részletezése során interjúkat készítenek a különböző munkafázisokért felelős munkatársakkal.

Fontos megérteni, hogy ennek eredményeként 2 jelölésre lesz szükség. Az első az üzleti folyamatokat olyan formában jeleníti meg, ahogy vannak. Interjú alapján készíti el, és minden részletet egyeztet a cég alkalmazottaival és a vezetővel. Nagyon fontos, hogy a meglévő folyamatokról alkotott elképzelésed egybeessen a valósággal, és ez minden szinten megerősítést igényel.

A második jelölés „ahogy lennie kell”. Az első és az Ön által javasolt változtatások alapján jön létre a munka struktúrájában, hogy a feladat részeként optimalizálja és automatizálja a vállalat munkáját.

IDEF0 követelmények

Az IDEF0 szabvány alapkövetelményeit elvileg fentebb leírtam és egy példával mutattam be.

1. A bal felső sarokban mindig a fő elem.
2. Minden elemnek rendelkeznie kell bejövő és kimenő nyilakkal, mivel a végrehajtáshoz a bemeneten kell valamit fogadni (megrendelés, feladat), a kimeneti feldolgozás után pedig a kész terméket kell átvinni. A bejövő nyilak mindig a bal oldalon, a kimenő nyilak mindig a jobb oldalon vannak.
3. Fent találhatók a vezérlőelemek, alább pedig a folyamat befejezéséhez szükséges mechanizmusok.
4. Ha egy lapon (képernyőn) több blokk található, minden következő blokk az előző jobb oldalán és alatta található.
5. Törekedni kell a sémák létrehozására oly módon, hogy a nyilak metszéspontja a szükséges minimumra csökkenjen.

Gyakori hibák

A funkcionális modellezés különféle eszközökkel történik, beleértve azokat is, amelyek nem modellezésre szolgálnak. Ez utóbbi esetben nem kell ellenőrizni a szabvány hibáit és korlátait. A láthatóság növelésének vágya és a tapasztalat hiánya gyakran hibákhoz vezet.

Különböző színek használata

A diagram minden eleme egyformán fontos. A funkcionális modellezésben nincsenek többé-kevésbé fontos elemek. Bármelyik eltűnése a folyamat megszakadásához és gyártási hibához vezet.

Amikor papíron vagy különböző programokban modelleznek, a felhasználók gyakran különböző színek használatával próbálják növelni a láthatóságot. Ez az egyik leggyakoribb hiba. Valójában a többszínű nyilak és blokkok használata csak további zavart okoz, és torzítja a séma észlelését.

A modellnek fekete-fehérben olvashatónak kell lennie, további színséma nélkül. Ez a megközelítés egyszerre segít elkerülni a félreértéseket és fegyelmezi a modell készítőjét, ennek eredményeként növekszik a modell olvashatósága és műveltsége.

Túl sok blokk

A modell összeállításakor gyakran igyekeznek egy lapon megjeleníteni a cég munkájának minden árnyalatát minden részlettel. Az eredmény nagyon sok blokk sok vezérlőnyíl. Az olvashatóság elveszett.

A legjobb megoldás a probléma megértéséhez elegendő részletezés, és semmi több. Egy-egy folyamat részletes nézetének kiválasztásakor az egyes részlegek vagy akár egy alkalmazott munkájának részletes részletei derülhetnek ki. Ilyen struktúra pedig csak akkor jön létre, ha valóban szükséges a munkához vagy a döntéshozatalhoz.

A szerkezet megsértése beállításkor

Figyelje meg alaposan, hogy elkerülje a zavart vagy a bejövő, kimenő és egyéb fontos elemek nélküli folyamatokat. Például, ha a fenti példában úgy látom, hogy a nézőpontot áthelyezem a szövegíróra, akkor eltávolítom a szerzőt a sémából. És akkor szükségtelenné válik a "szerző és külső források tapasztalata", valamint a közzétételi terv ellenőrzése. Hiszen a szerző ezeket használja. A szövegíró a hangfájllal dolgozik. És ha az általános sémában maradnak, akkor a részletezés során érthetetlenül hova vezetnek, és zavart okoznak.

Hasonlóképpen, ha úgy döntök, hogy hozzáadok egy blokkot, fontos megbizonyosodnom arról, hogy az is rendelkezik az összes szükséges attribútummal. Itt nagyon fontos a körültekintés, mert az összetett üzleti folyamatok modellezésekor a modell egyik részének változása egy másikban is változást eredményezhet. Be kell őket adni.

A vezérlőelemek és blokkok elnevezésének szabályai

Fontos megjegyezni egy egyszerű szabályt: a vezérlő nyilakat főneveknek, a blokkokat igének nevezik. Ezt az IDEF0 szabvány elfogadja, és ez a megközelítés segít elkerülni a félreértéseket és a hibákat.

Leggyakrabban a blokkok elnevezésekor követnek el hibákat. Például a "Cikket hozzon létre" helyett azt írják, hogy "Cikket hozzon létre". Ebben a megközelítésben a blokkok cselekvések, ezért mindig igéknek kell lenniük.

Az IDEF0 használatának előnyei

• A legelső előny nyilvánvaló – ez a láthatóság.Ön maga kezdi megérteni, hogyan működik ez vagy az a rendszer, és világosan elmagyarázhatja, hol vannak „vékony foltok” ebben a rendszerben, és hogyan segítenek a megoldások megszabadulni tőlük.
• Kölcsönös megértés és a nézeteltérés hiánya. Amikor a funkcionális modellt használó vállalat munkáját tárgyalja, vizuális és intuitív feladatblokkjai vannak vezérlőkkel. Ezen túlmenően a funkcionális modellezés magában foglalja egy szószedet létrehozását is, amelyben a szimbólumok és kifejezések megjelennek. Ennek eredményeként Ön és ügyfele, menedzsere és más alkalmazottak ugyanazt a nyelvet beszélik, amikor egy problémáról beszélnek.
• A modellkészítés egyszerűsége és nagy sebessége. Természetesen a modellezés megtanulása nem olyan egyszerű, mint amilyennek látszik. Hiszen egy séma valójában egy szupersűrű információ-megjelenítés, ami nagyon jó a megértéshez, de egy ilyen bemutatás megvalósításához speciális megközelítésre van szükség. Az elemző agya ebben az esetben egyrészt nagyon erős présként, másrészt szűrőként működik. De tapasztalattal ez a folyamat nagyon felgyorsul. Ennek eredményeként egy olyan eszközt kap, amely segítségével Ön maga is kitalálja, mi történik egy adott rendszerben, és egy rövid idő alatt elkészített szemléltetőeszköz segítségével szemlélteti a kollégák vagy az ügyfelek számára a fontos szempontokat.
• Fegyelem és semmi hiba. Az IDEF0 szabvány szigorú kereteket és szabályokat feltételez. Ez a szemlélet fegyelmez, a szabvány keretein belüli cselekvés szokása pedig segít elkerülni a figyelmetlenségből fakadó hibákat. A szabvány bármilyen megsértése azonnal észrevehető.

Milyen nehézségeket okoz az IDEF0 használata

Fontos megérteni, hogy csak a legegyszerűbb esetekben két üzleti elemző készít pontosan azonos funkcionális modelleket a vállalat munkájának leírására. Bármely modell tükrözi az elemző tapasztalatait, az általa leírni kívánt üzletág megértésének mélységét, valamint valamilyen módon az üzletről alkotott személyes álláspontját is. Azok. az ember olyan üzleti modellt alakít ki a vezető szemszögéből, mintha ő lenne a vezető.

Ugyanakkor úgy gondolom, hogy az üzleti elemző nem egészen szakma, minden üzletvezető vagy valamilyen rendszer fejlesztője üzletelemzéssel foglalkozik, aki elemzi az üzletet és a leghatékonyabb rendszer felépítésére törekszik. Ezeknek az embereknek és ezeknek a céloknak a célja az IDEF0 eszköz.

Ezért nagyon fontos, hogy a funkcionális üzleti modell összeállításakor folyamatosan konzultáljon a vállalat vezetőjével, hogy ne kövessen el olyan hibákat, amelyek automatikusan hibákhoz vezetnek a bomlás szakaszaiban. Ezenkívül a későbbi szakaszokban további jóváhagyásokra lehet szükség a strukturális részlegek vezetőitől és az alkalmazottaktól. Csak akkor hajthat végre néhány változtatást és javaslatot, ha „ahogy van” funkcionális modellje valóban tükrözi a dolgok valós állapotát. És ahhoz, hogy az ilyen munkában magas színvonalú eredményeket érjen el, mindenekelőtt gyakorlati tapasztalatra és egy adott típusú vállalkozás jellemzőinek ismeretére van szükség.

Tudtad, mi az a gondolatkísérlet, gedanken kísérlet?
Ez egy nem létező gyakorlat, egy túlvilági élmény, annak képzelete, ami valójában nincs. A gondolatkísérletek olyanok, mint az álmodozás. Szörnyeket szülnek. Ellentétben a fizikai kísérlettel, amely hipotézisek kísérleti tesztje, a „gondolatkísérlet” varázslatosan helyettesíti a kísérleti tesztet a kívánt, nem tesztelt következtetésekkel, manipulálva azokat a logikai konstrukciókat, amelyek valójában magát a logikát sértik azáltal, hogy bizonyított premisszákat használnak bizonyítottként, azaz helyettesítés. A „gondolatkísérletekre” jelentkezők fő feladata tehát az, hogy megtévessze a hallgatót vagy az olvasót azáltal, hogy egy valódi fizikai kísérletet a „babájával” helyettesít – ez a fiktív érvelés feltételesen szabadlábra helyezve, fizikai igazolás nélkül.
A fizika képzeletbeli, "gondolatkísérletekkel" való megtöltése abszurd, szürreális, zavaros világképhez vezetett. Egy igazi kutatónak meg kell különböztetnie az ilyen "burkolókat" a valódi értékektől.

A relativisták és a pozitivisták azzal érvelnek, hogy a „gondolatkísérlet” nagyon hasznos eszköz az elméletek (amelyek a fejünkben is felmerül) konzisztencia vizsgálatára. Ezzel megtévesztik az embereket, hiszen bármilyen ellenőrzést csak az ellenőrzés tárgyától független forrás végezhet. Maga a hipotézis kérelmezője nem lehet saját kijelentésének próbája, hiszen ennek az állításnak magának az az oka, hogy az állításban a kérelmező számára nem látható ellentmondások.

Ezt látjuk az SRT és a GR példáján, amelyek egyfajta tudományt és közvéleményt irányító vallássá változtak. Semmiféle ellentmondó tény nem tudja felülmúlni Einstein képletét: "Ha a tény nem felel meg az elméletnek, változtasd meg a tényt" (Egy másik változatban: "A tény nem felel meg az elméletnek? - Annál rosszabb a tény ").

A maximum, amit egy "gondolatkísérlet" állíthat, az csak a hipotézis belső konzisztenciája a pályázó saját, sokszor egyáltalán nem igaz logikájának keretei között. A gyakorlat betartása ezt nem ellenőrzi. Valódi tesztre csak valódi fizikai kísérlet során kerülhet sor.

A kísérlet kísérlet, mert nem a gondolat finomítása, hanem a gondolat próbája. Az önmagában következetes gondolat nem tudja magát tesztelni. Ezt Kurt Gödel is bebizonyította.

Gennagyij Vernyikov

Jelenleg Oroszországban meredeken megnőtt az érdeklődés a Nyugaton általánosan elfogadott vezetési szabványok iránt, azonban a valós vezetési gyakorlatban van egy nagyon fontos momentum. Sok vezetőt továbbra is megzavarhat a vállalat szervezeti felépítésére vagy a meglévő üzleti folyamatok felépítésére vonatkozó közvetlen kérdés. A legfejlettebb és leggyakrabban olvasó gazdasági folyóirat-menedzserek általában elkezdenek csak számukra érthető hierarchikus diagramokat rajzolni, de ebben a folyamatban általában gyorsan megtorpannak. Ugyanez vonatkozik az alkalmazottakra és a különböző szolgálatok és funkcionális egységek vezetőire. A legtöbb esetben az egyetlen meghatározott szabályrendszer, amely alapján a vállalkozásnak működnie kell, egy különálló szabályzat és munkaköri leírás. Leggyakrabban ezek a dokumentumok több mint egy éve készültek, rosszul strukturáltak és nem kapcsolódnak egymáshoz, és ennek eredményeként egyszerűen port gyűjtenek a polcokon. Egyelőre indokolt volt egy ilyen megközelítés, hiszen az orosz piacgazdaság kialakulása idején gyakorlatilag hiányzott a verseny fogalma, és nem volt különösebb szükség a költségek kalkulálására - a profit óriási volt. Ennek eredményeként az elmúlt két évben teljesen érthető képet láthattunk: a 90-es évek elején felnövő nagyvállalatok fokozatosan veszítenek, egészen a teljes piacról való kivonulásig. Ez részben annak tudható be, hogy a vállalatnál nem vezettek be vezetési standardokat, teljesen hiányzott a funkcionális tevékenység- és küldetésmodell fogalma. A különböző tevékenységi területek modellezésével lehetőség nyílik a menedzsment "szűk keresztmetszete" hatékony elemzésére és az általános üzleti séma optimalizálására. Ám, mint ismeretes, minden vállalkozásban csak a közvetlenül nyereséget hozó projektek élveznek elsőbbséget, így általában csak a cégvezetés kézzelfogható válsága során van szó a tevékenységek vizsgálatáról és átszervezéséről.

Az 1990-es évek végén, amikor a piac versenyképesebbé vált, és a vállalkozások jövedelmezősége meredeken csökkenni kezdett, a vezetők nagy nehézséget éreztek a költségek optimalizálása terén, hogy a termékek nyereségesek és versenyképesek maradjanak. Éppen abban a pillanatban mutatkozott meg egyértelműen az az igény, hogy szemünk előtt legyen a vállalkozás tevékenységének egy olyan modellje, amely tükrözi a különböző alrendszerek egy üzleten belüli összekapcsolásának összes mechanizmusát és elvét.

Maga az "üzleti folyamatmodellezés" fogalma a legtöbb elemző életébe a vállalatirányítás komplex automatizálására tervezett komplex szoftvertermékek piaci megjelenésével egyidejűleg került be. Az ilyen rendszerek mindig a vállalat tevékenységének projekt előtti mélyreható felmérését jelentik. Ennek a felmérésnek az eredménye egy szakértői vélemény, amelyben külön bekezdésekben ajánlásokat fogalmaznak meg a tevékenységek irányításának „szűk keresztmetszete” megszüntetésére. Ebből a következtetésből kiindulva közvetlenül az automatizálási rendszer bevezetése előtt sor kerül az úgynevezett üzleti folyamatok átszervezésére, amely esetenként meglehetősen súlyos és fájdalmas a vállalat számára. Ez természetesen egy csapat, amely az évek során fejlődött, mindig nehéz rávenni "új módon gondolkodni". A vállalkozások ilyen átfogó felmérései mindig összetettek, és esetenként jelentősen eltérnek. A komplex rendszerek modellezésének ilyen problémáinak megoldására jól bevált módszertanok és szabványok léteznek. Ezek a szabványok magukban foglalják az IDEF módszertancsaládot. Segítségükkel hatékonyan jelenítheti meg és elemezheti a komplex rendszerek széles skálájának tevékenységi modelljeit különböző szekciókban. Ugyanakkor a rendszerben zajló folyamatok vizsgálatának szélességét és mélységét maga a fejlesztő határozza meg, ami lehetővé teszi, hogy a létrehozott modellt ne terheljük túl szükségtelen adatokkal. Jelenleg a következő szabványok tulajdoníthatók az IDEF családnak:

Az IDEF0 egy funkcionális modellezési módszer. Az IDEF0 vizuális grafikus nyelv segítségével a vizsgált rendszer a fejlesztők és az elemzők számára egymással összefüggő függvények (funkcionális blokkok – IDEF0 szempontjából) halmazaként jelenik meg. Általában az IDEF0 modellezés az első lépés bármely rendszer tanulásában;

IDEF1 - a rendszeren belüli információáramlások modellezésére szolgáló módszertan, amely lehetővé teszi azok szerkezetének és kapcsolatainak megjelenítését és elemzését;

IDEF1X (IDEF1 Extended) - relációs struktúrák építésének módszertana. Az IDEF1X az Entity-Relationship (ER) típusú módszertanhoz tartozik, és jellemzően a kérdéses rendszer szempontjából releváns relációs adatbázisok modellezésére szolgál;

Az IDEF2 a rendszerek fejlődésének dinamikus modellezésének módszertana. A dinamikus rendszerek elemzésének igen komoly nehézségei miatt ezt a szabványt gyakorlatilag felhagyták, fejlesztését már a kezdeti szakaszban felfüggesztették. Jelenleg azonban léteznek olyan algoritmusok és számítógépes megvalósításaik, amelyek lehetővé teszik IDEF0 statikus diagramok halmazának dinamikus modellekké alakítását "színes Petri-hálók" (CPN - Color Petri Nets) alapján;

Az IDEF3 egy rendszerben lezajló folyamatok dokumentálásának módszertana, amelyet például a vállalatok technológiai folyamatainak tanulmányozására használnak. Az IDEF3 minden folyamathoz leírja a forgatókönyvet és a műveletek sorrendjét. Az IDEF3 közvetlen kapcsolatban áll az IDEF0 módszertannal – minden függvény (funkcionális blokk) külön folyamatként ábrázolható az IDEF3 eszközök segítségével;

Az IDEF4 egy módszertan objektum-orientált rendszerek felépítésére. Az IDEF4 eszközök lehetővé teszik az objektumok szerkezetének és interakciójuk alapelveinek vizuális megjelenítését, ezáltal lehetővé téve az összetett objektumorientált rendszerek elemzését és optimalizálását;

Az IDEF5 komplex rendszerek ontológiai vizsgálatának módszertana. Az IDEF5 módszertan segítségével a rendszerontológia egy bizonyos terminus- és szabályszókincs segítségével írható le, amely alapján megbízható állítások alkothatók a vizsgált rendszer adott időpontban fennálló állapotáról. Ezen megállapítások alapján következtetéseket vonunk le a rendszer továbbfejlesztésére és annak optimalizálására.
A cikk keretein belül megvizsgáljuk a leggyakrabban használt IDEF0 funkcionális modellezési módszertant.

Az IDEF0 szabvány története

Az IDEF0 módszertan a funkcionális rendszerek leírására jól ismert grafikus nyelv, a SADT (Structured Analysis and Design Teqnique) fejlesztésének következő állomásának tekinthető. Néhány évvel ezelőtt Oroszországban megjelent egy azonos nevű könyv kis kiadása, amely a SADT-diagramok készítésének alapelveit ismerteti. Történelmileg az IDEF0 szabványt 1981-ben fejlesztették ki egy kiterjedt ipari automatizálási program részeként, amely az ICAM (Integrated Computer Aided Manufacturing) elnevezést viselte, és az Egyesült Államok Légierejének Minisztériuma javasolta. Maga az IDEF szabványcsalád elnevezését ennek a programnak a nevéből örökölte (IDEF=ICAM DEFINÍCIÓ). A gyakorlati megvalósítás során az ICAM program résztvevői szembesültek azzal, hogy új módszereket kell kidolgozni az ipari rendszerek interakciós folyamatainak elemzésére. Ugyanakkor az üzleti folyamatok leírására szolgáló továbbfejlesztett funkciók mellett az új szabvány egyik követelménye az volt, hogy rendelkezésre álljon egy hatékony módszertan az "elemző-specialistán" belüli interakcióhoz. Vagyis az új módszernek csoportmunkát kellett volna biztosítania a modell létrehozásán, a projektben részt vevő összes elemző és szakember közvetlen részvételével.

A megfelelő megoldások keresése eredményeként született meg az IDEF0 funkcionális modellezési módszertan. 1981 óta az IDEF0 szabvány több kisebb változtatáson ment keresztül, többnyire korlátozó jellegűek, és utolsó változatát 1993 decemberében adta ki az Egyesült Államok Nemzeti Szabványügyi és Technológiai Intézete (NIST).

Az IDEF0 alapelemei és fogalmai

Az IDEF0 grafikus nyelv rendkívül egyszerű és harmonikus. A módszertan négy fő koncepción alapul.

Ezek közül az első az Activity Box koncepciója. A funkcionális blokk grafikusan téglalapként van ábrázolva (lásd az 1. ábrát), és a vizsgált rendszeren belül néhány speciális funkciót képvisel. A szabvány előírásai szerint az egyes funkcionális blokkok nevét verbális hangulatban kell megfogalmazni (például "szolgáltatást termelni" és nem "szolgáltatást termelni").

A funkcionális blokk mind a négy oldalának megvan a maga sajátos jelentése (szerep), míg:

A vizsgált rendszeren belül minden egyes funkcionális egységnek saját egyedi azonosító számmal kell rendelkeznie.

1. ábra Funkcióblokk.

Az IDEF0 módszertan második „bálnája” az interfészív (nyíl) fogalma. Az interfész íveket gyakran folyamoknak vagy nyilaknak is nevezik. Az interfészív egy olyan rendszerelemet jelöl, amelyet egy funkcióblokk dolgoz fel, vagy más módon befolyásolja a funkcióblokk által megjelenített funkciót.

Az interfész ív grafikus megjelenítése egyirányú nyíl. Minden interfész ívnek saját egyedi névvel kell rendelkeznie (Arrow Label). A szabvány szerint a névnek egy főnév forgalmának kell lennie.

Az interfész ívek segítségével különféle objektumok jelennek meg, amelyek valamilyen szinten meghatározzák a rendszerben lezajló folyamatokat. Az ilyen objektumok lehetnek a valós világ elemei (alkatrészek, kocsik, alkalmazottak stb.) vagy adat- és információáramlások (dokumentumok, adatok, utasítások stb.).

Attól függően, hogy az adott interfész ív melyik oldalra közelít, "bejövő", "kimenő" vagy "vezérlő" néven szerepel. Ezenkívül az egyes funkcionális ívek "forrása" (eleje) és "vevője" (vége) csak funkcionális blokkok lehetnek, míg a "forrás" csak a blokk kimeneti oldala, a "vevő" pedig bármilyen a maradék háromból.

Megjegyzendő, hogy a szabvány követelményei szerint minden funkcionális blokknak rendelkeznie kell legalább egy vezérlő interfész ívvel és egy kimenővel. Ez érthető – minden folyamatnak bizonyos szabályok szerint kell lezajlania (amelyet a vezérlőív jelenít meg), és valamilyen eredményt kell produkálnia (kimenő ív), különben a figyelembevételének nincs értelme.

IDEF0 - diagramok készítésekor fontos a bejövő interfész ívek helyes elkülönítése a vezérlőktől, ami gyakran nem könnyű. Például a 2. ábra a "Munkadarab feldolgozása" funkcióblokkot mutatja.

Valós folyamatban a feldolgozást végző dolgozó munkadarabot és technológiai utasítást kap a feldolgozáshoz (illetve biztonsági előírásokat a géppel végzett munka során). Tévesen úgy tűnhet, hogy a munkadarab és a technológiai utasításokat tartalmazó dokumentum is bejövő objektum, de ez nem így van. Valójában ebben a folyamatban a munkadarabot a technológiai utasításokban szereplő szabályok szerint dolgozzák fel, amelyeket a vezérlő interfész ívével kell ábrázolni.

2. ábra.

Másik dolog az, amikor a technológiai utasításokat a vezető technológus dolgozza fel és módosítja azokat (3. ábra). Ebben az esetben ezeket már a bejövő interfészív megjeleníti, a vezérlőobjektum pedig például az új ipari szabványok, amelyek alapján ezek a változtatások megtörténnek.

3. ábra

A fenti példák hangsúlyozzák a bejövő és vezérlő interfészívek látszólag hasonló jellegét, de mindig vannak bizonyos különbségek az azonos osztályba tartozó rendszerek esetében. Például a vállalkozások és szervezetek figyelembevétele esetén az objektumok öt fő típusát különböztetjük meg: anyagáramlások (alkatrészek, áruk, nyersanyagok stb.), pénzügyi áramlások (készpénzes és nem készpénzes, befektetések stb.), dokumentum áramlások (kereskedelmi, pénzügyi és szervezeti dokumentumok), információáramlások (információk, szándékadatok, szóbeli utasítások stb.) és erőforrások (alkalmazottak, gépek, gépek stb.). Ebben az esetben különböző esetekben a bejövő és kimenő interfész ívek minden típusú objektumot megjeleníthetnek, amelyek csak a dokumentumok és információk áramlásával kapcsolatosakat kezelik, és csak az erőforrások jeleníthetők meg ív-mechanizmusként.

A vezérlő interfész ívek kötelező jelenléte az egyik fő különbség az IDEF0 szabvány és a DFD (Data Flow Diagram) és WFD (Work Flow Diagram) osztályok más módszerei között.

Az IDEF0 szabvány harmadik alapkoncepciója a Dekompozíció. A dekompozíció elvét akkor alkalmazzuk, amikor egy összetett folyamatot alkotó funkciókra bontunk. Ebben az esetben a folyamat részletezettségét közvetlenül a modell fejlesztője határozza meg.

A dekompozíció lehetővé teszi a rendszermodell fokozatos és strukturált ábrázolását az egyes diagramok hierarchikus struktúrája formájában, ami kevésbé terheli és könnyen emészthetővé teszi.

Az IDEF0 modell mindig a rendszer egészének nézetével indul – egyetlen funkcionális blokk, amelynek interfészívei túlnyúlnak a vizsgált területen. Az ilyen, egy funkcióblokkot tartalmazó diagramot kontextusdiagramnak nevezzük, és az "A-0" azonosítóval jelöljük.

A kontextusdiagram magyarázó szövegében fel kell tüntetni a diagram elkészítésének célját (Célját) rövid leírás formájában, és rögzíteni kell a nézőpontot (Nézetpont).

Az IDEF0 modell fejlesztési céljának meghatározása és formalizálása rendkívül fontos szempont. Valójában a cél határozza meg a vizsgált rendszerben azokat a releváns területeket, amelyekre először fókuszálni kell. Például, ha egy vállalkozás tevékenységét modellezzük annak érdekében, hogy a jövőben ezen a modellen alapuló információs rendszert építsünk ki, akkor ez a modell jelentősen eltér attól, amelyet ugyanarra a vállalkozásra fejlesztenénk, de optimalizálási céllal. ellátási láncok.

A nézőpont határozza meg a modell fejlesztésének fő irányát és a szükséges részletezési szintet. A nézőpont egyértelmű rögzítése lehetővé teszi a modell kirakását, megtagadva az egyes nem szükséges elemek részletezését és tanulmányozását a rendszer választott nézőpontja alapján. Például ugyanannak a vállalkozásnak a funkcionális modelljei a vezető technológus és a pénzügyi igazgató szempontjából jelentősen eltérnek a részletezésük irányában. Ennek az az oka, hogy a pénzügyi igazgatót végső soron nem érdeklik a nyersanyag-feldolgozás szempontjai a gyártógépeken, a vezető technológust pedig a pénzáramlások megrajzolt sémája. A nézőpont helyes megválasztása jelentősen csökkenti a végső modell elkészítésére fordított időt.

A dekompozíció folyamatában a funkcionális blokkot, amely a kontextusdiagramban a rendszer egészét jeleníti meg, egy másik diagram részletezi. A második szint eredményül kapott diagramja olyan funkcionális blokkokat tartalmaz, amelyek a kontextusdiagram funkcionális blokkjának fő alfunkcióit jelenítik meg, és ehhez kapcsolódóan gyermekdiagramnak (Child diagram) nevezik (a gyermekdiagramhoz tartozó funkcionális blokkok mindegyike ill. gyermekblokknak hívják – Child Box). Viszont a funkcionális blokkot - az őst nevezzük szülőblokknak a gyermek diagrammal kapcsolatban (Parent Box), és a diagramot, amelyhez tartozik - a szülő diagramnak (Parent Diagram). A gyermekdiagram minden egyes alfunkciója tovább részletezhető a megfelelő funkcionális blokk hasonló bontásával. Fontos megjegyezni, hogy egy funkcionális blokk minden egyes bontása esetén az ebbe a blokkba tartozó vagy onnan kilépő összes interfészív rögzítve van a gyermekdiagramon. Ezzel elérhető az IDEF0 modell szerkezeti integritása. A bontás elvét a 4. ábra jól szemlélteti. Érdemes figyelni a funkcionális blokkok számozása és a diagramok közötti összefüggésre – minden blokknak saját egyedi sorszáma van a diagramon (a téglalap jobb alsó sarkában található szám) , a jobb sarokban lévő jelölés pedig a blokk gyermekdiagramjának számát jelzi. Ennek a jelölésnek a hiánya azt jelzi, hogy ennek a blokknak nincs dekompozíciója.

Gyakran vannak olyan esetek, amikor nincs értelme továbbra is figyelembe venni az egyes interfész íveket a hierarchia egy bizonyos szintje alatti gyermekdiagramokban, vagy fordítva - az egyes íveknek nincs gyakorlati értelme egy bizonyos szint felett. Például egy interfészív, amely egy "részletet" ábrázol a "Megmunkálás esztergán" funkcióblokk bemenetén, nincs értelme magasabb szintű diagramokra reflektálni - ez csak túlterheli a diagramokat és megnehezíti az olvashatóságot. Másrészt meg kell szabadulni a különálló "koncepcionális" interfész ívektől, és nem kell azokat egy bizonyos szintnél mélyebben részletezni. Az ilyen problémák megoldására az IDEF0 szabvány előírja az alagút fogalmát. Az „alagút” megjelölés (Arrow Tunnel) az interfészív eleje körül két zárójelben azt jelenti, hogy ez az ív nem öröklődött a funkcionális szülőblokktól, és csak ezen a diagramon jelent meg (az „alagútból”). Viszont az interfészív vége (nyíl) körül a vevőblokk közvetlen közelében lévő azonos megjelölés azt jelenti, hogy ez az ív nem jelenik meg, és nem veszi figyelembe a blokk gyermekdiagramjában. Leggyakrabban előfordul, hogy az egyes objektumokat és a hozzájuk tartozó interfészíveket nem veszik figyelembe a hierarchia egyes köztes szintjein - ebben az esetben először "belemerülnek az alagútba", majd szükség esetén "visszatérnek az alagútból".

Az IDEF0 fogalmak közül az utolsó a Glossary. Minden IDEF0 elemhez: diagramok, funkcióblokkok, interfész ívek, a meglévő szabvány magában foglalja a megfelelő definíciók, kulcsszavak, narratív utasítások stb. halmazának létrehozását és karbantartását, amelyek jellemzik az elem által megjelenített objektumot. Ezt a készletet szójegyzéknek nevezik, és ez az elem lényegének leírása. Például a „fizetési megbízás” vezérlőfelület ívéhez a szószedet tartalmazhatja a dokumentum ívének megfelelő mezők listáját, a szükséges vízumkészletet stb. A szószedet harmonikusan kiegészíti a vizuális grafikai nyelvet, ellátva a diagramokat a szükséges kiegészítő információkkal.

4. ábra Funkcionális blokkok bontása.

Az IDEF0 diagramok összetettségének korlátozásának elvei

Az IDEF0 modellek jellemzően összetett és koncentrált információkat hordoznak, és torlódásuk korlátozása és olvashatóvá tétele érdekében a megfelelő bonyolultsági korlátozásokat a megfelelő szabvány tartalmazza:

A diagramban szereplő funkcióblokkok számának korlátozása három-hatra. A felső határ (hat) arra kényszeríti a tervezőt, hogy hierarchiát alkalmazzon az összetett tárgyak leírásakor, az alsó határ (három) pedig biztosítja, hogy a megfelelő diagram elegendő részlettel rendelkezzen a létrehozásához;

Az egy funkcionális blokkot megközelítő (egy funkcionális blokkot elhagyó) interfészívek számának korlátozása négyre.
Természetesen egyáltalán nem szükséges szigorúan betartani ezeket a korlátozásokat, azonban a tapasztalatok szerint ezek nagyon praktikusak a valós munkában.

A csoportmunka tudományága egy IDEF0 modell kidolgozásán

Az IDEF0 szabvány olyan eljárásokat tartalmaz, amelyek lehetővé teszik egy modell kidolgozását és jóváhagyását a modellezett rendszer különböző tevékenységi területeihez tartozó emberek nagy csoportja számára. A fejlesztési folyamat jellemzően iteratív, és a következő feltételes lépésekből áll:

Modell készítése a vállalkozás különböző területeihez kapcsolódó szakértői csoport által. Ezt a csoportot IDEF0 kifejezéssel Szerzőknek hívják. A kezdeti modell felépítése egy dinamikus folyamat, melynek során a szerzők kompetens személyeket kérdeznek meg a különböző folyamatok felépítéséről. A meglévő rendelkezések, dokumentumok és felmérési eredmények alapján elkészül a modell tervezete (Model Draft).

A tervezet megfontolásra, jóváhagyásra és észrevételezésre történő kiosztása. Ebben a szakaszban a modelltervezetet a vállalaton belüli (IDEF0 olvasók tekintetében) kompetens személyek széles körével megvitatják. Ugyanakkor a vázlatmodell diagramjainak mindegyikét kritizálják és írásban kommentálják, majd átadják a szerzőnek. A szerző pedig írásban is egyetért a bírálattal, vagy a döntés logikájának kifejtésével visszautasítja és a javított tervezetet ismételten visszaküldi további megfontolásra. Ez a ciklus addig tart, amíg a szerzők és az olvasók konszenzusra nem jutnak.

Modell jóváhagyás. A jóváhagyott modellt a munkacsoport vezetője hagyja jóvá abban az esetben, ha a modell készítői és az olvasók között nincs nézeteltérés annak megfelelőségét illetően. A végső modell a vállalkozás (rendszer) konzisztens szemlélete egy adott nézőpontból és egy adott célra.
Az IDEF0 grafikus nyelv láthatósága a modellt jól olvashatóvá teszi azok számára is, akik nem vettek részt a létrehozási projektben, valamint hatékony bemutatók és bemutatók számára. A jövőben a felépített modell alapján új projektek szervezhetők, amelyek célja a vállalkozásban (rendszerben) történő változtatás.

Az IDEF0 eszközökkel történő funkcionális modellezés hazai gyakorlatának jellemzői

Az elmúlt években Oroszországban folyamatosan nőtt az érdeklődés az IDEF család módszerei iránt. Ezt folyamatosan megfigyelem, amikor személyes weboldalam (http://www.vernikov.ru) találati statisztikáit nézem, amely röviden leírja e szabványok alapelveit. Ugyanakkor az olyan szabványok iránti érdeklődést, mint az IDEF3-5, elméletinek nevezném, az IDEF0-ban pedig gyakorlatilag teljesen indokolt. Valójában az első Case-tools, amely lehetővé teszi a DFD és IDEF0 diagramok készítését, 1996-ban jelent meg az orosz piacon, egyidejűleg a SADT szabványok modellezési elveiről szóló népszerű könyv kiadásával.

A legtöbb menedzser azonban továbbra is a modellezés gyakorlati alkalmazását az IDEF szabványokban inkább a divat előtti tisztelgésnek tekinti, semmint a meglévő vállalatirányítási rendszer optimalizálásának hatékony módjának. Valószínűleg ennek oka az e módszerek gyakorlati alkalmazására vonatkozó információhiány, valamint a publikációk túlnyomó többsége nélkülözhetetlen szoftveres elfogultsága.

Nem titok, hogy az oroszországi vállalatok pénzügyi és gazdasági tevékenységeinek felmérésére és elemzésére irányuló szinte minden projekt ilyen vagy olyan módon kapcsolódik az automatizált vezérlőrendszerek kiépítéséhez. Ennek köszönhetően az IDEF szabványok a többség felfogásában feltételesen elválaszthatatlanokká váltak az informatika bevezetésétől, bár segítségükkel időnként akár kisebb helyi problémákat is hatékonyan lehet megoldani, szó szerint ceruzával és papírral.

Komplex vállalati felmérési projektek lebonyolítása során az IDEF0 szabványban szereplő modellek fejlesztése lehetővé teszi, hogy vizuálisan és hatékonyan jelenítse meg a vállalat tevékenységeinek teljes mechanizmusát a megfelelő kontextusban. A legfontosabb azonban az IDEF0 által biztosított együttműködési képesség. Praxisomban jó néhány olyan eset volt, amikor a modell felépítése a különböző részlegek munkatársainak közvetlen közreműködésével történt. Ugyanakkor a tanácsadó meglehetősen rövid időn belül elmagyarázta nekik az IDEF0 alapelveit, és megtanította nekik a megfelelő alkalmazási szoftverrel való munkát. Ennek eredményeként a különböző részlegek alkalmazottai IDEF diagramokat készítettek funkcionális egységük tevékenységéről, amelyeknek a következő kérdésekre kellett válaszolniuk:

Mi lép be az egységbe "a bejáratnál"?

Milyen funkciókat és milyen sorrendben hajtanak végre az egységen belül?

Ki a felelős az egyes funkciókért?

Mi vezérli az előadót az egyes funkciók ellátásában?

Mi az egység munkájának (kimenetének) eredménye?

A diagramvázlatok minden egyes egységen belüli koordinálása után egy tanácsadó összeállítja azokat egy vállalati modelltervezetté, amelyben az összes bemeneti és kimeneti elem összekapcsolódik. Ebben a szakaszban az egyes diagramok minden következetlensége és ellentmondásos helye rögzítésre kerül. Továbbá ez a modell ismét áthalad a funkcionális osztályokon a további koordináció és a szükséges kiigazítások elvégzése érdekében. Ennek eredményeként meglehetősen rövid időn belül és a tanácsadó cég minimális emberi erőforrásának bevonásával (és ezek az erőforrások, mint tudod, nagyon drágák), egy vállalkozás IDEF0 modelljét kapják meg a „Mint is" elve, és ami fontos, egy olyan vállalkozást képvisel, amelynek munkatársai beosztásban dolgoznak, és minden árnyalatot alaposan ismernek, beleértve az informálisakat is. A jövőben ezt a modellt elemzés és feldolgozás céljából átadják az üzleti elemzőknek, akik "szűk keresztmetszeteket" keresnek a vállalat irányításában és optimalizálják a fő folyamatokat, átalakítva az "As is" modellt a megfelelő "Ahogy kell". " reprezentáció. Ezen változtatások alapján végleges következtetést kell levonni, amely ajánlásokat tartalmaz az irányítási rendszer átszervezésére.

Természetesen egy ilyen megközelítéshez számos szervezési intézkedésre van szükség, elsősorban a vizsgált vállalkozás vezetése részéről. Ez annak a ténynek köszönhető, hogy ez a technika azt jelenti, hogy egyes munkavállalókra további felelősséget rónak az új módszerek kidolgozására és gyakorlati alkalmazására. Ez azonban végül is indokolttá válik, mivel az egyes alkalmazottak több napon át tartó további egy-két óra munkavégzése jelentősen megtakaríthatja a harmadik féltől származó tanácsadói szolgáltatások kifizetését (ami mindenesetre megszakítja a munkavégzést). ugyanazok az alkalmazottak kérdőívekkel és kérdésekkel). Magukat a vállalkozás alkalmazottait illetően, így vagy úgy, gyakorlatom során nem találkoztam tőlük kifejezett ellenkezéssel.

Mindebből a következő következtetés vonható le: egyáltalán nem szükséges minden alkalommal standard problémákra megoldást találni. Amikor egy adott funkcionális rendszer elemzésének szükségességével szembesül (az űrhajó tervezési rendszerétől a komplex vacsora elkészítési folyamatáig), használja az évek során bevált és bevált módszereket. Az egyik ilyen módszer az IDEF0, amely lehetővé teszi egyszerű és érthető eszköztárának használatát összetett életproblémák megoldására.