Problem · system a ludzie
Ludzie ciągle robią błędy w systemie. To rzadko wina ludzi.
Najczęstsza przyczyna, jaką spotykam, jest banalna i prawie nigdy nie pada na spotkaniu: system zaprojektowano dla jednej grupy, a korzysta z niego zupełnie inna. Wtedy „nieuwaga” jest tylko objawem i żadne szkolenie tego nie ruszy.
Bogusław Tolarz · aktualizacja: 19 sierpnia 2026
Jak to wygląda na co dzień
- Szkolenia się odbyły, część osób przeszkolono dwa razy, a te same błędy wracają.
- Obok systemu żyje drugi obieg: kartki, notatki w telefonie, ustalenia na grupowym czacie.
- Ludzie wypełniają pola „byle przejść dalej”, bo system wymaga informacji, której w tym momencie nie mają.
- Błąd widać dopiero w biurze, godziny albo dni po tym, jak powstał — i nikt już nie pamięta kontekstu.
- Rozmowa o tym kończy się słowem „nieuważni”, a nie pytaniem, dlaczego akurat w tym miejscu.
Jak to wygląda w praktyce
Przykład ilustrujący — nie opis konkretnej firmy
Firma zamawia system do obsługi zleceń. Rozmowy prowadzi dział, który planuje pracę i potem ją rozlicza — bo to oni wiedzą, jakie dane są potrzebne na końcu. System powstaje dokładnie pod nich i z ich punktu widzenia jest bardzo dobry.
Tylko że wypełniają go monterzy w terenie. Nie mieli głosu przy projektowaniu i mają zupełnie inne warunki: telefon zamiast dwóch monitorów, kilka minut zamiast spokojnego popołudnia, brak zasięgu w piwnicy, rękawice. Formularz, który w biurze jest logiczny, na miejscu okazuje się nie do wypełnienia bez kombinowania.
Po pół roku firma widzi, że dane są dziurawe, i wyciąga wniosek, że ekipa jest niesolidna. Zamawia szkolenia. Sytuacja poprawia się na dwa tygodnie. Nikt w tym czasie nie zadał pytania, dla kogo ten ekran w ogóle zaprojektowano.
Skąd biorą się te pomyłki
System kupiono dla biura, a używa go teren
Ekran projektowano pod osobę, która siedzi przy biurku, ma dwa monitory i pełen kontekst zlecenia. Realnie klika w niego ktoś na dworze, w rękawicach, w słońcu odbijającym się od ekranu, między jednym zadaniem a drugim.
Kolejność pól nie zgadza się z kolejnością pracy
Formularz odzwierciedla to, jak dane są potrzebne w rozliczeniu — a powstają w zupełnie innej kolejności. Człowiek musi wtedy przeskakiwać po ekranie albo zapamiętywać — i tu wchodzi pomyłka.
Wymagane jest to, czego w danym momencie nie da się wiedzieć
Pole obowiązkowe, którego wartość będzie znana dopiero za godzinę. System nie przepuszcza dalej, więc ktoś wpisuje cokolwiek — i od tej chwili dane są nieprawdziwe, choć komplet się zgadza.
Zgłoszenie problemu nie ma dokąd trafić
Osoba w terenie widzi błąd pierwsza, ale nie ma jak go zgłosić inaczej niż przez przełożonego, więc zwykle nie zgłasza. Informacja zwrotna, na której najbardziej zależy, nigdy nie wraca do tego, kto mógłby to naprawić.
Jak to sprawdzam
Ta diagnoza jest tania i szybka, pod jednym warunkiem: trzeba wyjść z sali konferencyjnej.
Patrzę, jak ta praca wygląda naprawdę
Na stanowisku, w trakcie zwykłego dnia. Połowa odpowiedzi jest widoczna w pierwszej godzinie: co ludzie mają w rękach, ile mają czasu, co robią, zanim w ogóle dotkną telefonu.
Zbieram obejścia
Każda kartka, notatka i wiadomość na czacie obok systemu to gotowa mapa jego braków. Ludzie rzadko potrafią powiedzieć, co jest źle zaprojektowane — ale zawsze pokażą, jak sobie z tym radzą.
Sprawdzam, w którym polu powstaje błąd
Nie „ilu ludzi się myli”, tylko „które konkretnie miejsce w formularzu generuje pomyłki”. Zwykle okazuje się, że chodzi o jedno albo dwa pola.
Pytam, co się dzieje po błędzie
Kto to wychwytuje, po jakim czasie i ile kosztuje poprawienie. To rozstrzyga, czy w ogóle warto tu cokolwiek zmieniać — czasem odpowiedź brzmi: nie warto.
Co bym z tym zrobił
Zmieniłbym narzędzie
Jeśli błąd powtarza się u wielu osób w tym samym miejscu, to jest cecha systemu. Szkolenie da poprawę na dwa tygodnie, bo walczy z objawem.
Zacząłbym od najmniejszej możliwej zmiany
Bardzo często wystarczy jeden ekran zaprojektowany pod tę grupę użytkowników — z trzema polami zamiast dwudziestu — postawiony obok istniejącego systemu, a nie zamiast niego. To robota na dni.
Przeniósłbym walidację tam, gdzie powstaje dana
System powinien mówić „to się nie zgadza” w momencie wpisywania, przy człowieku, który jeszcze pamięta kontekst — a nie tydzień później w zestawieniu, gdy poprawia to ktoś inny na podstawie domysłów.
Dałbym drogę powrotną dla zgłoszeń
Najtańsze źródło informacji o tym, co poprawić dalej, to ludzie, którzy używają systemu codziennie. Wystarczy, żeby mieli gdzie to wpisać i żeby widzieli, że coś się z tym dzieje.
Powtarzające się wzorce
- Nie dokładałbym kolejnego szkolenia jako pierwszej odpowiedzi. Jeśli dwa nie pomogły, trzecie nie pomoże.
- Nie wprowadzałbym kontroli ani rozliczania z błędów — to nie zmniejsza liczby pomyłek, tylko liczbę zgłoszeń o nich.
- Nie wymieniałbym całego systemu, dopóki nie wiem, które konkretnie miejsca są nie do uratowania.
- Nie zbierałbym opinii ankietą. Ludzie opisują to, co pamiętają; różnica wobec tego, co faktycznie robią, bywa większa, niż się wydaje.
Rozpoznanie tego u siebie jest trudniejsze niż zrozumienie samej zasady.
Firma patrzy na własny proces oczami tych, którzy go zamawiali — i to jest zupełnie naturalne. Dlatego rozjazd między „dla kogo zaprojektowano” a „kto tego używa” jest z zewnątrz widoczny w kilka godzin, a od środka bywa niewidoczny latami.
Potem trzeba zdecydować, co z tym zrobić. Poprawka jednego ekranu, dołożenie osobnego widoku dla terenu i wymiana systemu różnią się kosztem o dwa rzędy wielkości — a wyglądają na tym etapie podobnie sensownie.
Opisz, kto się myli i w którym miejscu.
Nie musisz mieć gotowej diagnozy. Wystarczy, że napiszesz, kto korzysta z systemu, co w nim robi i gdzie najczęściej coś idzie nie tak. Odpowiem, czy to wygląda na problem projektu, czy faktycznie na coś innego.
Pokrewny przypadek: dwie aplikacje, między którymi dane przenosi człowiek →