Często programiści proszeni są nie tylko o zidentyfikowanie i rozwiązanie problemu w pracy firmy, ale także o określenie, jaką rolę pełni on w strukturze firmy. Ponieważ o wiele ważniejsze jest zrozumienie, w jaki sposób nieprawidłowo działająca jednostka współdziała z innymi, niż po prostu zrozumienie, dlaczego działa nieprawidłowo. Dlatego identyfikacja problemu zaczyna się od przestudiowania pracy firmy i opracowania jej modelu funkcjonalnego.
Często programiści proszeni są nie tylko o zidentyfikowanie i rozwiązanie problemu w pracy firmy, ale także o określenie, jaką rolę pełni on w strukturze firmy. Ponieważ o wiele ważniejsze jest zrozumienie, w jaki sposób nieprawidłowo działająca jednostka współdziała z innymi, niż po prostu zrozumienie, dlaczego działa nieprawidłowo. Dlatego identyfikacja problemu zaczyna się od przestudiowania pracy firmy i opracowania jej modelu funkcjonalnego.
Powiesz, że menedżer powinien mieć funkcjonalny model firmy, niezależnie od tego, o jakiej firmie mówimy. Ale, jak pokazuje praktyka, w większości przypadków ten model jest nieobecny.
Zaleta grafiki
Jakie są modele IDEF0? Schematy graficzne z własnymi cechami i zasadami ich budowy. Dlaczego grafika? Ponieważ jest skuteczna. Widać to na kilku przykładach.
Wyobraźmy sobie, że wojskowy plan działań wyjaśniano słowami, a nie za pomocą map z naniesionymi na nich znakami graficznymi. Teraz wydaje się to niemożliwe, ale do drugiej połowy XIX wieku tak właśnie było. Grafika pomaga zrozumieć to, co trudno wyjaśnić, a co za tym idzie, zrozumieć to, co trudne.
Tak samo jest z procesami biznesowymi: wiele zadań technicznych można ułożyć w postaci notacji graficznych, co znacznie uprości zadanie programistom i zaoszczędzi pieniądze klientów.
Korzyści z IDEF0 dlaTO-specjalistów
Aktywność programistów, czy to np. instalowanie CRM, czy tworzenie skutecznego ERP, wiąże się z wprowadzaniem zmian w już założonym systemie. Aby zrobić to dobrze, najpierw musisz przestudiować, jak działa ten system. Deweloper po jej przestudiowaniu pisze propozycję komercyjną, w której przedstawia swoją wizję sytuacji, działania niezbędne do rozwiązania problemu, a także oczekiwany rezultat. Taki dokument może zająć kilkanaście stron. Z jednej strony to dobrze, bo klient otrzymuje maksimum interesujących go informacji. Z drugiej strony studiowanie obszernego tekstu wymaga czasu, który odnoszący sukcesy biznesmen często nie.
Jak więc przekazać esencję w przystępny sposób bez uciekania się do obszernych tekstów? Grafika! To ona pozwala skrócić to, co jest napisane, wyraźnie pokazując niezbędne informacje. W końcu jeden obraz może zastąpić setki słów. A jeśli chodzi o wykorzystanie grafiki w opisie procesów biznesowych, to prawda w 100%.
Najpierw zrozummy, czym jest notacja i IDEF0 i do czego służą.
Notacja opisu procesu biznesowego: co to jest
Notacja to format, w którym procesy biznesowe są reprezentowane jako obiekty graficzne używane w modelowaniu i bezpośrednio reguły modelowania. Notacja to rodzaj języka graficznego, który pozwala wyobrazić sobie funkcjonowanie firmy, demonstrując powiązania między działami i oddziałami. Oznacza to, że notację można uznać za rodzaj języka programowania w inteligencji biznesowej.
IDEF0 to...
IDEF0 to funkcjonalna metoda modelowania, a także notacja graficzna używana do opisywania i formalizowania procesów biznesowych. Cechą IDEF0 jest to, że ta metodologia koncentruje się na podporządkowaniu obiektów. IDEF0 został opracowany dla automatyzacji przedsiębiorstw w 1981 roku w USA.
Model funkcjonalny firmy
Model funkcjonalny IDEF0 to bloki, z których każdy ma kilka wejść i wyjść. Każdy blok ma elementy sterujące i mechanizmy, wyszczególniające do wymagany poziom. W lewym górnym rogu jest najwięcej ważna funkcja. Łączy się z resztą strzałek i opisami bloków funkcyjnych. Każda strzała lub czynność ma swoje znaczenie. Dzięki temu taki model służy do opisu wszelkich procesów administracyjnych i organizacyjnych.
Rodzaje strzałek
w pudełku zadania są ustawione.
towarzyski wyświetlić wynik działania.
Menedżerowie(strzałki od góry do dołu) to mechanizmy kontrolne.
Mechanizmy(strzałki od dołu do góry) służą do wykonania niezbędnej pracy.
Podczas pracy z modelem funkcjonalnym przyjmowane są następujące zasady. Na przykład strzałki są nazwane rzeczownikami (reguły, plan itp.), Bloki - czasownikami (aby prowadzić ewidencję, zawrzeć umowę).
IDEF0 pozwala na wymianę informacji, natomiast ze względu na wszechstronność i widoczność uczestnicy wymiany z łatwością się zrozumieją. IDEF0 został starannie opracowany i ulepszony, z IDEF0 można pracować za pomocą różnych narzędzi, np. ERWIN, VISIO, Bussines studio.
IDEF0 ma również niezaprzeczalną zaletę. Technika ta została opracowana stosunkowo dawno temu i przez ponad trzy dekady była poddawana starannemu polerowaniu i dostosowywaniu. Dzięki temu możliwe jest szybkie i z minimalnym prawdopodobieństwem błędu stworzenie funkcjonalnego modelu firmy.
Oczywiście istnieją inne metodologie, więc dlaczego polecamy IDEF0? Możesz także odciąć kawałek metalowej rury piłą do metalu, ale widzisz, znacznie łatwiej jest to zrobić za pomocą szlifierki. Tak więc z IDEF0: nie ma bardziej funkcjonalnego narzędzia do modelowania, dzięki niemu możesz łatwo i szybko uzyskać pożądany wynik.
Jak powstaje model funkcjonalny
Przeanalizujmy tworzenie modelu funkcjonalnego na przykładzie pisania artykułu.
Jednostka główna będzie się nazywać „Pisanie artykułu”.
To, co jest potrzebne do napisania artykułu, znajduje odzwierciedlenie w nadchodzące strzały- „Doświadczenie”, „Dodatkowa literatura”.
Strzałki kontrolne za napisanie artykułu - „Plan artykułu”, „Wymagania dotyczące rejestracji”, „Zasady języka rosyjskiego”.
Mechanizmy to bezpośrednio sam autor, copywriter, redaktor, oprogramowanie. Jak zorganizowane są te mechanizmy? Autor tworzy tekst nagrywając jego wersję dźwiękową. Copywriter przenosi tekst do formatu tekstowego, skupiając się na planie publikacji, przestrzegając wymagań wydawcy i zasad języka rosyjskiego. Następnie redaktor zostaje podłączony do pracy, który sprawdza artykuł, poprawiając błędy w mowie, ortografii i interpunkcji. Oprogramowanie – to programy i narzędzia, z których uczestnicy procesu korzystali podczas tworzenia artykułu.
Wszystko to jest tylko ogólnym schematem pracy, więc musi być szczegółowe.
Wróćmy do naszego modelu i rozłóżmy wspólny blok na kilka połączonych ze sobą elementów.
Tak więc cały proces pisania artykułu można podzielić na 4 etapy:
- Przygotuj wersję audio.
- Przygotuj tekst do druku.
- Redakcja i przygotowanie tekstu do druku.
- Publikacja artykułu.
Schemat odzwierciedla informacje o tym, które elementy kontroli i mechanizmy są zaangażowane na jakim etapie. Na przykład, aby stworzyć tekst wysokiej jakości, autor używa własne doświadczenie i wiedzy, wykorzystuje plan publikacji i wymagania wydawcy jako wytyczne. Copywriter, tworząc wersję drukowaną tekstu, a redaktor, poprawiając go, kierują się regułami języka rosyjskiego. Aby opublikować artykuł, na przykład w publikacji online, wymagane jest specjalne oprogramowanie.
Przygotowując funkcjonalny model, performer skupia się na celu jego powstania i swoim punkcie widzenia.
Modelowanie funkcjonalne jest skutecznie wykorzystywane w tworzeniu różnych decyzje zarządcze. W naszym przykładzie procesu pisania artykułu mamy dwóch specjalistów – copywritera i redaktora. A przy niezbędnej optymalizacji finansowania projektu zgodnie ze schematem łatwo jest określić, jak to zrobić. Copywriter i korektor mają podobne metody pracy, więc całą pracę można zaoferować copywriterowi, ponieważ pracuje on bezpośrednio z tekstem audio, czego redaktor nie może zrobić. Jednocześnie copywriterowi można zaproponować wykonanie tej pracy za połowę kwoty przeznaczonej dla redaktora. Tak, może to spowodować utratę jakości tekstu, ale zadanie optymalizacji zostało zakończone pomyślnie. A zrobienie tego bez schematu wizualnego byłoby trudniejsze.
Proces tworzenia notacjiIDEF0
Istnieje wiele programów do tworzenia notacji. Niektóre przeznaczone są do tworzenia modeli funkcjonalnych, inne umożliwiają pracę z dowolnymi obiektami graficznymi. A komuś na pierwszym etapie wystarczy kartka, ołówek i gumka.
Przed przystąpieniem do opisu pracy firmy, czyli bezpośrednio do tworzenia notacji procesów biznesowych, należy zapoznać się z zasadami funkcjonowania firmy. W tym celu wywiad przeprowadza zewnętrzny specjalista. W pierwszej kolejności na pytanie odpowiada szef firmy, a następnie specjaliści nadzorujący kolejne etapy prac.
Efektem pierwszego etapu prac są dwa zapisy. Odzwierciedlamy procesy biznesowe w ich oryginalnej formie. Notacja ta zostanie stworzona na podstawie wyników rozmowy kwalifikacyjnej, a każdy szczegół musi być uzgodniony z szefem firmy i jej pracownikami. Niezwykle ważne jest, aby Twoje zrozumienie procesów biznesowych zachodzących w firmie odpowiadało rzeczywistości, wymaga to potwierdzenia na wszystkich poziomach.
Drugi zapis można nazwać „Tak, jak powinien”. Tworzony jest na podstawie pierwszego z wprowadzonymi zmianami zgodnie z zadaniem.
Standard IDEF0 i jego wymagania
Rozmawialiśmy nieco wyżej o podstawowych wymaganiach IDEF0.
- Główny element znajduje się w lewym górnym rogu.
- Każdy element musi mieć strzałki przychodzące i wychodzące. Ponadto strzały nadlatujące znajdują się po lewej stronie, po prawej - wychodzące.
- Elementy sterujące znajdują się na górze, mechanizmy znajdują się poniżej.
- Gdy na jednym arkuszu lub ekranie znajduje się kilka klocków, kolejne są umieszczane na prawo pod poprzednim.
- Schematy należy tworzyć tak, aby strzałki się przecinały minimalna ilość pewnego razu.
Błędy podczas pracy z IDEF0
Jak w każdej innej działalności, podczas modelowania funkcjonalnego zdarzają się błędy. Przeanalizujmy najbardziej typowe z nich.
Korzystanie z wielu kolorów
Należy pamiętać, że w modelowaniu funkcjonalnym wszystkie elementy są ważne, nie ma ważniejszych ani mniej ważnych. Podczas modelowania na papierze lub w jednym z programów komputerowych użytkownicy starają się uczynić diagram bardziej wizualnym, kolorując klocki i strzałki na różne kolory. Jednak w praktyce nie tylko nie czyni to diagramu bardziej wizualnym, ale wręcz przeciwnie, prowadzi do zamieszania i zniekształcenia percepcji przedstawionego.
Dlatego idealnym rozwiązaniem jest czarno-biały schemat bez użycia dodatkowych opcji kolorystycznych. Pomoże to nie tylko wyeliminować nieporozumienia, ale także bezpośrednio zdyscyplinować twórcę modelu, co korzystnie wpływa na czytelność i widoczność modelu.
Duża liczba bloków
Tworząc funkcjonalny model firmy, jej autorzy często starają się odzwierciedlić wszystko, nawet najdrobniejsze szczegóły. Okazuje się schemat z ogromną liczbą bloków i strzał. W efekcie zmniejsza się jego czytelność i widoczność.
Aby uniknąć tego błędu, użyj szczegółów, które pozostaną, aby zrozumieć problem. Szczegółowe detalowanie przygotowywane jest tylko wtedy, gdy jest to naprawdę potrzebne do rozwiązania ważnej kwestii.
Restrukturyzacja podczas naprawiania błędów
Podczas tworzenia diagramu ważne jest, aby żaden proces nie pozostał bez przychodzących, wychodzących lub innych ważne elementy. Na przykład, jeśli chcesz usunąć autora ze schematu, musisz usunąć wszystkie elementy i strzałki, które są z nim bezpośrednio powiązane. Jeśli pozostaną w schemacie, pojawią się nieporozumienia i zamieszanie, ponieważ podczas opisywania szczegółów doprowadzą do tego, że nikt nie wie gdzie.
Ta sama sytuacja ma miejsce po dodaniu bloku. Jeśli potrzebujesz wprowadzić jakieś informacje, sprawdź, czy nie podałeś niezbędnych atrybutów. Należy to uważnie monitorować, ponieważ przy modelowaniu złożonych procesów biznesowych nawet niewielka zmiana w jednej części pociągnie za sobą zmiany w drugiej.
Nazwa bloków i kontrolek
Zasady nazewnictwa elementów modelu są dość proste, ale niezwykle ważne jest, aby o tym pamiętać: strzałki sterujące to rzeczowniki, bloki to czasowniki. Ta zasada jest napisana w standardzie IDEF0, pomaga uniknąć zamieszania i błędów.
Korzyści z używania IDEF0
widoczność. Przedstawiając pracę firmy w formie diagramu, staje się jasne, jak działa firma, gdzie mogą pojawić się problemy i jak zapobiegać ich występowaniu.
Wzajemne zrozumienie, wykluczenie możliwości błędnej interpretacji schematu. Widoczność i dostępność modelu funkcjonalnego, który reprezentuje pracę firmy w postaci bloków i kontrolek, pomoże w rozmowach z kierownictwem o funkcjonowaniu firmy. Nawiasem mówiąc, w razie potrzeby tworzony jest słownik dla modelu funkcjonalnego, w którym gromadzone są wszystkie terminy i symbole. W ten sposób zminimalizowana jest możliwość nieporozumienia między Tobą a menedżerem, pracownikami firmy.
Prostota i oszczędność czasu podczas tworzenia modelu. Oczywiście, aby opanować metodykę modelowania funkcjonalnego, trzeba poświęcić dużo czasu. Przede wszystkim musisz nauczyć się prezentować ogromną ilość informacji w formie zwięzłego schematu, tj. być w stanie filtrować i kompresować dane źródłowe. Ale wysiłek i czas spędzony na szkoleniu z nawiązką się później opłaca. Rzeczywiście, stworzenie funkcjonalnego modelu i zaprezentowanie go w przystępny sposób nie zajmie dużo czasu.
Minimalna szansa na błąd. Praca zgodnie ze standardem IDEF0 wymaga ścisłego przestrzegania jego zasad. To dyscyplinuje wykonawcę i eliminuje możliwość popełnienia błędu. Ponadto wszelkie niezgodności z normą natychmiast stają się zauważalne.
I w końcu
Dwóch analityków biznesowych może mieć te same modele funkcjonalne tylko wtedy, gdy struktura firmy jest niezwykle prosta. W innych przypadkach modele będą się od siebie różnić. To naturalne, bo każdy analityk ma swoje specyficzne doświadczenie, własne rozumienie funkcjonowania firmy, własny punkt widzenia, jak rozwiązywać przydzielone mu zadania. Analityk biznesowy opracowuje model funkcjonalny z punktu widzenia menedżera, wyobraża sobie, jak rozwiązywałby zadania.
Naszym zdaniem narzędzie IDEF0 przyda się nie tylko profesjonalnym analitykom biznesowym, ale także tym, którzy bezpośrednio analizują swój biznes i dążą do budowania skuteczny system kierownictwo.
Opis diagramów procesów biznesowych „Rachunkowość sprzętu komputerowego przedsiębiorstwa”
Opis diagramu IDEF0
Do budowy procesu biznesowego wykorzystano diagram IDEF0. Metodologia IDEF0 nakazuje budowę hierarchicznego systemu diagramów - pojedynczych opisów fragmentów systemu. Najpierw dokonuje się opisu systemu jako całości i jego interakcji ze światem zewnętrznym (diagram kontekstowy). Zbudowano trzy poziomy diagramu:
1. Kontekstowe
2. Rozkład funkcjonalny
Rysunek 1 – Diagram kontekstowy „Rachunkowość technologia komputerowa przedsiębiorstwa"
Rysunek 1 przedstawia diagram kontekstowy procesu biznesowego „Rachunkowość sprzętu komputerowego przedsiębiorstwa”. Wyświetla system jako całość i jego interakcję z głównymi zewnętrznymi przepływami informacji.
Strzałki są wskazane na diagramie kontekstowym.
Rodzaje strzał:
wejście (materiały wejściowe: komputery i akcesoria)
wyjście (wyjściem jest raport)
strzałki kontrolne to dokumenty i głowice
strzałki mechanizmów to pracownicy i sprzęt
Informacje wejściowe do przetwarzania:
Komputery - komputery PC (komputery osobiste) znajdujące się w przedsiębiorstwie
Akcesoria - materiały niezbędne do modernizacji komputerów (karty graficzne, płyty główne, procesory, obudowy, zasilacze, moduły pamięci)
Strumienie wyjściowe:
Raport - gotowy raport z rozliczenia sprzętu komputerowego przedsiębiorstwa
Kontrola wejścia:
Reguły to warunki, które należy spełnić, aby osiągnąć cel.
Zamówienia - zadanie postawione przed przedsiębiorstwem (prowadzenie ewidencji sprzętu komputerowego w przedsiębiorstwie przy użyciu określonych systemów informatycznych)
Menedżerowie - dyrektorzy i dyrektorzy naczelni przedsiębiorstwa.
Zasoby wejściowe:
PC - komputery, na których prowadzona jest księgowość.
Pracownicy to specjaliści wykonujący polecenia zlecone przez kierownictwo. Po zbudowaniu modelu koncepcyjnego przeprowadzono dekompozycję funkcjonalną – system podzielono na podsystemy i każdy z podsystemów został opisany osobno (diagramy dekompozycji).
Rysunek 2 przedstawia rozkład funkcjonalny składający się z czterech miejsc pracy.
Rysunek 2 - Rozkład funkcjonalny „Rachunkowość sprzętu komputerowego przedsiębiorstwa”
Zidentyfikowano następujące rodzaje prac:
1) Rejestracja dostaw – proces, w którym przypisywany jest id towarowi wysłanemu na składowanie do magazynu oraz wprowadzane są do programu informacje o produkcie.
Siedem strzałek granicznych (wejście, sterowanie, mechanizm) wchodzi do pracy Ewidencja dostaw, a strzałka wewnętrzna gaśnie (połączenie przez wejście).
Strzałka na wejściu między pracą Rejestracja dostaw i Konserwacja komputera (komputera);
Strzałki wjazdu, wyjazdu, kontroli powtarzają się w kolejnych pracach.
2) Konserwacja komputerów - proces, w którym komputery są montowane, naprawiane i modernizowane.
Zadanie Konserwacja komputera obejmuje cztery strzałki graniczne (wejście, sterowanie, mechanizm, wyjście) i kilka strzałek wewnętrznych (połączenie przez wejście, Opinia przy wejściu).
Sterowanie strzałką - zasady, rozkazy, lider;
Strzałkowe połączenie przez wejście pomiędzy zakładami Utrzymanie i Aranżacja Komputera (wprowadzanie danych do bazy danych), pomiędzy zakładami Utrzymanie i Sprawozdawczość Komputera (wprowadzanie danych do bazy danych);
3) Aranżacja – proces, w którym następuje rozmieszczenie komputerów w biurach (urzędach).
Zarządzanie strzałami - zasady, rozkazy, lider;
Strzałka mechanizmu - pracownicy;
Łącze wejściowe strzałki między Aranżacją a Raportowaniem (przypisanie identyfikatora);
4) Sporządzenie raportu jest ostatnim etapem procesu księgowego, który polega na podsumowaniu ostatecznych wskaźników uzyskanych w wyniku wykonania dotychczasowych bieżących danych księgowych.
Każdy podsystem jest następnie dzielony na mniejsze dekompozycje i tak dalej, aż do osiągnięcia pożądanego poziomu szczegółowości.
Rysunek 3 jest schematem przedstawiającym bardziej szczegółowo działanie Odprawy Dostawy.
W wyniku uszczegółowienia zidentyfikowano główne funkcje. Sekcja „Przetwarzanie dostawy” zawiera siedem głównych strzałek (wejście, wyjście, sterowanie, mechanizm).
Strzałka wjazdowa - komputery i akcesoria;
Strzałki kontrolne to zasady, rozkazy i przywódca. rozgałęzione strzały;
Rozgałęzienia strzałek zębatych - PC, pracownicy;
Strzałki wejścia, kontroli, mechanizmów powtarzają się we wszystkich pracach.
1) Nadanie numeru - nadanie indywidualnego numeru komputerom i podzespołom.
Strzałki wejściowe - komputery i akcesoria. Komputery Arrow są powtarzane w kolejnych pracach, z wyjątkiem kompilacji raportu;
Strzałki kontrolne - zasady, rozkazy i lider;
Strzałki mechanizmu - PC i Pracownicy;
Strzałka powiązania przy wejściu pomiędzy pracą Nadanie numeru a Wysłanie towaru na magazyn (przeniesienie), pomiędzy "Nadanie numeru" a "Ustawienie na saldzie" (wprowadzenie do bazy danych);
2) Wysłanie towaru do magazynu – wysłanie towaru z nadanym numerem do magazynu.
Strzałka wyjścia - komputer;
Strzałki kontrolne - zasady, rozkazy i lider.
Link ze strzałką na wejściu pomiędzy pracą „Wysłanie towaru na magazyn” a „Ustawienie w bilansie” (ilość);
3) Wyciąg z salda – wprowadzanie informacji do komputera.
Strzałki kontrolne - zasady, rozkazy i lider;
Strzałki mechanizmu - PC i Pracownicy;
Rysunek 4 jest schematem szczegółowo przedstawiającym konserwację komputera.
W wyniku uszczegółowienia zidentyfikowano główne funkcje, które są wykonywane podczas procesu konserwacji komputera.
Prace konserwacyjne komputera obejmują 4 strzałki graniczne (wejście, wyjście, sterowanie, mechanizm). Strzałki wewnętrzne (informacje zwrotne na wejściu, komunikacja wejściowa).
1) Montaż komputerów - konfiguracja komputerów na indywidualne zamówienie kierowników.
Strzałka wjazdowa - komputery;
Strzałki kontrolne - zasady, rozkazy i lider;
Strzałki mechanizmu - Pracownicy;
Powiązanie strzałkowe według danych wejściowych między zadaniami: „Montaż komputerów” i „Naprawa komputerów” (komputer);
2) Naprawa komputerów - montaż komputerów dopuszczonych do ulepszenia.
Strzałka wjazdowa - komputery;
Strzałka wyjścia - wejście do bazy danych;
Strzałki kontrolne - zasady, rozkazy i lider;
Strzałki mechanizmu - Pracownicy;
Strzałki wejścia, wyjścia, kontroli, mechanizmu rozgałęziają się;
Powiązanie strzałki według danych wejściowych między zadaniami: „Naprawa komputera” i „Uaktualnienie” (komponenty);
3) Upgrade - ulepszanie, ulepszanie, aktualizowanie komputera.
Strzałka wyjścia - wejście do bazy danych;
Strzałki kontrolne - zasady, rozkazy i lider;
Strzałki mechanizmu - Pracownicy;
Strzałki kontroli, mechanizm rozgałęziają się;
Rysunek 5 przedstawia bardziej szczegółowo wykres raportowania. Dekompozycja pracy sprawozdawczej obejmuje 4 strzałki graniczne (wejście, wyjście, kontrola, mechanizmy). Strzałki wewnętrzne (informacje zwrotne na wejściu, komunikacja wejściowa).
W wyniku prac wyprowadzono następujące funkcje:
1) Zbieranie danych – zbieranie informacji do analizy i podejmowania decyzji.
Strzałka wejściowa - przypisanie identyfikatora;
Strzałki kontrolne - zasady, rozkazy i lider;
Strzałki wejścia, kontroli, mechanizmu rozgałęziają się;
Powiązanie strzałkowe według danych wejściowych między zadaniami: Zbieranie danych i Walidacja danych (rekordy);
2) Weryfikacja danych – weryfikacja informacji i przesłanie ich do raportowania.
Strzałka wejściowa - nadanie identyfikatora, wprowadzenie danych do bazy;
Strzałka wyjścia — raport;
Strzałki kontrolne - zasady, rozkazy i lider;
Strzałki mechanizmu — pracownicy, PC;
Strzałki wejścia (przypisanie id), kontrola, mechanizm rozgałęziają się;
Strzałka opinii na wejściu od „Walidacja danych” do „Zbieranie danych” (ponowna weryfikacja).
Opis wykresu DFD
Podział pracy „Konserwacja komputera” Rysunek 1 definiuje cztery prace wewnętrzne, dwie jednostki zewnętrzne i dwa magazyny danych.
Rysunek 1 — Konserwacja komputera
1) Montaż komputera – proces montażu komputera z istniejących podzespołów.
2) Sporządzenie raportu to proces, który polega na podsumowaniu ostatecznych wskaźników uzyskanych w wyniku wykonywania prac bieżącej rachunkowości.
3) Diagnostyka - kontrola wydajności
4) Upgrade - ulepszanie, ulepszanie, aktualizowanie komputera.
Podmioty zewnętrzne: komputery i komponenty
Magazyny danych:
1) Magazyn - miejsce, w którym przechowywane są zmontowane i zmodernizowane komputery.
2) DB - baza danych, w której przechowywane są wszystkie raporty i wszystkie informacje o wykonanej pracy.
Zbieramy informacje o komputerze i dobieramy komponenty do jego montażu. Następnie składamy komputer i wysyłamy do magazynu na przechowanie, ale dodatkowo po złożeniu możemy go najpierw wysłać do diagnostyki, sprawdzić sprawność, a potem już tylko na magazyn. Po zdiagnozowaniu zmontowanego komputera przesyłamy dane do sporządzenia raportu z wykonanej pracy i wprowadzamy informacje do Bazy Danych.
Mamy też inny podmiot zewnętrzny, to jest komputer. Wysyłamy go do modernizacji, a następnie do diagnostyki w celu sprawdzenia jego sprawności, następnie sporządzamy raport i wprowadzamy informacje o wykonanej pracy do Bazy Danych. Lub po modernizacji wysyłamy towar do magazynu, a następnie przeprowadzamy diagnostykę, sporządzamy raport i wprowadzamy informacje do Bazy Danych.
Dekompozycja pracy „Skompilowanie raportu” Rysunek 2 definiuje trzy prace wewnętrzne, trzy podmioty zewnętrzne i dwa magazyny danych.
1) Zbieranie danych - zbieranie informacji o komputerach i podzespołach.
2) Weryfikacja – sprawdzenie poprawności danych.
3) Raport - napisanie raportu z wykonanej pracy.
Podmioty zewnętrzne: komponenty, komputery, manager.
Hurtownia Danych - Dane o komputerach i komponentach, dane raportu.
Zbierz informacje o komputerach i komponentach, a następnie wyślij je do magazynu. Następnie sprawdzamy dane pod kątem poprawności, sporządzamy raport i ponownie wysyłamy go do przechowania do pierwszej hurtowni danych (rys. 2) lub wysyłamy dane raportu do drugiej hurtowni danych (rys. 2), a następnie do weryfikacji do kierownika .
Kierownik sprawdza, robi notatki, poprawki i wysyła do ponownego sprawdzenia. Następnie raport jest wysyłany do magazynu do czasu ponownego sprawdzenia przez kierownika.
Opis diagramów IDEF3
W dekompozycji pracy Computer Maintenance (ryc. 1) zdefiniowano kilka skrzyżowań, które łączą jedno lub więcej zadań, kilka zadań wewnętrznych.
1) Naprawa – montaż komputera z prefabrykowanych elementów
2) Montaż - przywrócenie komputera do normy
3) Upgrade - aktualizacja komputera
4) Komputery - towary po montażu i modernizacji
5) Wyślij do magazynu - po ulepszeniu (montażu) wyślij do magazynu
6) Diagnostyka - kontrola wydajności.
7) Raport - informacja o wykonanej pracy.
Skrzyżowanie - łączniki:
1) J2 - wszystkie akcje rozpoczynają się w tym samym czasie.
2) J6 – Przecięcie zbiegu. Węzeł, który gromadzi wiele strzałek w jedną, wskazując, że warunek zakończenia pracy źródła strzałek jest wymagany, aby proces mógł być kontynuowany.
3) J7 - pokazano, że warunki te nie mogą być spełnione jednocześnie.
4) J9 - te czynności kończą się w tym samym czasie, po czym sporządzany jest raport z wykonanej pracy.
Diagram IDEF3 pokazuje, że skrzyżowanie J2 ma dwie strzałki rozgałęziające dla pracy (montaż i aktualizacja), które rozpoczynają się w tym samym czasie. Dopiero po zakończeniu tych prac wychodzi gotowy produkt (komputer), łączy skrzyżowanie J6. Po tym następuje połączenie na skrzyżowaniu J7, z którego wynika, że dwa zlecenia (wysyłka towaru do magazynu i diagnostyka) nie mogą być wykonywane jednocześnie. Po zakończeniu dotychczasowych prac trwa proces sporządzania raportu z przeprowadzonych prac, który jest połączony skrzyżowaniem J9.
Cel:
- poznanie podstawowych zasad metodyki IDEF0,
- tworzenie nowego projektu w BPWin,
- tworzenie diagramu kontekstowego,
- tworzyć połączenia.
Opisywanie systemu za pomocą IDEF0 nazywamy modelem funkcjonalnym. Model funkcjonalny ma na celu opisanie istniejących procesów biznesowych, które wykorzystują zarówno języki naturalne, jak i graficzne. Aby przekazać informacje o konkretnym systemie, źródłem języka graficznego jest sama metodologia IDEF0.
Metodologia IDEF0 nakazuje budowę hierarchicznego systemu diagramów - pojedyncze opisy fragmentów systemu. Najpierw następuje opis systemu jako całości i jego interakcji ze światem zewnętrznym (diagram kontekstowy), po czym następuje dekompozycja funkcjonalna – system dzieli się na podsystemy i każdy z podsystemów jest opisywany osobno (diagramy dekompozycji) . Następnie każdy podsystem jest dzielony na mniejsze i tak dalej, aż do osiągnięcia wymaganego stopnia szczegółowości.
Każdy IDEF0-diagramy zawiera bloki i łuki. Bloki reprezentują funkcje symulowanego systemu. Łuki łączą bloki i wyświetlają interakcje i relacje między nimi.
Bloki funkcjonalne (prace) na diagramach są przedstawione za pomocą ramek, czyli nazwanych procesów, funkcji lub zadań, które występują w określonym czasie i mają rozpoznawalne rezultaty. Nazwa dzieła musi być wyrażona jako rzeczownik słowny oznaczający czynność.
IDEF0 wymaga, aby diagram zawierał co najmniej trzy i nie więcej niż sześć pól. Te ograniczenia utrzymują złożoność diagramów i modeli na poziomie, który można odczytać, zrozumieć i wykorzystać.
Każda strona bloku ma określony, dobrze zdefiniowany cel. Lewa strona bloku przeznaczona jest na wejścia, górna na sterowanie, prawa na wyjścia, dolna na mechanizmy. Takie oznaczenie odzwierciedla pewne zasady systemu: dane wejściowe są przekształcane w dane wyjściowe, limity kontrolne lub określają warunki wykonywania przekształceń, mechanizmy pokazują, co i jak wykonuje funkcja.
Bloki w IDEF0 są umieszczone w kolejności 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 diagramu. Na przykład najbardziej dominującym blokiem na diagramie może być albo pierwszy z wymaganej sekwencji funkcji, albo funkcja planowania lub sterowania, która wpływa na wszystkie inne.
Najbardziej dominujące pole jest zwykle umieszczane w lewym górnym rogu diagramu, a najmniej dominujące w prawym.
Układ bloków na stronie odzwierciedla autorską definicję dominacji. W ten sposób topologia diagramu pokazuje, które cechy mają większy wpływ na inne. Aby to podkreślić, analityk może przenumerować bloki zgodnie z ich kolejnością dominacji. Kolejność dominacji może być wskazana przez liczbę umieszczoną w prawym dolnym rogu każdego pola: 1 wskazuje najwyższą dominację, 2 następną i tak dalej.
Interakcja dzieł ze światem zewnętrznym i między sobą jest opisana w postaci strzałek przedstawionych pojedynczymi liniami ze strzałkami na końcach. Strzałki przedstawiają pewne informacje i są nazywane rzeczownikami.
Rodzaje strzałek
IDEF0 rozróżnia pięć rodzajów strzał.
wejście- przedmioty używane i przekształcane przez dzieło w celu uzyskania rezultatu (produktu). Dopuszcza się, aby praca nie miała strzałki wejściowej. Strzałka wejściowa jest rysowana jako wchodząca po lewej stronie zadania.
Kontrola-.informacje, które kontrolują działania pracy. Zazwyczaj strzałki kontrolne zawierają informacje wskazujące, jakie zadanie ma wykonać. Każde zadanie musi mieć co najmniej jedną strzałkę kontrolną, która jest pokazana jako wejście do górnej powierzchni zadania.
Wyjście- obiekty, na które konwertowane są wejścia. Każde zadanie musi mieć co najmniej jedną strzałkę wyjścia, która jest narysowana jako wychodząca z prawej strony zadania.
Mechanizm- Zasoby, które wykonują pracę. Strzałka mechanizmu narysowana jest jako wchodząca w dolne lico pracy. Według uznania analityka strzałki mechanizmu mogą nie być wyświetlane na modelu.
Dzwonić- specjalna strzałka wskazująca inny model pracy. Strzałka wywołania jest rysowana jako wychodząca z dołu pracy i służy do wskazania, że część pracy jest wykonywana poza symulowanym systemem.
Ryż. 2,1 Rodzaje strzałek
W metodologii IDEF0 tylko pięć rodzajów interakcji między blokami jest wymaganych do opisania ich relacji: sterowanie, wejście, sprzężenie zwrotne sterowania, sprzężenie zwrotne wejściowe, mechanizm wyjścia. Relacje kontroli i wejścia są najprostsze, ponieważ odzwierciedlają działania bezpośrednie, które są intuicyjne i bardzo proste.
Ryż. 2.2. Komunikacja wyjściowa
Ryż. 2.3. Komunikacja zarządcza
Zależność sterowania występuje, gdy wyjście jednego bloku bezpośrednio wpływa na blok o mniejszej dominacji.
Informacje zwrotne dotyczące sterowania i wejściowe informacje zwrotne są bardziej złożone, ponieważ są iteracyjne lub rekurencyjne. Mianowicie, dane wyjściowe z jednego zadania wpływają na przyszłe wykonanie innych zadań, które następnie wpłyną na pierwotne zadanie.
Następuje wtedy sprzężenie zwrotne sterowania; gdy wyjście jakiegoś bloku wpływa na blok z większą dominacją.
Relacje mechanizmu wyjścia są rzadkie. Odzwierciedlają sytuację, w której wynik jednej funkcji staje się środkiem do celu innej.
Ryż. 2.4. Wejściowa informacja zwrotna
Ryż. 2.5. Informacje zwrotne od kierownictwa
Relacje wynik-mechanizm są charakterystyczne dla alokacji źródeł zasobów (np. wymagane narzędzia, przeszkolony personel, przestrzeń fizyczna, sprzęt, fundusze, materiały).
W IDEF0 łuk rzadko przedstawia pojedynczy obiekt. Zwykle symbolizuje zbiór przedmiotów. Ponieważ łuki reprezentują kolekcje obiektów, mogą mieć wiele punktów początkowych (źródeł) i końcowych (miejsc docelowych). Dlatego łuki mogą się rozgałęziać i łączyć różne sposoby. Cały łuk lub jego część może wyjść z jednego lub więcej bloków i kończyć się jednym lub kilkoma blokami.
Rozgałęzienia łuków, przedstawione jako rozbieżne linie, oznaczają, że całość lub część zawartości łuków może pojawić się w każdej gałęzi. Łuk jest zawsze oznaczony przed gałęzią, aby nadać nazwę całemu zestawowi. Ponadto każda gałąź łuku może, ale nie musi być oznaczona zgodnie z następującymi zasadami:
- nieoznakowane gałęzie zawierają wagę obiektów określonych w etykiecie łuku przed rozgałęzieniem;
- gałęzie oznaczone za punktem rozgałęzienia zawierają wszystkie lub część obiektów określonych w etykiecie łuku przed rozgałęzieniem.
Scalanie łuków w IDEFO, pokazane jako linie zbiegające się ze sobą, wskazują, że zawartość każdej gałęzi tworzy etykietę dla łuku powstałego w wyniku scalenia oryginalnych łuków. Po scaleniu powstały łuk jest zawsze zaznaczany, aby wskazać nowy zestaw funkcji, który pojawił się po scaleniu. Ponadto każdy oddział może, ale nie musi być oflagowany przed scaleniem, zgodnie z następującymi zasadami:
Ryż. 2.6. Połączenie wyjście-mechanizm
- gałęzie bez etykiety zawierają wagę obiektów określonych we wspólnej etykiecie łuku po scaleniu;
- gałęzie zaznaczone przed scaleniem zawierają wszystkie lub niektóre z obiektów wymienionych we wspólnym znaku po scaleniu,
Analiza wykresu ilościowego
Aby przeprowadzić analizę ilościową wykresów, podajemy wskaźniki modelu:
- ilość bloków na schemacie - N;
- poziom dekompozycji diagramu - L;
- saldo wykresu - W;
- liczba strzałek połączonych z klockiem - ALE
Ten zestaw czynników dotyczy każdego diagramu modelu. Poniżej wymieniono zalecenia dotyczące pożądanych wartości współczynników wykresu.
Należy dążyć do tego, aby liczba bloków na diagramach niższych poziomów była mniejsza niż liczba bloków na diagramach macierzystych, czyli wraz ze wzrostem poziomu dekompozycji współczynnik malał. Wskazuje więc na to spadek tego współczynnika. że w miarę dekompozycji modelu funkcje powinny być uproszczone, a zatem liczba bloków powinna się zmniejszać.
Wykresy muszą być zrównoważone. Oznacza to, że w ramach jednego diagramu sytuacja pokazana na ryc. 2.7: praca 1 ma znacznie więcej strzałek przychodzących i kontrolnych niż strzałek wychodzących. Należy zauważyć, że rekomendacja ta może nie być realizowana w modelach opisujących procesy produkcji. Na przykład, opisując procedurę montażu, blok może zawierać wiele strzałek opisujących komponenty produktu, a jedna strzałka może wyjść - gotowy produkt.
Ryż. 2.7. Przykład niezrównoważonego wykresu
Wprowadźmy współczynnik równowagi wykresu
Konieczne jest dążenie do Ky było minimum dla wykresu.
Poza analizą elementy graficzne schematy, należy wziąć pod uwagę nazwy bloków. Aby ocenić nazwy, kompilowany jest słownik elementarnych (trywialnych) funkcji symulowanego systemu. W rzeczywistości funkcje niższego, poziomowego rozkładu diagramów powinny należeć do tego słownika. Na przykład dla modelu bazy danych funkcje „znajdź rekord”, „dodaj rekord do bazy” mogą być elementarne, natomiast funkcja „rejestracja użytkownika” wymaga dalszego opisu.
Po utworzeniu słownika i skompilowaniu pakietu diagramów systemowych należy wziąć pod uwagę niższy poziom modelu. Jeśli pokazuje zgodność między nazwami bloków diagramów i słowami ze słownika, oznacza to, że osiągnięto wystarczający poziom dekompozycji. Współczynnik, który ilościowo odzwierciedla to kryterium, można zapisać jako L*C- iloczyn poziomu modelu przez liczbę dopasowań nazw bloków do słów ze słownika. Im niższy poziom modelu (wyższy L), tym bardziej wartościowe mecze.
Zestaw narzędzi BPWin
Po uruchomieniu BPWin domyślnie pojawia się główny pasek narzędzi, paleta narzędzi i Eksplorator modelu.
Podczas tworzenia nowego modelu pojawi się okno dialogowe, w którym należy określić, czy model będzie tworzony od nowa, czy zostanie otwarty z repozytorium ModelMart, wpisać nazwę modelu i wybrać metodologię, w jakiej będzie budowany model ( Rys. 2.8).
Rys.2.8 Okno dialogowe tworzenia modelu
BPWin obsługuje trzy metodologie - IDEF0, IDEF3 i DFD. W BPWin możliwe jest budowanie modeli mieszanych, tj. model może zawierać jednocześnie diagramy IDEF0, IDEF3 i DFD. Skład palety narzędzi zmienia się automatycznie podczas przełączania z jednej notacji na inną.
Model w BPWin jest postrzegany jako zbiór działań, z których każda operuje na jakimś zestawie danych. Jeśli klikniesz lewym przyciskiem myszy dowolny obiekt modelu, pojawi się wyskakujące menu kontekstowe, którego każdy element odpowiada edytorowi jakiejś właściwości obiektu.
Przykład
Budowanie modelu systemu należy rozpocząć od przestudiowania wszystkich opisujących go dokumentów. funkcjonalność. Jednym z tych dokumentów jest SIWZ, czyli sekcje „Cel opracowania”, „Cele i zadania systemu” oraz „ Charakterystyka funkcjonalna systemy” .
Po przestudiowaniu dokumentów źródłowych oraz przeprowadzeniu wywiadów z klientami i użytkownikami systemu konieczne jest sformułowanie celu modelowania oraz określenie punktu widzenia na model. Rozważmy technologię jego budowy na przykładzie systemu „Służba zatrudnienia w ramach uczelni”, którego główne cechy zostały opisane w pracy laboratoryjnej nr 1.
Sformułujmy cel modelowania: opisanie funkcjonowania systemu w sposób zrozumiały dla jego użytkownika, bez wchodzenia w szczegóły związane z wdrożeniem. Zbudujemy model z punktu widzenia użytkowników (studenta, nauczyciela, administratora, dziekanatu, firmy).
Zacznijmy od zbudowania diagramu kontekstu IDEF0.Zgodnie z opisem systemu, główną funkcją jest obsługa jego klientów poprzez przetwarzanie żądań od nich. W związku z tym definiujemy jedyne zadanie diagramu kontekstowego jako „Obsługa klienta systemu”. Następnie definiujemy dane wejściowe i wyjściowe oraz mechanizmy i kontrolę.
Aby obsłużyć klienta konieczne jest jego zarejestrowanie w systemie, otwarty dostęp do bazy danych oraz przetworzenie jego zapytania. Danymi wejściowymi będą „nazwa klienta”, „hasło klienta”, „oryginalna baza danych”, „żądanie klienta”. Wykonanie żądania prowadzi albo do uzyskania informacji z systemu, albo do zmiany zawartości bazy danych (np. podczas kompilacji ekspertyz), więc wyjściem będą „raporty” i „zmodyfikowana baza danych”. Proces przetwarzania żądania będzie realizowany przez monitor systemu pod kontrolą administratora.
Diagram kontekstowy
W ten sposób definiujemy diagram kontekstowy systemu (rys. 2.9).
Rys 2.9. Diagram kontekstu systemu
Zdekomponujmy diagram kontekstowy opisując kolejność obsługi klienta:
- Ustalenie poziomu dostępu do systemu.
- Wybór podsystemu.
- Dostęp do podsystemu.
- Zmiana bazy danych (jeśli to konieczne).
Otrzymujemy schemat pokazany na ryc. 2.10.
Po zakończeniu dekompozycji diagramu kontekstowego przechodzą do dekompozycji diagramu następnego poziomu. Zwykle przy rozważaniu trzeciego i niższego poziomu modele powracają do diagramów nadrzędnych i poprawiają je.
Ryż. 2.10. Dekompozycja pracy „Serwis, klient systemu”
Rozkładamy kolejno wszystkie bloki powstałego diagramu. Pierwszym krokiem w określeniu poziomu dostępu do systemu jest określenie kategorii użytkownika. Po nazwie klienta przeprowadzane jest wyszukiwanie w bazie użytkowników, określając jego kategorię. Zgodnie z pewną kategorią doprecyzowano uprawnienia przyznane użytkownikowi systemu. Następnie przeprowadzana jest procedura dostępu do systemu, sprawdzająca nazwę dostępową i hasło. Łącząc informacje o uprawnieniach i poziomie dostępu do systemu, tworzony jest zestaw dozwolonych akcji dla użytkownika. Tym samym definicja poziomu dostępu do systemu będzie wyglądać tak, jak pokazano na rys. 2.11.
Ryż. 2.11. Dekompozycja pracy „Określenie poziomu dostępu do systemu”
Po przejściu procedury dostępu do systemu monitor analizuje żądanie klienta, wybierając podsystem, który będzie przetwarzał żądanie. Dekompozycja pracy „Odniesienie do podsystemu” nie odpowiada celowi i punktowi widzenia modelu. Użytkownik systemu nie jest zainteresowany wewnętrznymi algorytmami jego pracy. W tym przypadku ważne jest dla niego, aby wybór podsystemu dokonywał się automatycznie, bez jego ingerencji, więc dekompozycja wywołania do podsystemu tylko skomplikuje model.
Rozłóżmy na części pracę „Przetwarzanie żądania klienta”, wykonywaną przez podsystem przetwarzania żądań, określając kategorie i uprawnienia użytkowników. Przed wyszukaniem odpowiedzi na zapytanie należy otworzyć bazę danych (połączyć się z nią). Zasadniczo baza danych może znajdować się na zdalnym serwerze, więc może być konieczne nawiązanie z nią połączenia. Zdefiniujmy kolejność prac:
- Otwarcie bazy danych.
- Wykonanie wniosku.
- Generowanie raportów.
Po otwarciu bazy danych należy poinformować system o nawiązaniu połączenia z bazą danych, a następnie wykonać zapytanie i wygenerować raporty dla użytkownika (rys. 2.12).
Należy zauważyć, że „Realizacja wniosku” obejmuje pracę różnych podsystemów. Na przykład, jeśli wniosek zawiera testy, to zostanie ono wykonane przez podsystem testów zawodowych i psychologicznych. Na etapie realizacji zapytania może zajść konieczność zmiany zawartości bazy danych, np. podczas sporządzania ocen eksperckich. Dlatego konieczne jest zapewnienie takiej możliwości na schemacie.
Ryż. 2.12.
Dostosowanie wykresu
Analizując powstały diagram, pojawia się pytanie, według jakich reguł generowane są raporty? Konieczne jest posiadanie wstępnie utworzonych szablonów, które będą używane do wybierania z bazy danych, a szablony te muszą odpowiadać zapytaniom i muszą być predefiniowane. Dodatkowo klient powinien mieć możliwość wyboru formy raportu.
Poprawmy diagram dodając strzałki „Szablony raportów” i „Wnioski o zmianę bazy danych” oraz strzałkę tunelu „Klient systemu”. Zastosowano tunelowanie „Klienta Systemu”, aby nie umieszczać strzałki na górnym diagramie, ponieważ funkcja wyboru formularza raportu nie jest na tyle istotna, aby wyświetlić go na diagramie nadrzędnym.
Zmiana diagramu pociągnie za sobą dostosowanie wszystkich diagramów nadrzędnych (ryc. 2.13 - 2.15).
Wskazane jest zdekomponowanie pracy „Wykonanie zapytania” za pomocą diagramu DFD (praca laboratoryjna nr 3), ponieważ metodologia IDEF0 traktuje system jako zbiór powiązanych ze sobą prac, które słabo odzwierciedlają procesy przetwarzania informacji.
Ryż. 2.13. Dekompozycja pracy „Przetwarzanie wniosku klienta”
Ryż. 2.14. Dekompozycja pracy „Obsługa klienta systemu” (opcja 2)
Ryż. 2.15. Diagram kontekstowy systemu (opcja 2)
Przejdźmy do rozkładu ostatniego bloku „Zmiana bazy danych”. Z punktu widzenia Klienta systemy te znajdują się w jednej bazie danych. W rzeczywistości w systemie jest sześć baz danych:
- baza użytkowników,
- baza studentów, (Opcja 2)
- baza ofert pracy,
- baza postępów,
- testowa baza danych,
- DB ekspertyz,
- Podsumowanie bazy danych.
Zgodnie z celem modelowania ważne jest, aby klient zrozumiał, że otrzymane dane nie są natychmiast aktualizowane w systemie, ale przechodzą przez dodatkowy etap przetwarzania i kontroli. Algorytm zmiany można sformułować w następujący sposób:
- Określana jest baza danych, w której informacje będą zmieniane.
- Operator tworzy tymczasowy zbiór danych i udostępnia go administratorowi.
- Administrator kontroluje dane i wprowadza je do bazy danych.
Model ten można zaimplementować w inny sposób, dając możliwość aktualizacji bazy bezpośrednio na żądanie, z pominięciem procesu kontroli danych. W takim przypadku konieczne jest zapewnienie integralności bazy danych, aby uniknąć jej uszkodzenia. W takim przypadku schemat będzie wyglądał tak (ryc. 2.17).
Ryż. 2.16. Dekompozycja pracy „Zmiana bazy danych”
Ryż. 2.17. Dekompozycja pracy „Zmiana bazy danych” (opcja 2) Dla pierwszej opcji pokazanej na ryc. 2.12
Przeprowadzenie dalszej dekompozycji „Zmiany w bazie danych” skomplikuje model, wyjaśniając, w jaki sposób odbywa się fizyczna zmiana bazy danych w systemie. W takim przypadku użytkownik nie otrzyma żadnych Dodatkowe informacje o pracy systemu służb zatrudnienia. Dekompozycja tych prac powinna być przeprowadzona w procesie projektowania systemu bazodanowego na etapie tworzenia logicznego modelu bazy danych.
Dekompozycja pracy „Wykonanie zapytania” zostanie przeprowadzona w kolejnym laboratorium, ilustrującym wykorzystanie diagramów DFD do opisu procesów przetwarzania informacji.
Wydajmy analiza ilościowa modele pokazane na ryc. 2.12 i 2.13, zgodnie z metodą opisaną powyżej. Rozważ zachowanie współczynnika ^ dla tych modeli. Diagram nadrzędny „Przetwarzanie żądania klienta” ma współczynnik 4/2 = 2, a diagramy dekompozycji 3/3 = 1. Wartość współczynnika maleje, co wskazuje na uproszczenie opisu funkcji ze spadkiem poziomu modelu.
Rozważ zmianę współczynnika Kb w dwóch modelach.
dla drugiej opcji
Współczynnik Kb nie zmienia swojej wartości, dlatego saldo wykresu nie ulega zmianie.
Przyjmiemy, że poziom dekompozycji rozważanych diagramów jest wystarczający do odzwierciedlenia celu modelowania, a na diagramach niższego Poziomu jako nazwy prac używane są funkcje elementarne (z punktu widzenia użytkownika systemu) .
Podsumowując rozważany przykład, należy zwrócić uwagę na znaczenie rozważenia kilku opcji diagramów podczas modelowania systemu. Takie opcje mogą pojawić się podczas dostosowywania diagramów, jak miało to miejsce przy „Przetwarzaniu wniosku klienta” lub przy tworzeniu alternatywnych implementacji funkcji systemu (dekompozycja pracy „Zmiana bazy danych”). Uwzględnienie opcji pozwala wybrać najlepszą i uwzględnić ją w pakiecie diagramów do dalszego rozważenia.
pytania testowe
Lista Pytania bezpieczeństwa:
- Czym jest model w notacji IDEF0?
- Co oznaczają miejsca pracy w IDEF0?
- Jaka jest kolejność nazywania prac?
- Ile zadań powinno znajdować się na jednym diagramie?
- Jaki jest porządek dominacji?
- Jak układa się miejsca pracy zgodnie z zasadą dominacji?
- Do czego służą boki prostokątów roboczych na diagramach?
- Wymień rodzaje strzał.
- Nazwij typy relacji.
- Czym są strzałki graniczne?
- Wyjaśnij zasadę nazywania rozgałęzień i łączenia strzałek.
- Jakie metodologie wspiera BPWin?
- Wymień główne elementy głównego okna BPWin.
- Opisz proces tworzenia nowego modelu w BPWin.
- Jak łączyć pracę?
- Jak ustawić nazwę pracy.
- Opisz proces rozkładu pracy.
- Jak dodać pracę do schematu?
- Jak rozwiązać tunelowane strzały?
- Czy model BPWin może zawierać wiele diagramów metodologii?
Czy wiedziałeś,
co to jest eksperyment myślowy, eksperyment gedanken?
To nieistniejąca praktyka, nieziemskie doświadczenie, wyobrażenie tego, czego tak naprawdę nie ma. Eksperymenty myślowe są jak marzenia. Rodzą potwory. W przeciwieństwie do eksperymentu fizycznego, który jest eksperymentalnym testem hipotez, „eksperyment myślowy” w magiczny sposób zastępuje test eksperymentalny pożądanymi, niesprawdzonymi wnioskami, manipulując konstrukcjami logicznymi, które faktycznie naruszają samą logikę, wykorzystując nieudowodnione przesłanki jako udowodnione, czyli poprzez podstawienie. Tak więc głównym zadaniem wnioskodawców „eksperymentów myślowych” jest oszukanie słuchacza lub czytelnika poprzez zastąpienie rzeczywistego fizycznego eksperymentu jego „lalką” – fikcyjnym rozumowaniem warunkowym bez fizycznej weryfikacji.
Wypełnianie fizyki wyimaginowanymi „eksperymentami myślowymi” doprowadziło do powstania absurdalnego, surrealistycznego, mylącego obrazu świata. Prawdziwy badacz musi odróżnić takie „opakowania” od prawdziwych wartości.
Relatywiści i pozytywiści twierdzą, że „eksperyment myślowy” jest bardzo użytecznym narzędziem do testowania teorii (również powstających w naszych umysłach) pod kątem spójności. W tym oszukują ludzi, ponieważ weryfikacja może być przeprowadzona tylko przez źródło niezależne od przedmiotu weryfikacji. Sam wnioskodawca hipotezy nie może być testem własnego twierdzenia, ponieważ sam powód tego twierdzenia jest brakiem sprzeczności widocznych dla wnioskodawcy w oświadczeniu.
Widzimy to na przykładzie SRT i GTR, które stały się rodzajem religii rządzącej nauką i… opinia publiczna. Żadna ilość sprzecznych z nimi faktów nie może pokonać formuły Einsteina: „Jeśli fakt nie odpowiada teorii, zmień fakt” (W innej wersji „Czy fakt nie odpowiada teorii? – Tym gorzej dla faktu ").
Maksymalną wartością „eksperymentu myślowego” jest jedynie wewnętrzna spójność hipotezy w ramach własnej, często bynajmniej nie prawdziwej, logiki wnioskodawcy. Zgodność z praktyką tego nie sprawdza. Prawdziwy test może mieć miejsce tylko w prawdziwym eksperymencie fizycznym.
Eksperyment jest eksperymentem, ponieważ nie jest udoskonalaniem myśli, ale testem myśli. Myśl, która jest spójna sama w sobie, nie może się sprawdzić. Udowodnił to Kurt Gödel.
Giennadij Wiernikow
Obecnie w Rosji gwałtownie wzrosło zainteresowanie standardami zarządzania ogólnie przyjętymi na Zachodzie, jednak w praktyce zarządzania jest jeden bardzo istotny moment. Wielu przywódców wciąż może być zbitych z tropu bezpośrednim pytaniem: struktura organizacyjna firmy lub o schemacie istniejących procesów biznesowych. Najbardziej zaawansowani i regularnie czytający menedżerowie pism ekonomicznych z reguły zaczynają rysować hierarchiczne diagramy zrozumiałe tylko dla nich samych, ale w tym procesie zwykle szybko się zatrzymują. To samo dotyczy pracowników i kierowników różnych służb i jednostek funkcjonalnych. W większości przypadków jedynym zbiorem określonych zasad, zgodnie z którymi musi działać przedsiębiorstwo, jest zbiór odrębnych przepisów i opisy stanowisk pracy. Najczęściej dokumenty te powstały ponad rok temu, są słabo ustrukturyzowane i niepowiązane ze sobą, przez co po prostu kurzą się na półkach. Na razie takie podejście było uzasadnione, ponieważ w okresie kształtowania się rosyjskiej gospodarki rynkowej praktycznie nie było pojęcia konkurencji, nie było szczególnej potrzeby liczenia kosztów - zysk był gigantyczny. W rezultacie w ciągu ostatnich dwóch lat widzieliśmy całkiem zrozumiały obraz: duże firmy, które dorastały na początku lat 90., stopniowo tracą swoje pozycje, aż do całkowitego wycofania się z rynku. Wynika to po części z faktu, że w przedsiębiorstwie nie wprowadzono standardów zarządzania, całkowicie zabrakło koncepcji funkcjonalnego modelu działania i misji. Modelując różne obszary działalności, możliwe jest efektywne analizowanie „wąskich gardeł” w zarządzaniu i optymalizacja całego schematu biznesowego. Ale, jak wiadomo, w każdym przedsiębiorstwie tylko te projekty, które bezpośrednio generują zysk mają najwyższy priorytet, więc zazwyczaj chodzi o zbadanie działalności i jej reorganizację dopiero podczas odczuwalnego kryzysu w zarządzaniu firmą.
Pod koniec lat 90., kiedy rynek zaczął stawać się konkurencyjny, a rentowność przedsiębiorstw gwałtownie spadać, menedżerowie odczuwali duże trudności w próbach optymalizacji kosztów, aby produkty pozostały zarówno rentowne, jak i konkurencyjne. Właśnie w tym momencie wyraźnie ujawniła się potrzeba posiadania przed oczami modelu działania przedsiębiorstwa, który odzwierciedlałby wszystkie mechanizmy i zasady łączenia różnych podsystemów w ramach jednego przedsiębiorstwa.
Sama koncepcja „modelowania procesów biznesowych” weszła w życie większości analityków wraz z pojawieniem się na rynku złożonych produktów oprogramowania przeznaczonych do zintegrowana automatyka zarządzanie przedsiębiorstwem. Takie systemy zawsze wiążą się z dogłębnym, przedprojektowym badaniem działalności firmy. Wynikiem tej ankiety jest ekspertyza, w której w osobnych akapitach formułowane są rekomendacje eliminowania „wąskich gardeł” w zarządzaniu działaniami. Na podstawie tego wniosku, tuż przed wdrożeniem systemu automatyzacji, przeprowadzana jest tzw. reorganizacja procesów biznesowych, czasem dość poważna i bolesna dla firmy. Jest to oczywiście zespół, który rozwijał się przez lata, jest zawsze trudny do „myślenia w nowy sposób”. Takie kompleksowe badania przedsiębiorstw są zawsze złożone i różnią się znacznie w zależności od przypadku. Istnieją ugruntowane metodologie i standardy rozwiązywania takich problemów modelowania złożonych systemów. Standardy te obejmują rodzinę metodologii IDEF. Za ich pomocą można skutecznie wyświetlać i analizować modele działania szerokiej gamy złożonych systemów w różnych sekcjach. Jednocześnie o szerokości i głębokości badania procesów w systemie decyduje sam deweloper, co pozwala nie przeciążać stworzonego modelu niepotrzebnymi danymi. Obecnie do rodziny IDEF można przypisać następujące normy:
IDEF0 to funkcjonalna metodologia modelowania. Za pomocą wizualnego języka graficznego IDEF0, badany system jawi się programistom i analitykom jako zestaw powiązanych ze sobą funkcji (bloków funkcjonalnych - w ujęciu IDEF0). Zazwyczaj modelowanie IDEF0 jest pierwszym krokiem w nauce dowolnego systemu;
IDEF1 - metodyka modelowania przepływów informacji w systemie pozwalająca na wyświetlanie i analizę ich struktury i relacji;
IDEF1X (IDEF1 Extended) - metodyka budowania struktur relacyjnych. IDEF1X należy do metodologii typu Entity-Relationship (ER) i jest zwykle używany do modelowania relacyjnych baz danych odpowiednich dla danego systemu;
IDEF2 to metodologia dynamicznego modelowania ewolucji systemów. W związku z bardzo poważnymi trudnościami w analizie układów dynamicznych, z tego standardu praktycznie zrezygnowano, a jego rozwój wstrzymano na bardzo początkowym etapie. Jednak obecnie istnieją algorytmy i ich komputerowe implementacje, które umożliwiają przekształcenie zestawu statycznych diagramów IDEF0 w dynamiczne modele zbudowane w oparciu o „kolorowe sieci Petriego” (CPN - Color Petri Nets);
IDEF3 to metodyka dokumentowania procesów zachodzących w systemie, która jest wykorzystywana m.in. w badaniach procesy technologiczne w przedsiębiorstwach. IDEF3 opisuje scenariusz i kolejność operacji dla każdego procesu. IDEF3 ma bezpośredni związek z metodologią IDEF0 - każda funkcja (blok funkcjonalny) może być reprezentowana jako osobny proces za pomocą narzędzi IDEF3;
IDEF4 to metodologia budowania systemów obiektowych. Narzędzia IDEF4 umożliwiają wizualne przedstawienie struktury obiektów i podstawowych zasad ich interakcji, co pozwala analizować i optymalizować złożone systemy obiektowe;
IDEF5 to metodologia badań ontologicznych złożonych systemów. Stosując metodologię IDEF5, ontologia systemu może być opisana za pomocą pewnego słownika pojęć i reguł, na podstawie których można sformułować wiarygodne twierdzenia o stanie rozważanego systemu w pewnym momencie. Na podstawie tych stwierdzeń wyciągane są wnioski dotyczące dalszego rozwoju systemu i przeprowadzana jest jego optymalizacja.
W ramach tego artykułu rozważymy najczęściej stosowaną metodologię modelowania funkcjonalnego IDEF0.
Historia standardu 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 Teqnique). Kilka lat temu w Rosji ukazało się niewielkie wydanie książki o tym samym tytule, poświęconej opisowi podstawowych zasad konstruowania diagramów SADT. Historycznie, IDEF0 jako standard został opracowany w 1981 roku jako część obszernego programu automatyzacji przedsiębiorstwa przemysłowe, który nosił oznaczenie ICAM (Integrated Computer Aided Manufacturing) i został zaproponowany przez Departament Sił Powietrznych USA. Sama rodzina standardów IDEF odziedziczyła swoje oznaczenie z nazwy tego programu (IDEF=ICAM DEFINition). W procesie praktycznego wdrożenia uczestnicy programu ICAM stanęli przed koniecznością opracowania nowych metod analizy procesów interakcji w systemach przemysłowych. Jednocześnie, oprócz ulepszonego zestawu funkcji do opisu procesów biznesowych, jednym z wymagań nowego standardu była dostępność efektywnej metodologii interakcji w ramach „analityka-specjalisty”. Innymi słowy, nowa metoda miała zapewnić pracę grupową nad stworzeniem modelu, przy bezpośrednim udziale wszystkich analityków i specjalistów zaangażowanych w projekt.
W wyniku poszukiwań odpowiednich rozwiązań narodziła się metodyka modelowania funkcjonalnego IDEF0. Od 1981 r. standard IDEF0 przeszedł kilka drobnych zmian, w większości restrykcyjnych, a ostatnia wersja została wydana w grudniu 1993 r. przez Narodowy Instytut Standardów i Technologii Stanów Zjednoczonych (NIST).
Podstawowe elementy i koncepcje IDEF0
Graficzny język IDEF0 jest niezwykle prosty i harmonijny. Metodologia opiera się na czterech głównych koncepcjach.
Pierwszym z nich jest koncepcja Pudełka Aktywności. Blok funkcjonalny jest przedstawiony graficznie jako prostokąt (patrz rys. 1) i reprezentuje określoną funkcję w rozważanym systemie. Zgodnie z wymaganiami normy nazwa każdego bloku funkcjonalnego musi być sformułowana w trybie słownym (np. „produkować usługi”, a nie „produkować usługi”).
Każda z czterech stron bloku funkcjonalnego ma swoje specyficzne znaczenie (rolę), podczas gdy:
Każda jednostka funkcjonalna w ramach jednego rozważanego systemu musi mieć swój niepowtarzalny numer identyfikacyjny.
Rysunek 1. Blok funkcyjny.
Drugim „wielorybem” metodologii IDEF0 jest koncepcja łuku interfejsu (strzałki). Ponadto łuki interfejsu są często nazywane przepływami lub strzałami. Łuk interfejsu reprezentuje element systemu, który jest przetwarzany przez blok funkcyjny lub w inny sposób wpływa na funkcję wyświetlaną przez ten blok funkcyjny.
Graficzne przedstawienie łuku interfejsu to strzałka jednokierunkowa. Każdy łuk interfejsu musi mieć własną unikalną nazwę (Etykieta strzałki). Zgodnie ze standardem nazwa musi być obrotem rzeczownika.
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, wagony, pracownicy itp.) lub przepływy danych i informacji (dokumenty, dane, instrukcje itp.).
W zależności od tego, po której stronie zbliża się dany łuk interfejsu, nazywa się to „przychodzącym”, „wychodzącym” lub „sterującym”. Ponadto „źródło” (początek) i „odbiornik” (koniec) każdego łuku funkcjonalnego mogą być tylko blokami funkcjonalnymi, podczas gdy „źródłem” może być tylko strona wyjściowa bloku, a „odbiornik” może być dowolnym z pozostałych trzech.
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 przebiegać według jakichś reguł (wyświetlanych przez łuk sterujący) i musi dawać jakiś wynik (łuk wychodzący), inaczej jego rozpatrywanie nie ma sensu.
Podczas konstruowania IDEF0 - diagramów ważne jest, aby poprawnie oddzielić przychodzące łuki interfejsu od kontrolnych, co często nie jest łatwe. Na przykład Rysunek 2 przedstawia blok funkcyjny „Obróbka przedmiotu”.
W rzeczywistym procesie pracownik wykonujący obróbkę otrzymuje przedmiot obrabiany i instrukcje technologiczne dotyczące obróbki (lub przepisy bezpieczeństwa podczas pracy z maszyną). Może się błędnie wydawać, że zarówno przedmiot, jak i dokument z instrukcjami technologicznymi są obiektami wejściowymi, ale tak nie jest. W rzeczywistości w tym procesie obrabiany przedmiot jest przetwarzany zgodnie z zasadami odzwierciedlonymi w instrukcjach technologicznych, które powinny być odpowiednio zobrazowane przez łuk interfejsu sterującego.
Rysunek 2.
Inna sprawa, kiedy instrukcje technologiczne są przetwarzane przez głównego technologa i wprowadzane w nich zmiany (rys. 3). W tym przypadku są one już wyświetlane przez przychodzący łuk interfejsu, a obiektem kontrolnym są np. nowe standardy przemysłowe, na podstawie których wprowadzane są te zmiany.
Rysunek 3
Powyższe przykłady podkreślają pozornie podobny charakter łuków interfejsu przychodzącego i sterującego, ale zawsze istnieją pewne rozróżnienia dla systemów tej samej klasy. Na przykład w przypadku rozpatrywania przedsiębiorstw i organizacji istnieje pięć głównych typów obiektów: przepływy materiałowe (części, towary, surowce itp.), przepływy finansowe (gotówkowe i bezgotówkowe, inwestycje itp.), dokument przepływy (dokumenty handlowe, finansowe i organizacyjne), przepływy informacji (informacje, dane intencji, rozkazy ustne itp.) oraz zasoby (pracownicy, maszyny, maszyny itp.). Jednocześnie w różnych przypadkach przychodzące i wychodzące łuki interfejsu mogą wyświetlać wszystkie typy obiektów, które zarządzają tylko tymi związanymi z przepływem dokumentów i informacji, a tylko zasoby mogą być wyświetlane jako łuki-mechanizmy.
Obowiązkowa obecność łuków interfejsu sterowania jest jedną z głównych różnic między standardem IDEF0 a innymi metodologiami klas DFD (Diagram przepływu danych) i WFD (Diagram przepływu pracy).
Trzecią podstawową koncepcją standardu IDEF0 jest dekompozycja. Zasada dekompozycji jest stosowana, gdy złożony proces rozkłada się na funkcje składowe. W tym przypadku poziom szczegółowości procesu jest określany bezpośrednio przez twórcę modelu.
Dekompozycja pozwala na stopniowe i ustrukturyzowane przedstawienie modelu systemu w postaci hierarchicznej struktury poszczególnych diagramów, dzięki czemu jest on mniej przeciążony i łatwo przyswajalny.
Model IDEF0 zawsze zaczyna się od spojrzenia na system jako całość - pojedynczy blok funkcjonalny z łukami interfejsu wychodzącymi poza rozważany obszar. Taki diagram z jednym blokiem funkcyjnym nazywa się diagramem kontekstowym i jest oznaczony identyfikatorem „A-0”.
W tekście objaśniającym dla diagramu kontekstowego cel (Cel) skonstruowania diagramu w postaci krótki opis i stały punkt widzenia (Viewpoint).
Zdefiniowanie i sformalizowanie celu rozwoju IDEF0 – modele są niezwykle ważny punkt. W rzeczywistości cel określa odpowiednie obszary w badanym systemie, na których należy się skoncentrować w pierwszej kolejności. Na przykład, jeśli modelujemy działalność przedsiębiorstwa, aby budować w przyszłości w oparciu o ten model System informacyjny, wtedy model ten będzie znacząco różnił się od tego, który opracowalibyśmy dla tego samego przedsiębiorstwa, ale w celu optymalizacji łańcuchów dostaw.
Punkt widzenia wyznacza 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. Na przykład modele funkcjonalne tego samego przedsiębiorstwa z punktu widzenia głównego technologa i dyrektora finansowego będą się znacznie różnić w kierunku ich uszczegółowienia. Wynika to z tego, że ostatecznie dyrektora finansowego nie interesują aspekty przetwarzania surowców na maszynach produkcyjnych, a głównego technologa nie interesują wykreślone schematy przepływów finansowych. Właściwy dobór punktu widzenia znacznie skraca czas poświęcony na zbudowanie finalnego modelu.
W procesie dekompozycji blok funkcjonalny, który na diagramie kontekstowym przedstawia system jako całość, jest szczegółowo opisany na innym diagramie. Powstały diagram drugiego poziomu zawiera bloki funkcjonalne, które wyświetlają główne podfunkcje bloku funkcjonalnego diagramu kontekstowego i jest w odniesieniu do niego nazywany diagramem potomnym (diagram potomny) (każdy z bloków funkcjonalnych należących do diagramu potomnego jest odpowiednio nazywany blokiem podrzędnym - Child Box). Z kolei blok funkcjonalny – przodek nazywany jest blokiem nadrzędnym w stosunku do diagramu potomnego (Parent Box), a diagram, do którego należy – diagramem nadrzędnym (Parent Diagram). Każdą z podfunkcji diagramu potomnego można dodatkowo uszczegółowić za pomocą podobnej dekompozycji odpowiadającego jej bloku funkcjonalnego. Należy zauważyć, że w każdym przypadku dekompozycji bloku funkcjonalnego wszystkie łuki interfejsu zawarte w tym bloku lub wychodzące z niego są ustalane na diagramie potomnym. Osiąga to integralność strukturalną modelu IDEF0. Zasada dekompozycji jest wyraźnie pokazana na rysunku 4. Należy zwrócić uwagę na związek pomiędzy numeracją bloków funkcjonalnych a diagramami – każdy blok ma swój niepowtarzalny numer seryjny na diagramie (numer w prawym dolnym rogu prostokąta), a oznaczenie w prawym rogu wskazuje numer diagramu podrzędnego dla tego bloku. Brak tego oznaczenia wskazuje, że nie ma rozkładu dla tego bloku.
Często zdarzają się przypadki, w których dalsze rozważanie poszczególnych łuków interfejsu na diagramach podrzędnych poniżej pewnego poziomu w hierarchii nie ma sensu lub odwrotnie – poszczególne łuki nie mają praktycznego sensu powyżej pewnego poziomu. Na przykład łuk interfejsu przedstawiający „szczegóły” na wejściu bloku funkcyjnego „Process on”. tokarka" nie ma sensu zastanawiać się nad diagramami wyższych poziomów - to tylko przeciąży diagramy i utrudni ich odczytanie. Z drugiej strony może być konieczne pozbycie się poszczególnych "konceptualnych" łuków interfejsów i nie uszczegółowienie ich niż pewien poziom.Do rozwiązania takich problemów w standardzie IDEF0 przewidziano pojęcie tunelowania.Zapis „tunel” (Arrow Tunnel) w postaci dwóch nawiasów wokół początku łuku interfejsu wskazuje, że łuk ten nie został odziedziczony z blok funkcjonalny nadrzędny i pojawił się (z "tunelowego") dopiero na tym schemacie. zakręt, to samo oznaczenie wokół końca (strzałka) łuku interfejsu w bezpośrednim sąsiedztwie bloku odbiorczego oznacza, że łuk ten nie będzie wyświetlane i uwzględniane na diagramie potomnym tego bloku. łuki interfejsu nie są uwzględniane na niektórych pośrednich poziomach hierarchii - w t W takim przypadku najpierw „nurkują do tunelu”, a następnie, jeśli to konieczne, „wracają z tunelu”.
Ostatnim z pojęć IDEF0 jest Słownik. Dla każdego z elementów IDEF0: diagramów, bloków funkcyjnych, łuków interfejsu, istniejąca norma zakłada stworzenie i utrzymanie zestawu odpowiednich definicji, słów kluczowych, instrukcji narracyjnych itp., które charakteryzują obiekt wyświetlany przez ten element. Zestaw ten nosi nazwę glosariusza i jest opisem istoty tego elementu. Na przykład dla interfejsu sterującego łukiem „zlecenie płatnicze” słowniczek może zawierać listę pól odpowiadających łukowi dokumentu, wymaganego zestawu wiz itp. Słowniczek harmonijnie uzupełnia wizualny język graficzny, dostarczając diagramom niezbędnych informacji dodatkowych.
Rysunek 4. Dekompozycja bloków funkcjonalnych.
Zasady ograniczania złożoności diagramów IDEF0
Zazwyczaj modele IDEF0 przenoszą złożone i skoncentrowane informacje, a w celu ograniczenia ich przeciążenia i uczynienia ich czytelnymi, odpowiednie ograniczenia złożoności są przyjmowane w odpowiednim standardzie:
Ograniczenie liczby bloków funkcyjnych na schemacie do trzech do sześciu. Górna granica (sześć) zmusza projektanta do korzystania z hierarchii podczas opisywania złożonych tematów, a dolna granica (trzy) zapewnia, że odpowiedni diagram ma wystarczająco dużo szczegółów, aby uzasadnić jego utworzenie;
Ograniczenie liczby łuków interfejsu zbliżających się do jednego bloku funkcjonalnego (pozostawiając jeden blok funkcjonalny) do czterech.
Oczywiście nie jest konieczne ścisłe przestrzeganie tych ograniczeń, jednak jak pokazuje doświadczenie, są one bardzo praktyczne w prawdziwej pracy.
Dyscyplina Praca grupowa w sprawie rozwoju modelu IDEF0
Standard IDEF0 zawiera zestaw procedur, które pozwalają na opracowanie i zatwierdzenie modelu przez dużą grupę osób należących do różnych obszarów działalności modelowanego systemu. Zazwyczaj proces rozwoju jest iteracyjny i składa się z następujących kroków warunkowych:
Stworzenie modelu przez grupę specjalistów związanych z różnymi obszarami przedsiębiorstwa. Ta grupa nazywa się Autorami w terminach IDEF0. Budowanie modelu wyjściowego jest procesem dynamicznym, podczas którego autorzy pytają kompetentne osoby o strukturę różnych procesów. Na podstawie istniejących przepisów, dokumentów i wyników badań tworzony jest projekt (Model Draft) modelu.
Dystrybucja projektu do rozpatrzenia, zatwierdzeń i komentarzy. Na tym etapie projekt modelu jest omawiany z szerokim gronem kompetentnych osób (w zakresie czytelników IDEF0) 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ę z krytyką pisemną lub odrzuca ją ze stwierdzeniem logiki decyzji i ponownie zwraca poprawiony projekt do dalszego rozpatrzenia. Cykl ten trwa, dopóki autorzy i czytelnicy nie osiągną 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 pokazach i prezentacjach. W przyszłości w oparciu o zbudowany model można organizować nowe projekty mające na celu wprowadzenie zmian w przedsiębiorstwie (w systemie).
Specyfika krajowej praktyki stosowania modelowania funkcjonalnego za pomocą IDEF0
W ostatnie lata zainteresowanie w Rosji metodologiami rodziny IDEF stale rośnie. Ciągle to obserwuję, patrząc na statystyki odwiedzin mojej osobistej strony internetowej (http://www.vernikov.ru), która pokrótce opisuje podstawowe zasady tych standardów. Jednocześnie zainteresowanie takimi standardami jak IDEF3-5 nazwałbym teoretycznymi, aw IDEF0 całkiem praktycznie uzasadnionymi. Właściwie pierwsze narzędzia Case pozwalające na budowanie diagramów DFD i IDEF0 pojawiły się na rynku rosyjskim już w 1996 roku, równocześnie z wydaniem popularnej książki o zasadach modelowania w standardach SADT.
Jednak większość menedżerów nadal traktuje praktyczne zastosowanie modelowania w standardach IDEF bardziej jako hołd dla mody niż skuteczny sposób optymalizacja istniejący system zarządzanie przedsiębiorstwem. Wynika to najprawdopodobniej z wyraźnego braku informacji na temat praktyczne zastosowanie tych metodologii oraz z nieodzowną stronniczością oprogramowania w zdecydowanej większości publikacji.
Nie jest tajemnicą, że prawie wszystkie badania i analizy projektów finansowych i działalność gospodarcza przedsiębiorstwa w Rosji są teraz w taki czy inny sposób związane z budową systemy zautomatyzowane kierownictwo. W związku z tym standardy IDEF w rozumieniu większości stały się warunkowo nierozerwalnie związane z wdrożeniem Technologie informacyjne, choć z ich pomocą czasami udaje się skutecznie rozwiązać nawet drobne lokalne problemy, dosłownie ołówkiem i papierem.
Podczas prowadzenia złożonych projektów ankietowych przedsiębiorstw opracowanie modeli w standardzie IDEF0 pozwala wizualnie i skutecznie wyświetlić cały mechanizm działania przedsiębiorstwa w odpowiedniej sekcji. Najważniejsza jest jednak możliwość współpracy, którą zapewnia IDEF0. W moim zajęcia praktyczne było sporo przypadków, kiedy model został zbudowany przy bezpośredniej pomocy pracowników różnych działów. Jednocześnie konsultant w dość krótkim czasie wyjaśnił im podstawowe zasady IDEF0 i nauczył ich pracy z odpowiednią aplikacją. oprogramowanie. W efekcie pracownicy różnych działów stworzyli diagramy IDEF działań ich jednostki funkcjonalnej, które miały odpowiedzieć na następujące pytania:
Co wchodzi do jednostki „przy wejściu”?
Jakie funkcje iw jakiej kolejności są realizowane w obrębie jednostki?
Kto odpowiada za każdą funkcję?
Co kieruje wykonawcą w wykonywaniu każdej z funkcji?
Jaki jest wynik pracy jednostki (wynik)?
Po skoordynowaniu szkiców diagramów w ramach poszczególnych działów, konsultant składa z nich szkicowy model przedsiębiorstwa, w którym wszystkie elementy wejściowe i wyjściowe są połączone. Na tym etapie naprawiane są wszystkie niespójności poszczególnych diagramów i ich kontrowersyjne miejsca. Co więcej, ten model ponownie przechodzi działy funkcjonalne do dalszego zatwierdzenia i dokonania niezbędnych korekt. W efekcie w dość krótkim czasie i przy minimalnym zaangażowaniu zasoby ludzkie ze strony firmy konsultingowej (a te zasoby, jak wiadomo, są bardzo drogie) model IDEF0 przedsiębiorstwa uzyskuje się zgodnie z zasadą „tak jak jest” i co ważne reprezentuje przedsiębiorstwo z pozycji pracowników, którzy w nim pracują i dokładnie znają wszystkie niuanse, także te nieformalne. W przyszłości model ten zostanie przekazany do analizy i przetwarzania analitykom biznesowym, którzy będą szukać „wąskich gardeł” w zarządzaniu firmą i optymalizować główne procesy, przekształcając model „Jak jest” na odpowiedni „Tak jak powinno być”. reprezentacja. Na podstawie tych zmian formułowany jest ostateczny wniosek, który zawiera zalecenia dotyczące reorganizacji systemu zarządzania.
Oczywiście takie podejście wymaga szeregu działań organizacyjnych, przede wszystkim ze strony kierownictwa badanego przedsiębiorstwa. Wynika to z faktu, że technika ta polega na przypisaniu niektórym pracownikom dodatkowych obowiązków związanych z opracowywaniem i praktycznym stosowaniem nowych metodologii. Jednak w końcu to się usprawiedliwia, ponieważ dodatkowa godzina lub dwie godziny pracy poszczególnych pracowników w ciągu kilku dni może znacznie zaoszczędzić pieniądze na opłaceniu usług doradczych od firmy zewnętrznej (co w każdym razie przerwie pracę ci sami pracownicy z ankietami i pytaniami). Jeśli chodzi o samych pracowników przedsiębiorstwa, w swojej praktyce nie spotkałem się z żadnym wyraźnym sprzeciwem z ich strony.
Wniosek z tego wszystkiego można wyciągnąć w następujący sposób: absolutnie nie jest konieczne każdorazowe wymyślanie rozwiązań standardowych problemów. Zawsze, gdy stajesz przed koniecznością przeanalizowania konkretnego układu funkcjonalnego (od systemu projektowania statku kosmicznego po proces przygotowania złożonego obiadu) – korzystaj ze sprawdzonych i sprawdzonych przez lata metod. Jedną z tych metod jest IDEF0, która pozwala na wykorzystanie prostych i zrozumiałych narzędzi do rozwiązywania złożonych problemów życiowych.
