Nie zaczynałem od kodu. Zacząłem od procesu, który znałem.

Najpierw było pytanie: co właściwie chcę pokazać?

Przez lata pracowałem na styku obsługi klienta, produkcji, dokumentacji, transportu i rozliczeń. W takim środowisku pojedyncze zadanie rzadko jest naprawdę pojedyncze. Jedna zmiana w zamówieniu potrafi wpłynąć na cenę, termin, materiały, pliki, produkcję, pakowanie, dostawę i fakturę.

W CV można napisać „koordynacja procesu”, ale to nadal tylko dwa słowa. Chciałem więc zbudować przykład, na którym da się zobaczyć, co pod tym pojęciem rozumiem. Tak powstał pomysł demonstracyjnego projektu ZIELONA MARKA.

Najtrudniejsze nie było dodawanie funkcji, tylko wybieranie tego, co naprawdę potrzebne.

Początkowo lista elementów rosła bardzo szybko. Oferta, negocjacje, proforma, zaliczka, pliki, preflight, produkcja, introligatornia, kontrola jakości, transport, faktura, reklamacje i raportowanie. Do tego role pracowników, sezonowość, koszty, flota i dokumenty.

W pewnym momencie zrozumiałem, że profesjonalny projekt nie polega na umieszczeniu wszystkiego na jednym ekranie. Ważniejsza jest czytelna odpowiedź na trzy pytania: kto wykonuje dany krok, na podstawie jakich danych oraz co musi się wydarzyć, aby proces mógł przejść dalej.

Ta zasada stała się szkieletem całego rozwiązania: etap, właściciel, status, warunek przejścia i ślad decyzji.

Arkusz był pierwszym modelem, bo dobrze pokazuje zależności.

Zacząłem od rozpisania procesu w arkuszu. Nie traktowałem go jak zwykłej tabeli. Miał być wspólnym modelem dla handlu, przygotowalni, produkcji, jakości, logistyki, administracji i osoby zarządzającej całością.

Dodałem zależności między etapami, pola kontrolne, KPI, koszty, terminy i odpowiedzialności RACI. Założenie było proste: osoba z danego działu powinna widzieć przede wszystkim swój zakres, natomiast właściciel procesu musi rozumieć cały przepływ i miejsca ryzyka.

Wszystkie rekordy zostały przygotowane jako syntetyczne. Nie przenosiłem do projektu danych klientów, pracowników ani prawdziwych dokumentów. Zależało mi, żeby pokazać strukturę i logikę bez naruszania poufności.

Potem pojawiło się pytanie: jak ten proces zobaczy klient i jak zobaczą go działy?

Sam arkusz był dobrym fundamentem, ale nie pokazywał doświadczenia użytkownika. Dlatego powstał portal demonstracyjny. Klient może sprawdzić przykładowy status zlecenia, a działy widzą własne kolejki i kolejne kroki.

Portal przygotowałem jako PWA, czyli stronę, którą można dodać do ekranu telefonu i uruchamiać podobnie jak aplikację. Działa na Androidzie, iPhonie i komputerze, a podstawowy interfejs jest dostępny również po utracie połączenia. Wersja publiczna zapisuje zmiany wyłącznie lokalnie w przeglądarce.

To celowe ograniczenie. Portfolio nie udaje gotowego systemu produkcyjnego. Nie ma prawdziwych kont, płatności ani centralnej bazy klientów.

Python i SQLite wykorzystałem tam, gdzie potrzebna była logika, a nie tylko prezentacja.

Kolejnym krokiem był lokalny PrintFlow Control Center. Chciałem sprawdzić, jak proces zachowa się po dodaniu walidacji, ról, historii zmian, alertów i danych przechowywanych w relacyjnej bazie.

Python obsługuje logikę aplikacji i proste API, SQLite przechowuje demonstracyjne zlecenia oraz historię statusów, a JSON służy do konfiguracji i eksportu. Dzięki temu projekt nie kończy się na makiecie. Można go uruchomić lokalnie, dodać rekord, przejść przez etapy i zobaczyć wynik działania reguł.

Testy dodałem dlatego, że działający ekran to jeszcze nie dowód jakości.

Najwięcej uczą sytuacje, w których coś nie powinno się wydarzyć. Zlecenie nie powinno przejść dalej bez wymaganych danych. Zamkniętego procesu nie można przesuwać ponownie. Rola przypisana do jednego obszaru nie powinna zarządzać przypadkowym etapem.

Dlatego przygotowałem przypadki testowe, checklisty smoke i regresji, raporty defektów oraz testy automatyczne. Sprawdzają między innymi walidację, API, bazę SQLite, role, alerty, eksport i bezpieczeństwo ścieżek. Osobne kontrole obejmują też portal PWA i publiczne narzędzia strony.

Narzędzia AI przyspieszyły pracę, ale nie zastąpiły decyzji.

W projekcie korzystałem z narzędzi wspierających porządkowanie materiału, pracę nad kodem, kontrolę spójności oraz testy. Żadnej automatycznie przygotowanej odpowiedzi nie traktowałem jednak jako gotowego wyniku. Każdy etap wymagał sprawdzenia: czy pasuje do rzeczywistego procesu, czy nie tworzy fałszywej deklaracji i czy nie ujawnia danych, które powinny pozostać prywatne.

Dla mnie właśnie na tym polega rozsądne użycie AI w pracy: narzędzie może przyspieszyć analizę i wykonanie, ale odpowiedzialność za sens, jakość oraz końcową decyzję nadal pozostaje po stronie człowieka.

Co ten projekt mówi o mojej pracy?

Najważniejszym rezultatem nie jest sama strona ani liczba użytych technologii. Jest nim spójny model, który łączy doświadczenie operacyjne, dane i komunikację z prostym narzędziem cyfrowym.

Projekt pokazał mi też, że potrafię przejść od wiedzy praktycznej do dokumentacji, od dokumentacji do prototypu, a następnie sprawdzić rezultat z perspektywy użytkownika i jakości. To właśnie tę umiejętność chcę rozwijać dalej w pracy związanej z koordynacją operacyjną, administracją, raportowaniem i usprawnianiem procesów.