Nie używamy notacji BPMN do modelowania tego co się dzieje na produkcji. Skoro nie BPMN to czego używamy?

Wprowadzenie

Analityczne modele BPMN to łańcuchy aktywności reprezentujących procedury oraz ich produkty czyli dokumenty (dane). Na tych modelach aktywność to abstrakcja reprezentująca (całą) pracę, której efekt (wynik) jest prezentowany jako treść (DataObject), czyli aktywność kopania rowu kończy się pisemnych stwierdzeniem, że rów wykopano, z ewentualnym opisem parametrów tego rowu (patrz specyfikacja BPMN i definicja atomowej aktywności w procesach [zotpressInText item=”{5085975:QJUPRFNR}”]).

A gdzie dokładny opis machania łopatą albo obsługi koparki? Ten opis to procedura, instrukcja stanowiskowa lub instrukcja obsługi urządzenia (patrz Procesy a procedury).

Do modelowania produkcji używamy notacji SysML i korzystamy z tego, że znakomita większość dzisiejszego oprogramowania wspomagającego produkcję została zbudowana w oparciu o normę ANSI ISA-95. Struktura integracji w systemach tego typu wygląda tak:

Niedawno cytowałem:

SLIM (Systems LIfecycle Management) jest śro­do­wi­skiem dla zin­te­gro­wa­nej inży­nie­rii sys­te­mów opar­tej na mode­lach, nota­cji SysML (OMG Systems Modeling Language) i pro­duk­tach PLM (Product Lifecycle Management). Dzięki temu podej­ściu inży­nie­ro­wie zło­żo­nych sys­te­mów mogą opra­co­wy­wać i zarzą­dzać wyso­ko­po­zio­mo­wą archi­tek­tu­rą systemu/produktu w SysML i jed­no­cze­śnie łączyć się, komu­ni­ko­wać i syn­chro­ni­zo­wać ze szcze­gó­ło­wy­mi wyma­ga­nia­mi, czę­ścia­mi…

Source: Inteligentna pralka czyli czym jest mechatronika – Jarosław Żeliński IT-Consulting

W czym rzecz? W tym, że produkcja to złożony system powiązanych ze sobą maszyn, obsługujących je ludzi (ale nie zawsze, bo są roboty) oraz produktów jakie powstają z ich użyciem. To co się dzieje na takiej hali to nie procesy biznesowe, hala produkcyjna to pewien złożony mechanizm wytwarzania lub przetwarzania określonych rzeczy. Wyzwaniem jest tu stworzenie modelu tej hali i tych rzeczy [zotpressInText item=”{5085975:8BLSMKW4}”]. Opisuje to między innymi specyfikacja ANSI/ISA-95 [zotpressInText item=”{5085975:3NTCEURC}”]. Na jej podstawie można także opisać jakimi danymi zarządzamy i jak integrujemy dziedzinowe podsystemy zarządzające produkcją [zotpressInText item=”{5085975:WCZIC2ZZ}”].

Norma ANSI/ISA-95

Kluczem do napisania tego artykułu jest warstwowa struktura zarządzania produkcją opisana w normie ANSI/ISA-95:

Dlatego granica między modelem procesów biznesowych (tu używamy notacji BPMN) a modelem systemu produkcji (tu używamy notacji SysML) jest granica miedzy Level 4 a Level e3. Systemy MES operują w warstwie Level 3. Śledzenie i kolekcjonowanie danych to Levels 2, 1,0. (patrz także: OPC Foundation. (2024). ISA-95 Common Object Model—4 Concept [Organisation]. OPC Foundation. https://reference.opcfoundation.org/ISA-95/v100/docs/4)

Polecam także ten krótki film:

Proces biznesowy

Zgodnie z definicją BPMN proces biznesowy to aktywność i jej produkt, złożoność aktywności nie ma znaczenia, ten symbol to abstrakcja dowolnej pracy ograniczonej materialnym (dokument) wejściem i wyjściem (więcej na stronie Notacja BPMN…).

Poniżej dwa kluczowe dla produkcji procesy biznesowe: przyjęcie zamówienia i uzupełnienie niedoboru.

Co do zasady nie łączymy tych procesów w jeden, bo liczba zamówień nie musi być równa liczbie zleceń produkcyjnych: możemy mieć produkcję na zapas, łączenie zamówień w jedno zlecenie produkcji itp.. Na to nakłada się zarządzanie partiami produkcyjnymi.

Powyższe diagramy to typowe modele analityczne procesów. Liczba aktywności nie może być większa niż liczba dokumentów lub zmiany ich statusów (zgodnie z definicją BPMN elementarny proces to aktywność i jej produkt, mogą nim dwa dokumenty, ale analitycznym modelu nie dopuszczamy aktywności bez produktu).

Proces rejestracji i weryfikacji Zamówień jest z reguły realizowany przez system ERP/MRPII: osoba odpowiedzialna za przyjmowanie zamówień rejestruje je i weryfikuje. Wadliwe zamówienia są anonsowane zamawiającemu, pozostałe są rejestrowane ze statusem [przyjęte] (patrz stan vs status dokumentu).

A gdzie są te wszystkie potrzebne detale?

Integracja systemów

Proces uruchamiający zlecenia produkcyjne jest sterowany niedoborem produktów a nie zamówieniem od klienta, gdyż na takim zamówieniu może być wiele produktów, każdy o innym cyklu życia i produkcji.

Tu pojawia się “magiczna” granica między modelami procesów biznesowych, opartych na zadaniach i dokumentach biznesowych, a modelem “fabryki”, czyli złożonego mechanizmu wytwarzającego produkty. Tą fabryką steruje się komunikatami. Są one wysyłane z systemów informatycznych przetwarzających informacje z Zamówień na komunikaty sterujące realizacją zadań na maszynach (generalnie na gniazdach produkcyjnych).

Tu ma miejsce zamiana treści Zamówienia na sekwencję określonych w czasie zleceń produkcyjnych określonych produktów (indeksów). Są to niedobory. Pojawienie się niedoboru (w magazynie) jest wychwytywane w systemie ERP (magazyny, coraz częściej ERP sprawdza to w odrębnym systemie WMS, nie pokazano go tu). Niedobór jest zgłaszany do MOM (Manufacturing Operation Management), składający się z trzech kluczowych podsystemów: planowanie, sterowanie produkcją i zarzadzanie informacją o produktach. Realizacja uzupełnienia niedoboru to sekwencja jak poniżej:

Po prawej, wg, typowej obecnej nomenklatury są to odpowiednio systemy: APS (Advanced Planning & Scheduling), MES (Manufacturing Execution System), PLM (Product Lifecycle Management). Fabryką steruje bezpośrednio system MES, interfejsem jest tu system komunikatów przekazywanych np. na panele dotykowych operatorów stanowisk lub jako komunikaty NX do maszyn CNC sterowanych cyfrowo.

Maszyny, zasoby i produkty

W większości wdrożeń kluczowym systemem jest MES, gdyż tu powstają komunikaty sterujące “fabryką”. Na rynku mamy dość duży ich wybór, jedną z cech tych systemów jest ich branżowość, czyli branże dla których każdy z nich się szczególnie nadaje (patrz porównanie: https://www.gartner.com/reviews/market/manufacturing-execution-systems).

System MES to “wielki koordynator zadań”. Każde zadanie to także komunikat wysłany i zwrotny komunikat odebrany, innymi słowy MES zleca zdania i śledzi ich postęp. W tym miejscu technologia (opisana w PLM) jest zamieniana (przeliczana) na sekwencję zadań dla określonych stanowisk (cell) w fabryce.

Podstawową informacją dla MES jest technologia i wymagane zasoby (BOM, BOR). Poniżej poglądowy schemat:

Modelowanie struktury produktu, jako jego definicji, to modelowanie wraz z pracochłonnością jego wykonania (SysML). Innymi słowy model kosztowy lodów z perspektywy budki z lodami, to gałki lodów, rożek i praca wymagana do przygotowania i wydania loda. Poniżej ogólna struktura pojęć związanych z wytwarzaniem produktów.

Wytwarzanie ich wymaga zarzadzania pokaźną ilością danych:

Jak widać mamy do czynienia z dość poważną złożonością. I tu z pomocą przychodzi traktowanie fabryki wraz z tym co wytwarza jak systemu i notacja SysML bardzo pomaga tu w modelowaniu [zotpressInText item=”{5085975:ZXMTN7WR}”].

Zaczynamy od zapoznania się z dokumentacją opisująca fabrykę (zakład produkcyjny) i tworzymy bibliotekę typów komponentów systemu

Mając przygotowany “zestaw typów klocków” możemy przystąpić do modelowania konkretnego zakładu produkcyjnego i produktów. Można zbudować model ciągu produkcyjnego dla określonego produktu:

Np. stanowisko zbudowane z elementów których typy są na powyższym diagramie może wyglądać tak:

Jeżeli dla lepszego zrozumienia chcemy pokazać jakie zadania są realizowane na tym stanowisku używamy diagramu aktywności:

Nieco bardziej wyrafinowany przykład opisu stanowiska:

Powyżej cytowany model jest precyzyjny, gdyż może posłużyć do symulacji (ww. źródło zawiera komplet modeli opisujących pewną fabrykę). W przypadku typowego wdrożenia systemu MES celem zidentyfikowanie stanowisk, ich wyposażenia i etapów produkcji wraz z przezbrojeniami oraz strukturę opisu technologii wykonania produktu, czyli musimy zidentyfikować dane wymagane do parametryzacji systemu na etapie wdrożenia. Opisywany powyżej model to kolejny “digital twin” fabryki na poziomie abstrakcji pozwalającym bezbłędnie i za pierwszym razem przygotować informacje wymagane by skonfigurować i uruchomić system MES a później zarządzać zmianą.

Podsumowanie

Opisano krótko metody i notacje używane do modelowania systemu produkcji. Celem tych modeli jest skompletowanie danych potrzebnych do skonfigurowania systemów: CAD, CAM, MES, APS, PLM. Gdzie te dane? To atrybuty i ich wartości. Atrybuty elementów tych modeli (bloki funkcjonalne i ich instancje). Opis produktu to struktura treści składająca sie z elementów opisujących nie tylko listę składników BOM, ale także listę operacji wraz z ewentualnymi przezbrojeniami na stanowiskach realizujących kolejne operacje w toku wytwarzania. Kolejne stanowiska, ich wyposażenie, operacje jakie są realizowane na każdym z nich, pozwalają dokonać sprawdzenia, czy wszystko rozumiemy.

Kluczowe są także modele samych produktów, detale powstaję z pomocą aplikacji CAD, ale abstrakcje opisujące ich architekturę to SysML. Mając takie modele możemy upewnić się, że całość jest spójna, kompletna i niesprzeczna. Mamy też możliwość dokonania świadomych optymalizacji, które na modelach odbywają się to wielokrotnie niższym kosztem niż “na żywym ciele” w toku wdrożenia [zotpressInText item=”{5085975:FI9PGYD7},{5085975:LSFREFR4},{5085975:29NZ6BRG}”].

Całość jest nazywana Design Chain Management (DCM), czyli zarządzanie łańcuchem projektowym, rozumianym tu jako ciąg zdarzeń (prac, czynności) od zaprojektowania produktu, przez jego wytworzenie do dostarczenia zamawiającemu.

Jak widać musimy zarządzać zmiennością funkcjonalności, zmiennością struktury produktu, zmiennością procesów produkcji, zmiennością procesów w logistyce. To wszystko cechuje sie określonymi parametrami. Łańcuch projektowania i wytwarzania płynnie przechodzi w łańcuch dostaw. Jednak CAŁOŚĆ opiera sie na zarządzaniu informacją. Dlaczego? Bo systemy informatyczne nie produkują kół zębatych, one jedynie przechowują i przetwarzają informacje o całym tym procesie. WSZYSTKIE.

Dlaczego więc nie tylko BPMN? Dlaczego inne systemy notacyjne? A jak w BPMN opisać wszystko powyższe? Zakład produkcyjny to skomplikowany system, nie da się go skutecznie opisać używając jedynie nazw aktywności. Zresztą detaliczne prace wykonywane przy maszynach i ich kolejność, materialne elementy, które w toku produkcji nie są “wydaniem z magazynu i przyjęciem na magazyn”.

BPMN to tylko biznesowy model łańcucha pracy i jej produktów: informacji (dokumentów). To co wytwarzamy to systemy: od prostych sterowników klimatyzacji, przez sprzęt AGD, do samochodów i samolotów. To wszystko to mieszanka podzespołów mechanicznych, elektromechanicznych i komputerów (programator pralki i sterownik wtrysku silnia spalinowego to komputery) [zotpressInText item=”{5085975:8G9TUWIG}”]:

System informatyczny zarządzający tym wszystkim to informacje zarówno o produkowanych produktach jak i o samych same halach produkcyjnych i tym co sie tam dzieje. Model BPMN tu to tylko malutki wierzchołek góry lodowej, to czwarty poziom (Level4) hierarchii modeli.

Znane są próby wdrożenia produkcji jako sekwencji dokumentów MM między stanowiskami w fabryce, albo kastomizacja systemu ERP z prostej operacji kompletacji w obsługę produkcji. No nie są to sukcesy… świat tak nie robi. Jak? Zalecenia ANSI/ISA-95 to zbiór dobrych praktyk i modeli, który warto poznać i zrozumieć. Głównie dlatego, że oprogramowanie czołowych producentów na świecie jest budowane na bazie tych standardów. To zaś oznacza, że łamanie tych standardów w toku wdrożeń tych aplikacji, może się tylko źle skończyć, tak samo jak wciskanie kwadratowego korka w okrągła szyjkę butelki.

Źródła

[zotpressInTextBib style=”apa” sortby=”author” sort=”ASC”]

Wprowadzenie

Ontologia jako narzędzie tworzenia “modeli świata”, jest bardzo dobrym narzędziem do projektowania danych, zorganizowanych – w łatwe do zarządzania w bazach NoSQL – dokumenty. Niedawno napisałem:

Czy opra­co­wa­nie onto­lo­gii jest łatwe? Nie, nie jest. Czy zła onto­lo­gia szko­dzi? Tak, potra­fi dopro­wa­dzić do fia­ska pro­jek­tu infor­ma­tycz­ne­go.

źr.;: Ontologia czyli jak się to robi

Po co to wszystko? Obecnie często mówimy o Big Data, czyli o masowo gromadzonych danych. Ich gromadzenie wymaga opracowania struktury ich gromadzenia i zarządzania nimi, bez tego powstanie “stos nieskatalogowanych dokumentów”. Proces gromadzenia danych jest stratny, więc dane te można zgromadzić raz, przepisanie ich do nowej struktury jest możliwe tylko gdy nowa struktura jest prostsza (przepisywanie do identycznej nie ma sensu) więc każda migracja to utrata informacji. Innymi słowy: architekt danych, podobnie jak saper, myli się tylko raz.

Ontologia

Przypomnijmy definicję:

ontologia: lista pojęć i kategorii z jakiegoś obszaru tematycznego, która pokazuje związki między nimi

Generalnie, zgodnie z zasadą wyłączonego środka, każde dwa pojęcia mozna połączyć w zdanie albo generalizacją albo predykatem. Kolejna zasada: w poprawnej ontologii, wstawienie w zdaniu, w miejsce pojęcia, jego typu (specjalizacja), zachowuje prawdziwość tego zdania. Trzecia: zdanie tworzą także jedno pojęcie i predykat. Przykłady odpowiednio:

1. jeżeli “ratler to rasa (typ) psa”
2. a także “mały pies to także pies”
3. oraz “pies szczeka na listonosza”
4. więc “ratler szczeka na listonosza”
5. także “mały pies szczeka na listonosza”
6. oraz “pies szczeka”

Wszystkie powyższe zdania to zdania prawdziwe i sensowne w języku polskim. Są to zdania prawdziwe w sensie “tak sią (generalnie) dzieje, że… “, są to fakty jeżeli zdanie jest relacją. Patrz:

W The Philosophy of Logical Atomism Russell pisze: Jeśli mówię „Pada”, to to, co ja mówię jest prawdziwe przy pewnych warunkach pogodowych a jest fałszywe przy innych. Warunki pogodowe, które czynią moje stwierdzenie prawdziwym (lub fałszywym w innym przypadku), są tym, co nazywam faktem” [zotpressInText item=”{5085975:52F4HLJ6}”]

Modelowanie

Wśród wielu znanych metod modelowania ontologii jest OntoUML [zotpressInText item=”{5085975:V8JX39Y2},{5085975:5K34YGSS}”]. Moim zdaniem ma pewne wady: autorzy wprowadzają pojęcie ‘event’ mające takie cechy jak początek i koniec (wartością tych atrybutów jest czas: timestamp). Uważam, że stwarza to pewien problem z klasyfikacją treści takiego komunikatu. Po drugie, jeżeli uznamy, że przestrzegamy zasady “nie lubimy pustych pól” (bazy danych nie zawierają pól/atrybutów bez wartości) to ‘event’ łamie tę zasadę, bo wartość zadeklarowanego pola “end event” będzie pusta do momenty zakończenia “zdarzenia”. Jednym z ciekawszych podejść do ontologii, jej modelowanie i integracją z modelami systemów (MDA, SysML, UML) opisali w swojej pracy Devedzic i inni [zotpressInText item=”{5085975:K6Z5L6JM},{5085975:K2PIVCKQ}”] z czego także tu korzystam.

W publikacji na temat klasyfikacji i jednoznaczności opisu [zotpressInText item=”{5085975:9KMR85JV}”] opisywałem metodę dzielenia informacji wg. kontekstu, jakim jest sklasyfikowanie treści jako opisu obiektu (ten trwa w czasie) oraz faktu (nie trwa w czasie). Zdanie “Dom ma cztery okna i czerwony dach” jest prawdziwe mimo upływu czasu, zawsze będzie wypowiadane w czasie teraźniejszym. Zdanie “w Dom uderzył piorun” jest prawdziwe ale zawsze będzie wypowiadane w czasie przeszłym. Obiekty trwają w czasie, ich stan może się zmieniać: “Po przemalowaniu (fakt) dom ma zielony dach” (i to trwa). Wszystko to co trwa w czasie, jest ograniczane faktami, w szczególności fakt powstania rzeczy (obiektu) i fakt jego “zniszczenia”, w międzyczasie mogą mieć miejsce fakty zmieniające stan rzeczy (obiektu, np. zmiana koloru).

Generalizując: obiekty trwają w czasie zaś fakty nie. Początek i koniec trwania obiektu to dwa kluczowe fakty z “jego życia” (cykl życia obiektu) a nie “event” mający początek i koniec. W “życiu” obiektu mogą wystąpić inne fakty. Cechy obiektu to jego własności (kolor, waga i wiele innych itp.), cechami faktów są moment w czasie (time stamp) oraz to jakiego obiektu (obiektów) dotyczyły.

W systemach informacyjnych mamy do czynienia z gromadzeniem wiedzy o świecie oraz z gromadzeniem sprawozdań. Powyżej ontologia czyli pojęciowy model wycinka świata. Zdanie “pies szczeka na listonosza” a także “pies szczeka” to ogólna wiedza o psach. Zdanie “listonosz boi się psa” to ogólna wiedza o listonoszach. Sprawozdaniem było by tu zdanie: “mały pies, pudel, szczekał na listonosza od godzony 16:16 do godziny 16:18” (można by jeszcze podać adres).

Ontologia, jako językowy opis świata, to metamodel zdań opisujących pewną klasę obiektów i zdarzeń. Sprawozdanie mówiące, że konkretny pies, w określonym okresie czasu, szczekał na konkretnego listonosza (w konkretnym miejscu) to taka właśnie instancja (wystąpienie).

Projektowanie architektury danych

Jaką architekturę powinien mieć “dokument” będący treścią tego sprawozdania?

Poniżej trzy etapy analizy.

Ogólnie można powiedzieć, że predykaty (fakty zdaniotwórcze) dotyczą obiektów: zbieramy informacje (wiedzę) o tym, kiedy pies szczekał na ludzi, jaki pies i na jakich ludzi szczekał. To rysunek a. powyżej, możemy go nazwać koncepcją. Zapisanie takiej informacji wymaga zaprojektowania trzech repozytoriów: pies, człowiek, predykat. Powiązanie psa z człowiekiem jest zapisane jako atrybuty predykatu (rys. b.). To projekt architektury danych i logiki ich wiązania. Bardziej uniwersalny model pokazano na rys. c., wymagał by on uzupełnienia “bazą szablonów obiektów” (struktury agregatów opisujacych różne typy obiektów) z uwagi na to, że różne obiekty mogą mieć różne cechy. Tu pokazano je w uproszczeniu jako atrybuty, jednak realny projekt dziedzinowy były już bardziej precyzyjny i rozbudowany.

Powyższe można zapisać w bazie NoSQL, w w bazie grafowej obiekty były by węzłami a predykaty krawędziami. Detale obiektów mogą być agregatami w bazie dokumentowej.

Rola ontologii w projektach

Kluczową rolą i celem tworzenia ontologii jest wspólny słownik i zrozumienie pojęć. Ontologia pełni rolę centralnej współdzielonej przestrzeni pojęciowej (namespace) i wiedzy dziedzinowej (np. reguły biznesowe). Wszystkie systemy w organizacji (bardzo często od różnych producentów) mają – każdy swój – wewnętrzny i lokalnie spójny system pojęciowy (namespace). Jakakolwiek ich integracja (wymiana komunikatów między systemami) wymaga mapowania synonimów w komunikatach (nazwy pój, ich wartości, robi to adapter, bardzo często jest to implementowane jako szyna integracyjna ESB):.

Podsumowanie

Uważam, że ontologie nie wymagają skomplikowanych metamodeli takich jak ww. OntoUML czy bardziej skomplikowanych, opartych na rozbudowanych taksonomiach i modelu UFO [zotpressInText item=”{5085975:743UXHMB}”].

Gromadzenie wiedzy to albo wiedza “generalna” opisująca świat (właściwa ontologia) albo sprawozdania (opisy), dla których ontologia jest metamodelem (ontologia tu, to metadane sprawozdań). Tak więc możemy powiedzieć, że gromadzenie wiedzy wymaga dziedzinowego (specyficznego dla dziedziny) modelu pojęciowego: ontologii. Na tej podstawie można zbudować model struktury danych. Pokazano, że obecnie najbardziej adekwatny do opisów byłby model dokumentowy, gdyż opisy obiektów będą skomplikowanymi agregatami o zmieniającej się w czasie strukturze, zależnej od typu obiektu, ale też odwzorowującej wiedzę o nim. Predykaty są znacznie prostsze i przechowywanie ich w postaci samych prostych metadanych wydaje się wystarczające. Całość tworzy sieć, w której węzły są obiektami a krawędzie faktami.

Biorąc pod uwagę ogromne ilości zbieranych danych oraz to, że “nie można sie pomylić”, modele SQL/RDBMS, z ich sztywnością i brakiem redundancji, wydają się nieadekwatne. Ontologie jako wiedza o istocie świata (np. w systemach sztucznej inteligencji) bardzo dobrze pasują do baz grafowych. Ogromne ilości danych sprawozdawczych doskonale pasują do baz dokumentowych. Wyzwaniem w projektach tego typu jest zbudowanie dziedzinowej ontologii, a potem zaprojektowanie agregatów (dokumentów) przechowujących dane sprawozdawcze. Przykładem takich agregatów są np. opisy zmieniających się produktów jako obiektów oraz faktury jako fakty dokonania transakcji ich sprzedaży (co, kto komu, za ile, kiedy). Zdanie “Jan sprzedał Krzysztofowi rower” to wiedza o tym, że pewien fakt (moment dokonania transakcji) połączył trzy obiekty: sprzedawcę, nabywcę, sprzedany produkt.

Dalsze prace

Dalsze prace prowadzone są w kierunku stworzenia ogólnej uniwersalnej metody analizy i projektowania systemów zarządzania informacją na bazie ontologii i struktur dokumentowych i wdrażanie ich w systemach zarzadzania informacją zarówno ERP jak AI.

Dodatek

Pojęcia klasy obiektów, klasyfikatora, wartości a także pojęcia reprezentującego obiekty, które mogę reprezentować wartość czego to zbiory, definicje elementów i elementy. Z elementów zbioru, za pomocą predykatów, mozna budować “zdania prawdziwe” czyli opisy. Poniżej ciekawa prezentacja o teorii zbiorów i rachunku predykatów. Bardzo ważna dla zrozumienia tego czym tak na prawde jest analiza pojęciowa.

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

Wprowadzenie

Wiele problemów w projektach informatycznych, to skutki źle zbudowanej ontologii lub jej braku w projekcie. Niemal co druga firma (46 proc. badanych przez AIIM, 2022) ocenia, że przeciwdziałanie chaosowi informacyjnemu wewnątrz ich organizacji ?wypada słabo? lub ?wymaga poprawy?. Obecnie większość przetwarzanych w firmach treści to treści częściowo lub nawet całkowicie nieustrukturyzowane. Zarzadzanie nimi wymaga nowych metod [zotpressInText item=”{5085975:RE8Y697A}”].

Czym jest ontologia

Ontologia jest często nazywana reprezentacją wiedzy. Pozostaje pytanie co jest tu tą wiedzą? Czy wiedzą jest to co oznacza w określonym języki (tu polskim) słowo “samochód”, czy wiedzą jest to, kto wczoraj jechał, gdzie, kiedy i jakim samochodem? Nie jest ontologią sprawozdanie, więc jest nią słownictwo użyte do stworzenia tego sprawozdania. Dlatego często ontologię nazywa się także modelem pojęciowym ale nie jest to “domain model” bo model dziedziny to nie model pojęciowy!

An object model of the domain that incorporates both behavior and data [Obiektowy model dziedziny, który zawiera zarówno opis zachowania systemu, jak i dane w nim przetwarzane]

[zotpressInText item=”{5085975:NVN9AR49}”]

Model dziedziny to model opisujący mechanizm działania/funkcjonowania czegoś. W nauce model to opis (wyjaśnienie) zjawiska [zotpressInText item=”{5085975:LCAP9JJ4}”]. W inżynierii oprogramowania jest to logika dziedzinowa czyli to “jak to działa” np. jak wystawić poprawną fakturę na podstawie zamówienia, czy też jak kontrolować rezerwowane w hotelu pokoje [zotpressInText item=”{5085975:NVN9AR49}”].

Ontologia jest definiowana jako “część filozofii, która bada, czym jest istnienie” (Cambridge Dictionary). Słownik języka polskiego pokrewnie: “nowsze określenie metafizyki jako działu filozofii”. W encyklopedii PWN znajdziemy:

ontologia [gr. on óntos ?będący?, ?byt?, óntos on ?rzeczywiście będący, istniejący?, lógos ?słowo?, ?nauka?, ?teoria?]

(https://encyklopedia.pwn.pl/szukaj/ontologia.html)

Gdzie indziej czytamy:

ontology noun /?n?t?l?d?i/ /??n?t??l?d?i/
??[uncountable] a branch of philosophy that deals with the nature of existence
??[countable] a list of concepts and categories in a subject area that shows the relationships between them

(Oxford Advanced Learner’s Dictionary)

Tak więc jest to owszem “dział filozofii zajmujący się naturą bytu”, jednak jest to także

ontologia: lista pojęć i kategorii z jakiegoś obszaru tematycznego, która pokazuje związki między nimi

Obecnie, w branży jaką jest informatyka, ontologia jest określana jako narzędzie “modelowanie i reprezentowanie struktur wiedzy” [zotpressInText item=”{5085975:DLGT99FK}”].

Czytamy tamże: “Za najważniejsze uważamy kategoryzację i hierarchizację pojęć (a tym samym ich definicji). Kategoryzacja oznacza zdolność do porządkowania symboli, pojawiających się w komunikacie należących do ściśle określonej grupy obiektów, posiadających określone cechy. Komunikacji ludzkiej daleko do doskonałości, jednak staramy się, by ten abstrakcyjny model świata stał się sformalizowanym i samodzielnym bytem.” Pojawia się tu “abstrakcyjny model świata”, pytanie czym on jest? Tym co jest i można nazwać (ontologia jako natura bytu)? Czy może tym co wyjaśnia “Jak i do czego doszło?”

Problemy projektowania

Powszechnym problem w projektach informatycznych jest mylenie faktów z obiektami oraz pojęć z ich cechami (definicje). Różnicę między faktami a obiektami szerzej opisałem niedawno [zotpressInText item=”{5085975:9KMR85JV}”], zaś pojęcie nazwy rzeczy i jej atrybutów (definicje sprawozdawcze a atrybutowe) opisuje [zotpressInText item=”{5085975:6LD24N2L}”]). Problem ten pokazano na schemacie poniżej:

Lewy diagram to model pojęciowy (ontologia, tu taksonomia pojęcia trasa) i jest niesłusznie używany (utożsamiany z) jako “model dziedziny systemu” lub “model danych” (o “złych diagramach klas” pisałem wielokrotnie na blogu).

Model pojęciowy to nie struktura kodu ani danych

Modele struktury informacji i modele systemów, które tę informacje przetwarzają, to odrębne modele. Model dziedziny systemu (mechanizm jego działania) tworzymy jako model przetwarzania i przechowywania informacji (oprogramowanie, o ile nie jest grą symulacyjną, przetwarza informacje o świecie a nie świat).

Tak więc ontologia to “formalna, jawna specyfikacja konceptualizacji” (nazewnictwo). Kluczowymi cechami ontologii są: jednoznaczność, spójność, rozszerzalność. Proces budowania ontologii często jest opisywany jako: definiowanie klas i ich hierarchicznej struktury, definiowanie własności klas [zotpressInText item=”{5085975:7QNTDALR}”].

Nauka o znaczeniu słów to semiotyka a za jej ojca uznaje się (autor powieści “Imię róży”) Umberto Eco [zotpressInText item=”{5085975:ZAV7CQ6P}”]. Prekursorem nauki o znaczeniu słów był Ullman, który opisał tak zwany trójkąt Ullmana, później zwany także trójkątem semiotycznym [zotpressInText item=”{5085975:RSU5DBMZ}”]. O znaczeniu słów w języku pisał Ogden [zotpressInText item=”{5085975:US5TQ96Y}”].

Trójkąt ten wiąże nazwę (konotacja, tu górny wierzchołek), jej definicję (definicja, dolny lewy wierzchołek) i (wszystkie) przedmioty określane tą nazwą (denotacja, desygnaty nazwy, prawy dolny wierzchołek).

Object Management Group opublikował notację SBVR (Semantics Of Business Vocabulary And Business Rules) [zotpressInText item=”{5085975:B7SVMTNQ}”]. Specyfikacja ta opisuje metody budowania i dokumentowania słowników i reguł biznesowych. Jest to bardzo ważna specyfikacja, bo opisuje metodę opisu, dokumentowania mechanizmu działania organizacji z użyciem reguł biznesowych, te zaś są budowane z użyciem pojęć, które muszą być jednoznaczne i spójne, a ich zbiór: przestrzeń pojęciowa, musi być kompletny (patrz też opis w SBVR…).

W specyfikacji tej znajdziemy rozdział dedykowany omawianej tu tematyce. Zawiera on bardzo precyzyjnie opisany trójkąt semiotyczny i to jak konstrukcja ta jest wykorzystywana do budowy Jednolitego Biznesowego Słownika Pojęć.

Generalnie autorzy są zgodni co do tego, że ontologie to narzędzie dokumentowania wiedzy, co oznacza, że nie mniej istotnym elementem, poza pojęciami i ich hierarchią, są związki między nimi. Kluczem jest także to, że ontologia to pojęcia, czyli nazwy rzeczy a nie rzeczy jako takie.

Krótkie podsumowanie:

1. świat rzeczywisty to rzeczy, aby “o nich” opowiedzieć i móc tę opowieść zapisać (gromadzić wiedzę), musimy dysponować nazwami (pojęciami) i umieć je utrwalić (wyrazić to znakami),
2. pojęcie to nazwa rzeczy lub faktu, każde pojęcie to jego brzmienie (i znaki czyli forma zapisu) oraz definicja (co oznacza),
3. słowo ‘pies’ w języku polskim oznacza “zwierzę domowe hodowane m.in. dla przyjemności lub do polowań” i odnosi się do wszystkich istniejących “psów” (zbiór rzeczy będących psem wg. określonej definicji),
4. w nomenklaturze OMG [zotpressInText item=”{5085975:7SY4A9KE},{5085975:DCYU6XZJ}”], są to klasa (pojęcie), klasyfikator (definicja), instancje klasy (wystąpienia obiektów danej kasy).

Brakuje nam jeszcze związków między klasami (pojęciami). W ontologii są to: generalizacja (pozwala budować taksonomie pojęć) oraz predykat (skierowana asocjacja reprezentująca związek zdaniotwórczy [zotpressInText item=”{5085975:BRZPXW8K}”]). Poniżej przykład:

Przypominam, że to nie jest model dziedziny w rozumieniu projektu oprogramowania (model w rozumieniu wzorca MVC). Przykład ten szerzej opisałem w artykule Gabinet weterynarza. Często stosowany model danych dla ontologii to Grafowe bazy danych.

Czym jest powyższy diagram? To model pojęciowy (diagram faktów w nomenklaturze SBVR, diagram klas UML). Generalizacja (nie jest to dziedziczenie!) czytamy (tworzy zdanie) “pudel jest typem psa”, predykaty tworzą zdania, które czytamy “pies śpi w budzie”, “pies szczeka na listonosza” (końcówki w j. polskim tu zaniedbujemy). Warunkiem poprawności modelu jest bezwzględna prawdziwość wszystkich tych zdań w danym języku. Bardzo ważna rzecz: dokumentacja projektu powinna zawierać definicje wszystkich użytych do opisu danych (metadane) pojęć.

Testowanie ontologii, jako sprawdzanie poprawności i prawdziwości zdań, także na sprawdzaniu związków: podstawiamy w zdaniach definicje pojęcia w miejsce ich wystąpienia, co nie może spowodować zmiany treści zdania ani tego, że stanie się ono nieprawdziwe (zasada podstawiania w logice):

• definicja psa: zwierzę domowe hodowane m.in. dla przyjemności lub do polowań
• zdania:
  • pies śpi w budzie
  • pies szczeka na listonosza
  • pudel jest typem psa
• testy:
  • zwierzę domowe hodowane m.in. dla przyjemności lub do polowań śpi w budzie
  • zwierzę domowe hodowane m.in. dla przyjemności lub do polowań szczeka na listonosza
  • pudel jest typem zwierzęcia domowego hodowanego m.in. dla przyjemności lub do polowań

Powyższe to trywialne testy, ale celem moim jest pokazanie istoty tych testów.

W 2013 roku opisywałem Produkty w procesie analizy wymagań, gdzie pokazałem ontologię tego obszaru wiedzy:

I teraz przykład. Na pewnym blogu znalazłem taki diagram (nie podaję źródła bo celem jest ocena diagramu a nie autora):

Popatrzmy:

• aktywność: praca, którą firma lub organizacja wykonuje za pomocą procesów biznesowych, może być atomowa lub nieatomowa (złożona), rodzaje aktywności, które są częścią Modelu Procesu: Proces, Podproces i Zadanie (źr. OMG.org BPMN)
• funkcjonalny: dotyczący funkcjonowania lub funkcji czegoś w jakimś systemie (s.j.p.)
• wymaganie: warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać (s.j.p.)

Autor przywołuje pojęcie Proces biznesowy BPMN 2.0, ale nie ma w specyfikacji tej notacji pojęcia “krok procesu biznesowego”. Można domniemywać, że pojęcie Aktywność pochodzi z przywołanej notacji, więc zdanie “Integracja jest typem aktywności” albo “Logika biznesowa jest typem Aktywności (zwraca, że Logika to rzeczownik). Proszę samemu przetestować resztę pojęć powyższego diagramu wg. wcześniej opisanych reguł. Zielony komentarz wskazuje na cel powstania tego modelu: pojęcia na tym diagramie mają stanowić metadane jakiegoś zbioru danych (wiedzy). Przemieszano pojęcia z obszaru notacji BPMN, notacji UML i obszaru prac realizowanych przez zespół projektowy: trzy różne dziedziny … Obawiam się, że to repozytorium zbudowane na powyższym modelu nie będzie działać zgodnie z oczekiwaniami…

Na zakończenie

Ontologia jako system nazw, stanowi źródło pojęć, których używamy jako nazw dokumentów (formularzy), ich sekcji, pól, wartości tych pól. Podstawowym zastosowaniem ontologii jest zapewnienie spójności i jednoznaczności treści (danych) przetwarzanych przez systemy informatyczne, poprzez budowanie systemu metadanych z pojęć danej ontologii. Uwaga: częstym błędem jest zawężanie ontologii do taksonomii.

A zarządzanie wiedzą? A jaką? Popatrzmy na użyte wyżej zdanie: “pies szczeka na listonosza”. Jest to (to że szczeka na nieznajomych, w tym na listonoszy) jedna z cech tego zwierzęcia ale też, może to być stwierdzenie tego co właśnie zachodzi (albo zaszło). Mamy tu więc wiedzę, że (ogólnie) psy szczekają, np. na listonoszy, ale też może to być wiedza o tym, że jakiś pies w określonym momencie szczekał na listonosza. Dokument opisujący psa jako gatunek, będzie zapewne zawierał to zdanie. Jednak zapis przesłuchania świadka tego zdarzenia, oznaczony określoną datą i miejscem, będzie zawierał identyczne zdanie. Pierwszy to opis psa jako pewnego obiektu, drugi to opis faktu. Poprawne zdanie może zawierać też jedno pojęcie i predykat: stwierdzenie Pies szczeka, podobnie: jest zdaniem charakteryzującym psa (w zasadzie mogło by być jego definicją) i jest (może być) stwierdzeniem, że właśnie w tym momencie Pies (jakiś lub mój) szczeka.

Czy opracowanie ontologii jest łatwe? Nie, nie jest. Czy zła ontologia szkodzi? Tak, potrafi doprowadzić do fiaska projektu informatycznego. Zapraszam do:

1. skorzystania z usługi Zamień artykuł na warsztat
2. przesłania mi do recenzji ontologii
3. zlecenia mi opracowania ontologii

(Patrz strona Zamów)

Zapraszam także do lektury artykułu Inżynieria oprogramowania z użyciem narzędzia CASE ? przykładowy projekt Biblioteka, gdzie krok po kroku pokazałem powstawanie dokumentacji analitycznej zawierającej ontologię dziedziny systemu i to jaką ona rolę odegrała w projekcie.

Źródła

[zotpressInTextBib style=”apa” sortby=”author” sort=”ASC”]

Normy ISO, bo o nich będę tu pisał, to przedmiot wielu kontrowersji: zwolennicy i audytorzy namawiają, reszta zaleca rozwagę.

Czym są Normy

W kontekście norm ISO, słownikowa definicja normy brzmi:

norma ?ustalona, ogólnie przyjęta zasada?

(https://sjp.pwn.pl/szukaj/norma.html)

Normami nazywamy także zbiory zasad. Dla porządku będę używał słowa norma pisanego z małej litery w ogólnym słownikowym znaczeniu (zasada), oraz w formie Norma, pisanego z dużej litery, w rozumieniu tekstu (produktu) komitetu normalizacyjnego.

Generalnie stosowanie Norm jest dobrowolne:

CZY STOSOWANIE NORM JEST OBOWIĄZKOWE?
Nie. Od 1 stycznia 2003 r. nowa Ustawa o normalizacji zniosła obligatoryjność norm i stosowanie Polskich Norm zgodnie z art. 5 ust. 3 ustawy jest już całkowicie dobrowolne.

(https://www.pkn.pl/na-skroty/faq/czy-stosowanie-norm-jest-obowiazkowe)

Tu jednak ważna uwaga: Norma, jako zbiór zasad, to także tak zwana definicja atrybutowa [zotpressInText item=”{5085975:6LD24N2L}”]. Innymi słowy, stosowanie normy nie jest obowiązkowe a dobrowolne, jednak (dobrowolna) deklaracja wdrożenia określonej Normy to już obowiązek zachowania zgodności z nią. Np. dobrowolne nazwanie produkowanego swojego produktu “kabanosem” stanowi obowiązek wytwarzania go zgodnie z normą (PN-A-82024, patrz uzasadnienie https://www.sejm.gov.pl/sejm7.nsf/InterpelacjaTresc.xsp?key=3261FC15). Innymi słowy zgodność z Normą jest dobrowolna ale całkowita albo żadna.

Normy powstają jako wynik prac wielu ekspertów dziedzinowych, stanowią zbiór wskazówek i dobrych praktyk. Jako teksty (ich struktura i zawartość) nie są to jednak publikacje naukowe (te zawierają uzasadnienie, normy nie uzasadniają swojej treści). Normy więc, to zalecenia na mocy autorytetu (dowód z autorytetu). Jest to ich poważana wada, bo forsowane są jako dogmaty (Norma, jej treść jako zalecenie jest dobra, bo tak uważa zespół ekspertów).

Niewątpliwie, jako zebrany dorobek niemałej grupy doświadczonych ludzi, Normy mają ogromną wartość, jednak są aż i tylko eksperckim zaleceniem. Niewątpliwą zaletą norm jest standaryzacja, czyli zapewnienie, że jak się coś “tak nazywa” to “to jest to coś” (patrz pojęcia i ich definicje atrybutowe oraz słownik j. polskiego: standaryzacja ?wprowadzenie jednolitych norm, zwłaszcza w przemyśle?).

Standaryzacja, podobnie jak stosowanie prawa, to przede wszystkim przewidywalność. Użycie nazwy Normy w stosunku do czegoś (coś jest zgodne z Normą, nie należy mówić “spełnia normę”) to stwierdzenie mówiące, że coś spełnia określoną listę warunków. Jak ktoś zadeklaruje, że postępuje zgodnie z określoną Normą to można uznać, że postępuje zgodnie z zawartymi w niej regułami. I tu pojawia się pojęcie “deklaruje”, czyli jest to obietnica. Owszem mamy system certyfikacji, ale certyfikat to “zdjęcie” wykonane w dniu certyfikacji. Dlatego ocena organizacji na podstawie certyfikatu to troszkę tak, jakby umówić się z kimś na randkę w grudniu na podstawie zdjęcia ze stycznia: ryzyko musimy ocenić sami.

Podsumowując, można powiedzieć, że Norma jako treść, jest dokumentem opisującym określony standard postępowania w prowadzonej działalności usługowej, technologicznej, badawczej. Jest dokumentem powszechnie dostępnym. Często mówi się, że Normy opierają się na podstawach naukowych. Uważam jednak, że skoro treść Norm jest dogmatem, to w moich oczach teza o ich naukowości jest nieuprawniona. Uważam, że uczciwie należy poprzestać na tym, że są one oparte na danych sprawdzonych pod względem słuszności technicznej, ekonomicznej i użytkowej. Z zasady Normy powinny uwzględniać aktualny stan wiedzy, czy tak jest zawsze? Norma zostaje przyjęta na zasadzie konsensusu (czyli przez aklamację) i akceptowana jest przez uznane jednostki normalizacyjne. Robi się to jednak kilka lat.

Najważniejsze jest tu to, że ich respektowanie ma charakter dobrowolny.

Czy warto wdrażać normy

To pytanie zadaje mi prawie każdy klient. Odpowiedź, moim zdaniem, nie jest tak prosta jak uważają firmy je wdrażające i audytorskie oraz komitety normalizacyjne (od momentu komercjalizacji Norm, podmioty te – wygłaszając takie opinie – mają tu konflikt interesu).

Normy mają obecnie także charakter marketingowy, tak jak certyfikaty umiejętności: “masz certyfikat więc robisz to dobrze”, rzecz w tym, że to teza podobna do: “masz prawo jazdy więc jeździsz zgodnie z Kodeksem Ruchu Drogowego”. Jak to wygląda na rynku? Takie ogłoszenia nie są rzadkością:

Potrzebujesz certyfikatu dla celów przetargowych lub kontraktowych? Z naszą pomocą uzyskasz certyfikat systemu zarządzania ISO 9001.

(celowo nie podaje źródła by nie promować tej firmy, google pomoże)

Jeżeli jakiś podmiot uzyskuje certyfikat zgodności z jakąś Normą, nie z powodów własnego przekonania do niego, a z powodu samej chęci “posiadania papieru”, to zdobędzie go ale to, czy jako podmiot, (zawsze) spełnia wymagania Normy, pozostaje dużym znakiem zapytania.

Jak już wyżej wspomniałem, certyfikacja to zdjęcie na moment certyfikowania i warto o tym nie zapominać. Czy to znaczy, że podmioty certyfikowane na co dzień nie spełniają tych Norm? Absolutnie nie. To znaczy tylko tyle, że wiedzą jak je spełnić, nie ma jednak gwarancji, że spełniają. Pamiętajmy także, że certyfikacja jest skuteczna tak samo jak zapowiedziana kontrola. I to co tu teraz napisałem nie jest żadną tajemnicą tak jak to, że każdy posiadacz prawa jazdy wie z jaką prędkością ma jeździć, i że nie każdy tego przestrzega (pamiętajmy, że egzamin na prawo jazdy to to samo co audyt zgodności z Normą).

Jak widać nie jest prawdą, że certyfikat przyznany jakiejś firmie cokolwiek gwarantuje. Poniżej dane na temat liczby wydawanych certyfikatów w różnych krajach:

Nie ma żadnej korelacji pomiędzy poziomem gospodarki danego kraju a liczbą wydanych w nim certyfikatów zgodności z Normami. Wartości dla Włoch i USA są chyba dostatecznym dowodem na brak tej korelacji (Chiny na tle liczby mieszkańców i firm, też nie wypadają imponująco).

Na tle tego wszystkiego ciekawą i słuszną moim zdaniem, opinię prezentują pracownicy Uniwersytetu Ekonomicznego w Krakowie na swoim portalu:

Ciągły postęp nauki i techniki powoduje, że normy opracowywane przez jednostki normalizacyjne dezaktualizują się lub zaczynają odstawać od wymagań praktyki. mimo iż standardy wprowadzają ład i porządek w gospodarce, nie powinny stanowić ograniczeń dla jej rozwoju.

https://mfiles.pl/pl/index.php/Nowelizacja_norm_ISO_9000

Podsumowanie

Niewątpliwie Normy, jako uporządkowany dorobek wielu ludzi, stanowiący zbiór najlepszych praktyk, co ma ogromną wartość. Jednak bałwochwalcze podejście do nich wyrządziło wiele zła. Widać to było 20 lat temu, gdy pojawiła się “moda” na wdrażanie norm serii ISO9000 (zarządzanie jakością), a następnie kolejne firmy nie przedłużały certyfikacji nie widząc w tym żadnej wartości dla siebie. Po pewnym czasie ustabilizowała się sytuacja: część firm co roku przechodzi audyty i utrzymuje certyfikat, część tego nie robi, co jednak nie oznacza, że są gorsze. Warto też pamiętać, że w niektórych sektorach pewne certyfikaty są obowiązkiem (np. farmacja, żywność), ale tylko w niektórych.

Po pierwsze brak certyfikatu nie jest tożsame ze złą oceną. Po drugie zgodność z Normą to zero-jedynkowa ocena: zgodny – niezgodny. Przypominam, że Normy to definicje atrybutowe ustalone zbiorowo. Popatrzmy na sport: rekord świata w biegu na 100m to 10 sek. (dokładnie 9,58 sek.). Załóżmy, że wynik 11 sek. ustalimy jako Normę dla “dobrego sprintera”. Czy wynik 11,1 sek. czyni kogoś złym sprinterem? W świetle Norm, taki wynik mówi: “ten człowiek nie jest dobrym sprinterem” i w myśl tej Normy nie jest nim. Taka klasyfikacja to cecha stosowania definicji atrybutowych, i jest to dobra cecha systemu Norm (podobnie jest ze stosowaniem prawa): nie można być Dobrym Sprinterem “troszkę”. Pozostaje pytanie: czy człowiek z wynikiem >11 sek. jest gorszy? Nie, co najwyżej nie zaklasyfikuje się do składu drużyny olimpijskiej, ale czy musi?

Wiele firm ma w swojej strategii utrzymywanie wysokiej jakości, bezpieczeństwa itp.. Robi to jednak adekwatnie do swojej sytuacji i warunków. Korzystanie z Norm, jako zbioru najlepszych praktyk, jest bardzo dobrym pomysłem, podobnie jednak dobrym pomysłem jest pragmatyczna decyzja czy, w danej sytuacji, konieczne jest spełnienie wszystkich warunków danej Normy, czy może świadomie zrezygnujemy z jakiegoś “obowiązku”, bo może on nie mieć wartości w określonym produkcie, usłudze, czy w ogóle w firmie.

Np. zamki do drzwi maja kategorie bezpieczeństwa A, B i C (C najwyższa). Załóżmy, że mamy Normę opisującą warunki nadania certyfikatu “Bezpieczne mieszkanie”, wśród wielu ważnych i wartościowych zaleceń jest zastosowanie zamka kategorii C. Czy świadome zastosowanie zamka kategorii B (bo np. nie mamy w domu złota i diamentów) czyni to mieszkanie “niebezpiecznym”? Nie! To powoduje TYLKO to, że to mieszkanie nie spełnia TEJ Normy. No to jest bezpieczne czy nie? W warunkach świadomie (raport z audytu) określonych przez lokatora jest “wystraczająco bezpieczne”.

W tym miejscu moja sugestia:

1. przeprowadzić analizę procesów biznesowych organizacji,
2. na jej podstawie przeprowadzić jej ewentualną optymalizację,
3. zlecić audyt zgodności z wybraną Normą dziedzinową,
4. na podstawie wyników (raport z audytu):
   1. zapoznać się z zasadami/warunkami, których organizacja nie spełnia,
   2. dla każdego z nich wykonać analizę ryzyka jakie stwarza on dla organizacji,
   3. podjąć decyzję czy podjąć działania by spełnić określony warunek,
5. po tych działach albo kwalifikujemy się na certyfikat albo nie, ale brak certyfikatu to świadoma decyzja.

Powyższe robię prawie u każdego klienta, który zleca mi analizę i modelowanie procesów biznesowych organizacji. Niejeden pragmatycznie decyduje, że uzyskany poziom jest wystarczający dla jego strategii. To, że nie dostał certyfikatu nie znaczy, że coś robi źle, to znaczy, że nie spełnia danej Normy, tak samo jak można być wystarczająco szybkim w swoim segmencie rynku, i nie być olimpijczykiem. Pamiętajmy, że kolejne wymagania to koszty, które powinny być adekwatne do uzyskanych korzyści. Stawianie sobie wymagań wyższych niż to konieczne jest złym pomysłem (wręcz rozrzutnością).

Zgodność z określoną Normą może być dla klientów zarówno zaletą jak i wadą organizacji, warto o tym pomyśleć.

Żródła

[zotpressInTextBib style=”apa” sortby=”author” sort=”ASC”]