W tym wpisie, kończąc serię artykułów o modelach pojęciowych, przypominam najważniejsze myśli w nich zawarte i robię krótkie podsumowanie.

Seria składa się z następujących artykułów:

• Model pojęciowy: Semantyka
• Model pojęciowy: Diagram
• Model pojęciowy: Definicje
• Model pojęciowy: Fakty i zdarzenia

Czy tworzyć model pojęciowy?

Po lekturze pierwszego artykułu powinniśmy wiedzieć, że to nie jest dobrze postawione pytanie. W większości przypadków nie tworzymy modeli pojęciowych, bo one już istnieją w głowach naszych pracowników. Ludzie sami starają się poukładać sobie wiedzę w głowach. Ich naturalne sieci neuronowe same doszukują się znaczeń, łączą kropki, uczą się komunikacji. Ludzie w większości mają już jakieś pojęcie o tym, czym się zajmują.

A zatem nie tworzymy modeli pojęciowych. My możemy je:

• zobrazować czyli zaprezentować (na diagramach, w słownikach),
• uwspólniać,
• korygować,
• rozbudowywać (wprowadzając nowe pojęcia i terminy).

W ogólności możemy tą wiedzą po prostu zarządzać.

A zatem prawidłowo jest zapytać: czy można pozwolić sobie na pozostawienie pracowników bez wsparcia? Czy możemy liczyć na to, że ludzie sami się douczą i domyślą? Jesteśmy gotowi przyjąć związane z tym ryzyka?

Z czego składa się model?

Drugi artykuł na pierwszy rzut oka tłumaczy notację diagramów. Ale to jest tylko narzędzie. Celem było wskazać z czego składają się modele pojęciowe. A są to – w dużym uproszczeniu – tylko dwa elementy:

• pojęcia rzeczownikowe (mentalne kropki),
• pojęcia czasownikowe (mentalne kreski).

Kropki są jak niezależne byty, osamotnione punkty martwej wiedzy. Jeśli się zatrzymamy na spisaniu ich znaczeń, to nie będziemy jeszcze mieć modelu. Zostaniemy ze zwykłym słownikiem – takim, jaki znamy z bibliotek. Dopełnieniem, które wnosi największą wartość, są kreski, odpowiednio łączące kropki. Umożliwiają budowę poprawnych zdań, którymi można stwierdzać fakty. A to ożywia wiedzę, bo pozwala przełożyć ją na rzeczywistość, zastosować w praktyce.

Artykuł opisuje szczegóły działania tych połączeń, dla ułatwienia prezentując je w formie graficznej.

Jak przekazywać znaczenia?

Trzeci artykuł poświęcony jest przekazywaniu wiedzy. Same diagramy do tego nie wystarczą. Potrzebny jest opis słowny. Ale ten nie może być rozlazły – precz z watą słów! Stosując formalizm i kilka praktycznych zasad opisanych w artykule, można uzyskać definicje, które są przede wszystkim:

• stabilne: nie dezaktywują się z upływem czasu,
• praktyczne: krótkie i gotowe do zastosowania w różnych sytuacjach.

Żelazna reguła pojęć czasownikowych

W czwartym artykule są wskazówki dotyczące pojęć czasownikowych.

Przede wszystkim została tam opisana żelazna reguła: aby mogło zaistnieć dane pojęcie czasownikowe (pewien fakt), muszą istnieć egzemplarze wszystkich pojęć rzeczownikowych, wchodzących w jego skład.

Ta zasada stoi na straży logiki i kompletności wypowiedzi. Nie ma od niej wyjątków. Jej bezwzględność wpływa na kształt modelowanego języka. Po pierwsze pojęcia czasownikowe nie mogą wyrażać nieprawdziwych zdań (np. klient kupił podpis kwalifikowany). Poza tym muszą być jak najprostsze – dotyczyć tylko koniecznych pojęć rzeczownikowych. Dla przykładu porównajmy dwa pojęcia:

• klient składa zamówienie
• klient składa zamówienie na podstawie oferty

Jeśli do modelu pojęciowego wybierzemy drugie, będzie to znaczyć, że nie da się złożyć zamówienia bez oferty.

Co dalej?

Kolejnym etapem powinno być stosowanie całej tej teorii w praktyce. Niestety nie udało mi się domknąć serii artykułem o narzędziach, które wspierają spisywanie modeli pojęciowych. Jest to sprawa drugorzędna wobec ogólnych zasad przedstawionych we wpisach. Tym niemniej dobry program może znaczenie ułatwić wprowadzanie tych dobrych praktyk.

Artykuł nie powstał przede wszystkim dlatego, że nie mam dobrego rozeznania w tego typu narzędziach. Nawet jeśli o niektórych słyszałem, to nie miałem okazji zastosować. A zatem mój opis nie mógłby zbyt wiele wnieść.

Sam stosuję zawsze to, co w danej organizacji jest najbardziej dostępne i najlepiej da się dopasować. To może być pakiet office, kod pisany w AsciiDoc i budowany do PDF/HTML albo strony na Confluence (lub połączenie dwóch ostatnich punktów przy pomocy Confluence Publisher). Do rysowania diagramów używałem drawio.com (połączone z GDrive) a ostatnio miro.com.

Podsumowanie

Cała seria ma dla mnie duże znaczenie.

Pracowałem w wielu firmach, więc często musiałem się uczyć nowych pojęć. Widziałem wiele nieporozumień – niektóre groźne. Widziałem raporty z danych produkcyjnych, które zakłamywały rzeczywistość (ci, którzy zasilali bazy danymi i ci, którzy na ich podstawie robili zestawienia, mieli różne rozumienie pojęć). Odkręcałem obietnice, niesłusznie złożone przez niezrozumienie.

Korzystając z wolności, którą daje własny blog, opowiedziałem Wam ze szczegółami to, czego nauczyłem się z lektur fachowej literatury i co udało mi się do tej pory sprawdzić w praktyce.

Mam nadzieję, że materiał Was zainteresował i przyda się Wam w codziennej pracy. A przede wszystkim liczę na to, że dzięki tej serii zarządzanie wiedzą będziecie postrzegać nie jak czarną magię lecz bardziej jak rzemiosło, którego się można po prostu nauczyć.