Cykl działa w tradycyjnym planowaniu i sterowaniu produkcj:

Transkrypt

1 Cykl działa w tradycyjnym planowaniu i sterowaniu produkcj:

2

3 Hierarchia planów i decyzji planistycznych Poziom planu Podmiot Horyzont Okres Typowe decyzje SOP-planowanie produkcji i sprzedaŝy MPS-główny harmonogram produkcji MRP-plan potrzeb materiałowych SFC-harmonogramy warsztatowe Rodzina produktów Produkt i harmonogram montaŝu Element 1-6 miesięcy Operacje techniczne 1-2 lata Kwartał, miesiąc 0,5-1 rok Miesiąc, tydzień 1-4 tygodni Tydzień, dzień Dzień, godzina Ilości do produkcji w kolejnych miesiącach Ilości do produkcji w kolejnych tygodniach Ilości elementów, terminy rozpoczęcia i zakończenia zleceń produkcji i zakupu Terminy rozpoczęcia i zakończenia poszczególnych operacji

4 Notacja diagramów DFD Obiekt Zewntrzny Obiekt zewntrzny powtórzony Magazyn Danych Proces Proces (powtórzony) Magazyn danych (powt)

5 Klient zamówienie 1 Przyjmowanie zamówie zamów. Zamówienia zoone Katalog odrzucenie 2 zamówienie Sprawdzenie poprawnoci dane o wyrobie zam. Zamówienia poprawne zam. Klient faktura 3 Fakturowanie dane o wyrobie Katalog Faktury kopia faktury Diagram DFD systemu obsługi zamówie

6 Systemy ERP: ERP Najczęściej spotykane moduły to: sprzedaŝ i dystrybucja serwis raporty administracja personelem finanse wytwarzanie ewidencja i zaopatrzenie. W przedsiębiorstwie produkcyjnym zakres modułów moŝe wyglądać następująco: rejestr główny (utrzymuje dane finansowe przedsiębiorstwa) rejestr sprzedaŝy (obejmuje rejestr odbiorców, dane o wystawianych dokumentach sprzedaŝy i związanych z nimi płatnościach) rejestr zakupów (umoŝliwia zarządzanie zobowiązaniami, wynikającymi z zakupów towarów i usług) środki trwałe (obejmuja zarządzanie procesami związanymi z obsługą finansową środków trwałych) gospodarka materiałowa (obejmuje dane o kaŝdym materiale, surowcu, produkcie, towarze, umoŝliwiając zarządzanie zasobami magazynowymi) obsługa zakupów (wspomaga cykl zakupów od zamawiania łącznie z ewentualnymi kontaktami długookresowymi i automatycznym ponawianiem zamówień; od przyjęcia o magazynu po rozliczenie dostawy z fakturą) obsługa sprzedaŝy (oznacza wsparcie od rejestracji zamówień przez klienta łącznie z ewentualnymi kontraktami długookresowymi; przez dokumentację magazynową, po wystawienie faktury oraz obsługę zwrotów i reklamacji z wystawieniem faktury korygującej) planowanie ogólne działalności (z tworzeniem planów produkcji, zakupów, transportu, potrzeb dystrybucyjnych i kontrolą sieci dystrybucyjnej włącznie) zarządzanie bazą danych produkcyjnych (obejmuje bazę danych o materiałach, półproduktach, produktach, metodach wytwarzania stanowiskach roboczych, operacjach i narzędziach, umoŝliwiając tworzenie i modyfikację specyfikacji materiałowych i procesów technologicznych) wspomaganie produkcji(zawiera analizy zarzadzania stanowiskami roboczymi, strumieniem ich zadań oraz zapasami w toku produkcji łącznie z kontrolą produkcji o stanie realizacji zleceń, wydanych materiałach i obciąŝeniu stanowisk roboczych obejmującą system jakości) planowanie zdolności produkcyjnych (obejmuje obliczanie obciąŝeń kaŝdego stanowiska pracy w podziale na okresy z uwzględnieniem stanu robót w toku i zleceń, co umoŝliwia korygowanie i bilansowanie zdolności produkcyjnych) zarządzanie zasobami ludzkimi(zawiera ewidencję pracowników i obliczanie płac wraz ze świadczeniami socjalnymi i szkoleniami) Strona 1

7 ERP elektroniczna wymiana danych (równieŝ z systemami firm kooperujacych) analizy i raporty (analizy sprzedaŝy, prognozowanie popytu, symulacje itp.) Systemy ERPII są zorientowane na integrację zewnętrzną (z dostawcami i klientami) wspomagaja łańcuchy dostaw. Strona 2

8 Podstawowe systemy w firmie handlowej: 1. Wspomagajcy obrót towarów: Zakup towarów Sprzeda towarów Obsługa zamówie System magazynowy 2. Wspomagajcy działalno firmy Relacje z klientami (CRM) System analityczny (bazy analityczne, raportowanie) 3. Wspomagajcy zarzdzanie firm System finansowo-ksigowy (ksika przychodów i rozchodów, ksigi handlowe, rozrachunki z kontrahentami, obsługa kasowa, rodki trwałe, kadrypłace) System wspomagajcy zarzdzanie (MIS) 1. Podsystem zakupów: Zakup i sprzeda towarów: Rejestracja zakupów (wprowadzanie danych o zakupach z faktur obcych) Emisja dowodów przychodu do magazynu Rejestracja faktur korygujcych Wystawianie zamówie na towary do dostawców Prowadzenie kartoteki dostawców Przygotowanie (np. agregacja) i eksport danych o wartoci przychodów towarów do systemu ksigowego Przygotowanie i eksport danych o fakturach zakupu (zobowizania, naliczony podatek VAT) do systemu ksigowego Drukowanie rejestru VAT zakupu Generowanie rónego rodzaju zestawie o zakupach wg dostawców i towarów 2. Podsystem sprzeday Rejestracja zamówie od odbiorców Wystawianie faktur sprzeday Polecenia wydania z magazynu Wystawianie faktur korygujcych Prowadzenie kartoteki odbiorców Przygotowanie i eksport danych o fakturach sprzeday do systemu ksigowego Drukowanie rejestru faktur sprzeday Generowanie zestawie o sprzeday wg odbiorców i wg towarów

9 Planowanie działalnoci gospodarczej BIZNESPLAN Planowanie sprzeday Poziom strategiczny Planowanie rozwoju wyrobów Planowanie produkcji i usług Głowny harmonogram Poziom taktyczn Planowanie zasobów materiałowych MRP1 Planowanie zdolnoci produkcyjnych Poziom operacyjny Sterowanie zakupami Sterowanie wytwarzaniem iloci i jakoci wyrobów Sterowanie zapasami i przetwarzaniem czynników produkcji Sterowanie dystrybucj Poziom strategiczny Inne informacje wew. i zew. firmy System sterowania: -iloci i jakoci wyrobów, *finansami firmy *kosztami produkcji

10

11 Normy IDEF Historia IDEF W latach 1970 Departament obrony USA opracował norm przebiegu procesu IDEF0 (Integration DEFinition Language0). Norma IDEF0 była stosowana jako narzdzie tworzenia programów komputerowych wspomagajcych procesy produkcyjne. Nastpnie przyjła si jako narzdzie umoliwiajce sporzdzenie mapy procesów w firmach usługowych i produkcyjnych. Normy IDEF wykorzystywane s równie do tzw. inynierii biznesu, obejmujcej reengineering i Bussines Process Reengineering. Rodzina IDEF IDEF0 technika uywana do tworzenia modelu funkcjonalnego. Prezentuje struktur funkcji, procesów lub czynnoci w ramach modelowanego systemu lub obszaru, IDEF1- technika uywana do tworzenia modelu informacyjnego. Prezentuje struktur i charakter zalenoci midzy wyraeniami a obiektami, do których si odnosi w ramach modelowanego systemu lub obszaru. Została ona rozszerzona take o zagadnienia projektowania i powstała technika, IDEF1X, IDEF2 technika uywana do tworzenia modelu dynamicznego. Prezentuje zmiany zachowa modelu procesu, systemu lub obszaru w czasie. IDEF3 technika opisu procesów, IDEF4 technika projektowania obiektowego, IDEF5 technika opisu ontologii (opis i strukturalizacja rzeczywistoci), IDEF6 technika opisu koncepcji projektu (racjonalne projektowanie), IDEF7 technika audytu systemów informatycznych, IDEF8 technika projektowania interakcji człowiek system, IDEF9 technika wykrywania wizów biznesu, IDEF10 technika implementacji modelu architektury (Implementation Architecture Modeling), IDEF11 technika modelowania informacji (Information Artifact Modeling),

12 IDEF12 technika modelowania organizacji (Organization Modeling), IDEF13 technika projektowania map w schemacie drzewa (Tree Schema Mapping Design), IDEF14 technika projektowania sieci (network design). Najczciej stosowane s techniki IDEF0 i IDEF3. IDEF0 IDEF0 modeluje decyzje, działania oraz działalno organizacji lub systemu, w celu pokazania sposobu jego funkcjonowania. Modele IDEF0 s tworzone jako jedno z pierwszych zada w kierunku rozwoju systemowego, poniewa opisuj one: funkcje, które s wykonywane, oraz narzdzia potrzebne do wykonania tych funkcji. Głównym celem normy IDEF0 jest pomoc w ustaleniu zakresu analizy oraz zbudowanie relacji pomidzy analitykiem a klientem. IDEF0 moe by wykorzystywane zarówno jako narzdzie komunikacji, za spraw znormalizowanych symboli graficznych, jak i jako narzdzie analizy ukazujce, jakie czynnoci maj by wykonane w celu prawidłowego zamodelowania procesu. Norma IDEF0 pomaga równie w ustaleniu słabych i mocnych stron modelowanego systemu. Norma ta wykorzystuje dwa graficzne elementy, których połczenie tworzy kostk kostki - reprezentujce funkcje (procesy, systemy), posiadajce nazw i numer, strzałki - które s obiektami obustronnych relacji midzy funkcjami, i okrelaj informacj lub materiały: strzałka wejcia (Input) nakłady materiałowe i informacyjne, strzałka wyjcia (Output) efekty wykonania: materialne i informacyjne, strzałka sterowania (Control) mechanizmy sterowania funkcj np. wewntrzna polityka firmy, czynniki zewntrzne, strzałka mechanizmu (Mechanism) mechanizmy niezbdne do wykonania I Input (wejscie) funkcji np. narzdzia, pojazdy, wykonawcy. C Control (Sterowanie) Nazwa funkcji (procesu, systemu) O Output (wyjscie) M Mechanisms (mechanizmy)

13 Zbudowane modele mog składa si z wielu funkcji (kostek), które połczone s ze sob za pomoc strzałek. Wyjcia jednej funkcji (kostki) mog by wejciami lub mechanizmami sterowania dla innych funkcji (kostki). Norma ta umoliwia równie współbiene wykonywanie dwóch lub wikszej iloci funkcji w sytuacji, gdy wyjcie jednej funkcji jest wejciem dla kilku innych funkcji. Kada funkcja moe by opisana przez osobny podrzdny model. Kostk moemy podzieli na dwa typy : kostka rodzic, której detale przedstawione s na poziomie niszym, kostka dziecko, która przedstawia szczegóły (detale) kostki rodzic. Diagram rodzic Kostka rodzic Diagram dziecko Kostka dziecko A-0 A0 Bardziej ogólnie A1 A2 A3 A4 Bardziej szczegółowo A0 Hierarchiczna struktura diagramu IDEF0 Zasady IDEF0 Główne zasady normy IDEF0 to: 1. zwizło, dziki której w sposób zrozumiały opisuje przepływ pracy w przedsibiorstwie, 2. komunikatywno, dziki której prezentuje procesy na kadym poziomie złoonoci. W wyniku zastosowania normy IDEF0 otrzymujemy zestaw hierarchicznych serii diagramów tekstu i objanie przepływu pracy w przedsibiorstwie. Rozróniamy dwa typy diagramów: diagram rodzic i diagram dziecko bdcym rozwiniciem kostki

14 rodzic. Nota indeksu lokalizuje funkcj (proces) w hierarchicznej strukturze diagramu. Numer indeksu okrela dokładnie, do jakiej głównej funkcji (procesu) naley dana podfunkcja (podproces). Norma IDEF0 szczegółowo i precyzyjnie opisuje sposób umieszczania funkcji, strzałek i ich opisów. Kada funkcja, strzałka i model opisane s przez nadany zgodnie z norm identyfikator. Model główny IDEF0 oznaczony jest symbolem A-0 (A-0) i znajduje si w nim jedna, nadrzdna funkcja A0. Moe by ona opisana przez model A0. Funkcje które si w nim znajd bd nosi oznaczenia A1, A2, A3, itd. Model podrzdny, opisujcy funkcj A1, bdzie równie oznaczany jako A1, a funkcje które si w nim si znajduj symbole A11, A12, A13, itd. Ten usystematyzowany sposób opisu umoliwia szybsze stworzenie spisu poszczególnych modeli i funkcji. Zalenoci midzy modelami podrzdnymi i nadrzdnymi mona równie pokaza graficznie za pomoc drzewa hierarchii funkcji: w jednym diagramie moe wystpi do szeciu podfunkcji (podprocesów). Zwiksza to przejrzysto diagramu, tekst wspomagajcy diagram (glosariusz), zwiksza precyzj graficznej prezentacji, proces główny jest rozpisywany na niszym poziomie na podprocesy. 3. precyzyjno wykorzystuje opracowane normy: nie mona opuszcza lub dodawa kostek. Kady proces powinien by powizany ze swoim poprzednikiem i nastpnym procesem, nazwy procesu oraz noty indeksów diagramu powinny by niepowtarzalne, strzałki musz by nazwane lub oznaczone (strzałki oznaczone nie koresponduj ze sob w diagramach rodzic-dziecko), wystpuje moliwo rozgałzienia strzałek - rozłczenie lub połczenie oraz oznaczenie strzałek niekorespondujcych ze sob w diagramach rodzic dziecko. 4. metodologia modelowanie i przedstawienie przepływu pracy realizowane jest krok po kroku. a Rozgałzienia strzałek. (a.) rozłczenie, (b.) połczenie. b

15 Grafika rozgałzie strzałek A Grafika A Interpretacja A znaczy A znaczy A A A B znaczy A B A A A A A&B B znaczy B Interpretacja grafiki rozgałzie strzałek Korespondencja diagramów Przykład 1. Korespondencja diagramów: Diagram rodzic 1 ( ) 2 Diagram dziecko 3 A1 I1 C1 1 C3 Strzałka sterownika C2 nie koresponduje z diagramem dziecko 2 3 ( ) O1 Strzałka wyjcia nie koresponduje z diagramem rodzic A12 Przykład korespondencji diagramów Norma IDEF0 zawiera równie szereg zalece dotyczcych odpowiedniego sposobu tworzenia modelu, zbierania potrzebnych do jego sporzdzenia danych oraz oceny

16 zbudowanego modelu. Implementacj normy IDEF0 umoliwiaj róne narzdzia informatyczne. IDEF1- Metoda Modelujca Informacj Norma IDEF1 została zaprojektowana jako metoda zarówno dla analizy oraz jako narzdzie komunikacji. Uywana jest w celu: identyfikacji, jak informacj aktualnie zarzdzamy w organizacji, ustalenia, który z problemów zidentyfikowanych podczas analizy spowodowany jest brakiem zarzdzania odpowiedni informacj, wyszczególnienia, jak informacja bdzie zarzdzana, czyli zestaw reguł zarzdzania informacj. IDEF1 wykorzystuje istniejc informacj o przedmiotach w zakresie przedsibiorstwa. Norma IDEF1 została zaprojektowana jako metoda analizy, zarzdzaniem informacj oraz wymaganiami przedsibiorstwa. Została zidentyfikowana za pomoc kilku zasad: 1. zebranie informacji, zachowanie, zarzdzanie w przedsibiorstwie, 2. reguły zarzdzania informacj, 3. zastanowienie si nad logicznymi zalenociami i relacjami pomidzy informacjami, 4. problemy bdce skutkiem braku dobrego zarzdzania informacj. W wyniku analizy, informacja moe zosta uyta do strategicznych oraz taktycznych planów przedsibiorstwa, w celu osignicia przewagi konkurencyjnej. Plany te mog zawiera projektowanie oraz wprowadzenie zautomatyzowanego systemu, który moe skuteczniej skorzysta z dostpnej informacji. Zasady IDEF1 IDEF1 uywa prostych graficznych konwencji by wyrazi obszerny komplet reguł, które pomagaj modelowa rónice pomidzy: obiektem rzeczywistym, fizycznymi lub abstrakcyjnymi powizaniami z rzeczywistymi obiektami, zarzdzan informacj o rzeczywistym obiekcie, struktur danych reprezentowanych przez informacj w celu zdobywania, zastosowania i zarzdzania t informacj.

17 IDEF1 dostarcza kompletu reguł, procedur oraz wskazówek dla rozwoju modeli informacji. Jednym z celów IDEF1 jest dostarczenie gotowego procesu do analizy zarzdzania informacj w przedsibiorstwie. Cel ten osigany jest przez rozwój procesu zdefiniowanego w metodzie oraz przez skutki i nakazy okrelone przez t metod. IDEF1 pojcia Funkcjonuj dwa najwaniejsze pojcia w modelowaniu wymaga informacji. Pierwsze dotyczy wiata rzeczywistego w odczuciu ludzi pracujcych w przedsibiorstwie. Obejmuje ono fizyczne i obiektowe pojcia (ludzie, miejsca, rzeczy, pomysły), ich wzajemne zalenoci i relacje. Drugie natomiast obejmuje pojcie informacji, która zawiera obraz informacji w odniesieniu do wiata rzeczywistego. Obraz informacji nie jest dokładnym odzwierciedleniem informacji w rzeczywistym wiecie, lecz jest informacj, któr mona zebra, zachowa i zarzdza. IDEF1 jest zaprojektowany, aby wspomaga organizacj, zarzdzanie i dokumentacj tych obrazów informacji. W ten sposób jest ograniczony tylko do pojcia informacji. Jednostki IDEF1 reprezentuj informacj utrzyman w okrelonej organizacji fizycznej lub konceptualnej przedmiotu. Istniej dwa podstawowe pojcia okrelajce jednostki: jednostki s stałe organizacja wydaje swoje zasoby by obserwowa, zapisywa, organizowa i składowa istniejce jednostki, jednostki mog by pojedyncze jednostki mog by zidentyfikowane jako unikatowe w porównaniu z innymi jednostkami, Jednostki maj charakterystyczne atrybuty powiza. Zbiór jednego lub wicej atrybutów klasy, które wyróniaj jednego członka jednostki klasy od innych, nazywamy kluczem klasy. Relacja w IDEF1 wie dwa indywidualne obrazy informacji. Z uwagi na to, e atrybuty klasy jednej jednostki zawieraj atrybuty klasy innej jednostki, które odnosz si do zalenoci midzy nimi, moemy stwierdzi, e istnienie relacji jest znane. Relacja klas moe wystpowa jako forma powiza istniejcych jednostek klas. Przykładem relacji IDEF1 moe by etykieta pracuje dla w połczeniu z jednostk informacji pracownik oraz dział. Jeli informacja nie jest powizana z dwoma lub wicej obiektami rzeczywistymi, wtedy z punktu widzenia IDEF1, informacja nie istnieje. Relacje midzy klasami s reprezentowane na diagramach IDEF1 poprzez połczone kostki jednostek klas. Kostka ma na kocu połczenie oraz zawiera dodatkow informacj o relacji klas (liczebnik główny zalenoci).

18 DZIAŁ# Dział Liczebnik główny zalenoci Klucz klasy Atrybuty klasy { { 1 * (_PRACOWNIK#) WYPŁATA DZIAŁ# Pracuje dla/zatrudnienie Powizanie klas Etykieta powizania Kostka klasy Pracownik Nazwa klasy Diagram IDEF1 IDEF1 jest efektywn metod dokumentujc informacj na temat wymaga przedsibiorstwa. IDEF1 wykorzystuje dostarczone podstawowe wymagania do projektowania bazy danych. Sama dostarcza definicje struktury informacji odzwierciedlajce podstawowe potrzeby informacji. IDEF1 uywajc reguł i zasad buduje sposób by odkry i zrozumie reguły biznesowe oraz informacje uywane przez organizacj. IDEF1 wymaga aktywnego uczestnictwa wszystkich uytkowników informacji. Zmusza uytkowników do mylenia o tym jak i gdzie informacja jest uywana i zarzdzana. Pozwala na dokładniejsze zamodelowanie organizacji. Metoda IDEF1 X IDEF1X jest metod projektujc relacj bazy danych wraz ze składni projektowania. Wspiera semantyczne konstrukcje konieczne przy rozwijaniu koncepcji projektu. Koncepcja projektu jest pojedyncz definicj przedsibiorstwa, która jest stworzona dla pojedynczej aplikacji oraz jest niezalena od dostpu oraz fizycznego przechowywania danych składowych. IDEF1X najczciej jest uywany do projektowania logiki bazy danych, w przypadku, gdy wymagania, co do informacji s znane oraz decyzja, aby wprowadzi w ycie baz danych jest podjta. Perspektywa systemu IDEF1X skupia si na faktycznych elementach relacji bazy danych. W przypadku gdy cel systemu nie jest w zalenoci z systemem, np. dla systemu zorientowanego obiektowo, IDEF1X nie jest najlepsz metod modelowania. IDEF1X nakazuje, na przykład, aby klucze klasy były róne, po to, aby

19 moliwe było odrónienie jednej klasy od drugiej. W systemie zorientowanym obiektowo nie jest wymagane, aby klucze były indywidualne dla kadego obiektu. W tej sytuacji, gdy wicej ni jeden atrybut jest stosowany dla indywidualnych jednostek IDEF1 X, modelowanie musi wskazywa jeden klucz główny oraz spisywa list wszystkich pozostałych kluczy. Jednoznaczna etykieta klucza obcego jest wymagana. Głównym celem projektowania logicznego modelu IDEF1X jest to, aby mógł on zosta uyty przez programistów, którzy bior logiczny projekt bazy danych i go implementuj. IDEF1X jest bardzo podobny do IDEF1, dziki czemu modele informacji wygenerowane za pomoc, IDEF1 mog zosta przejrzane przez ostatecznych uytkowników proponowanego systemu. IDEF1X pojcia. Jednostki IDEF1X odnosz si do zbioru albo podobnych przypadków, które mog zosta odrónione od siebie. Indywidualni członkowie zbioru s nazywani instancj jednostki. W ten sposób kostki IDEF1X reprezentuj komplet rzeczy realnego wiata. Atrybut zbioru okrela zakres wartoci przynalenoci kadego elementu zbioru. Relacja, która istnieje midzy indywidualnymi członkami zbioru, okrelona jest poprzez nazw. Relacja ta zakłada ograniczenie łcznej referencji. Główn cech IDEF1X jest jego poparcie dla modelowania logicznej bazy typów przy uyciu struktury klasyfikacji lub konstrukcji generalizacji/specjalizacji. Konstrukcja ta odzwierciedla naturalne rodzaje elementów reprezentowanych przez kostki lub obiekty. Skategoryzowane relacje reprezentuj wspólne podtypy jednostki głównej. Podtypy jednake nie mog mie wspólnej instancji. Dla przykładu: główna jednostka człowiek ma dwa podtypy reprezentujce wszystkie komplety kategorii nazwane jako eskie i mskie. adna instancja podtypu mskie nie moe by instancj podtypu eskie. Unikalny identyfikator atrybutu dla kadego podtypu jest tym samym atrybutem, jaki jest dla głównej jednostki instancji. W IDEF1X jednostki s identyfikowane zalenie lub niezalenie. Instancje niezalenych identyfikatorów jednostek mog istnie bez innych instancji jednostki. Instancje identyfikatorów zalenych s zalene od innych jednostek instancji. Relacje powiza (cigła lub przerywana linia z wypełnieniem na jednym albo obu kocach) wskazuje, jak jednostki (komplety instancji bazy) s wzajemnie powizane. Relacje powizania wystpuj zawsze pomidzy dwoma jednostkami. Relacja powizania zaczyna si w niezalenym punkcie ródłowym oraz koczy si w zalenej jednostce potomka (dziecka), gdzie etykieta opisuje zaleno. Kada relacja powizania ma przyporzdkowany sobie

20 liczebnik główny. Liczebnik główny wyszczególnia numer instancji zalenej jednostki, który zwizany jest z instancj niezalenej jednostki. Relacje skategoryzowane pozwalaj modelom zdefiniowa kategorie jednostek. Jednostki mog nalee tylko do jednej kategorii. Atrybuty s właciwociami opisujcymi jednostki. Nazwy atrybutów s unikalne a znaczenie nazw musi by zgodne z modelem. Dla przykładu: atrybut kolor mógłby mie kilka moliwych zastosowa, np. dla koloru włosów, koloru skóry, lub koloru tczy. Kade uycie ma inny zasig znaczcych wartoci, dlatego jednostki musz zosta dokładnie nazwane. Kady atrybut posiada dokładnie jedn jednostk. Dla przykładu atrybuty PESEL mógłby zosta uyty w wielu miejscach w modelu, ale przynaley do tylko jednej jednostki (np. Człowiek ). Kady atrybut musi mie warto (reguł niepust) oraz aden atrybut nie moe posiada wielokrotnej wartoci (reguł niepowtórzeniow). Reguły egzekwuj tworzenie odpowiedniego modelu. W sytuacji, gdzie wydaje si, e reguła nie moe by utrzymana, model prawdopodobnie jest błdny. Klucz jest grup tych atrybutów, za pomoc, których mona jednoznacznie zidentyfikowa instancj jednostki. Rozróniamy dwa klucze, klucze główne oraz klucze obce. Kada jednostka ma dokładnie jeden klucz główny, pokazany powyej horyzontalnej linii kostki. Jednostki mog równie mie klucze obce, które take jednoznacznie identyfikuj jednostk, lecz nie mog by uyte do opisania relacji z innymi jednostkami. W relacji powizania, klucz główny rodzica przekazywany jest do dziecka. Jeli relacja jest relacj skategoryzowan, klucz główny dziecka jest tym samym kluczem, co kategoria. Jeli relacja jest relacj identyfikujc klucz główny dziecka, musi zawiera atrybuty od rodzica. Oprócz faktu, e klucz unikalnie identyfikuje jednostki, wszystkie atrybuty w kluczu musz przyczyni si do powstania unikatowego identyfikatora (najmniejszy to klucz reguły). W ten sposób decydujc czy dziedziczenie atrybutu powinno by czci klucza, sprawdzamy, czy ten atrybut jest konieczny, do stworzenia unikatowego identyfikatora. Istniej dwie zasady zalenoci reguł: pełne funkcjonalne zalenoci reguł, wtedy, gdy klucz główny jest złoony z wielokrotnych atrybutów. Wszystkie nieklucze atrybutów musz by funkcjonalnie zalene na całym kluczu głównym, nie przechodnie zalenoci, wtedy, gdy kady atrybut nieklucz musi by zaleny tylko od klucza atrybutu.

21 Klucze obce nie s typowymi kluczami, lecz atrybutami dziedziczonymi z kluczy głównych innych jednostek. Klucze obce maj etykiet (FK) by wyrazi, e nie s własnoci tej jednostki. Klucze obce s znaczce, poniewa pokazuj relacje midzy jednostkami. Metoda IDEF2 Modelowanie symulujce wspiera narzdzia pomocy przy rozwizywaniu kompleksowych problemów z zakresu aplikacji. Symulacja uwzgldnia scenariusz, co jeli i jego moliwe efekty analizy w istniejcym lub wyimaginowanym systemie. Celem IDEF2 jest umoliwienie symulacji modelu. W przypadku potencjalnego ponownego uycia, model symulacji jest podzielony na cztery podmodele: funkcjonalny podmodel: precyzujcy model główny, jednostkowy przepływowy podmodel: transformacja modeli poprzez jednostki, dyspozycyjne zasoby: główne logiczne zadania potrzebne do transformacji, system kontrolujcy podmodele: efekty zewntrzne modelu. IDEF2 pomaga w przypadku informacji dotyczcej symulacji modelu generujcego system. Metoda IDEF3 Norma IDEF3 jest kompleksow metod modelowania procesów. Została stworzona pod ktem zobrazowania łacucha nastpujcych po sobie działa. Zawiera opis mechanizmów umoliwiajcych zebranie odpowiednich do opisu procesu. Przesłankami do stworzenia normy IDEF3 były czynniki takie jak: zwikszenie wydajnoci analizy systemów biznesowych, ułatwienie zbudowania opisu wymaga systemu, wspieranie procesu zarzdzania projektami. Norma IDEF3 zbudowana jest w sposób, który umoliwia zrozumienie metody opisu przez osoby nie zajmujce si modelowaniem procesów, ma te ułatwi łatwe poznanie rónic pomidzy alternatywnymi wersjami procesu. Podstawowym elementem schematu procesu według normy, IDEF3 jest symbol UOB (Unit of Behavior box), ukazujcy pojedyncze działanie (funkcj). Symbole UOB łczone s za pomoc rónego typu połcze, przedstawione jako strzałki. Rozgałzienia procesu w schematach IDEF3 przedstawiaj wzły. Wystpuj wzły AND, rozdzielajce proces na wiele równolegle przebiegajcych gałzi, wzły OR (wzeł ten aktywuje jedn lub wicej gałzi) oraz XOR (wzeł aktywuje jedn z kilku moliwych gałzi). Dodatkowo wystpuj wzły synchroniczne

22 OR i AND, które oznaczaj rozpoczcie w tym samym momencie wielu odpowiednich dla danego wzła gałzi (nie wystpuje synchroniczne XOR, gdy po wle aktywowana jest jedynie jedna gał). W symbolu okrgu umieszczane s wystpujce w procesie obiekty (na przykład poszczególne komponenty uywane w produkcji). Bramka Xor Trasa powrotna 4 Cz malowania Cz suszenia Test X Trasa do nastpnego stopu 5 Diagram przepływu IDEF3 Norma IDEF3 ukazuje te kolejno przeprowadzania reorganizacji procesów, dzielc j na nastpujce etapy: udokumentowanie istniejcego procesu, zidentyfikowanie zebrania najwaniejszych dla procesu danych, przeanalizowanie istniejcego procesu, zaprojektowanie nowego procesu, wyznaczenie alternatyw i wyboru konkretnej alternatywy, opracowanie projektu biznesowego, uzyskanie zgody na implementacj zmian, zaplanowanie i wdroenie zmian, cigłe ulepszanie procesu. Normy IDEF stanowi, wic nie tylko zbiór metod opisu procesów i systemów informacyjnych, ale zawieraj te sposoby zbierania danych i metody przeprowadzania zmian. IDEF3 pojcia IDEF3 słuy do opisu scenariuszy typowych sytuacji w przedsibiorstwie. Pokazuje, jak działa system lub proces. Wykorzystuje znacznie bogatszy zestaw elementów: graficznych i logicznych. Mona wyróni dwa typy IDEF3:

23 Process Flow Description opisuje przepływ procesów. Wykorzystujc elementy logiczne, pozwala zrozumie proces i sie relacji pomidzy działaniami, Object State Transition Description opisuje zachodzce zmiany stanu obiektów. Obiekty okrelaj przedmioty rzeczywiste (materiały) oraz konceptualne (zamówienia). Zdecydowanie czciej wykorzystywany jest jednak schemat procesowy a nie obiektowy. Schematy procesowe mog równie by dekomponowane na podobnych zasadach jak w technice IDEF0. W notacji IDEF3 Process Flow Description, podstawowymi elementami s: kostki UOB (ang. Unit Of Behavior), okrelajce typy zdarze, decyzji, działa, czy czynnoci, strzałki, okrelane take mianem wizi. Definiuj one zwizek nastpstwa midzy kostkami UOB, W tabeli 3.1 zostały przedstawione podstawowe elementy wraz z opisami. Nastpstwo proste, kostka A jest poprzednikiem, kostka B nastpc Po kadej czynnoci reprezentowanej przez kostk A, musi nastpowa czynno reprezentowana przez kostk B Kada czynno reprezentowana przez kostk B, musi by poprzedzona czynnoci reprezentowan przez kostk A Kada czynno reprezentowana przez kostk B musi by poprzedzona czynnoci reprezentowan przez kostk A, oraz kostka A musi by poprzedniczk kostki B Nastpstwo zdefiniowane jest indywidualnie, za pomoc osobnego diagramu

24 małe kostki elementy logiczne wprowadzane w miejscu rozgałzie strzałek, jako złczenia. W miejscu rozgałzienia strzałek, proces ulega rozdzieleniu na wiele cieek a w miejscu złczenia strzałek, nastpuje złczenie wielu cieek procesu. Małe kostki w swoim wntrzu zawieraj znak operacji logicznej: & - koniunkcja i, 0 alternatywa lub, X - alternatywa wykluczajca xor. oraz oznaczenia: asynchronicznoci pojedyncza kreska pionowa, synchronicznoci dwie kreski pionowe. Czynnoci reprezentowane przez kostki B i C musz by nastpczyniami czynnoci reprezentowanej przez kostk A. Czynnoci reprezentowane przez kostki A i B musz by poprzedniczkami czynnoci reprezentowanej przez kostk C. Co najmniej w jednej z kostek B i C musi by realizowana czynno bdca nastpczyni czynnoci reprezentowanej przez kostk A. Co najmniej w jednej z kostek A i B musi by realizowana czynno bdca poprzedniczk czynnoci reprezentowanej przez kostk C. Czynno reprezentowana przez jedn z kostek B lub C musi by nastpczyni czynnoci reprezentowanej przez kostk A. Czynno reprezentowana przez jedn z kostek A lub B musi by poprzedniczk czynnoci reprezentowanej przez kostk C. Czynnoci reprezentowane przez kostki B i C musz by nastpczyniami czynnoci reprezentowanej przez kostk A i musz rozpocz si jednoczenie. Czynnoci realizowane przez kostki A i B musz by poprzedniczkami czynnoci reprezentowanej przez kostk C i musz si koczy jednoczenie.

25 Co najmniej w jednej z kostek B i C musi by realizowana czynno bdca nastpczyni czynnoci reprezentowanej przez kostk A i czynnoci te (jeli s realizowane obie) musz rozpocz si jednoczenie. Co najmniej w jednej z kostek A i B musi by realizowana czynno bdca poprzedniczk czynnoci reprezentowanej przez kostk C i czynnoci te, (jeli s realizowane obie) musz si koczy jednoczenie. Elementy logiczne, oraz oznaczenia a- i synchronicznoci w schemacie procesowym Opis przemiany obiektu Diagram opisu przemiany obiektu jest streszczeniem obiektu. Diagram jest tylko kompozycj stanu obiektu. Obiekt stanu definiuje termin wartoci właciwoci oraz ograniczenia. Właciwoci obiektu mog by zdefiniowane jako atrybuty normy IDEF1, oraz mog przenosi referencj na diagram. UOB/ Cze malowania 1/1 UOB/Test 3/1 Malowanie na nowo Płynna farba w maszynie Stała farba UOB/Cz suszenia UOB/ Test Malowanie z połyskiem 2/1 3/1 IDEF3 Przykładowy diagram przemiany obiektu

26 Literatura: 1. D. Vaskevitz, Strategie klient serwer, systemy informatyczne w procesie przekształcania przedsiebiorstwa, IDG Poland S.A. w-wa I. Durlik, Inynieria zarzdzania, strategia i projektowanie systemów produkcyjnych cz. I, Agencja Wydawnicza Placet, W-wa S. Abt, Zarzdzanie logistyczne w przedsibiorstwie, PWE, W-wa M. Christopher, Strategia zarzdzania dystrybucj, praktyka logistyki biznesu. Marketing a dystrybucja. Analiza i okrelenie poziomu obsługi klienta, Agencja Wydawnicza Placet, Wyd. II, M. Christopher, Logistyka i zarzdzanie łacuchem poday, Wydawnictwo profesjonalnej szkoły biznesu, Kraków J. Ochman, Integracja w systemach informatycznych zarzdzania, PWE, W-wa, P. Adamczewski, Wdroeniowe uwarunkowania zintegrowanych systemów informatycznych, Akademicka Oficyna PLJ, W-wa, P. Beynon-Davies, Inynieria systemów informacyjnych, WNT, W-wa, P. Fuglewicz, K. Stpor, A. Trojnar, CASE dla ludzi, LUPUS, W-wa, R. Barker, C. Longman, Case Method SM. Modelowanie funkcji i procesów, WNT, W- wa, A. Korzeniowski, A. Weselik, Z.M. Skowroski, M. Kaczmarek, Zarzdzanie gospodark magazynow, PWE, W-wa, J. Majewski, Informatyka dla logistyki, Biblioteka Logistyka, Pozna J. Majewski, Informatyka w magazynie, Biblioteka Logistyka, Pozna Strategia informatyzacji współczesnej organizacji. Teoria i praktyka. Pod red. Bernarda. F. Kubiaka, Uniwersytet Gdaski, Wydział Zarzdzania Gdask Architektura zintegrowanego systemu informatycznego zarzdzania, pod red. Andrzeja Bytniewskiego, Wydawnictwo Akademii Ekonomicznej im. Oskara Langego we Wrocławiu, Wrocław A. Januszewski, Funkcjonalno informatycznych systemów zarzdzania, Tom1, Zintegrowane systemy transakcyjne, PWN, Warszawa, A. Stachowicz-Stanusch, M. Stanusch, CRM. Przewodnik dla wdraajcych, Wydawnictwo Placet, Warszawa W.J. Jabłoski, W. Bartkiewicz, Systemy informatyczne zarzdzania. Klasyfikacja i charakterystyka systemów, Wydawnictwo KPSW, Bydgoszcz 2006