Mała zmiana, dziewięć miesięcy opóźnienia

Miałem kiedyś wymienić sterownik PLC. Brzmiało jak prosta zmiana komponentu — nowsza wersja, lepsza dostępność, mniej ryzyka zakupowego. Skończyło się na 9 miesiącach pracy, 7 dotkniętych obszarach i recertyfikacji UL.

Tak wygląda „mała zmiana” w firmie HW+SW bez kontroli ECR/ECO.

Efekt domina

Powód wymiany był prozaiczny: stary sterownik zbliżał się do end-of-life. Firma musiała wdrożyć następcę. Na papierze wyglądało to jak rozsądna decyzja — jeden komponent za drugi, nowszy, z lepszą dostępnością.

Ale tu zaczął się problem. Okazało się, że to nie była tylko wymiana PLC.

Trzeba było:

przetestować nowy sterownik w laboratorium,
zaktualizować dokumentację techniczną, bo piny w diagramach elektrycznych były opisane inaczej,
przygotować nową wersję obrazu systemu,
utrzymywać równolegle software dla starej i nowej wersji PLC,
testować oba warianty, bo urządzenia z poprzednią wersją nadal istniały w terenie,
ponownie przejść certyfikację UL, ponieważ PLC był krytycznym komponentem dla bezpieczeństwa systemu.

Jedna zmiana komponentu. Jedna mała zmiana w hardware.

Efekt: praca dla engineeringu, software, dokumentacji, testów, compliance, produkcji i serwisu. Cała organizacja obsługiwała konsekwencje decyzji, która siedziała w mailach i rozmowach — nigdy w formalnym zatwierdzeniu.

9 miesięcy. I nikt nie powiedział na początku: „to będzie drogo”.

W produktach hardware+software najdroższe zmiany nie zawsze wyglądają groźnie na początku. Często wyglądają jak rozsądna, techniczna decyzja: nowszy komponent, lepsza dostępność, prostszy zakup.

Problem zaczyna się wtedy, gdy nikt przed wdrożeniem nie zada pytania:

Co ta zmiana naprawdę pociąga za sobą?

W oprogramowaniu zmiana zostawia ślad w repozytorium. W HW+SW musi zostawić ślad także w dokumentacji, produkcji, konfiguracji systemu, certyfikacji, serwisie i urządzeniach, które już pracują u klientów. Jeśli tego śladu nie ma, firma zaczyna zgadywać.

Najdroższe zmiany to nie te największe. Najdroższe są te, które ktoś uznał za zbyt małe, żeby je formalnie ocenić.

Dlaczego „mała zmiana” brzmi niewinnie

„To tylko mała zmiana” — to zdanie słyszysz w każdej firmie tuż przed katastrofą.

Bo przecież:

nie zmieniamy funkcji produktu,
klient nawet tego nie zauważy,
software da się szybko przepiąć,
dokumentację poprawimy później,
testy będą takie same,
produkcja „jakoś to ogarnie”.

I czasem to wszystko jest prawdą. Tylko nie całą.

Mała zmiana w produkcie hardware+software rzadko kończy się na jednym miejscu. Zostawia ślad w kodzie, konfiguracji, schematach, instrukcjach, procedurach testowych, BOM-ie, dokumentach jakościowych i serwisie. Jeśli ten ślad jest świadomie prowadzony, firma płaci raz. Jeśli nie, zaczyna płacić przy każdej kolejnej decyzji.

Są tu dwa rodzaje długu.

Pierwszy to dług techniczny. Powstaje wtedy, gdy produkt działa, ale coraz trudniej go rozwijać. Kod ma wyjątki. Konfiguracje różnią się między wersjami. Testy przestają być jednoznaczne. Zespół wie, że „dla tej wersji trzeba zrobić inaczej” — tylko ta wiedza siedzi w głowach kilku osób.

Drugi to dług dokumentacyjny. Bardziej nudny, ale często droższy. W historii zmian nie ma decyzji — tylko efekty. Nikt nie zapisał, dlaczego ten komponent, a nie inny. Wpływ na certyfikację, produkcję i serwis gdzieś po drodze wyparował. Zmiana w hardware i zmiana w software to dwa zdarzenia, między którymi nikt nie postawił połączenia.

Przy wymianie sterownika PLC największy koszt nie pojawił się w żadnym harmonogramie — ani przy pozycji „nowy sterownik”, ani przy żadnej konkretnej linii kodu.

Kosztem było życie przez wiele miesięcy w dwóch równoległych światach.

Stary PLC nadal pracował w urządzeniach w terenie. Nowy PLC wchodził do kolejnych wersji produktu. To oznaczało dwie gałęzie software, dwie ścieżki testów, dwa zestawy zachowań, które trzeba było rozumieć i utrzymywać.

Każda poprawka wymagała pytania: czy dotyczy starej wersji, nowej wersji, czy obu? Jeśli obu — trzeba było wdrożyć ją dwa razy, przetestować dwa razy, upewnić się, że dokumentacja i serwis nie rozjechały się po drodze.

To nie wygląda dramatycznie na jednym spotkaniu statusowym. Jedna poprawka tu, jeden test tam. Ale po kilku miesiącach robi się z tego codzienny podatek od wcześniejszej zmiany. Niewidoczny w planie. Bardzo widoczny w pracy zespołu.

Harmonogram nie rozpada się w dniu podjęcia złej decyzji. Rozpada się wtedy, gdy firma musi odtworzyć historię zmian, których nie zapisała.

ECR/ECO — co to jest i dlaczego małe firmy tego nie robią

Firmy, które to opanowały, nie polegają na pamięci inżynierów. Mają mechanizm, który zatrzymuje zmianę na 30–60 minut, zanim wygeneruje 3 miesiące chaosu. Ten mechanizm to ECR/ECO: Engineering Change Request (wniosek z opisem zmiany i jej wpływu) i Engineering Change Order (zatwierdzona decyzja wdrożeniowa z datą, wersjami i odpowiedzialnościami).

Małe firmy często tego nie robią:

„Jesteśmy za mali.” „Za dużo papierologii.” „Nie mamy czasu.”

Ten ostatni argument jest najdroższy: 1,5 godziny na ocenę wpływu zmiany vs 20 godzin na gaszenie pożaru. Albo 200 godzin, jeśli problem wyjdzie u klienta lub na certyfikacji.

Jeśli myślisz: „Mamy mały zespół, rozmowy wystarczają” — zrób prosty test. Zapytaj trzy różne osoby w firmie, jaka wersja PCB stoi u klienta X. Jeśli dostaniesz różne odpowiedzi albo „trzeba sprawdzić u Tomka”, rozmowy nie wystarczają. Masz wiedzę w ludziach, nie w systemie.

Lekki proces to godzina, może dwie, na każdą zmianę. Brak procesu to kilkadziesiąt godzin na każdy pożar, który z niej wyniknie. Na własnym przykładzie: recertyfikacja UL nie jest darmowa, a „podmiana PLC” zajęła ponad 9 miesięcy — i nikt tego w harmonogramie nie wpisał jako koszt zmiany.

ECR/ECO nie musi oznaczać SAP-a ani Windchilla. Chodzi o jedno pytanie zadane przed każdą zmianą: Co ta zmiana pociąga za sobą?

Lekki proces kontroli zmian — jak zacząć bez biurokracji

Firma 20–80 osób nie potrzebuje ciężkiego systemu. Potrzebuje czterech elementów.

1. Trzy pytania przed każdą zmianą:

Co dokładnie się zmienia? — nie „poprawiamy złącze”, tylko: które, w której rewizji, z jakiego powodu. Jeśli nie da się opisać jednym akapitem, zmiana prawdopodobnie nie jest taka mała.
Na co ta zmiana wpływa? — krótka checklista: hardware, firmware, BOM, dostawcy, dokumentacja, certyfikacja, produkcja, serwis, sprzedaż. Najważniejsza odpowiedź to „nie wiem” — nie blokuje zmiany, mówi tylko: ktoś musi sprawdzić zanim wdrożymy.
Kto zatwierdza i bierze odpowiedzialność? — jedna konkretna osoba, nie „wszyscy”.

2. Jeden rekord zmiany — numer, opis, powód, produkty i wersje, ocena wpływu, właściciel, zatwierdzenie, data, linki do dokumentów. Narzędzie drugorzędne: Notion, Jira, arkusz — co macie.

3. Jeden rejestr zmian — wszystkie zatwierdzone zmiany w jednym miejscu, z numerem seryjnym lub rewizją od której zmiana obowiązuje. Nie w mailach, nie na Slacku.

4. Definicja zamknięcia — zmiana nie jest zamknięta, kiedy inżynier „wrzucił poprawkę”. Jest zamknięta, kiedy zaktualizowane są: projekt, BOM, firmware, testy, instrukcje produkcyjne, dokumentacja klienta i serwisowa, oznaczenia wersji.

Najtrudniejsze nie jest stworzenie szablonu. Najtrudniejsze jest ustalenie, gdzie zmiana naprawdę powstaje, kto ją faktycznie zatwierdza i jak trafia do produkcji, dokumentacji i serwisu. W każdej firmie wygląda to inaczej.

Sygnały, że twoja firma ma problem ze zmianami

Zaznacz, które z poniższych dotyczą twojej firmy:

Serwisanci nie wiedzą, jaka wersja produktu jest u klienta — pytają trzy osoby, szukają w mailach
Dokumentacja nie nadąża za hardware — „prawie aktualna” to nie to samo co aktualna
„Poprawki” są odkrywane podczas wdrożenia u klienta, nie przez firmę
Każda zmiana wymaga spotkania pięciu osób, bo nie ma rejestru decyzji
Nikt nie wie, które zmiany weszły do której partii produkcyjnej
Zakupy zmieniają komponenty z powodu dostępności, a engineering dowiaduje się po fakcie
Nowy inżynier przez pierwsze tygodnie odtwarza historię produktu z rozmów, nie z dokumentów
Zespół boi się ruszać produkt, bo „nie wiadomo, co się wysypie”

3+ punktów: problem już istnieje — kolejna zmiana prawdopodobnie wejdzie do produkcji bez oceny wpływu.
5+ punktów: ryzykujesz opóźnienia serii i błędne serwisy w terenie.
7–8 punktów: zmianami nie zarządzasz — tylko je gasisz.

Najlepszy moment na uporządkowanie był przed pierwszą większą serią produkcyjną. Drugi najlepszy jest teraz.

Jeśli 3+ objawów dotyczy twojej firmy, następna zmiana wejdzie do produkcji bez oceny wpływu. Pytanie nie brzmi czy, tylko przy której.

Product Control Review to 90-minutowe spotkanie dla firm HW+SW z rosnącą liczbą rewizji, zmian i urządzeń w terenie. Bierzemy ostatnie 3–5 realnych zmian z twojej firmy i sprawdzamy, gdzie uciekła kontrola: decyzja, wpływ, zatwierdzenie, numer seryjny, dokumentacja, serwis.

Bez SAP-a, bez Windchilla, bez procedur do procedur.

Po spotkaniu masz: mapę przepływu zmian, 3–5 konkretnych luk i priorytetową listę ryzyk oraz checklistę do użycia przy następnej zmianie.

Umów Product Control Review →