Cel
Jedna, kontrolowana ścieżka pracy technicznej: co jest do zrobienia, kto się tym zajmuje, co wykonano i co wymaga zatwierdzenia.
← Strona główna
PROJEKTY
Rozwiązania problemów operacyjnych
Od analizy procesu, przez projekt workflow, po wdrożenie — projekty pokazuję jako case studies, nie listę technologii.
Nie każde rozwiązanie wewnętrzne ma publiczne demo. Opisuję kontekst, problem, analizę, decyzje projektowe i wartość organizacyjną — bez danych firmowych.
Lista case studies
- Peklimar Panel
-
Analiza danych / raportowanie
-
Automatyzacja procesu
WYRÓŻNIONE CASE STUDY
Peklimar Panel
Uporządkowanie procesu utrzymania ruchu poprzez zaprojektowanie systemu wspierającego przepływ informacji — zgłoszenia awarii, przeglądy, checklisty i prace serwisowe w jednym workflow.
Projekt rozwijany w realnym środowisku produkcyjnym firmy Madej Wróbel. Publicznie opisuję zakres, podejście i decyzje projektowe — bez danych operacyjnych.
- Typ
- system wewnętrzny
- Obszar
- utrzymanie ruchu
- Użytkownicy
- dział techniczny i produkcja
- Etap
- pilotaż na produkcji
W skrócie
Użytkownicy
dział techniczny, produkcja, kierownicy i osoby wspierające utrzymanie ruchu.
Zakres
zgłoszenia, maszyny, przeglądy, checklisty, paczki pracy i historia wykonania.
Status
system rozwijany modułowo, uruchomiony pilotażowo na realnym procesie.
Case study: Peklimar Panel
firma produkcyjna z branży spożywczej · Specjalista ds. IT
Kontekst biznesowy
W zakładzie produkcyjnym dział techniczny odpowiada za utrzymanie ruchu maszyn, od których zależy ciągłość produkcji. Każda awaria, przegląd i czynność serwisowa to informacja, która musi dotrzeć do właściwej osoby, zostać wykonana i potwierdzona.
Środowisko jest wielodziałowe: produkcja zgłasza problemy, dział techniczny je obsługuje, a osoby zarządzające potrzebują wglądu w to, co zostało wykonane. Skala — wiele maszyn, zmianowość, równoległe zgłoszenia — sprawia, że pilnowanie tego ręcznie przestaje być możliwe.
Użytkownicy biznesowi potrzebowali nie kolejnego formularza, lecz uporządkowanego obiegu: od zgłoszenia problemu, przez przydział i wykonanie, po historię, która zostaje w systemie.
Problem
Informacje o zgłoszeniach, działaniach i historii były rozproszone — między rozmowami, dokumentacją papierową, notatkami i ręcznym pilnowaniem terminów. Utrudniało to kontrolę procesu utrzymania ruchu.
Przy większej liczbie maszyn brakowało jednego miejsca odpowiadającego na pytania: co jest do wykonania, kto to robi, co zostało zrobione i co wymaga zatwierdzenia.
Sam formularz zgłoszeń nie rozwiązałby tego problemu. Potrzebny był uporządkowany obieg pracy: rejestracja, przydział, realizacja, potwierdzenie i trwała historia działań — a nie tylko miejsce na wpisanie awarii.
Od problemu do rozwiązania
Punktem wyjścia nie była technologia, tylko obecny proces utrzymania ruchu.
- Analiza obecnego procesu — rozmowy z działem technicznym i produkcją, obserwacja codziennej pracy oraz spisanie, jak faktycznie przepływa informacja o awarii czy przeglądzie.
- Identyfikacja punktów problemowych — miejsca, w których informacja się urywa: brak właściciela zadania, brak śladu wykonania, brak wspólnej historii.
- Projekt workflow — jedna ścieżka pracy: zgłoszenie → przydział → wykonanie → zatwierdzenie → historia.
- Model danych — maszyny, zgłoszenia, przeglądy, checklisty i paczki pracy na wspólnym fundamencie, tak by kolejne typy prac dało się dokładać bez przebudowy systemu.
Narzędzie miało odwzorować realny sposób pracy — nie wymuszać nowego procesu.
Maszyny stanowią kontekst. Zgłoszenia, przeglądy i checklisty opisują działania. Wszystko spływa do wspólnej historii.
Przepływ informacji
Zamiast równoległych kanałów (rozmowa, papier, notatka) system porządkuje przepływ wokół jednego obiegu:
- Źródło produkcja / plan przeglądu
- Rejestracja zgłoszenie w systemie
- Obsługa dział techniczny
- Kontrola zatwierdzenie i historia
Proces projektowania rozwiązania
-
Problem biznesowy
Rozproszony obieg informacji o awariach, przeglądach i pracach serwisowych utrudniał kontrolę procesu.
-
Analiza procesu
Mapowanie obecnego obiegu: rozmowy z działem technicznym, obserwacja pracy i identyfikacja punktów, w których informacja się urywa.
-
Model danych
Zaprojektowanie wspólnego fundamentu: maszyny, zgłoszenia, przeglądy, checklisty i paczki pracy — pod realny sposób pracy organizacji.
-
Projekt workflow
Jedna ścieżka pracy od zgłoszenia, przez przydział i realizację, po weryfikację i historię — zamiast równoległych kanałów informacji.
-
Budowa rozwiązania
Rozwój modułowy, etapami, zgodnie z zaprojektowanym procesem i potrzebami działów — nie jako osobny produkt oderwany od workflow.
-
Weryfikacja
Pilotaż na realnej maszynie produkcyjnej: sprawdzenie obiegu w użyciu i dostosowanie na podstawie doświadczeń użytkowników.
-
Wdrożenie i rozwój
Uruchomienie rozwiązania w procesie utrzymania ruchu oraz dalszy rozwój wraz z potrzebami organizacji — kolejne maszyny, lokalizacje i typy prac.
Decyzje projektowe
Każda decyzja wynikała z problemu organizacyjnego i ograniczeń środowiska — nie z listy technologii.
Własne rozwiązanie zamiast gotowego systemu
- Problem
- Organizacja potrzebowała narzędzia dopasowanego do własnego sposobu pracy utrzymania ruchu — bez przebudowy procesu pod gotowy produkt.
- Decyzja
- Zaprojektować własne rozwiązanie zamiast wdrażać pełny system klasy CMMS.
- Dlaczego
- Gotowe systemy wymagają często dopasowania organizacji do narzędzia. Tutaj narzędzie miało dopasować się do istniejącego procesu i rosnąć razem z nim.
Workflow zamiast pojedynczego formularza
- Problem
- Sam zapis zgłoszenia nie daje kontroli nad wykonaniem: kto bierze pracę, co zrobiono i kto zatwierdza.
- Decyzja
- Zaprojektować pełną ścieżkę pracy — od rejestracji, przez przydział i realizację, po potwierdzenie i historię.
- Dlaczego
- Problem dotyczył obiegu informacji i odpowiedzialności, a nie braku miejsca na wpisanie awarii.
Historia działań zamiast jednorazowych zgłoszeń
- Problem
- Bez trwałego śladu wykonania trudno kontrolować prace, zatwierdzać je i odtwarzać, co działo się przy maszynie.
- Decyzja
- Budować model wokół maszyny / lokalizacji oraz historii działań, a nie wokół pojedynczego, znikającego zgłoszenia.
- Dlaczego
- Historia jest podstawą kontroli, zatwierdzania i dalszego rozwoju procesu utrzymania ruchu.
Rozwój modułowy zamiast budowy wszystkiego naraz
- Problem
- Zakres obejmuje zgłoszenia, przeglądy, checklisty i paczki pracy — zbyt dużo, by uruchamiać wszystko jednocześnie na realnym procesie.
- Decyzja
- Rozwijać rozwiązanie etapami na wspólnym fundamencie danych, zaczynając od pilotażu na realnym przypadku produkcyjnym.
- Dlaczego
- Pozwala weryfikować workflow w użyciu, dostosowywać go do potrzeb działów i dokładać kolejne typy prac bez przebudowy całego obiegu.
Rozwiązanie
Peklimar Panel porządkuje przepływ informacji w utrzymaniu ruchu: łączy zgłoszenia, maszyny, przeglądy, checklisty i prace serwisowe w jeden workflow. Każdy etap zostawia ślad — widać, co czeka, co jest w toku i co zostało zakończone.
Jedna ścieżka pracy: od zgłoszenia, przez analizę i realizację, po weryfikację i historię działań.
Przepływ informacji przed i po rozwiązaniu
Porównanie pokazuje zmianę organizacji procesu — z rozproszonych kanałów do jednej, kontrolowanej ścieżki pracy.
Przed rozwiązaniem: rozproszone zgłoszenie, rozmowa lub papier, brak jednej historii, trudniejsza kontrola wykonania. Po rozwiązaniu: zgłoszenie, rejestracja w systemie, przydział zadania, realizacja pracy, potwierdzenie wykonania, historia i kontrola.
Przed
- Rozproszone zgłoszenie
- Rozmowa / papier / wiadomość
- Brak jednej historii
- Trudniejsza kontrola wykonania
Po
- Zgłoszenie
- Rejestracja w systemie
- Przydział zadania
- Realizacja pracy
- Potwierdzenie wykonania
- Historia i kontrola
Wartość organizacyjna
Efekt nie polega na samym uruchomieniu systemu, lecz na zmianie sposobu organizacji pracy utrzymania ruchu.
- uporządkowany przepływ informacji — jeden obieg zamiast równoległych kanałów: rozmowa, papier, notatka
- centralizacja historii działań przy maszynie / lokalizacji — łatwiejsze odtworzenie wykonanych prac
- większa kontrola statusów — widać, co czeka, co jest w toku i co wymaga potwierdzenia
- czytelna odpowiedzialność w procesie — od rejestracji zgłoszenia po zatwierdzenie wykonania
Zakres systemu
Zgłoszenia awarii
Rejestrowanie problemów technicznych i ich obsługa.
Maszyny i lokalizacje
Baza maszyn, miejsc i kontekstu pracy technicznej.
Przeglądy
Harmonogramy, terminy i cykliczne czynności serwisowe.
Checklisty
Uporządkowane listy czynności do wykonania przy przeglądach.
Paczki pracy
Grupowanie wielu czynności w jedną praktyczną pracę dla technika.
Historia
Podgląd wykonania, podstawy audytu i zatwierdzania.
Moja rola
Nie ograniczałem się do stworzenia systemu. Zaprojektowałem rozwiązanie odpowiadające na konkretny problem organizacji: rozproszony obieg informacji w utrzymaniu ruchu.
Odpowiadam za analizę potrzeb, rozumienie procesu, modelowanie informacji, decyzje projektowe oraz rozwój rozwiązania razem z użytkownikami — od koncepcji po uruchomienie na realnym procesie.
- analiza potrzeb działu technicznego i produkcji
- mapowanie procesu i identyfikacja punktów, w których informacja się urywa
- projektowanie workflow i modelu informacji (maszyny, zgłoszenia, przeglądy, historia)
- podejmowanie decyzji projektowych pod ograniczenia organizacji
- weryfikacja rozwiązania z użytkownikami i dalszy rozwój systemu
Współpraca z użytkownikami
Rozwiązanie powstawało w kontakcie z osobami, które z niego korzystają — nie jako izolowany projekt techniczny.
- Zbieranie potrzeb — rozmowy z działem technicznym i produkcją o tym, jak dziś zgłaszają awarie, jak planują przeglądy i czego brakuje w codziennej pracy.
- Weryfikacja na procesie — sprawdzenie obiegu na realnym przypadku produkcyjnym, zanim zakres obejmie kolejne maszyny i typy prac.
- Iteracyjne poprawki — dostosowanie workflow i sposobu rejestracji działań na podstawie doświadczeń użytkowników z pilotażu.
System miał wspierać realną pracę działów — dlatego decyzje projektowe były weryfikowane użytkiem, nie tylko modelem.
Obszary
Narzędzia wykorzystane do realizacji
Narzędzia dobrane do zaprojektowanego workflow i modelu danych — służą realizacji rozwiązania, nie są punktem wyjścia projektu.
Dostęp i prywatność
Projekt jest rozwiązaniem wewnętrznym. Publicznie opisuję zakres, podejście i narzędzia użyte do realizacji — bez dostępu do panelu, danych produkcyjnych i szczegółów infrastruktury.
wewnętrzny system produkcyjny — dostęp ograniczony