System ERP do harmonogramowania dla centrum edukacyjnego

Kontekst i problem

Po rozpoczęciu pracy w naukowo-edukacyjnym centrum fizyki i chemii odkryłem, że organizacja korzysta z ciężkiego systemu zbudowanego na bazie Excela. System stale się zawieszał, nie radził sobie pod obciążeniem, a codzienne zmiany operacyjne były wyjątkowo uciążliwe i podatne na błędy.

Właśnie dlatego postanowiłem stworzyć system, który uczyniłby zarządzanie harmonogramem i zasobami bardziej niezawodnym i przewidywalnym. W czasie wolnym od pracy głównej opracowałem własny produkt — Scheduling System, a w połowie sierpnia, tuż przed rozpoczęciem nowego roku szkolnego, bezpłatnie wdrożyłem i skonfigurowałem dedykowaną kopię systemu dla centrum edukacyjnego, aby ułatwić kolegom codzienną pracę.

Doświadczenie w pracy z relacyjnymi bazami danych ukształtowało główną zasadę architektoniczną projektu: zmiany w harmonogramie i zasobach powinny być obsługiwane jak transakcje, a nie jak zwykła edycja tabel.

Kontrola spójności danych została przeniesiona na poziom bazy danych, historia zmian jest niezmienna dzięki Audit Log, a architektura pozwala bezpiecznie przywrócić stan harmonogramu na dowolny dzień.

Moja rola

Przegląd systemu

System ERP do zarządzania harmonogramem i działalnością operacyjną:

• Szablon roczny + generowany na jego podstawie harmonogram roczny
• Edycja harmonogramu na poziomie dnia z freeze / unfreeze / rollback
• Zastępstwa nauczycieli
• Odwoływanie i przekładanie lekcji
• Tworzenie nowych lekcji i zajęć dodatkowych
• Proces zamawiania sprzętu laboratoryjnego
• Kolejka zgłoszeń (zasada „jednego okienka")
• Powiadomienia e-mail o wszystkich kluczowych zdarzeniach — zmiany harmonogramu, zmiana sali, przydzielenie zastępstwa, odwołanie lekcji, zamówienia sprzętu, zatwierdzanie zgłoszeń, a także powiadomienia operacyjne dla administratorów
• Granularny dostęp oparty na rolach
• Korytarzowe telebimy dla nauczycieli i uczniów
• W pełni niezmienny audit log

Stos technologiczny:

• PostgreSQL — wybrany ze względu na natywne wsparcie dla EXCLUDE USING GIST. Pozwala to na poziomie silnika bazy danych zapewnić brak nakładania się przedziałów czasowych i automatycznie wyeliminować race conditions przy równoległych zapytaniach.
• Logika w bazie danych — przeniesienie niezmienników do bazy danych zapewniło jedno źródło prawdy i spójność danych niezależnie od punktu połączenia (API, skrypty w tle czy bezpośrednie sesje administracyjne).
• Node.js + Express — cienka, bezstanowa bramka (Thin API Gateway), ograniczona do autoryzacji i przekazywania zapytań, bez duplikowania logiki biznesowej.
• Vue 3 + PrimeVue — skrócił time-to-market dzięki gotowemu ekosystemowi złożonych komponentów UI dla ekranów administracyjnych.
• Cloudflare Tunnel — odizolował infrastrukturę zgodnie z zasadą Zero Trust, eliminując potrzebę publikowania publicznego adresu IP i otwierania portów przychodzących.

Struktura projektu:

Struktura repozytorium — system od początku zaprojektowany z wyraźnym podziałem aplikacji, logiki bazy danych i infrastruktury.

System w praktyce:

Telebim korytarzowy w pokoju nauczycielskim — na żywo, na ścianie centrum edukacyjnego.

Telebim korytarzowy dla uczniów — na żywo, na ścianie centrum edukacyjnego.

Production monitoring — system znajduje się pod stałym zewnętrznym monitoringiem dostępności. 100% uptime w ciągu ostatnich 30 dni; 99,995% od 1 września 2026 — jedyny incydent trwający 5 minut to planowany przestój podczas wdrażania nowej wersji (migracja bazy danych i restart kontenerów backend/frontend). Od tego czasu — bez awarii.

Infrastruktura wysyłki e-maili — powiadomienia są wysyłane przez zweryfikowaną domenę za pomocą transakcyjnego dostawcy poczty (Resend), co zapewnia niezawodne doręczanie i poprawną autentykację (SPF/DKIM).

Interfejs systemu

Kliknij dowolny zrzut ekranu, aby otworzyć go w pełnym rozmiarze.

Dzienny wykres Gantta — aktualny harmonogram dnia w podziale na sale. Kolorowe oznaczenia przedmiotów, podświetlenie zastępstw, wskaźnik bieżącego czasu.

Szablon roczny (Basic Schedule) — źródło prawdy. Zmiany z niego są bezpiecznie propagowane do wygenerowanego harmonogramu rocznego za pomocą dwufazowego algorytmu.

Panel nauczyciela — osobisty pulpit: najbliższe lekcje, zgłoszenia sprzętu, historia zastępstw i grafik pracy.

Panel administratora — centralne „jedno okienko". Nauczyciele wyłącznie tworzą zgłoszenia, administratorzy je rozpatrują, korygują i wprowadzają zmiany.

Panel laborantów — operacyjny widok: zamówienia sprzętu i notatki na wybrany dzień.

Audit Log — w pełni niezmienna historia wszystkich istotnych działań. Nawet superadministrator nie może zmienić ani usunąć wpisów.

Reguły wysyłki powiadomień e-mail — komu o czym informować. Każdy typ zdarzenia (nowe zgłoszenie, zatwierdzenie, zamówienie sprzętu, zastępstwo, konserwacja serwera...) można skierować niezależnie do wybranych ról i uczestników zdarzenia (autor zgłoszenia, nauczyciel lekcji, zastępca, nauczyciel prowadzący) — konfigurowane na ekranie „Control Panel", z globalnym wyłącznikiem do natychmiastowego wstrzymania całej wysyłki.

Rzeczywista skrzynka pocztowa systemu — przychodzące powiadomienia same sortują się według typu zdarzenia (zamówienie sprzętu, odwołanie lekcji, zmiana sali, zastępstwo...) do osobnych folderów, każdy z własnym adresem nadawcy.

Potwierdzenie zamówienia sprzętu — z kodami pozycji i bezpośrednimi linkami do biblioteki materiałów Hemda.

Tablica dla uczniów — publiczny ekran z bieżącym harmonogramem.

Kultura inżynierska — kod i dokumentacja

Jedna z kluczowych zasad projektu: logika i decyzje są wyjaśnione bezpośrednio w kodzie — nie tylko co robi dana funkcja, ale też dlaczego jest potrzebna i co się zepsuje, jeśli naruszy się dany niezmiennik.

1. Wyraźny podział struktury i logiki biznesowej

schema.sql — jasna zasada: tu znajduje się wyłącznie struktura. Logika biznesowa mieszka w plikach modułowych.

2. Dobór sal z jawnie zapisanymi regułami biznesowymi

campus._find_room() — reguły priorytetów sal dla fizyki i chemii są udokumentowane i zakodowane wprost w zapytaniu.

year_schedule.sql — w nagłówku pliku wyjaśniono przeznaczenie każdej kluczowej funkcji oraz przepływ freeze / unfreeze dnia.

3. Kontrola jakości i weryfikacja niezmienników

391 automatycznych testów regresyjnych (warstwy API i bazy danych) uruchamianych przed każdym wdrożeniem — obejmujących przepływy zatwierdzania zgłoszeń, zastępstwa nauczycieli, mechanikę zamrażania/wycofywania dnia, zapobieganie konfliktom harmonogramu (EXCLUDE USING GIST), zamówienia sprzętu oraz macierz reguł powiadomień.

4. Dyscyplina wdrożeń i eksploatacji

Każde z ~20 wdrożeń na produkcję w ciągu 9 miesięcy przechodzi przez ten sam protokół: próba migracji na świeżej kopii bazy produkcyjnej, obrazy Docker otagowane :rollback przed przebudową, backup tuż przed nałożeniem zmian i pisemny dziennik wdrożenia na serwerze. Rzeczywiste okno przełączenia kontenerów to 13–55 sekund.

Plan odzyskiwania po całkowitej awarii nie jest tylko teorią: pełny cykl (usunięcie wolumenu → czysta inicjalizacja od zera → przywrócenie prawdziwego zrzutu produkcyjnego do tymczasowej bazy) został przeprowadzony od początku do końca, a kluczowe tabele (pracownicy, lekcje, zgłoszenia, uprawnienia) zostały zweryfikowane wiersz po wierszu względem żywej bazy.

5. Wdrażanie i zarządzanie zmianą

Aby przejście ze starego Excela przebiegło sprawnie, opracowałem stopniową strategię wdrożenia:

• Wczesne zaangażowanie i prezentacje. Na etapie rozwoju regularnie pokazywałem współpracownikom działające prototypy, wyjaśniając na konkretnych przykładach, jak system uwolni ich od codziennej rutyny i chaosu. Początkowa obojętność szybko przerodziła się w szczere oczekiwanie na wdrożenie.
• Płynna adaptacja na 2 tygodnie przed startem. Uważnie obserwowałem reakcje pracowników i oceniałem ich otwartość na zmiany. Kiedy zobaczyłem, że większość jest nastawiona pozytywnie, udałem się do dyrektora z propozycją: nie komplikować przejścia zbędną pracą równoległą w dwóch systemach, ponieważ podwójne wprowadzanie danych tylko wywołałoby niepotrzebny stres. Nowy system obiektywnie okazał się znacznie prostszy i wygodniejszy od poprzedniego, dlatego zaproponowałem rozpoczęcie roku szkolnego od razu na nim — dyrektor wyraził zgodę. Aby zespół miał czas na oswojenie się, w połowie sierpnia udostępniono wszystkim pracownikom dostęp do środowiska testowego („piaskownicy”), gdzie każdy mógł bez obaw przetestować interfejs i poznać swój panel. Jednocześnie nowy układ planu zajęć został wyświetlony na wszystkich ekranach korytarzowych centrum — na dwa tygodnie przed 1 września, aby zespół oswoił się wizualnie z nowym formatem.
• Praktyczne szkolenia. Przeprowadziłem kilka rund praktycznych szkoleń dla nauczycieli i laborantów: jak zbudowany jest panel osobisty, jak za pomocą kilku kliknięć zamówić sprzęt laboratoryjny, złożyć wniosek o przełożenie lekcji i śledzić status zgłoszenia w czasie rzeczywistym.
• Szacunek dla nawyków i notatek na papierze. Wziąłem pod uwagę, że części laborantów i nauczycieli wygodniej pracuje się z kartką w ręku — oznaczając ołówkiem przygotowane doświadczenia czy robiąc notatki na marginesie. Ta funkcjonalność (oznaczanie gotowości sprzętu, komentarze do lekcji) została wbudowana w sam system — niektórzy wprowadzają to bezpośrednio w interfejsie, a inni najpierw na papierze, przenosząc dane później do systemu. Dlatego przewidziałem możliwość eksportu do Excela, do późniejszego wydruku, informacji wyświetlanej na ekranie.
• Rezultat. Dzięki intuicyjnemu interfejsowi nawet najbardziej konserwatywna część zespołu opanowała system praktycznie bez pytań. Już pod koniec września (pierwszy miesiąc roku szkolnego) system w pełni i bezproblemowo wtopił się we wszystkie codzienne procesy operacyjne centrum naukowego.

Rezultaty

• System działa produkcyjnie i stabilnie od września 2026
• Wytrzymuje rzeczywiste, codzienne obciążenie operacyjne centrum
• Krytyczne niezmienniki (konflikty harmonogramu, uprawnienia dostępu, audyt) są zagwarantowane na poziomie bazy danych
• Pełna, niezmienna historia wszystkich istotnych działań
• Z systemu codziennie korzysta ok. 50 pracowników