Projekty usługowe: ontologia dla MŚP

Model projektu usługowego łączy umowę z zakresem, etapami, zadaniami, czasem pracy, odbiorami i fakturami. To autorski, przykładowy model dla MŚP, a nie specyfikacja gotowa do wdrożenia w każdej firmie. Odpowiada na pytanie: Czy projekt usługowy zostanie wykonany i rozliczony w uzgodnionym zakresie? Zawiera 12 encji i 13 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

Otwórz pełny graf: 12 encje, 13 relacje ↗

Projekty usługowe12 encje · 13 relacje

−Całość+Zamknij ×

Kliknij lub wybierz węzeł albo relację, aby przeczytać opis. Przeciągnij tło, aby przesunąć 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?

Agencja wdraża sklep klienta. Tablica zadań pokazuje 90 procent ukończenia, lecz klient nie odebrał integracji płatności. Zespół doliczył prace poza umową i wystawił fakturę według planu. Kierownik chce wiedzieć, co można uczciwie uznać za zakończone i rozliczalne.

Graf wskazuje wersję zakresu, dowód wykonania, odbiór oraz podstawę każdej faktury. Granica modelu jest równie ważna jak jego zakres: Nie uznaje procentu wykonanych zadań za formalny odbiór ani wystawionej faktury za otrzymaną płatność.

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
Klient	Strona zamawiająca usługę.	identyfikator klienta	CRM
Umowa	Uzgodnione warunki projektu i rozliczeń.	numer i wersja	repozytorium umów
Zakres	Wersjonowany wykaz rezultatów i wyłączeń.	identyfikator wersji	repozytorium umów
Zmiana zakresu	Wniosek i decyzja o modyfikacji rezultatu.	identyfikator zmiany	system projektowy
Projekt	Zorganizowana realizacja umowy.	numer projektu	system projektowy
Etap	Część projektu z rezultatem i kryteriami odbioru.	identyfikator etapu	system projektowy
Zadanie	Praca składająca się na etap.	identyfikator zadania	system projektowy
Pracownik	Wykonawca zadania.	identyfikator pracownika	katalog organizacji
Czas pracy	Zarejestrowany nakład na zadanie.	identyfikator wpisu	ewidencja czasu
Koszt	Wydatek przypisany do zadania lub etapu.	identyfikator kosztu	system finansowy
Odbiór	Decyzja klienta o przyjęciu rezultatu.	identyfikator odbioru	system projektowy
Faktura	Dokument rozliczający ustaloną podstawę.	numer faktury	system finansowy

Zadanie opisuje pracę, etap grupuje rezultat, a odbiór potwierdza zgodność z uzgodnionymi kryteriami. Czas pracy i koszt pokazują nakład; nie stanowią automatycznie podstawy faktury w umowie ryczałtowej. Zmiana zakresu wymaga własnej decyzji i wersji.

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
Klient	zawiera	Umowa	0..n : 0..n	Wskazuje stronę projektu.
Umowa	określa	Zakres	1 : 1..n	Zachowuje wersje zakresu.
Zmiana zakresu	modyfikuje	Zakres	0..n : 1	Wymaga zatwierdzenia.
Projekt	realizuje	Umowa	0..n : 1	Ustala podstawę pracy.
Projekt	składa się z	Etap	1 : 1..n	Porządkuje rezultaty.
Etap	wymaga	Zadanie	1 : 0..n	Wskazuje pracę do wykonania.
Pracownik	wykonuje	Zadanie	0..n : 0..n	Zachowuje odpowiedzialność.
Czas pracy	dotyczy	Zadanie	0..n : 1	Przypisuje nakład.
Pracownik	raportuje	Czas pracy	1 : 0..n	Wskazuje autora wpisu.
Koszt	obciąża	Etap	0..n : 1	Pokazuje wydatki.
Odbiór	potwierdza	Etap	0..n : 1	Oddziela wykonanie od akceptacji.
Faktura	rozlicza	Etap	0..n : 0..n	Wymaga zgodności z umową.
Faktura	jest wystawiona dla	Klient	0..n : 1	Wskazuje nabywcę.

Jak przejść po grafie w jednej sprawie?

Projekt P4 wynika z umowy U2. Etap E3 wymaga zadań Z8 i Z9. Czas C5 i koszt K6 przypisano do Z8, lecz odbiór O1 dotyczy tylko wcześniejszego etapu E2. Faktura F7 może rozliczać E2, ale E3 pozostaje bez potwierdzenia.

Nie wiadomo, czy dodatkowe zadanie Z9 mieści się w umowie; potrzebna jest decyzja o zmianie zakresu przed rozliczeniem. 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 system umów, plan projektu, ewidencję czasu i fakturowanie po numerze projektu oraz wersji zakresu. Zachowuj identyfikator akceptacji i autora każdej zmiany. 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.

Klient może widzieć stan etapów i odbiorów, lecz wewnętrzne stawki pracowników i marże wymagają odrębnych uprawnień. 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:

1. Zadanie ukończone bez odbioru nie zamyka etapu.
2. Zmiana zakresu zachowuje starą wersję umowy.
3. Godzina pracy jest przypisana do jednego zadania i dnia.
4. Faktura wskazuje konkretną podstawę rozliczenia.

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: Operacje sklepu detalicznego.