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. írja le 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. Megkülönböztető tulajdonság Az IDEF0 az objektumok alárendeltségére helyezi a hangsúlyt. 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 Államokban a légierő minisztériuma dolgozta ki automatizálás céljából. ipari vállalkozások. 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 a 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 az induláshoz.

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. 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 nemcsak vizuális, hanem nagyon kényelmes is a hatékony döntések meghozatalához. vezetői döntések. 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.

Én személy szerint úgy gondolom, hogy az első szakaszban semmi sem jobb, mint a normál papír, egy egyszerű ceruza és egy radír, amely hibák esetén korrigálni tudja.

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 látás meglévő folyamatokat egybeesett 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ők é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 szükség esetén egy szószedet létrehozását jelenti, 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 legtöbb egyszerű esetek két üzleti elemző pontosan ugyanazokat a funkcionális modelleket hozza létre 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, és bizonyos módon az ő személyes álláspontját is az üzletről. 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. A következő szakaszokban további vezetői jóváhagyásokra is szükség lehet. szerkezeti felosztásokés az alkalmazottak. 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.

Tanuld meg látni és megérteni vállalkozásod funkcionális felépítését!

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 a teljes ü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 javaslatokat tesznek a „ szűk keresztmetszetek” a teljesítménymenedzsmentben. 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 olyan csapat, amely az évek során fejlődött, mindig nehéz „ú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 - modellezési módszertan információáramlások a rendszeren belül, lehetővé téve azok szerkezetének és kapcsolatainak megjelenítését és elemzését;

Az IDEF1X (IDEF1 Extended) egy módszertan relációs struktúrák építésére. Az IDEF1X az Entity-Relationship (ER) módszertanok típusába tartozik, és általában a vizsgált 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 „színes Petri-hálók” (CPN – Color Petri Nets) alapján épített dinamikus modellekké alakítását;

Az IDEF3 a rendszerben lezajló folyamatok dokumentálására szolgáló módszertan, amelyet például kutatásban használnak technológiai folyamatok vállalkozásoknál. 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 folyamat gyakorlati megvalósítás, 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ó funkciók továbbfejlesztett készlete mellett az új szabvány egyik követelménye az volt, hogy rendelkezésre álljon egy hatékony módszertan az „analitikus-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 követelményei 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 felső oldal a "Control";

A bal oldal az "Input";

A jobb oldal „Output”-ra van állítva;

Az alsó oldal jelentése „Mechanizmus” (Mechanizmus).

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 elemek lehetnek ilyen objektumok. való Világ(alkatrészek, kocsik, alkalmazottak stb.) vagy adat- és információáramlás (dokumentumok, adatok, utasítások stb.).

Attól függően, hogy ez az interfészív melyik oldalhoz 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őívektől, ami gyakran nem egyszerű. 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 bemeneti 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 kezdődik – egyetlen funkcionális egység, interfészívekkel, amelyek 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 a diagram elkészítésének célja (célja) a formában Rövid leírásés fix nézőpont (Viewpoint).

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 a gyermekdiagramhoz viszonyítva szülőblokknak (Parent Box), a diagramot pedig, amelyhez tartozik, szülődiagramnak (Parent Diagram) nevezik. 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 „Feldolgozás bekapcsolva” bemeneténél esztergapad” nincs értelme a magasabb szintű diagramokon gondolkodni – 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” (Arrow Tunnel) megjelölése két zárójelben az interfészív eleje körül 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. Az IDEF0 minden egyes elemére: diagramok, funkcióblokkok, interfész ívek, a meglévő szabvány megfelelő definíciók halmazának létrehozását és karbantartását jelenti, kulcsszavakat, narratív kijelentések stb., amelyek az elem által megjelenített objektumot jellemzik. 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 íve esetében 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

NÁL NÉL utóbbi évek Oroszországban folyamatosan nő 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. Ennek valószínűleg az az oka, hogy nyilvánvalóan hiányoznak az információk praktikus alkalmazás e módszertanok és a publikációk túlnyomó többsége nélkülözhetetlen szoftverelfogultsága mellett.

Nem titok, hogy szinte minden felmérési és elemzési projekt pénzügyi és gazdasági aktivitás Az oroszországi vállalatok mostanra így vagy úgy kapcsolódnak az építkezéshez automatizált rendszerek menedzsment. Emiatt az IDEF szabványok a többség felfogásában feltételesen elválaszthatatlanokká váltak a megvalósítástól információs technológiák, 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 „ „Ahogy van” elv, é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ésre és feldolgozásra benyújtják az üzleti elemzőknek, akik a „szűk keresztmetszetek” után kutatnak 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óvá. . 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ésének folyamatáig), használjon évek óta 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.

Célkitűzés:

• az IDEF0 módszertan alapelveinek tanulmányozása,
• új projekt létrehozása BPWinben,
• kontextusdiagram kialakítása,
• kapcsolatok létrehozása.

A rendszer IDEF0 használatával történő leírását funkcionális modellnek nevezzük. A funkcionális modell célja a meglévő üzleti folyamatok leírása, amelyek természetes és grafikus nyelveket egyaránt használnak. Egy adott rendszerrel kapcsolatos információk továbbításához a grafikus nyelv forrása maga az IDEF0 módszertan.

IDEF0 módszertan diagramok hierarchikus rendszerének felépítését írja elő - a rendszertöredékek egységes leírását. Először a rendszer egészének és a külvilággal való interakciójának leírását (kontextusdiagramot) hajtják végre, majd egy funkcionális bontást hajtanak végre - a rendszert alrendszerekre osztják, és minden alrendszert külön írnak le (bontási diagramok). . Ezután az egyes alrendszereket kisebbekre bontják, és így tovább, amíg el nem érik a kívánt részletezési fokot.

Minden egyes IDEF0-diagramok a blokkokat és íveket tartalmaz. A blokkok a szimulált rendszer funkcióit reprezentálják. Az ívek összekapcsolják a blokkokat, és megjelenítik a köztük lévő interakciókat és kapcsolatokat.

Az ábrákon a funkcionális blokkokat (műveket) téglalapok ábrázolják, amelyek elnevezett folyamatokat, függvényeket vagy feladatokat jelentenek, amelyek egy bizonyos idő alatt fordulnak elő, és felismerhető eredménnyel járnak. A mű nevét a cselekvést jelző verbális főnévként kell kifejezni.

IDEF0 megköveteli, hogy egy diagramnak legalább három és legfeljebb hat doboza legyen. Ezek a megszorítások olyan szinten tartják a diagramok és modellek összetettségét, hogy olvasható, érthető és használható legyen.

A blokk minden oldalának meghatározott, jól meghatározott célja van. A blokk bal oldala a bemeneteket, a felső a vezérlést, a jobb oldali a kimeneteket, az alsó a mechanizmusokat szolgálja. Az ilyen megjelölés bizonyos rendszerelveket tükröz: a bemeneteket kimenetekké alakítják; a vezérlés korlátozza vagy előírja a transzformációk végrehajtásának feltételeit; a mechanizmusok megmutatják, hogy egy funkció mit és hogyan teljesít.

Az IDEF0-ban lévő blokkok fontossági sorrendben vannak elhelyezve, ahogy azt a diagram készítője megérti. Ezt a relatív rendet dominanciának nevezzük. A dominancia alatt azt a hatást értjük, amelyet az egyik blokk gyakorol a diagram többi blokkjára. Például a diagram legdominánsabb blokkja lehet a szükséges függvénysorozatok közül az első, vagy egy tervezési vagy vezérlési funkció, amely az összes többit befolyásolja.

A legdominánsabb doboz általában a diagram bal felső sarkában, míg a legkevésbé domináns doboz a jobb sarokba kerül.

A blokkok elrendezése az oldalon tükrözi a szerző dominancia-definícióját. Így a diagram topológiája megmutatja, hogy mely jellemzők vannak nagyobb hatással a többire. Ennek hangsúlyozására az elemző átszámozhatja a blokkokat a dominancia sorrendjének megfelelően. A dominancia sorrendjét az egyes mezők jobb alsó sarkában elhelyezett szám jelzi: az 1 a legmagasabb dominanciát jelölné, a 2 a következőt, és így tovább.

A művek interakcióját a külvilággal és egymás között nyilak formájában írják le, amelyeket egyetlen vonallal ábrázolnak, a végén nyíllal. A nyilak bizonyos információkat jelentenek, és főneveknek nevezik őket.

Nyíl típusok

Az IDEF0 ötféle nyíltípust különböztet meg.

Bejárat- a munka által eredmény (kimenet) eléréséhez használt és átalakított objektumok. Megengedett, hogy a munkán ne legyen belépő nyíl. A beviteli nyíl a munka bal oldalára kerül.

Ellenőrzés-.a mű cselekvéseit irányító információk. A vezérlő nyilak általában olyan információkat tartalmaznak, amelyek jelzik a feladat elvégzését. Minden jobnak rendelkeznie kell legalább egy vezérlő nyíllal, amely a job felső felületén jelenik meg.

Kijárat- objektumok, amelyekké a bemeneteket átalakítják. Minden jobnak rendelkeznie kell legalább egy kilépési nyíllal, amely a job jobb oldaláról jön.

Gépezet- Erőforrások, amelyek elvégzik a munkát. A mechanizmus nyíl a munka alsó felületére kerül. Az elemző belátása szerint előfordulhat, hogy a mechanizmus nyilai nem jelennek meg a modellen.

Hívás- egy speciális nyíl, amely egy másik munkamodellre mutat. A hívó nyíl a munka aljáról jön, és azt jelzi, hogy bizonyos munka a szimulált rendszeren kívül történik.

Rizs. 2.1 Nyíl típusok

Az IDEF0 módszertanban mindössze ötféle interakció szükséges a blokkok között a kapcsolatuk leírásához: vezérlés, bemenet, vezérlési visszacsatolás, bemeneti visszacsatolás, kimeneti mechanizmus. Az irányítási és belépési kapcsolatok a legegyszerűbbek, mivel olyan közvetlen cselekvéseket tükröznek, amelyek intuitívak és nagyon egyszerűek.

Rizs. 2.2. Kimeneti kommunikáció

Rizs. 2.3. Vezetői kommunikáció

Vezérlési kapcsolat akkor jön létre, ha egy blokk kimenete közvetlenül érint egy kisebb dominanciájú blokkot.

A vezérlő visszacsatolása és a bemeneti visszacsatolás összetettebb, mert iteratív vagy rekurzív. Ugyanis az egyik jobból származó kimenetek befolyásolják a többi job jövőbeli végrehajtását, ami később hatással lesz az eredeti jobra.

A vezérlés visszacsatolása ekkor következik be; amikor valamilyen blokk kimenete nagyobb dominanciájú blokkot érint.

A kilépési mechanizmus kapcsolatok ritkák. Olyan helyzetet tükröznek, amelyben az egyik funkció kimenete a másik céljának eszközévé válik.

Rizs. 2.4. Bemeneti visszajelzés

Rizs. 2.5. Vezetői visszajelzés

Az output-mechanizmus kapcsolatok az erőforrás-források (pl. szükséges eszközök, képzett személyzet, fizikai tér, felszerelés, finanszírozás, anyagok) elosztására jellemzőek.

Az IDEF0-ban egy ív ritkán ábrázol egyetlen objektumot. Általában tárgyak halmazát szimbolizálja. Mivel az ívek objektumok gyűjteményét képviselik, több kiindulási ponttal (forrással) és végponttal (célállomással) rendelkezhetnek. Ezért az ívek elágazhatnak és összekapcsolódhatnak különböző utak. A teljes ív vagy annak egy része kiléphet egy vagy több blokkból, és egy vagy több blokkban végződhet.

Az ívek szétágazó vonalként ábrázolt elágazása azt jelenti, hogy az ívek tartalmának egésze vagy egy része megjelenhet az egyes ágakban. Egy ív mindig egy elágazás előtt van felcímkézve, hogy nevet adjon a teljes halmaznak. Ezenkívül az ív minden ága felcímkézhető vagy nem a következő szabályok szerint:

• a címkézetlen ágak az ív elágazás előtti címkéjében megadott objektumok súlyát tartalmazzák;
• az elágazási pont után címkézett ágak az elágazás előtti ívcímkében megadott objektumok egészét vagy egy részét tartalmazzák.

Az IDEFO-ban összefutó vonalakként ábrázolt ívösszevonások azt jelzik, hogy az egyes ágak tartalma az eredeti ívek egyesítéséből származó ív címkéjét képezi. Egyesítés után az eredményül kapott ív mindig megjelölésre kerül, hogy jelezze az összevonás után megjelent új jellemzőket. Ezenkívül az egyes ágak megjelölhetők vagy nem megjelölhetők az egyesítés előtt, a következő szabályok szerint:

Rizs. 2.6. Kimeneti-mechanizmus kapcsolat

• a címkézetlen ágak az egyesítés után a közös ívcímkében megadott objektumok súlyát tartalmazzák;
• az összevonás előtt megjelölt ágak az összevonás után a közös jelölésben felsorolt ​​objektumok mindegyikét vagy egy részét tartalmazzák,

Kvantitatív diagram elemzés

A diagramok kvantitatív elemzéséhez felsoroljuk a modell indikátorait:

• blokkok száma a diagramon - N;
• diagram bontási szint - L;
• diagram egyenleg - NÁL NÉL;
• a blokkhoz kapcsolódó nyilak száma - DE

Ez a tényezőkészlet minden modelldiagramra vonatkozik. Az alábbiakban felsoroljuk a diagramtényezők kívánt értékére vonatkozó ajánlásokat.

Arra kell törekedni, hogy az alsóbb szintek diagramjain a blokkok száma kisebb legyen, mint a szülődiagramokon, azaz a dekompozíció szintjének növekedésével az együttható csökkenjen. Így ennek az együtthatónak a csökkenése azt jelzi. hogy a modell felbontásával a függvények egyszerűsödjenek, ezért a blokkok száma csökkenjen.

A diagramoknak kiegyensúlyozottnak kell lenniük. Ez azt jelenti, hogy egy diagram keretein belül az ábrán látható helyzet. 2.7: az 1. feladatnak lényegesen több bejövő és vezérlő nyila van, mint a kimenőnek. Megjegyzendő, hogy ezt az ajánlást nem lehet megvalósítani a leíró modellekben termelési folyamatok. Például egy összeszerelési eljárás leírásakor egy blokk sok nyilat tartalmazhat, amelyek leírják a termék összetevőit, és egy nyíl kiléphet - a késztermékből.

Rizs. 2.7. Példa egy kiegyensúlyozatlan diagramra

Vezessük be a diagram egyensúlyi együtthatóját

Arra kell törekedni ky volt a minimum a diagramhoz.

A diagram grafikai elemeinek elemzése mellett figyelembe kell venni a blokkok elnevezését is. A nevek kiértékeléséhez összeállítjuk a szimulált rendszer elemi (triviális) függvényeinek szótárát. Valójában a diagramok alsó, szintű bontásának funkciói ebbe a szótárba tartoznak. Például egy adatbázismodellnél a „rekord keresése”, „rekord hozzáadása az adatbázishoz” függvények lehetnek elemiek, míg a „felhasználói regisztráció” függvény további leírást igényel.

A szókincs kialakítása és a rendszerdiagram-csomag összeállítása után figyelembe kell venni a modell alsó szintjét. Ha egyezést mutat a diagramblokkok nevei és a szótárból származó szavak között, akkor ez azt jelzi, hogy megfelelő szintű bontást sikerült elérni. Az ezt a kritériumot mennyiségileg tükröző együtthatót így írhatjuk fel L*C- a modellszint szorzata a blokknevek szótárbeli szavakkal való egyezéseinek számával. Minél alacsonyabb a modell szintje (magasabb L), annál értékesebbek az egyezések.

BPWin Toolkit

A BPWin indításakor alapértelmezés szerint a fő eszköztár, az eszközpaletta és a Model Explorer jelenik meg.

Új modell létrehozásakor egy párbeszédablak jelenik meg, amelyben meg kell adni, hogy a modell újonnan jön-e létre, vagy a ModelMart tárhelyből nyílik meg, írja be a modell nevét és válassza ki a módszert, amelyben a modell épül ( 2.8. ábra).

2.8 Modellkészítés párbeszédpanel

A BPWin három módszert támogat – IDEF0, IDEF3 és DFD. A BPWin-ben lehetőség van vegyes modellek felépítésére, azaz egy modell IDEF0, IDEF3 és DFD diagramokat is tartalmazhat egyszerre. Az eszközpaletta összetétele automatikusan megváltozik, amikor egyik jelölésről a másikra váltunk.

A BPWin modelljei tevékenységek gyűjteményének tekinthetők, amelyek mindegyike valamilyen adatkészleten működik. Ha a modell bármely objektumára kattintunk a bal egérgombbal, egy felugró helyi menü jelenik meg, amelynek minden eleme megfelel az objektum valamely tulajdonságának szerkesztőjének.

Példa

A rendszermodell felépítését a működését leíró összes dokumentum tanulmányozásával kell kezdeni. Az egyik ilyen dokumentum a feladatmeghatározás, nevezetesen a „Fejlesztési cél”, „A rendszer céljai és célkitűzései” és „A rendszer működési jellemzői” fejezetek.

A forrásdokumentumok áttanulmányozása, valamint a vevők és a rendszer felhasználóinak megkérdezése után szükséges a modellezés céljának megfogalmazása és a modellre vonatkozó nézőpont meghatározása. Tekintsük felépítésének technológiáját a „Foglalkoztatási szolgáltatás az egyetem keretein belül” rendszer példáján, amelynek főbb jellemzőit az 1. számú laboratóriumi munka ismertette.

Fogalmazzuk meg a modellezés célját: a rendszer működésének leírását, amely a felhasználó számára érthető lenne, anélkül, hogy a megvalósítással kapcsolatos részletekbe mennénk. A modellt a felhasználók (hallgató, tanár, adminisztrátor, dékáni hivatal, cég) szemszögéből építjük fel.

Kezdjük egy IDEF0 kontextusdiagram felépítésével, melynek fő feladata a rendszer leírása szerint az ügyfelek kiszolgálása a tőlük érkező kérések feldolgozásával. Így a kontextusdiagram egyetlen feladatát a "Rendszer kliensének kiszolgálása"-ként határozzuk meg. Ezután meghatározzuk a bemeneti és kimeneti adatokat, valamint a mechanizmusokat és a vezérlést.

Az ügyfél kiszolgálásához regisztrálni kell a rendszerben, meg kell nyitni az adatbázishoz való hozzáférést és feldolgozni kérését. A bemeneti adatok a következők lesznek: "kliens neve", "kliens jelszava", "eredeti adatbázis", "ügyfél kérése". A kérés teljesítése vagy a rendszerből történő információszerzéshez, vagy az adatbázis tartalmának megváltoztatásához vezet (például szakértői értékelések összeállításakor), így a kimenet „jelentések” és „módosított adatbázis” lesz. A kérésfeldolgozási folyamatot a rendszerfigyelő végzi az adminisztrátor felügyelete mellett.

Kontextus diagram

Így definiáljuk a rendszer kontextus diagramját (2.9. ábra).

2.9. ábra. Rendszerkontextus diagram

Bontsuk fel a környezeti diagramot az ügyfélszolgálat sorrendjének leírásával:

• A rendszerhez való hozzáférés szintjének meghatározása.
• Alrendszer kiválasztása.
• Hozzáférés egy alrendszerhez.
• Az adatbázis módosítása (ha szükséges).

ábrán látható diagramot kapjuk. 2.10.

Miután befejezték a kontextusdiagram bontását, folytatják a következő szint diagramjának bontását. Általában a harmadik és az alsó szint figyelembevételekor a modellek visszatérnek a szülődiagramokhoz és kijavítják azokat.

Rizs. 2.10. A "Szolgáltatás, a rendszer kliense" munka bontása

A kapott diagram összes blokkját egymás után felbontjuk. A rendszerhez való hozzáférés szintjének meghatározásának első lépése a felhasználói kategória meghatározása. A kliens neve alapján keresés történik a felhasználói adatbázisban, meghatározva annak kategóriáját. Egy bizonyos kategória szerint a rendszer használója számára biztosított jogkörök pontosításra kerülnek. Ezután a rendszerhez való hozzáférési eljárást hajtják végre, ellenőrizve a hozzáférési nevet és jelszót. Az engedélyekkel és a rendszerhez való hozzáférés szintjével kapcsolatos információk kombinálásával a felhasználó számára engedélyezett műveletek készlete jön létre. Így a rendszerhez való hozzáférés szintjének meghatározása az ábrán látható módon fog kinézni. 2.11.

Rizs. 2.11."A rendszerhez való hozzáférés szintjének meghatározása" című munka bontása

A rendszer-hozzáférési eljárás végrehajtása után a monitor elemzi az ügyfél kérését, és kiválaszt egy alrendszert, amely feldolgozza a kérést. A „Hivatkozás egy alrendszerre” mű dekompozíciója nem felel meg a modell céljának és nézőpontjának. A rendszer felhasználóját nem érdeklik a rendszer munkájának belső algoritmusai. Ebben az esetben fontos számára, hogy az alrendszer kiválasztása automatikusan, az ő beavatkozása nélkül történjen, így az alrendszer hívásának dekompozíciója csak bonyolítja a modellt.

Bontsuk fel az alrendszer által a kérések feldolgozására, kategóriák és felhasználói jogosultságok meghatározására végzett "Kliens kérésének feldolgozása" munkát. Mielőtt választ keres egy lekérdezésre, meg kell nyitnia az adatbázist (csatlakoznia kell hozzá). Általánosságban elmondható, hogy az adatbázis egy távoli szerveren található, ezért szükséges lehet kapcsolatot létesíteni vele. Határozzuk meg a munka sorrendjét:

• Az adatbázis megnyitása.
• Kérés teljesítése.
• Jelentéskészítés.

Az adatbázis megnyitása után tájékoztatni kell a rendszert az adatbázishoz való kapcsolódásról, majd végrehajtani a lekérdezést és jelentéseket generálni a felhasználó számára (2.12. ábra).

Meg kell jegyezni, hogy a "Kérés végrehajtása" magában foglalja a különböző alrendszerek munkáját. Például, ha egy kérés tesztelést is tartalmaz, akkor azt a szakmai és pszichológiai tesztek alrendszere hajtja végre. A lekérdezés végrehajtásának szakaszában szükség lehet az adatbázis tartalmának módosítására, például szakértői értékelések összeállításakor. Ezért szükséges egy ilyen lehetőséget biztosítani a diagramon.

Rizs. 2.12.

Diagram beállítás

A kapott diagram elemzésekor felvetődik a kérdés, hogy milyen szabályok szerint készülnek a jelentések? Előre formált sablonokra van szükség, amelyek az adatbázisból történő kiválasztáshoz fognak használni, és ezeknek a sablonoknak meg kell felelniük a lekérdezéseknek és előre definiáltaknak kell lenniük. Ezen túlmenően az ügyfélnek lehetőséget kell biztosítani a jelentés formájának megválasztására.

Javítsuk ki a diagramot a „Jelentéssablonok” és „Az adatbázis módosítási kérelmek” nyilak, valamint a „Rendszerkliens” alagútnyilat hozzáadásával. A "Rendszerkliens" alagútkezelését azért alkalmaztuk, hogy a nyíl ne kerüljön a felső diagramra, mivel a jelentés űrlap kiválasztásának funkciója nem elég fontos ahhoz, hogy a szülő diagramon megjelenjen.

A diagram megváltoztatása az összes szülődiagram beállítását vonja maga után (2.13 - 2.15 ábra).

A „Lekérdezés végrehajtása” munkát célszerű a DFD diagram segítségével felbontani (3. számú laboratóriumi munka), mivel az IDEF0 módszertana a rendszert egymással összefüggő munkák halmazának tekinti, amely rosszul tükrözi az információfeldolgozási folyamatokat.

Rizs. 2.13. Az „Ügyfél kérésének feldolgozása” című munka bontása

Rizs. 2.14. A „Rendszer kliensének kiszolgálása” munka bontása (2. lehetőség)

Rizs. 2.15. Rendszerkörnyezet-diagram (2. lehetőség)

Térjünk át az utolsó blokk "Az adatbázis megváltoztatása" felbontására. A kliens szempontjából ezek a rendszerek egy adatbázisban helyezkednek el. Valójában hat adatbázis van a rendszerben:

• felhasználói adatbázis,
• tanulói adatbázis, (2. lehetőség)
• üres álláshelyek adatbázisa,
• haladás adatbázis,
• teszt adatbázis,
• szakértői értékelések DB,
• DB összefoglaló.

A modellezés célja szerint fontos, hogy az ügyfél megértse, hogy a kapott adatok nem frissülnek azonnal a rendszerben, hanem egy további feldolgozási és ellenőrzési szakaszon esnek át. A változtatási algoritmus a következőképpen fogalmazható meg:

• Meg van határozva az adatbázis, amelyben az információ megváltozik.
• Az üzemeltető ideiglenes adatkészletet képez, és azt az adminisztrátor rendelkezésére bocsátja.
• Az adminisztrátor kezeli az adatokat, és beviszi azokat az adatbázisba.

Ez a modell más módon is megvalósítható, lehetővé téve az adatbázis közvetlen kérésre történő frissítését, megkerülve az adatkezelési folyamatot. Ebben az esetben biztosítani kell az adatbázis integritását, hogy elkerüljük az adatbázis károsodását. Ebben az esetben a diagram így fog kinézni (2.17. ábra).

Rizs. 2.16. Az "Adatbázis módosítása" című munka bontása

Rizs. 2.17. Az "Adatbázis módosítása" (2. lehetőség) munka bontása Az ábrán látható első lehetőséghez. 2.12

Az "Adatbázis módosításai" további dekompozíció végrehajtása bonyolítja a modellt, elmagyarázva, hogyan történik az adatbázis fizikai megváltoztatása a rendszerben. Ebben az esetben a felhasználó nem kap további tájékoztatást a foglalkoztatási szolgálati rendszer működéséről. Ennek a munkának a bontását az adatbázisrendszer tervezésének folyamatában kell elvégezni, a logikai adatbázismodell létrehozásának szakaszában.

A "Lekérdezés végrehajtása" munka bontása a következő laborban kerül végrehajtásra, bemutatva a DFD diagramok használatát az információfeldolgozási folyamatok leírására.

Végezzük el az 1-3. ábrán bemutatott modellek kvantitatív elemzését. 2.12 és 2.13, a fent leírt módszer szerint. Tekintsük a ^ együttható viselkedését ezeknél a modelleknél. Az "Ügyfél kérésének feldolgozása" szülődiagram együtthatója 4/2 = 2, a dekompozíciós diagramok pedig 3/3 = 1. Az együttható értéke csökken, ami azt jelzi, hogy a funkciók leírása egyszerűsödik a függvények szintjének csökkenésével. a modell.

Vegye figyelembe az együttható változását K b két modellben.

a második lehetőséghez

Együttható K b nem változtatja meg az értékét, ezért a diagram egyensúlya nem változik.

Feltételezzük, hogy a vizsgált diagramok dekompozíciós szintje elegendő ahhoz, hogy tükrözze a modellezés célját, és az alsó szint diagramjain elemi függvények szerepelnek a művek neveként (a rendszerhasználó szemszögéből).

Összegezve a vizsgált példát, meg kell jegyezni annak fontosságát, hogy egy rendszer modellezése során több diagramot is figyelembe vegyünk. Ilyen lehetőségek merülhetnek fel a diagramok módosításakor, mint ahogy az "Ügyfélkérelem feldolgozása" vagy a rendszerfunkciók alternatív megvalósításainak létrehozásakor (az "Adatbázis módosítása" munka bontása) során. Az opciók mérlegelése lehetővé teszi, hogy kiválassza a legjobbat, és további mérlegelés céljából belefoglalja a diagramcsomagba.

tesztkérdések

Lista Biztonsági kérdések:

1. Mi az a modell az IDEF0 jelölésben?
2. Mit jelentenek a munkahelyek az IDEF0-ban?
3. Mi a művek elnevezésének sorrendje?
4. Hány állásnak kell szerepelnie egy diagramon?
5. Mi a dominancia sorrendje?
6. Hogyan rendeződnek a munkakörök a dominancia elve szerint?
7. Mi a célja a diagramokon szereplő munkatéglalapok oldalainak?
8. Sorolja fel a nyilak típusait!
9. Nevezze meg a kapcsolatok típusait!
10. Mik azok a határnyilak?
11. Ismertesse az elágazó és összevonó nyilak elnevezésének elvét!
12. Milyen módszereket támogat a BPWin?
13. Sorolja fel a BPWin főablakának fő elemeit.
14. Ismertesse az új modell létrehozásának folyamatát a BPWinben.
15. Hogyan lehet összekapcsolni a munkákat?
16. Hogyan állítsuk be a munka nevét.
17. Ismertesse a munkabontás folyamatát!
18. Hogyan adjunk munkát a diagramhoz?
19. Hogyan lehet megoldani az alagútban lévő nyilakat?
20. Tartalmazhat-e egy BPWin modell több módszertani diagramot?

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.

A fejlesztőket gyakran nem csak arra kérik, hogy azonosítsák és oldják meg a vállalat munkájában felmerülő problémákat, hanem azt is, hogy az milyen szerepet tölt be a vállalat felépítésében. Mert sokkal fontosabb megérteni, hogy egy hibásan működő egység hogyan kommunikál másokkal, mint egyszerűen megérteni, miért hibás. Ezért minden probléma azonosítása a vállalat munkájának tanulmányozásával és funkcionális modelljének összeállításával kezdődik.

A fejlesztőket gyakran nem csak arra kérik, hogy azonosítsák és oldják meg a vállalat munkájában felmerülő problémákat, hanem azt is, hogy az milyen szerepet tölt be a vállalat felépítésében. Mert sokkal fontosabb megérteni, hogy egy hibásan működő egység hogyan kommunikál másokkal, mint egyszerűen megérteni, miért hibás. Ezért minden probléma azonosítása a vállalat munkájának tanulmányozásával és funkcionális modelljének összeállításával kezdődik.

Azt fogja mondani, hogy a menedzsernek rendelkeznie kell a vállalat funkcionális modelljével, függetlenül attól, hogy melyik cégről beszélünk. De amint azt a gyakorlat mutatja, a legtöbb esetben ez a modell hiányzik.

Grafikai előny

Mik azok az IDEF0 modellek? Grafikus sémák saját jellemzőikkel és felépítésükre vonatkozó szabályokkal. Miért a grafika? Mert hatékony. Ez több példán is látható.

Képzeljük el, hogy a hadműveleti tervet szavakkal magyarázták el, nem pedig a rájuk felvitt grafikus szimbólumokkal ellátott térképek segítségével. Ma már lehetetlennek tűnik, de egészen a 19. század második feléig ez pontosan így volt. A grafika segít megérteni, mi a nehéz megmagyarázni, és ennek megfelelően megérteni, mi a nehéz.

Ugyanez vonatkozik az üzleti folyamatokra is: sok technikai feladat grafikus jelölések formájában is elrendezhető, ami nagyban leegyszerűsíti a fejlesztők feladatát, és pénzt takarít meg az ügyfeleknek.

Az IDEF0 előnyei aAZT- szakemberek

A fejlesztők tevékenysége, legyen szó például a CRM telepítéséről vagy egy hatékony ERP létrehozásáról, egy már kiépített rendszer módosításához kapcsolódik. És ahhoz, hogy jól csinálja, először tanulmányoznia kell, hogyan működik ez a rendszer. Tanulmányozása után a fejlesztő kereskedelmi javaslatot ír, amelyben bemutatja a helyzetről alkotott elképzelését, a probléma megoldásához szükséges lépéseket, valamint a várható eredményt. Egy ilyen dokumentum több mint egy tucat oldalt foglalhat el. Ez egyrészt jó, mert a kliens a maximálisan őt érdeklő információt kapja. Másrészt egy hosszadalmas szöveg áttanulmányozása időt vesz igénybe, ami egy sikeres üzletembernek gyakran nincs meg.

Hogyan lehetséges tehát a lényeget hozzáférhető módon átadni anélkül, hogy terjedelmes szövegekhez folyamodnánk? Grafika! Ő az, aki lehetővé teszi, hogy lerövidítse a leírtakat, egyértelműen bemutatva a szükséges információkat. Hiszen egy kép több száz szót helyettesíthet. Ami pedig a grafika használatát illeti az üzleti folyamatok leírásában, ez 100%-ban igaz.

Először nézzük meg, mi a jelölés és az IDEF0, és mire valók.

Üzleti folyamatleírás jelölése: mi ez

A jelölés olyan formátum, amelyben az üzleti folyamatokat a modellezéshez használt grafikus objektumok és közvetlenül modellező szabályok formájában jelenítik meg. A jelölés egyfajta grafikus nyelv, amely lehetővé teszi a vállalat működésének elképzelését, bemutatva az osztályok és a részlegek közötti kapcsolatot. Vagyis a jelölés egyfajta programozási nyelvnek tekinthető az üzleti intelligencia területén.

Az IDEF0...

Az IDEF0 egy funkcionális modellezési módszer, valamint egy grafikus jelölés, amelyet az üzleti folyamatok leírására és formalizálására használnak. Az IDEF0 jellemzője, hogy ez a módszertan az objektumok alárendeltségére összpontosít. Az IDEF0-t vállalati automatizálásra fejlesztették ki 1981-ben az Egyesült Államokban.

A vállalat funkcionális modellje

Az IDEF0 funkcionális modell blokkokból áll, amelyek mindegyike több bemenettel és kimenettel rendelkezik. Minden blokk rendelkezik vezérlőkkel és mechanizmusokkal, amelyek a kívánt szintre vannak részletezve. A legfontosabb funkció a bal felső sarokban található. Csatlakozik a többi nyílhoz és funkcióblokk leíráshoz. Minden nyílnak vagy tevékenységnek megvan a maga jelentése. Emiatt egy ilyen modellt használnak bármilyen adminisztratív és szervezeti folyamat leírására.

Nyíl típusok

beérkező levelek feladatok vannak kitűzve.

kimenő megjeleníti a tevékenység eredményét.

Menedzserek(nyilak fentről lefelé) vezérlőmechanizmusok.

Mechanizmusok(nyilak alulról felfelé) a szükséges munkák elvégzésére szolgálnak.

Amikor funkcionális modellel dolgozik, a következő szabályokat kell elfogadni. Például a nyilakat főnevek (szabályok, terv stb.), blokkokat - igék szerint nevezik el (nyilvántartás vezetése, megállapodás megkötése).

Az IDEF0 lehetővé teszi az információcserét, miközben a sokoldalúság és a láthatóság miatt a csere résztvevői könnyen megértik egymást. Az IDEF0-t gondosan fejlesztették és továbbfejlesztették, az IDEF0-vel különféle eszközökkel dolgozhat, például ERWIN, VISIO, Bussines stúdió.

Az IDEF0-nak van egy tagadhatatlan előnye is. Ezt a technikát viszonylag régen fejlesztették ki, és három évtized alatt gondos polírozáson és beállításon esett át. Ezért lehetőség van a vállalat funkcionális modelljének elkészítésére gyorsan és minimális hibalehetőség mellett.

Természetesen vannak más módszerek is, miért ajánljuk az IDEF0-t? A fémcső egy darabját fémfűrésszel is le lehet fűrészelni, de látod, ezt köszörűvel sokkal egyszerűbb megtenni. Így van ez az IDEF0-val is: nincs funkcionálisabb eszköz a modellezéshez, vele egyszerűen és gyorsan elérheti a kívánt eredményt.

Hogyan jön létre a funkcionális modell

Elemezzük a funkcionális modell létrehozását egy cikkírás példáján.

Fő egység"Cikk írása" lesz a neve.

Ami egy cikk megírásához szükséges, az tükröződik benne bejövő nyilak- "Tapasztalat", "További irodalom".

Vezérlő nyilak cikk írásához - "A cikk terve", "Regisztráció követelményei", "Az orosz nyelv szabályai".

A mechanizmusok közvetlenül maga a szerző, a szövegíró, a szerkesztő, a szoftver. Hogyan szerveződnek ezek a mechanizmusok? A szerző a szöveget annak hangváltozatának rögzítésével hozza létre. A szövegíró szöveges formátumba helyezi át a szöveget, a megjelenési tervre összpontosítva, betartva a kiadó követelményeit és az orosz nyelv szabályait. Ezután a szerkesztő csatlakozik a munkához, aki ellenőrzi a cikket, kijavítja a beszéd-, helyesírási és központozási hibákat. Szoftver - ezek azok a programok és eszközök, amelyeket a folyamat résztvevői a cikk elkészítésekor használtak.

A fentiek mindegyike csak egy általános munkaséma, ezért részletezni kell.

Térjünk vissza a modellünkhöz, és bontsuk fel a közös blokkot több egymással összefüggő elemre.

Tehát a cikkírás teljes folyamata 4 szakaszra osztható:

1. Készítsen hangos verziót.
2. Szöveg előkészítése nyomtatáshoz.
3. Szöveg szerkesztése és előkészítése nyomtatásra.
4. Cikk publikáció.

A séma információkat tükröz arról, hogy melyik szakaszban mely vezérlőelemek és mechanizmusok vesznek részt. A minőségi szövegalkotás érdekében például a szerző saját tapasztalatait, tudását használja fel, a publikációs tervet és a kiadó követelményeit vezérelve. A szövegíró a szöveg nyomtatott változatának létrehozásakor, a szerkesztő pedig a javításkor az orosz nyelv szabályait használja. Egy cikk közzétételéhez, például online kiadványban, speciális szoftverre van szükség.

A funkcionális modell elkészítésekor az előadó a létrehozásának céljára és nézőpontjára összpontosít.

A funkcionális modellezést hatékonyan alkalmazzák különféle vezetési döntések meghozatalában. A cikkírási folyamatra vonatkozó példánkban két szakember szerepel: egy szövegíró és egy szerkesztő. És a projektfinanszírozás séma szerinti szükséges optimalizálásával könnyen meghatározható, hogyan kell ezt megtenni. A szövegíró és a lektor hasonló munkamódszerekkel rendelkezik, így minden munkát fel lehet ajánlani a szövegírónak, hiszen közvetlenül a hangszöveggel dolgozik, amit a szerkesztő nem tehet meg. Ugyanakkor a szövegírónak felajánlható, hogy a szerkesztőnek szánt összeg feléért elvégzi ezt a munkát. Igen, ettől a szöveg minősége elveszhet, de az optimalizálási feladatot sikeresen elvégezték. És ezt vizuális séma nélkül nehezebb lenne megtenni.

Jegyzetkészítési folyamatIDEF0

Számos program létezik a jelölések létrehozására. Egyesek funkcionális modellek létrehozására szolgálnak, míg mások lehetővé teszik bármilyen grafikus objektum használatát. És valakinek az első szakaszban elég egy papírlap, egy ceruza és egy radír.

Mielőtt rátérne a cég munkájának leírására, azaz közvetlenül az üzleti folyamatok jelölésének létrehozására, tanulmányozza a vállalat működésének alapelveit. Ehhez egy külső szakember interjút készít. A kérdésre mindenekelőtt a cégvezető válaszol, majd a munka egyéb szakaszait felügyelő szakemberek.

A munka első szakaszának eredménye két jelölés. Az egyik az üzleti folyamatokat eredeti formájukban fogja tükrözni. Ez a jelölés az interjú eredménye alapján készül, és minden részletet egyeztetni kell a cég vezetőjével és munkatársaival. Rendkívül fontos, hogy a vállalatnál meglévő üzleti folyamatok megértése megfeleljen a valóságnak, ez minden szinten megerősítést igényel.

A második jelölés „Ahogy lennie kell”. Az első alapján jön létre a feladatnak megfelelő változtatásokkal.

IDEF0 szabvány és követelményei

Az IDEF0 alapkövetelményeiről kicsit feljebb beszéltünk.

1. A fő elem a bal felső sarokban található.
2. Minden elemnek rendelkeznie kell bejövő és kimenő nyíllal. Sőt, a bejövő nyilak a bal oldalon vannak, a jobb oldalon - a kimenő.
3. A vezérlőelemek felül, a mechanizmusok alul találhatók.
4. Ha több blokk található egy lapon vagy képernyőn, a következő blokk jobbra, az előző alá kerül.
5. A sémákat úgy kell létrehozni, hogy a nyilak a minimális számú alkalommal metsszék egymást.

Természetesen az IDEF0 szabványnak vannak általánosan elfogadott normái, követelményei és megnevezései. Nem foglalkozunk velük részletesen, ha szükséges, ezeket az információkat könnyű megtalálni.

Hibák az IDEF0-val való munka során

Mint minden más tevékenységnél, a funkcionális modellezés során is előfordulnak hibák. Elemezzük ezek közül a legjellemzőbbeket.

Több szín használata

Fontos megjegyezni, hogy a funkcionális modellezésben minden elem fontos, nincs fontosabb vagy kevésbé fontos. Amikor papíron vagy valamelyik számítógépes programban modelleznek, a felhasználók a blokkokat és a nyilakat különböző színekkel próbálják vizuálisabbá tenni. Ez azonban a gyakorlatban nemhogy nem teszi vizuálisabbá az ábrát, hanem éppen ellenkezőleg, zavarhoz és az ábrázolt észlelésének torzulásához vezet.

Ezért az ideális lehetőség a fekete-fehér séma további színopciók használata nélkül. Ez nemcsak a félreértések kiküszöbölését segíti elő, hanem közvetlenül fegyelmezi a modell készítőjét, ami kedvezően befolyásolja a modell olvashatóságát és láthatóságát.

Nagy számú blokk

A cég funkcionális modelljének összeállításakor a szerzők gyakran igyekeznek mindent, még a legapróbb részleteket is tükrözni. Kiderült, hogy egy rendszer hatalmas számú blokkot és nyilat tartalmaz. Ennek eredményeként az olvashatóság és a láthatóság csökken.

A hiba elkerülése érdekében használja a megmaradt részleteket a probléma megértéséhez. A részletes részletezés csak akkor készül, ha egy fontos kérdés megoldásához valóban szükség van rá.

Szerkezetátalakítás a hibák javítása során

Diagram készítésekor fontos, hogy egyetlen folyamat se maradjon bejövő, kimenő vagy egyéb fontos elemek nélkül. Például, ha el kell távolítania a szerzőt a sémából, akkor el kell távolítania az összes olyan elemet és nyilat, amely közvetlenül kapcsolódik hozzá. Ha a sémában maradnak, akkor félreértés és zűrzavar keletkezik, mivel a részletezés során senki sem tudja, hova vezet.

Ugyanez a helyzet következik be egy blokk hozzáadásával. Ha bármilyen információt meg kell adnia, ellenőrizze, hogy megadta-e a szükséges attribútumokat. Ezt gondosan figyelemmel kell kísérni, hiszen az összetett üzleti folyamatok modellezésekor az egyik rész enyhe változtatása is változásokat von maga után a másikban.

A blokkok és vezérlőelemek neve

A modellelemek elnevezésének szabályai meglehetősen egyszerűek, de rendkívül fontos megjegyezni: a vezérlő nyilakat főneveknek, a blokkokat igéknek nevezik. Ez a szabály az IDEF0 szabványban van írva, segít elkerülni a félreértéseket és a hibákat.

Az IDEF0 használatának előnyei

láthatóság. A vállalat munkáját diagram formájában ábrázolva világossá válik, hogyan működik a cég, hol merülhetnek fel problémák és hogyan előzhető meg azok előfordulása.

Kölcsönös megértés, a séma helytelen értelmezésének lehetőségének kizárása. A vállalat munkáját blokkok és vezérlők formájában reprezentáló funkcionális modell láthatósága és elérhetősége segít Önnek abban, hogy a vezetőséggel megbeszéljük a cégük működését. Egyébként, ha szükséges, a funkcionális modellhez szószedetet készítenek, ahol az összes kifejezést és szimbólumot összegyűjtik. Így minimálisra csökken a félreértés lehetősége Ön és a vállalat vezetője, alkalmazottai között.

Egyszerűség és időmegtakarítás a modell elkészítésekor. Természetesen a funkcionális modellezés módszertanának elsajátításához sok időt kell töltenie. Mindenekelőtt meg kell tanulni, hogyan kell hatalmas mennyiségű információt tömör séma formájában bemutatni, pl. képes legyen a forrásadatok szűrésére és tömörítésére. De az edzésre fordított erőfeszítés és idő később bőven megtérül. Valójában nem sok időt vesz igénybe egy funkcionális modell létrehozása és hozzáférhető módon történő bemutatása.

Minimális hibalehetőség. Az IDEF0 szabvány szerinti munkavégzés megköveteli annak szabályainak szigorú betartását. Ez fegyelmezi az előadót és kiküszöböli a hiba lehetőségét. Ezenkívül a szabványnak való bármilyen meg nem felelés azonnal észrevehetővé válik.

És végül

Két üzleti elemző csak akkor rendelkezhet azonos funkcionális modellel, ha a vállalati struktúra rendkívül egyszerű. Más esetekben a modellek eltérnek egymástól. Ez természetes, hiszen minden elemzőnek megvan a maga sajátos tapasztalata, saját megértése a cég működéséről, saját nézőpontja a rábízott feladatok megoldására. Az üzleti elemző funkcionális modellt dolgoz ki a vezető szemszögéből, elképzeli, hogyan oldaná meg a feladatokat.

Véleményünk szerint az IDEF0 eszköz nemcsak a professzionális üzleti elemzők számára lesz hasznos, hanem azok számára is, akik közvetlenül elemzik vállalkozásukat, és hatékony irányítási rendszer kiépítésére törekszenek.