Komunikacja w firmie: ontologia dla MŚP
Temat: Ontologia firmy
Model komunikacji oddziela wiadomość od zatwierdzonej decyzji, a decyzję od zadania z właścicielem i terminem. To autorski, przykładowy model dla MŚP, a nie specyfikacja gotowa do wdrożenia w każdej firmie. Odpowiada na pytanie: Która decyzja wynika z jakiej rozmowy i kto ma ją wykonać? Zawiera 12 encji i 14 nazwanych relacji. Przed użyciem trzeba uzgodnić definicje z właścicielami procesu i sprawdzić je na rzeczywistych rekordach.
Ten tekst należy do katalogu ontologii w filarze Ontologia firmy. Jeśli dopiero zaczynasz, przeczytaj jak odróżnić ontologię od taksonomii i modelu danych.
Zobacz model jako graf
Miniatura otwiera pełny graf, w którym można wybrać encję lub relację i odczytać jej znaczenie. Tabele poniżej zawierają tę samą informację w formie tekstowej.
Jaką decyzję pomaga podjąć ten model?
Zespół uzgadnia zmianę terminu dostawy podczas rozmowy wideo. W czacie ktoś pisze „zróbmy to”, ale protokół spotkania wskazuje warunek: zgoda klienta. Zadanie trafia do pracownika przed potwierdzeniem warunku. Model ma pokazać, co było propozycją, co decyzją i co wolno wykonać.
Graf pozwala prześledzić podstawę decyzji i zatrzymać zadanie, gdy brakuje wymaganego zatwierdzenia. Granica modelu jest równie ważna jak jego zakres: Nie uznaje wypowiedzi na czacie za obowiązującą instrukcję bez potwierdzenia uprawnionej osoby.
Jakie pojęcia trzeba rozróżnić?
W tabeli każda encja ma własną definicję, klucz identyfikacyjny i przykładowe źródło. Nazwa rekordu w dwóch systemach nie dowodzi jeszcze, że chodzi o ten sam obiekt. Tożsamość trzeba potwierdzić kluczem lub świadomą regułą mapowania; status i prognozę należy datować.
| Encja | Znaczenie w tym modelu | Identyfikator | Przykładowe źródło |
|---|---|---|---|
| Zespół | Grupa odpowiedzialna za obszar pracy. | identyfikator zespołu | katalog organizacji |
| Pracownik | Uczestnik rozmowy lub właściciel zadania. | identyfikator pracownika | katalog organizacji |
| Rozmowa | Wątek lub spotkanie o określonym czasie i uczestnikach. | identyfikator rozmowy | komunikator, kalendarz |
| Wiadomość | Pojedyncza wypowiedź zachowana z autorem i czasem. | identyfikator wiadomości | komunikator |
| Dokument | Wersjonowany zapis warunków albo ustaleń. | identyfikator i wersja | repozytorium dokumentów |
| Propozycja | Wariant działania wymagający rozpatrzenia. | identyfikator propozycji | rejestr decyzji |
| Warunek | Wymóg który musi być spełniony przed wykonaniem. | identyfikator warunku | rejestr decyzji |
| Potwierdzenie | Dowód spełnienia określonego warunku. | identyfikator potwierdzenia | rejestr decyzji |
| Decyzja | Zatwierdzony wybór z autorem, datą i wersją. | identyfikator decyzji | rejestr decyzji |
| Zadanie | Praca wynikająca z decyzji z terminem i statusem. | identyfikator zadania | system zadań |
| Termin | Uzgodniona data wykonania lub kontroli. | identyfikator terminu | system zadań |
| Powiadomienie | Komunikat o decyzji albo zadaniu do odbiorcy. | identyfikator powiadomienia | system zadań |
Wiadomość dokumentuje wypowiedź, propozycja opisuje wariant działania, decyzja ma autora i warunki obowiązywania. Zadanie realizuje decyzję, ale samo przypisanie zadania nie jest dowodem, że decyzja zapadła.
Jak encje łączą się w graf biznesowy?
Krawędź ma kierunek, czasownik i znaczenie. Krotność w tabeli opisuje założenie tego modelu, które trzeba zweryfikować w konkretnej firmie. Gdy powiązanie ma własną kwotę, datę albo dowód, warto zachować je jako osobną encję zamiast ukrywać w atrybucie.
| Od | Relacja | Do | Krotność | Co potwierdza |
|---|---|---|---|---|
| Pracownik | należy do | Zespół | 0..n : 0..n | Zachowuje czas przynależności. |
| Pracownik | uczestniczy w | Rozmowa | 0..n : 0..n | Wskazuje uczestników. |
| Rozmowa | zawiera | Wiadomość | 1 : 0..n | Umieszcza wypowiedź w kontekście. |
| Pracownik | pisze | Wiadomość | 1 : 0..n | Zachowuje autora. |
| Wiadomość | wnosi | Propozycja | 0..n : 0..n | Oddziela tekst od sformalizowanego wariantu. |
| Dokument | opisuje | Warunek | 0..n : 0..n | Zachowuje podstawę warunku. |
| Propozycja | wymaga | Warunek | 0..n : 0..n | Pokazuje zależność przed zatwierdzeniem. |
| Potwierdzenie | spełnia | Warunek | 0..n : 1 | Dostarcza dowód. |
| Decyzja | rozstrzyga | Propozycja | 0..n : 1 | Łączy wybór z wariantem. |
| Pracownik | zatwierdza | Decyzja | 0..n : 1 | Wskazuje uprawnioną osobę. |
| Decyzja | uruchamia | Zadanie | 1 : 0..n | Pozwala przejść od decyzji do pracy. |
| Pracownik | wykonuje | Zadanie | 0..n : 0..n | Zachowuje odpowiedzialność. |
| Zadanie | ma | Termin | 1 : 0..n | Pozwala śledzić zmiany terminu. |
| Powiadomienie | ogłasza | Decyzja | 0..n : 1 | Wskazuje treść przekazaną zespołowi. |
Jak przejść po grafie w jednej sprawie?
Rozmowa R4 zawiera wiadomość W8 i propozycję P2. Dokument D3 opisuje warunek zgody klienta. Kierownik zatwierdza decyzję D7 po otrzymaniu potwierdzenia. Dopiero wtedy zadanie Z5 może przejść ze stanu oczekuje do realizacji, a powiadomienie N1 dociera do zespołu.
Jeżeli potwierdzenie klienta znajduje się poza systemem, graf musi pokazać brak dowodu zamiast automatycznie uznać warunek za spełniony. Puste powiązanie ma pozostać widoczną luką. Model nie powinien dopowiadać relacji tylko dlatego, że rekordy mają podobne nazwy lub bliskie daty.
Jak połączyć dane i nie zgubić kontekstu?
Połącz komunikator, kalendarz, repozytorium dokumentów i listę zadań identyfikatorami rozmowy, dokumentu oraz decyzji. Cytowana wiadomość musi zachować autora i czas, a decyzja wersję. Dla każdego mapowania zapisz system źródłowy, lokalny identyfikator, czas aktualizacji i regułę, która połączyła rekordy. Sprzeczne dane powinny trafić do kolejki wyjaśnienia, a nie zostać po cichu nadpisane. Właściciel procesu zatwierdza znaczenie relacji, a właściciel systemu potwierdza sposób jej pobierania.
Rozmowy mogą zawierać treści poufne i prywatne. Do grafu operacyjnego przenoś tylko potrzebne odnośniki, decyzje i dowody uprawnień, z kontrolą dostępu do oryginału. Dostęp do połączonych danych musi odzwierciedlać cel pracy i uprawnienia. Sam fakt, że graf potrafi przejść między dwiema encjami, nie oznacza, że każda osoba może zobaczyć wszystkie atrybuty po obu stronach.
Jak sprawdzić pierwszy wycinek modelu?
Weź kilka prawdziwych, ale bezpiecznie udostępnionych spraw. Dla każdej ustal oczekiwaną ścieżkę i dokument, który potwierdza każdą krawędź. Na początek wystarczą poniższe próby:
- Luźna sugestia nie uruchamia zadania.
- Zmiana decyzji zachowuje poprzednią wersję.
- Zadanie bez właściciela jest widoczną luką.
- Warunek z dokumentu blokuje wykonanie do chwili potwierdzenia.
Jeżeli dwie osoby inaczej interpretują ten sam węzeł lub relację, popraw definicję przed budową interfejsu. Przy niewielkiej liczbie stabilnych powiązań istniejąca baza i widok mogą wystarczyć. Graf pomaga rozmawiać o znaczeniu danych; nie naprawia automatycznie błędów w źródłach.
Co zrobić dalej?
Wybierz jedno pytanie operacyjne z początku tekstu i wskaż osobę, która potwierdzi znaczenie kluczowych pojęć. Następnie sprawdź pięć spraw w systemach źródłowych. Szerszą procedurę opisuje poradnik budowy ontologii firmy. Kolejny model w katalogu: Finanse międzynarodowe.
- Ontologia
- Model danych
- MŚP
