Metodyka modelowania funkcjonalnego idef0. IDEF0: funkcjonalne modelowanie procesów biznesowych Opis metodologii IDEF0

Większość osób zaangażowanych w realizację projektów związanych z tworzeniem lub rozwojem korporacyjnych systemów informatycznych zgadza się z tezą, że klient potrzebuje systemu informatycznego zwiększającego efektywność przedsiębiorstwa. Jednak klienci i twórcy systemów informatycznych wciąż mówią różnymi językami: inaczej rozumieją, co to znaczy zwiększyć efektywność przedsiębiorstwa.

Twórcy systemów informatycznych bardzo często rozumieją wzrost wydajności jako wzrost liczby stacji roboczych w sieci lokalnej (LAN) przedsiębiorstwa, wzrost przepustowości sieci LAN, wzrost liczby dokumentów przetwarzanych na zautomatyzowanych stacjach roboczych (AWPs). ) itp.

Klienci poprzez zwiększenie efektywności przedsiębiorstwa oznaczają wzrost wydajności pracy, obniżenie kosztów oraz wzrost jakości produktów i usług. W ostatnim czasie w życie klientów gwałtownie wdzierają się nowe warunki i nowe koncepcje: strategia rozwoju, kluczowe kompetencje, architektura biznesowa, zasady biznesowe i wiele innych.

Aby klient i twórca systemu informatycznego rozumieli się nawzajem, konieczne jest, aby twórca przeorientował się od rozwiązywania problemów technicznych w celu stworzenia lub rozwoju systemu informacyjnego do rozwiązywania złożonych problemów w celu poprawy wydajności przedsiębiorstwa klienta. Przy takim podejściu na pierwszy plan wysuwa się problem skutecznego sposobu badania zakresu działalności klienta:

• badanie istniejącej architektury biznesowej, procesów biznesowych, reguł biznesowych, przepływów informacji;
• identyfikacja problemów, „wąskich gardeł”, które negatywnie wpływają na efektywność przedsiębiorstwa;
• opracowanie i wdrożenie środków eliminujących istniejące problemy i zmianę architektury biznesowej przedsiębiorstwa, reorganizację procesów biznesowych;
• opracowanie konkretnego projektu korporacyjnego systemu informatycznego, wdrożenie tego projektu i wsparcie w przyszłości.

W ramach tego podejścia projektowane są narzędzia przeznaczone do modelowania przedsiębiorstw i re-engineeringu procesów biznesowych w celu zwiększenia wydajności twórców systemów informatycznych. Jednym z przedstawicieli tej rodziny narzędzi są narzędzia CASE do funkcjonalnego modelowania procesów biznesowych.

Ten artykuł zawiera przegląd jednej klasy narzędzi do funkcjonalnego modelowania procesów biznesowych skoncentrowanych na wykorzystaniu metodologii IDEF0.

IDEF0 - Metodologia modelowania funkcjonalnego

W trakcie realizacji programu zintegrowanej komputeryzacji produkcji (ICAM), zaproponowanego niegdyś przez Siły Powietrzne dla przemysłu lotniczego USA, zidentyfikowano potrzebę opracowania metod analizy interakcji procesów w systemach produkcyjnych . Aby sprostać tym potrzebom, opracowano metodologię IDEF0 (Integrated Definition Function Modeling), która jest obecnie akceptowana jako standard federalny USA. Metodologia została z powodzeniem zastosowana w wielu różnych branżach, sprawdzając się jako skuteczne narzędzie do analizy, projektowania i prezentacji procesów biznesowych. Obecnie metodologia IDEF0 jest szeroko stosowana nie tylko w Stanach Zjednoczonych, ale na całym świecie. W Rosji IDEF0 był z powodzeniem stosowany w agencjach rządowych (np. w Państwowej Inspekcji Podatkowej), w przemyśle lotniczym (przy projektowaniu kosmodromu w Plesieck), w Banku Centralnym i bankach komercyjnych Rosji, w branży naftowej i gazowej przemysł i przedsiębiorstwa w innych branżach.

Podstawowe pojęcia IDEF0

Metodologia IDEF0 opiera się na koncepcji bloku, który reprezentuje określoną funkcję biznesową. Cztery boki bloku pełnią różne role: lewa strona jest „w środku”, prawa jest „na zewnątrz”, góra to „kontrola”, spód to „mechanizm” (patrz rys. 1).

Interakcja między funkcjami w IDEF0 jest reprezentowana jako łuk, który wyświetla przepływ danych lub materiałów z wyjścia jednej funkcji do wejścia innej. W zależności od tego, do której strony bloku jest podłączony strumień, nazywa się to odpowiednio „wejściem”, „wyjściem”, „sterowaniem”.

Zasady modelowania w IDEF0

IDEF0 implementuje trzy podstawowe zasady modelowania procesów:

• zasada rozkładu funkcjonalnego;
• zasada ograniczania złożoności;
• zasada kontekstu.

Zasada dekompozycji funkcjonalnej jest sposobem modelowania typowej sytuacji, w której dowolne działanie, operację, funkcję można rozłożyć (dekomponować) na prostsze czynności, operacje, funkcje. Innymi słowy, złożoną funkcję biznesową można przedstawić jako zbiór funkcji atomowych. Reprezentując funkcje graficznie, w postaci bloków, można niejako zajrzeć do wnętrza bloku i szczegółowo zbadać jego strukturę i kompozycję (patrz rys. 2).

Zasada ograniczania złożoności. Podczas pracy z diagramami IDEF0 ważne jest, aby były czytelne i czytelne. Istotą zasady ograniczania złożoności jest to, że liczba bloków na diagramie musi wynosić co najmniej dwa i nie więcej niż sześć. Praktyka pokazuje, że przestrzeganie tej zasady prowadzi do tego, że procesy funkcjonalne, przedstawione w postaci modelu IDEF0, są dobrze ustrukturyzowane, zrozumiałe i łatwe do analizy.

Zasada diagramu kontekstowego. Modelowanie procesu biznesowego zaczyna się od zbudowania diagramu kontekstowego. Ten diagram wyświetla tylko jeden blok - główną funkcję biznesową modelowanego systemu. Jeśli chodzi o modelowanie całego przedsiębiorstwa czy nawet dużego oddziału, nie można sformułować głównej funkcji biznesowej jako np. „sprzedawać produkty”. Główną funkcją biznesową systemu jest „misja” systemu, jego znaczenie w otaczającym świecie. Nie da się poprawnie sformułować głównej funkcji przedsiębiorstwa bez znajomości jego strategii.

Definiując główną funkcję biznesową należy zawsze mieć na uwadze cel modelowania i punkt widzenia modelu. Jedno i to samo przedsiębiorstwo można opisać na różne sposoby, w zależności od punktu widzenia, z którego się na nie patrzy: dyrektor przedsiębiorstwa i inspektor podatkowy widzą organizację zupełnie inaczej.

Diagram kontekstowy odgrywa inną rolę w modelu funkcjonalnym. „Naprawia” granice modelowanego systemu biznesowego, definiując sposób interakcji modelowanego systemu z otoczeniem. Robi to, opisując łuki połączone z blokiem, który reprezentuje główną funkcję biznesową.

Zastosowanie IDEF0

Po zapoznaniu się z podstawowymi pojęciami i zasadami modelowania funkcjonalnego procesów biznesowych, naturalne pytanie brzmi: w jaki sposób przyczynia się to do wzrostu efektywności i jakości przedsiębiorstwa.

Budowanie modelu JAK JEST... Ankieta przedsiębiorstwa jest nieodzowną częścią każdego projektu tworzenia lub rozwoju korporacyjnego systemu informacyjnego. Budowa modelu funkcjonalnego JAK JEST pozwala w przejrzysty sposób rejestrować, jakie procesy biznesowe są realizowane w przedsiębiorstwie, jakie obiekty informacyjne są wykorzystywane w realizacji procesów biznesowych i poszczególnych operacji. Model funkcjonalny AS-IS jest punktem wyjścia do analizy potrzeb przedsiębiorstwa, identyfikacji problemów i wąskich gardeł oraz opracowania projektu usprawnienia procesów biznesowych.

Zasady biznesowe... Model procesów biznesowych pozwala na identyfikację i dokładne zdefiniowanie reguł biznesowych wykorzystywanych w działalności przedsiębiorstwa.

Na ryc. 3 przedstawia fragment funkcjonalnego modelu obiegu dokumentów. Podczas wykonywania operacji „sortuj dokumenty” stosowana jest reguła biznesowa: „Rejestracja nie podlega: dokumenty przesłane w kopiach w celach informacyjnych, telegramy i zezwolenia na podróże służbowe i urlopy…”. Ta zasada została ustalona w instrukcjach przepływu dokumentów. Model funkcjonalny pozwala nie tylko na stwierdzenie istnienia tej zasady, ale także na określenie, podczas której operacji i na jakim stanowisku pracy należy ją zastosować.

W ramach modelu funkcjonalnego reguła biznesowa wygląda następująco: „jeżeli dokument przeznaczony do zarządzania dotarł do recepcji, podlega on sortowaniu, w wyniku którego na podstawie instrukcji ustala się, czy dokument podlega rejestracji lub nie."

Jeśli ta reguła biznesowa nie zostanie uwzględniona przy tworzeniu systemu informatycznego, to taki system będzie działał niewłaściwie.

Bardzo często zasady biznesowe w przedsiębiorstwie nie są spisane w instrukcjach: wydaje się, że tam są, ale też ich nie ma. W rezultacie próby zmiany czegoś w działalności przedsiębiorstwa lub działu mogą zakończyć się niepowodzeniem tylko dlatego, że zmiany te są sprzeczne z ustalonymi regułami biznesowymi.

Obiekty informacyjne... Model funkcjonalny pozwala na identyfikację wszystkich obiektów informacyjnych, którymi przedsiębiorstwo operuje w swojej działalności. W przeciwieństwie do modeli informacyjnych (Diagramy Przepływu Danych, IDEF1X), model funkcjonalny IDEF0 odzwierciedla sposób wykorzystania obiektów informacyjnych w procesach biznesowych.

Budowanie modelu TAK JAK BĘDZIE... Stworzenie i wdrożenie korporacyjnego systemu informatycznego prowadzi do zmiany warunków wykonywania poszczególnych operacji, struktury procesów biznesowych oraz przedsiębiorstwa jako całości. Prowadzi to do konieczności zmiany systemu reguł biznesowych stosowanych w przedsiębiorstwie, modyfikacji opisów stanowisk pracy pracowników. Model funkcjonalny AS IT WILL pozwala określić te zmiany już na etapie projektowania przyszłego systemu informatycznego. Zastosowanie modelu funkcjonalnego AS IT WILL pozwala nie tylko na skrócenie czasu wdrożenia systemu informatycznego, ale także na zmniejszenie zagrożeń związanych z odpornością personelu na technologię informatyczną.

Alokacja zasobów... Model funkcjonalny pozwala na jasne zdefiniowanie podziału zasobów pomiędzy operacje procesu biznesowego, co umożliwia ocenę efektywności wykorzystania zasobów.

To zadanie jest szczególnie istotne przy tworzeniu nowych procesów biznesowych w przedsiębiorstwie. Na przykład firma specjalizująca się w tworzeniu oprogramowania na zamówienie postanowiła stworzyć własne siły sprzedaży. Funkcjonalny model procesu biznesowego sprzedaży oprogramowania pozwoli kierownictwu firmy jasno określić, jakie zasoby należy przeznaczyć, aby zapewnić funkcjonowanie obsługi sprzedaży, ilu pracowników trzeba przyciągnąć do pracy w nowej usłudze, co obowiązki funkcjonalne, jakie powinni wykonywać ci pracownicy itp.

Systemy oprogramowania IDEF0

Obecnie istnieje wiele narzędzi CASE wspierających modelowanie funkcjonalne w standardzie IDEF0.

WNIOSEK

Metodologia modelowania funkcjonalnego IDEF0 jest dość prostym narzędziem, które pozwala twórcom korporacyjnych systemów informatycznych na badanie zakresu działań klienta i rozwiązywanie problemów w celu poprawy efektywności tej działalności.

Zastosowanie modelowania funkcjonalnego pozwala nam rozwiązywać nie tylko problemy techniczne klienta związane z informatyką, ale także problemy związane z dziedziną działalności klienta. Pozwala to przekształcić projekt systemu informatycznego z „paczki papieru”, za którą klient nie chce płacić, w usługę, która może przynieść klientowi dodatkowy efekt porównywalny z późniejszą automatyzacją.

Proces modelowania biznesowego może być realizowany w ramach różnych metodologii, różniących się przede wszystkim podejściem do tego, czym jest modelowana organizacja. Zgodnie z różnymi wyobrażeniami na temat organizacji zwyczajowo dzieli się metodologię na obiektową i funkcjonalną (strukturalną).

Techniki obiektowe rozważ modelowaną organizację jako zbiór oddziałujących ze sobą obiektów - jednostek produkcyjnych. Obiekt definiuje się jako namacalną rzeczywistość - obiekt lub zjawisko, które ma jasno określone zachowanie. Celem tej techniki jest identyfikacja obiektów składających się na organizację oraz podział między nimi odpowiedzialności za wykonywane czynności.

Techniki funkcjonalne Najbardziej znaną z nich jest metodologia IDEF, organizacja jest postrzegana jako zestaw funkcji, które przekształcają przychodzący strumień informacji w strumień wyjściowy. Proces konwersji informacji pochłania określone zasoby. Główna różnica od metodologia obiektowa polega na wyraźnym oddzieleniu funkcji (metod przetwarzania danych) od samych danych.

Z punktu widzenia modelowania biznesowego każde z przedstawionych podejść ma swoje zalety. Podejście obiektowe pozwala na zbudowanie systemu bardziej odpornego na zmiany, lepiej dopasowanego do już istniejących struktury organizacyjne. Modelowanie funkcjonalne dobrze się sprawdza w przypadkach, gdy struktura organizacyjna jest w trakcie zmian lub jest ogólnie słabo ukształtowana. Podejście oparte na funkcjach jest intuicyjnie lepiej rozumiane przez wykonawców, gdy otrzymują od nich informacje o swojej bieżącej pracy.

Metodologia funkcjonalna IDEF0

Metodologia IDEF0 może być uważana za kolejny etap rozwoju znanego języka graficznego do opisu systemów funkcjonalnych SADT (Structured Analysis and Design Technique). Historycznie, IDEF0 został opracowany jako standard w 1981 roku jako część obszernego programu automatyki przemysłowej o nazwie ICAM (Integrated Computer Aided Manufacturing). Rodzina standardów IDEF dziedziczy swoje oznaczenie z nazwy tego programu (IDEF = Icam DEFinition), a jej ostatnia wersja została wydana w grudniu 1993 r. przez Narodowy Instytut Standardów i Technologii Stanów Zjednoczonych (NIST).

Celem tej techniki jest budowanie schemat funkcjonalny badanego systemu, który opisuje wszystkie niezbędne procesy z dokładnością wystarczającą do jednoznacznego modelowania działania systemu.

Metodologia opiera się na czterech głównych koncepcjach: blok funkcyjny, łuk interfejsu, dekompozycja, słowniczek.

(Pole aktywności) reprezentuje określoną funkcję w ramach rozważanego systemu. Zgodnie z wymaganiami normy nazwa każdego bloku funkcjonalnego musi być sformułowana w trybie czasownikowym (np. „produkować usługi”). Na schemacie blok funkcjonalny jest przedstawiony prostokątem (ryc. 6.1). Każda z czterech stron bloku funkcjonalnego ma swoje specyficzne znaczenie (rolę), podczas gdy:

• górna strona to Control;
• lewa strona to Wejście;
• prawa strona jest ustawiona na Wyjście;
• spód to „mechanizm”.

Ryż. 6.1.

Łuk interfejsu(Strzałka) wyświetla element systemu, który jest przetwarzany przez blok funkcyjny lub w inny sposób wpływa na funkcję reprezentowaną przez ten blok funkcyjny. Łuki interfejsu są często określane jako strumienie lub strzałki.

Za pomocą łuków interfejsu wyświetlane są różne obiekty, które w takim czy innym stopniu określają procesy zachodzące w systemie. Takimi obiektami mogą być elementy świata rzeczywistego (części, samochody, pracownicy itp.) lub strumienie danych i informacji (dokumenty, dane, instrukcje itp.).

W zależności od tego, do której strony bloku funkcjonalnego pasuje ten łuk interfejsu, nazywa się to „przychodzącym”, „wychodzącym” lub „sterującym”.

Należy zauważyć, że każdy blok funkcjonalny, zgodnie z wymaganiami normy, musi mieć co najmniej jeden łuk interfejsu sterującego i jeden wychodzący. Jest to zrozumiałe - każdy proces musi przestrzegać pewnych reguł (wyświetlanych przez łuk kontrolny) i musi dawać jakiś wynik (łuk wychodzący), w przeciwnym razie nie ma sensu się nad tym zastanawiać.

Obowiązkowa obecność łuków interfejsu sterującego jest jedną z głównych różnic standardu IDEF0 od innych metodologii klas DFD (Diagram Przepływu Danych) i WFD (Diagram Przepływu Pracy).

Rozkład(Dekompozycja) to podstawowa koncepcja standardu IDEF0. Zasada dekompozycji jest stosowana przy rozkładaniu złożonego procesu na jego funkcje składowe. W której poziom detali proces jest definiowany bezpośrednio przez modelarza.

Dekompozycja pozwala na stopniowe i uporządkowane przedstawienie modelu systemu w postaci hierarchicznej struktury poszczególnych diagramów, dzięki czemu jest on mniej przeciążony i łatwy do strawienia.

Ostatnią z koncepcji IDEF0 jest Słowniczek... Dla każdego z elementów IDEF0 - diagramów, bloków funkcjonalnych, łuków interfejsu - istniejący standard implikuje stworzenie i utrzymanie zestawu odpowiednich definicji, słów kluczowych, narracji itp., które charakteryzują obiekt wyświetlany przez ten element. Zestaw ten nosi nazwę glosariusza i jest opisem istoty tego elementu. Słowniczek harmonijnie uzupełnia język graficzny, dostarczając diagramom niezbędnych informacji dodatkowych.

Model IDEF0 zawsze zaczyna się od przedstawienia systemu jako całości - pojedynczego bloku funkcjonalnego z łukami interfejsu wychodzącymi poza rozpatrywany obszar. Taki schemat z jednym blokiem funkcjonalnym nazywa się diagram kontekstowy.

W tekście objaśniającym do diagram kontekstowy należy określić bramka(Cel) zbuduj diagram jako krótki opis i zatwierdź punkt widzenia(Punkt widzenia).

Niezwykle ważnym punktem jest określenie i sformalizowanie celu opracowania modelu IDEF0. W rzeczywistości cel określa odpowiednie obszary w badanym systemie, na których należy się najpierw skoncentrować.

Punkt widzenia określa główny kierunek rozwoju modelu i wymagany poziom szczegółowości... Wyraźne utrwalenie punktu widzenia pozwala rozładować model, odmawiając szczegółów i przestudiować poszczególne elementy, które nie są konieczne, w oparciu o wybrany punkt widzenia na system. Właściwy dobór punktu widzenia znacznie skraca czas poświęcony na zbudowanie finalnego modelu.

Przydział podprocesów. W procesie dekompozycji blok funkcjonalny, który w diagram kontekstowy wyświetla system jako całość, szczegółowo opisano na innym schemacie. Wynikowy diagram drugiego poziomu zawiera bloki funkcyjne reprezentujące główne podfunkcje bloku funkcyjnego diagram kontekstowy, i jest w stosunku do niego nazywany blokiem potomnym (Diagram podrzędny) (każdy z bloków funkcjonalnych należących do diagramu podrzędnego jest odpowiednio nazywany blokiem podrzędnym - Pole podrzędne). Z kolei nadrzędny blok funkcyjny nazywany jest blokiem nadrzędnym w stosunku do diagramu potomnego (Parent Box), a diagram, do którego należy, nazywany jest diagramem nadrzędnym (Parent Diagram). Każda z podfunkcji diagramu potomnego może być dalej uszczegółowiona przez podobną dekompozycję odpowiedniego bloku funkcjonalnego. W każdym przypadku dekompozycji bloku funkcjonalnego wszystkie łuki interfejsu wchodzące lub wychodzące z tego bloku są ustalane na diagramie potomnym. Osiąga to integralność strukturalną modelu IDEF0.

Czasami nie ma sensu dalsze rozpatrywanie poszczególnych łuków interfejsu wyższego poziomu na diagramach niższego poziomu lub odwrotnie - odzwierciedlanie poszczególnych łuków niższego poziomu na diagramach wyższych poziomów - to tylko przeciąży diagramy i sprawi, że trudne do zrozumienia. Aby rozwiązać takie problemy, standard IDEF0 zawiera koncepcję tunelowania. Notacja „Tunel strzałkowy” w postaci dwóch nawiasów wokół początku łuku interfejsu oznacza, że ​​łuk ten nie został odziedziczony z funkcjonalnego bloku nadrzędnego i pojawił się (z „tunelu”) tylko na tym schemacie. Z kolei to samo oznaczenie wokół końca (strzałki) łuku interfejsu w bezpośrednim sąsiedztwie bloku docelowego oznacza, że ​​ten łuk jest wyświetlany i nie będzie uwzględniony na diagramie potomnym tego bloku. Najczęściej zdarza się, że poszczególne obiekty i odpowiadające im łuki interfejsu nie są brane pod uwagę na jakichś pośrednich poziomach hierarchii – w tym przypadku najpierw „zagłębiają się w tunel”, a następnie, jeśli to konieczne, „powracają z tunelu”.

• Stworzenie modelu przez grupę specjalistów związanych z różnymi obszarami przedsiębiorstwa. Ta grupa jest nazywana Autorami w kategoriach IDEF0. Budowanie wstępnego modelu to dynamiczny proces, podczas którego autorzy przeprowadzają wywiady z kompetentnymi osobami na temat struktury różnych procesów, tworząc modele działania działów. Jednocześnie interesują ich odpowiedzi na następujące pytania:

  Co trafia do jednostki „przy wejściu”?

  • Jakie funkcje iw jakiej kolejności są wykonywane w obrębie jednostki?
  • Kto odpowiada za każdą z funkcji?
  • Czym kieruje się wykonawca wykonując każdą z funkcji?
  • Jaki jest wynik pracy jednostki (wynik)?

  Na podstawie istniejących przepisów, dokumentów i wyników badań tworzony jest Wzorcowy Projekt modelu.

• Dystrybucja projektu do recenzji, zatwierdzeń i komentarzy. Na tym etapie następuje dyskusja nad projektem modelu z szerokim gronem kompetentnych osób (w zakresie IDEF0 – czytelników) w przedsiębiorstwie. Jednocześnie każdy z diagramów projektu modelu jest krytykowany i komentowany pisemnie, a następnie przekazywany autorowi. Autor z kolei również zgadza się na piśmie z krytyką lub odrzuca ją, nakreślając logikę podejmowania decyzji i zwraca poprawiony projekt do dalszego rozpatrzenia. Cykl ten trwa, dopóki autorzy i czytelnicy nie dojdą do konsensusu.
• Zatwierdzenie modelu. Zatwierdzony model jest zatwierdzany przez szefa grupy roboczej w przypadku, gdy autorzy modelu i czytelnicy nie mają sprzeczności co do jego adekwatności. Ostateczny model to spójne spojrzenie na przedsiębiorstwo (system) z określonego punktu widzenia i dla określonego celu.

Widoczność języka graficznego IDEF0 sprawia, że ​​model jest dość czytelny dla osób, które nie brały udziału w projekcie jego tworzenia, a także skuteczny przy prowadzeniu pokazów i prezentacji. W przyszłości na podstawie zbudowanego modelu można organizować nowe projekty mające na celu wprowadzenie zmian w modelu.

IDEF0 jest obecnie głównym standardem modelowania procesów biznesowych. Opis systemu wykorzystujący IDEF0 nazywa się model funkcjonalny ... Model opisuje, co dzieje się w systemie, w jaki sposób jest kontrolowany, jakie podmioty przekształca, jakich narzędzi używa do wykonywania swoich funkcji i co wytwarza.

Budując model, cel symulacji, odpowiadając na następujące pytania:

· Dlaczego należy modelować ten proces?

· Co powinien pokazać model?

· Co może otrzymać czytelnik?

Przykłady definicji celów: „identyfikacja i zdefiniowanie bieżących problemów, umożliwienie analizy potencjalnych usprawnień”, „określenie ról i obowiązków pracowników do pisania opisów stanowisk”, „określenie możliwości automatyzacji…”, „określenie regulować proces…” itp.

Punkt widzenia jest również jednym z kluczowych elementów budowy modelu. Punkt widzenia można traktować jako punkt widzenia osoby, która widzi system w aspekcie niezbędnym do modelowania. Punkt widzenia musi być zgodny z celem symulacji.

Główną zasadą koncepcyjną metodologii IDEF jest reprezentacja dowolnego badanego systemu jako zestawu wzajemnie oddziałujących i wzajemnie połączonych bloków, które odzwierciedlają procesy, operacje, działania zachodzące w badanym systemie. W IDEF0 wszystko, co dzieje się w systemie i jego elementach, zwykle nazywa się Funkcje. Każda funkcja jest przypisana blok.

Bloki funkcjonalne na diagramach są reprezentowane przez prostokąty reprezentujące nazwane procesy, funkcje, czynności lub operacje, które występują w czasie i mają rozpoznawalne wyniki. Każdy blok zawiera swoją nazwę i numer. Nazwa bloku musi być aktywnym czasownikiem, słowną zmianą lub słownym rzeczownikiem oznaczającym czynność.

Bloki w IDEF0 są uporządkowane według ważności, zgodnie z rozumieniem autora diagramu. Ten względny porządek nazywa się dominacją. Dominacja jest rozumiana jako wpływ, jaki jeden blok ma na inne bloki na diagramie. Najbardziej dominujący blok znajduje się zwykle w lewym górnym rogu wykresu, a najmniej dominujący w prawym.

Reprezentowane są interfejsy, przez które blok oddziałuje z innymi blokami lub ze środowiskiem zewnętrznym względem modelowanego systemu strzały, wejście lub wyjście z bloku. Każda strona bloku funkcyjnego ma standardowe znaczenie w zakresie komunikacji blok/strzałka. Typowe położenie strzałek pokazano na rysunku 1.

Ryż. 1. Kontekst IDEF0.

Strzałki opisać interakcję bloków ze światem zewnętrznym i ze sobą. Strzałki reprezentują pewien rodzaj informacji i są nazywane rzeczownikami lub wyrażeniami rzeczownikowymi.

IDEF0 rozróżnia pięć rodzajów strzał:

1. Wejście - materiał lub informacja, która jest wykorzystywana lub przekształcana przez blok funkcjonalny w celu uzyskania wyniku (wyjście). Zakłada się, że praca nie może mieć żadnych strzałek wejściowych.

2. Zarządzanie – zasady, strategie, procedury lub standardy rządzące jednostką. Sterowanie wpływa na blok, ale nie jest przez niego przekształcane.

3. Wyjście - materiał lub informacja, która jest wytwarzana przez blok. Blok bez wyniku jest bez znaczenia i nie powinien być modelowany.

4. Mechanizm – zasoby realizujące blok, np. personel zakładu, maszyny, urządzenia itp. Według uznania analityka strzałki mechanizmu mogą nie pojawiać się w modelu.

5. Call (Call) – specjalna strzałka wskazująca inny model pracy. Strzałka wywołania służy do wskazania, że ​​część pracy jest wykonywana poza symulowanym systemem.

Strzałki na diagramie kontekstowym służą do opisu interakcji systemu ze światem zewnętrznym. Strzałki graniczne- strzałki, które zaczynają się na granicy schematu, a kończą na pracy lub odwrotnie. Strzałki wewnętrzne połącz bloki ze sobą. Istnieje pięć rodzajów stosunków pracy.

1. Komunikacja wejściowa - strzałka wyjściowa bloku wyższego poziomu skierowana jest na wejście jednostki niższego poziomu (rys. 2).

Ryż. 2. Stosunek „wyjście-wejście”.

2. Komunikacja sterująca - wyjście jednostki wyższego poziomu kierowane jest do sterowania jednostki niższego poziomu (rys. 3).

Ryż. 3. Relacja „sterowanie wyjściem”.

3. Sprzężenie zwrotne sterowania – wyjście bloku niższego poziomu kierowane jest do sterowania bloku wyższego poziomu (rys. 4).

Ryż. 4. Informacje zwrotne na temat zarządzania

4. Sprzężenie zwrotne na wejściu - wyjście bloku niższego poziomu kierowane jest na wejście bloku wyższego poziomu (rys. 5).

Ryż. 5. Współczynnik sprzężenia zwrotnego wejściowego

5. Mechanizm wyjścia komunikacyjnego - wyjście jednego bloku kierowane jest do mechanizmu drugiego (rys. 6).

Ryż. 6 Komunikacja „mechanizm wyjścia”.

W notacji IDEF0 opis systemu (modelu) jest zorganizowany w postaci hierarchicznie uporządkowanych i połączonych diagramów. Najpierw dokonuje się opisu systemu jako całości i jego interakcji ze światem zewnętrznym (diagram kontekstowy). Diagram kontekstowy zawiera tylko jeden blok, który bez szczegółów charakteryzuje cały zestaw symulowanych procesów.

Ryż. 7 Przykład diagramu kontekstowego IDEF0.

Następnie przeprowadzana jest dekompozycja funkcjonalna (ryc. 8) - ten blok aktywności (duży proces) jest podzielony na duże podprocesy - a każdy podproces jest opisany osobno (diagramy dekompozycji). Następnie każdy podproces jest rozkładany na mniejsze – i tak dalej, aż do osiągnięcia wymaganej szczegółowości opisu.

Rys.8 Przykład diagramu dekompozycji IDEF0.

Jeden obraz jest wart tysiąca słów

Mądrość ludowa

Często w mojej pracy pojawia się potrzeba nie tylko przestudiowania i rozwiązania konkretnego problemu, ale zidentyfikowania jego umiejscowienia w ogólnym modelu pracy firmy. Nie wystarczy zrozumieć, że dany dział nie działa prawidłowo, ważne jest, aby zrozumieć, w jaki sposób współdziała z innymi. W przeciwnym razie niemożliwe jest zidentyfikowanie wszystkich istniejących problemów i wybranie najlepszej metody rozwiązania problemu. A do tego wymagane jest przestudiowanie pracy firmy i opracowanie jej modelu funkcjonalnego.

Oczywiście teoretycznie menedżer powinien mieć funkcjonalny model pracy firmy i nie ma znaczenia, czy mówimy o organizacji pracy magazynu, czy o systemie informatycznym od leadu do aplikacji. Ale w rzeczywistości prawie nigdy się to nie okazuje, dlatego w procesie studiowania i poszukiwania rozwiązania problemu postawionego przez klienta, również samodzielnie tworzę funkcjonalny model pracy firmy lub pewien proces (funkcję) .

Kilka słów o zaletach grafiki

Jak wiadomo, modele funkcjonalne IDEF0 są zawsze diagramami graficznymi. Mają swoje własne cechy i zasady kompilacji. Porozmawiamy o tym nieco później. Teraz chciałbym podać kilka przykładów skuteczności grafiki. Dlaczego to podkreślam? Najprawdopodobniej po moim stwierdzeniu o potrzebie funkcjonalnego modelu pracy firmy wiele osób uznało, że to wszystko nie jest konieczne, można wyjaśnić słowami, jak ta czy inna funkcja działa w firmie. O tym chcę porozmawiać.

Na początek zróbmy małą wycieczkę do historii. Wróćmy do odległego 1877 roku, podczas wojny rosyjsko-tureckiej. Wtedy to poligrafista Sytin po raz pierwszy wykorzystał grafikę do opisu operacji wojskowych. Teraz dla nas wszystko to jest znajome, opisując każdą bitwę, przed oczami wszystkich pojawiają się karty ze strzałkami, które wyraźnie pokazują przebieg bitwy. A w tamtych czasach działania wojskowe opisywano słowami. Na każdą walkę jest wiele, wiele słów. I bardzo trudno było zrozumieć, co się w końcu dzieje.

Dlatego pomysł Sytina był iście rewolucyjny – zaczął drukować litograficzne kopie map ukazujących fortyfikacje i rozmieszczenie jednostek wojskowych. Karty te nosiły nazwę „Dla czytelników gazet. Korzyść ". Pomysł okazał się na tyle trafny, że pierwsze wydanie „Podręczników” zostało natychmiast wyprzedane. A potem takie aplikacje były bardzo poszukiwane. Powód jest oczywisty. Grafika pomogła zrozumieć to, co było prawie niemożliwe do zrozumienia za pomocą samych słów.

Podobny przykład bezradności opisów słownych mogę podać z własnej praktyki. Jeden z moich klientów bardzo prosił o podjęcie się wdrożenia systemu ERP dla swojej firmy. Na pytanie, czy mają jakieś zadanie techniczne, otrzymałem odpowiedź: „Tak, jest. Ale ma 400 stron”. Jednocześnie klient bardzo narzekał, że moi koledzy, z którymi wcześniej się kontaktował, albo całkowicie zrezygnowali z projektu, albo nazwali wyraźnie zawyżone ceny. Po tym, jak zobaczyłem, że zakres zadań ma tak naprawdę 400 stron i składa się wyłącznie z opisu tekstowego, zrozumiałem powody zachowania deweloperów. Przeczytanie takiego tomu tekstu, zagłębienie się w niego, uporządkowanie wszystkich niuansów tylko po to, by zrozumieć zadanie i nazwać cenę jest naprawdę bardzo trudne.

Zaproponowałem temu klientowi alternatywną opcję - opisanie wszystkiego, co jest możliwe graficznie w postaci notacji. Pokazał mu przykłady modelowania. W rezultacie przemyśleli teraz swoje życzenia i projekt zadania technicznego.

Znam też wiele innych przykładów, kiedy graficzne modelowanie procesów biznesowych pomogło zarówno moim kolegom, konsultantom biznesowym i programistom, jak i samym biznesmenom.

Dlaczego jest to ważne dla mojej pracy

Moja praca jest zawsze związana z wprowadzaniem zmian w istniejącym systemie. Aby wprowadzić zmiany i uzyskać pożądany rezultat, musisz przestudiować to, co już istnieje. I nie ma znaczenia, co dokładnie robimy - konfigurujemy lub instalujemy system CRM od podstaw, tworzymy skuteczny system ERP, integrujemy różne systemy, aby ogólnie zwiększyć automatyzację pracy. W każdym razie na początek musisz zorientować się w istniejącym schemacie pracy, a dopiero potem możesz zaproponować pewne zmiany i przemyśleć opcje rozwiązania problemu.

Po zapoznaniu się z aktualnym stanem rzeczy, jak każdy inny specjalista, tworzę ofertę handlową, w której jak najdokładniej przedstawiam swoją wizję aktualnej sytuacji oraz czynności, które należy wykonać, aby rozwiązać zadanie i oczywiście oczekiwany rezultat.

Takie raporty z badania pracy są obszerne, zajmują więcej niż jedną stronę, co z jednej strony jest konieczne, az drugiej komplikuje percepcję. Na początku, podobnie jak wielu innych, uważałem, że obszerne raporty są dobre, bo człowiek płaci za pracę i musi otrzymać jak najwięcej szczegółowych informacji.

Typowe błędy

Modelowanie funkcjonalne wykonujemy przy użyciu szerokiej gamy narzędzi, także tych nieprzeznaczonych do modelowania. W tym drugim przypadku nie ma sprawdzania błędów i ograniczeń normy. Chęć zwiększenia widoczności i brak doświadczenia często kończą się błędami.

Używanie różnych kolorów

Wszystkie elementy na diagramie są równie ważne. W modelowaniu funkcjonalnym nie ma mniej lub bardziej ważnych elementów. Zniknięcie któregokolwiek z nich doprowadzi do zakłóceń procesu i wad produkcyjnych.

Często podczas modelowania na papierze lub w różnych programach użytkownicy starają się zwiększyć widoczność, używając różnych kolorów. To jeden z najczęstszych błędów. W rzeczywistości użycie kolorowych strzałek i bloków wprowadza tylko dodatkowe zamieszanie i zniekształca postrzeganie diagramu.

Twój model powinien być czytelny w czerni i bieli, bez dodatkowych schematów kolorystycznych. Takie podejście jednocześnie pomaga uniknąć nieporozumień i dyscyplinuje twórcę modelu, co skutkuje lepszą czytelnością i umiejętnością korzystania z modelu.

Za dużo bloków

Tworząc model, często starają się pokazać wszystkie niuanse pracy firmy ze wszystkimi szczegółami na jednym arkuszu. Rezultatem jest bardzo duża liczba bloków z dużą liczbą strzałek kontrolnych. W takim przypadku czytelność zostaje utracona.

Najlepszą opcją są szczegóły, wystarczające do zrozumienia problemu i nic więcej. Szczegółowe uszczegółowienie pracy każdego działu, a nawet pracownika można ujawnić przy wyborze szczegółowego widoku danego procesu. A taka struktura powstaje tylko wtedy, gdy jest naprawdę niezbędna do pracy lub podejmowania decyzji.

Podział struktury podczas dokonywania korekt

Uważaj, aby nie wprowadzać zamieszania ani procesów bez przychodzących, wychodzących i innych ważnych elementów. Np. jeśli w powyższym przykładzie uznam za stosowne przesunąć punkt widzenia na copywritera, to autora usunę ze schematu. A wtedy kontrole „doświadczenie autora i źródła zewnętrzne”, a także plan publikacji stają się niepotrzebne. W końcu autor ich używa. Copywriter pracuje z plikiem audio. A jeśli pozostaną w ogólnym schemacie, to szczegółowe doprowadzą do czegoś niezrozumiałego i spowodują zamieszanie.

Podobnie, jeśli zdecyduję się dodać blok, ważne jest, aby upewnić się, że ma on również wszystkie wymagane atrybuty. Opieka jest tutaj bardzo ważna, ponieważ podczas modelowania złożonych procesów biznesowych zmiany w jednej części modelu mogą prowadzić do zmian w innej. Muszą być wprowadzone.

Zasady nazewnictwa kontrolek i bloków

Należy pamiętać o prostej zasadzie: strzałki sterujące to rzeczowniki, a bloki to czasowniki. Jest to standard IDEF0, a takie podejście pomaga uniknąć zamieszania i błędów.

Najczęściej popełniane są błędy podczas nazywania bloków. Na przykład zamiast „Utwórz artykuł” piszą „Utwórz artykuł”. Bloki w tym podejściu to akcje i dlatego zawsze powinny być czasownikami.

Korzyści z używania IDEF0

• Pierwsza korzyść jest oczywista – to widoczność. Sam zaczynasz rozumieć, jak działa ten lub inny system, a także możesz jasno wyjaśnić, gdzie znajdują się „wąskie gardła” w tym systemie i w jaki sposób twoje decyzje pomogą się ich pozbyć.
• Wzajemne zrozumienie i brak rozbieżności. Omawiając pracę firmy za pomocą funkcjonalnego modelu, masz do dyspozycji wizualne i intuicyjne bloki zadań z elementami kontrolnymi. Ponadto modelowanie funkcjonalne obejmuje tworzenie, jeśli to konieczne, glosariusza, w którym ujawniane są konwencje i terminy. W rezultacie Ty i klient, kierownik i inni pracownicy rozmawiacie w tym samym języku podczas omawiania problemu.
• Prostota i duża szybkość tworzenia modelu. Oczywiście nauka modelowania nie jest tak łatwa, jak się wydaje. W końcu schemat jest w rzeczywistości bardzo gęstą prezentacją informacji, co jest bardzo dobre do zrozumienia, ale do realizacji takiej prezentacji wymagane jest specjalne podejście. Mózg analityka działa w tym przypadku z jednej strony jako bardzo potężna prasa, az drugiej jako filtr. Ale z doświadczeniem ten proces staje się bardzo szybki. W efekcie otrzymujesz narzędzie, które pomoże Ci zorientować się, co dzieje się w konkretnym systemie, a za pomocą stworzonej w krótkim czasie pomocy wizualnej zilustrować ważne punkty współpracownikom lub klientom.
• Dyscyplina i brak błędów. Standard IDEF0 ma ścisłe ramy i zasady. Takie podejście jest zdyscyplinowane, a nawyk działania w ramach normy pomaga uniknąć błędów wynikających z nieuwagi. Wszelkie naruszenia normy są natychmiast widoczne.

Jaka jest trudność korzystania z IDEF0?

Ważne jest, aby zrozumieć, że tylko w najprostszych przypadkach dwóch analityków biznesowych stworzy dokładnie te same modele funkcjonalne opisujące pracę firmy. Każdy model jest odzwierciedleniem doświadczenia analityka, głębi zrozumienia biznesu, który stara się opisać, a także, w pewien sposób, jego osobistego punktu widzenia na ten biznes. Te. człowiek opracowuje model biznesowy z punktu widzenia lidera, tak jakby był liderem.

Jednocześnie uważam, że analityk biznesowy nie jest tak naprawdę zawodem, każdy lider biznesowy lub deweloper niektórych systemów, który analizuje biznes i dąży do zbudowania najbardziej efektywnego systemu, zajmuje się analityką biznesową. To dla tych osób i do tych celów przeznaczone jest narzędzie IDEF0.

Dlatego bardzo ważne jest, aby przy opracowywaniu funkcjonalnego modelu biznesowego „tak jak jest”, stale konsultować się z szefem firmy, aby nie popełniać błędów, które automatycznie pociągną za sobą błędy na etapach rozkładu. Również na kolejnych etapach może być wymagana dodatkowa koordynacja z kierownikami działów strukturalnych i pracownikami. Tylko jeśli Twój model funkcjonalny „tak jak jest” naprawdę odzwierciedla rzeczywisty stan rzeczy, możesz wprowadzić pewne zmiany i sugestie. A aby w takiej pracy osiągnąć wysokiej jakości wyniki, wymagane jest przede wszystkim praktyczne doświadczenie i znajomość specyfiki konkretnego rodzaju działalności.

Więcej artykułów na ten temat.

Niniejsze zalecenia normalizacyjne przeznaczone są do wykorzystania w analizie i syntezie systemów produkcyjno-technicznych i organizacyjno-ekonomicznych metodami modelowania funkcjonalnego w różnych sektorach gospodarki.
Rekomendacje zawierają opis zestawu narzędzi do wizualizacji szerokiego zakresu procesów biznesowych, produkcyjnych oraz innych procesów i operacji przedsiębiorstwa na dowolnym poziomie szczegółowości,oraz organizacyjne i metodyczne sposoby korzystania z tych narzędzi.

Ciągłe komplikowanie systemów produkcyjno-technicznych i organizacyjno-gospodarczych - firm, przedsiębiorstw, branż i innych podmiotów produkcji i działalności gospodarczej - oraz potrzeba ich analizy w celu usprawnienia funkcjonowania i zwiększenia efektywności wymuszają zastosowanie specjalnych środków opisu i analizowanie takich systemów. Problem ten ma szczególne znaczenie w związku z pojawieniem się zintegrowanej skomputeryzowanej produkcji i zautomatyzowanych przedsiębiorstw.
W Stanach Zjednoczonych pod koniec lat 70. zaproponowano i wdrożono ICAM - Integrated Computer Aided Manufacturing Program, którego celem jest zwiększenie efektywności przedsiębiorstw poprzez powszechne wprowadzanie technologii komputerowych (informacyjnych).
Wdrożenie programu ICAM wymagało stworzenia odpowiednich metod analizy i projektowania systemów produkcyjnych oraz sposobów wymiany informacji pomiędzy specjalistami zajmującymi się takimi problemami. Wychodząc naprzeciw tej potrzebie, w ramach programu ICAM opracowano metodykę modelowania IDEF (ICAM Definition), która pozwala na badanie struktury, parametrów i charakterystyk systemów produkcyjno-technicznych i organizacyjno-ekonomicznych.

Metodologia IDEF

Ogólna metodologia IDEF składa się z trzech konkretnych metodologii modelowania opartych na graficznych reprezentacjach systemów:
IDEF0 służy do tworzenia funkcjonalnego modelu, który wyświetlastrukturę i funkcje systemu, a także przepływy informacji i materiałówobiekty przekształcone przez te funkcje;
IDEF1 służy do budowania modelu informacji, który wyświetlastruktura i treść przepływów informacji wymaganych do obsługifunkcje systemu;
IDEF2 pozwala zbudować dynamiczny model zmienny w czasiezachowanie funkcji, informacji i zasobów systemu.
Do tej pory najbardziej rozpowszechnionymi i stosowanymi metodologiami są IDEF0 i IDEF1 (IDEF1X).
Metodologia IDEF0, której cechy i zastosowanie opisano w niniejszych zaleceniach, opiera się na podejściu zwanym
SADT - Structured Analysis & Design Technique - metoda analizy strukturalnej i projektowania. Podstawą tego podejścia i metodologii IDEF0 jest graficzny język opisu (modelowania) systemów.

Pojęcia ogólne

Model IDEF0: Graficzny opis systemu, zaprojektowany w określonym celu iz wybranym punktem widzenia. Zestaw dokumentów IDEF0, które przedstawiają funkcje systemu za pomocą grafiki (diagramów), tekstu i glosariusza.
Cel: Krótkie przedstawienie powodu powstania modelu.
Punkt widzenia: wskazanie urzędnika lub wydziału organizacji, z którego stanowiska opracowywany jest model. Dla każdego modelu istnieje tylko jeden punkt widzenia.
Słowniczek: ​​Lista definicji słów kluczowych, fraz i skrótów związanych z węzłami, blokami, strzałkami lub ogólnie modelem IDEF0.
Tekst: Dowolny tekstowy (nie graficzny) komentarz do diagramu graficznego IDEF0.
Uwaga dotycząca modelu: komentarz tekstowy, który jest częścią diagramu IDEF0 i służy do zapisania faktu, w którym nie znaleziono grafiki.
Funkcja: czynność, proces lub transformacja (modelowana przez blok IDEF0) identyfikowana przez czasownik lub formę czasownika, która opisuje, co należy zrobić.
Dekompozycja: podział modelowanej funkcji na funkcje składowe.

Przykład diagramu kontekstowego

Diagram

Diagram: Część modelu opisująca rozkład bloku.
Kontekst: Środowisko, w którym działa funkcja (lub zestaw funkcji na diagramie).
Diagram kontekstowy: diagram z numerem węzła A – n (A minus n), który reprezentuje kontekst modelu. Diagram А – 0, składający się z jednego bloku, jest niezbędnym (obowiązkowym) diagramem kontekstowym; diagramy z numerami węzłowymi А – 1, А – 2, ..., - dodatkowe diagramy kontekstowe (n> 0). Diagram A – 0 (A minus zero): Specjalny widok (kontekstowego) diagramu IDEF0, składający się z jednego bloku opisującego funkcję najwyższego poziomu, jej wejścia, wyjścia, sterowanie i mechanizmy, wraz z określeniem celu model i punkt widzenia, z którego jest zbudowany model.
Diagram podrzędny: diagram szczegółowo opisujący blok rodzica (rodzica).
Wykres nadrzędny: wykres zawierający blok nadrzędny.
Odniesienie węzłowe: kod przypisany do wykresu w celu jego identyfikacji i umieszczenia w hierarchii modelu; tworzony jest ze skróconej nazwy modelu i numeru węzłowego diagramu z dodatkowymi rozszerzeniami.
Numer węzła wykresu: Część odniesienia do węzła wykresu, która odpowiada numerowi bloku nadrzędnego.

Rozkład

Na diagramie kontekstowym A – 0 obiekt modelowania jest reprezentowany przez pojedynczy blok ze strzałkami brzegowymi, które reprezentują połączenie obiektu modelowania
ze środowiskiem.

Pojedynczą funkcję prezentowaną na diagramie kontekstowym najwyższego poziomu można rozłożyć na główne podfunkcje, tworząc diagramy potomne zawierające szczegóły bloków nadrzędnych.

Blok

Blok: prostokąt zawierający nazwę i numer używany do opisu funkcji.

Numer bloku: numer (0-6) umieszczony w prawym dolnym rogu bloku i jednoznacznie identyfikujący blok na schemacie.

Nazwa bloku: czasownik lub zwrot czasowy umieszczony wewnątrz bloku i opisujący modelowaną funkcję.

Blok podrzędny: blok w diagramie podrzędnym (dziecko).

Blok nadrzędny: blok, który jest szczegółowo opisany przez diagram podrzędny.

Dla bloków ustawione są następujące reguły składni:

Rozmiary bloków muszą być wystarczająco duże, aby zawierały nazwę i numer bloku.

Bloki muszą być prostokątne pod kątem prostym;

Bloki należy rysować liniami ciągłymi.

Węzeł

Węzeł: blok, który tworzy bloki podrzędne; blok nadrzędny.

Numer węzła: kod przypisany do bloku i określający jego pozycję w hierarchii modelu; może być używany jako szczegółowe wyrażenie referencyjne.

Drzewo węzłów: Reprezentacja relacji między węzłami nadrzędnymi i podrzędnymi modelu IDEF0 w postaci grafu drzewa. Ma takie samo znaczenie i treść jak lista węzłów.

Lista węzłów: lista, często schodkowa, pokazująca węzły modelu IDEF0 w uporządkowany sposób. Ma takie samo znaczenie i treść jak drzewo węzłów.

Strzałka

Strzałka: Linia kierunkowa, składająca się z jednego lub więcej segmentów, symulująca otwarty kanał lub kanał, który przesyła dane lub obiekty materialne ze źródła (punkt początkowy strzałki) do konsumenta (punkt końcowy z „końcówką”).Strzałka wejściowa: Klasa strzałek reprezentujących dane wejściowe bloku IDEF0, czyli obiekty danych lub materiałów, które funkcja konwertuje na dane wyjściowe. Strzałki wejściowe łączą się z lewą stroną bloku IDEF0.Strzałka wyjściowa: Klasa strzałek reprezentujących dane wyjściowe bloku IDEF0, to znaczy dane lub obiekty materialne wytwarzane przez funkcję. Strzałki wyjściowe są połączone z prawą stroną bloku IDEF0.Mechanizm strzałkowy: Klasa strzałek reprezentujących mechanizmy IDEF0, czyli środki używane do wykonania funkcji; Zawiera specjalny futerał na strzałkę. Strzałki mechanizmu komunikują się ze spodem bloku IDEF0.Strzałka kontrolna: Klasa strzałek, które w IDEF0 reprezentują kontrolki, czyli warunki, w których wyjście bloku będzie poprawne. Dane lub obiekty modelowane jako kontrolki mogą być przekształcane przez funkcję generującą odpowiednie dane wyjściowe. Strzałki kontrolne są powiązane z górną stroną bloku IDEF0.

Etykieta strzałki: obrót rzeczownika lub rzeczownika związany ze strzałką lub segmentem strzałki i określający jego znaczenie.

Strzałka wewnętrzna: strzałka wejściowa, kontrolna lub wyjściowa, której końce łączą źródło i odbiorcę, które są blokami tego samego schematu. Różni się od strzałki granicy.Strzałka graniczna: Strzałka, której jeden koniec jest połączony ze źródłem lub odpływem, a drugi nie jest połączony z żadnym blokiem na schemacie. Pokazuje połączenie schematu z innymi blokami systemu i różni się od strzałki wewnętrznej.Segment strzałki: segment linii, który zaczyna się lub kończy z boku bloku, w punkcie rozgałęzienia lub scalania albo na granicy (niepołączony koniec strzałki).Rozgałęzienie: podział strzałki na dwa lub więcej segmentów.Scal: Łączy dwa lub więcej segmentów strzałek w jeden segment.Binding/unbundling: Łączenie wartości strzałek w wartość złożoną (łączenie) lub dzielenie wartości strzałek (rozwiązywanie „wiązki”), wyrażone w składni strzałek fuzji lub rozgałęzień.Tylda: Mała przerywana (falista) linia służąca do łączenia etykiety z określonym segmentem strzałki lub notatką modelu z komponentem wykresu.Kod ICOM: kod dopasowujący strzałki graniczne diagramu potomnego do strzałek bloku nadrzędnego; używany do połączeń (skrót ICOM oznacza Input - input, Control - control, Output - output, Mechanism - mechanizm).

Semantyka pudełek i strzałek

Każda strona bloku funkcyjnego ma standardowe przeznaczenie w zakresie komunikacji blok/strzałka. Z kolei strona klocka, do której przymocowana jest strzałka, jednoznacznie określa swoją rolę.

Zasady składni strzałek są następujące:- Złamane strzałki zmieniają kierunek tylko pod kątem 90 °;- Strzałki muszą być narysowane liniami ciągłymi.
Można stosować linie o różnej grubości; - Strzałki mogą składać się tylko z linii pionowych lub poziomych.
Linie ukośne są niedozwolone; - Końce strzałek muszą dotykać zewnętrznej granicy bloku funkcyjnego,
ale nie wolno jej przekraczać;

Strzałki muszą przyczepiać się do bloku po jego bokach.
Łączenie w rogach jest niedozwolone.