Od problemów z terminowością do pełnej kontroli…

Właścicielem przedsiębiorstwa jest fundusz inwestycyjny aktywnie zaangażowany w zarządzanie spółką, nieograniczający się do analizy wyników finansowych. Oczekiwania wobec zarządu i organizacji są ambitne: dalszy wzrost, poprawa efektywności operacyjnej, większa przewidywalność realizacji oraz stworzenie systemu zdolnego obsłużyć rosnącą skalę biznesu bez proporcjonalnego zwiększania kosztów.

Jednym z kluczowych obszarów funkcjonowania zakładu są projekty wdrażania nowych produktów do produkcji (new product introduction, NPI). Jest to cały proces od otrzymania zapytania i dokumentacji klienta, przez przygotowanie technologii, konstrukcji i oprzyrządowania, wykonanie pierwszych detali, aż po przygotowanie oraz dostarczenie klientowi próbki lub partii próbnej (sample) do zatwierdzenia.

Rys. 1. Proces NPI – od zapytania klienta do produkcji seryjnej (akceptacja próbki jako brama biznesowa)

I właśnie ten ostatni etap ma fundamentalne znaczenie biznesowe. W tym modelu produkcyjnym samo zainteresowanie klienta, a nawet pozytywna ocena oferty, nie oznaczają jeszcze zamówienia seryjnego. Producent musi najpierw udowodnić, że potrafi wytworzyć wymagany produkt zgodnie ze specyfikacją, w oczekiwanej jakości i w uzgodnionym terminie. Dopiero akceptacja próbki lub partii wzorcowej przez klienta otwiera drogę do uruchomienia produkcji seryjnej.

Proces NPI nie jest zatem procesem pomocniczym ani technicznym zapleczem sprzedaży. Jest jednym z najważniejszych elementów procesu zdobywania przychodów. Jeżeli zakład szybko i przewidywalnie przeprowadza nowe wdrożenie, przygotowuje oprzyrządowanie, wykonuje próbki i uzyskuje ich akceptację, zwiększa swoje szanse na pozyskanie produkcji seryjnej. Jeśli jednak proces się przeciąga, terminy są niewiarygodne, a próbki nie spełniają oczekiwań jakościowych, klient może skierować zamówienie do innego dostawcy.

W tym biznesie sprawność NPI wpływa bezpośrednio na przyszły portfel produkcyjny zakładu. Dlatego problemy z terminowością projektów NPI, które początkowo wyglądały niemal jak kwestia organizacyjna lub projektowa, w rzeczywistości dotyczyły zdolności firmy do skutecznego konkurowania o przyszłe zamówienia.

Punktem wyjścia transformacji nie był kryzys firmy, lecz coś bardziej interesującego – bardzo szybki wzrost biznesu. W ciągu kilku lat przychody organizacji wzrosły o ponad 200 proc., a liczba nowych wdrożeń i przygotowywanych próbek rosła jeszcze szybciej. To, co sprawdzało się przy mniejszej skali, zaczęło stopniowo tracić efektywność.

Poszczególne działy radziły sobie z rosnącą liczbą zadań, tworząc własne rozwiązania lokalne. Dział konstrukcyjny optymalizował swoją kolejkę, podobnie narzędziownia (tool shop) oraz działy obróbki sterowanej numerycznie (computer numerical control, CNC), technologii czy jakości. Każdy z wypracowanych mechanizmów miał uzasadnienie operacyjne, ale wraz ze wzrostem liczby równoległych projektów coraz trudniej było zsynchronizować cały przepływ NPI od początku do końca.

W rezultacie organizacja coraz częściej pracowała w trybie reaktywnym. Zmiana priorytetu jednego ważnego projektu wpływała na kolejne. Pilne zlecenia wypierały wcześniej zaplanowaną pracę, a decyzje racjonalne z perspektywy pojedynczego działu nie zawsze prowadziły do najlepszego wyniku dla całego portfela.

Największym ograniczeniem była jednak widoczność. Dane istniały, ale były rozproszone między system planowania zasobów przedsiębiorstwa (ERP), lokalne arkusze Excel i wiedzę poszczególnych osób. System ERP bardzo dobrze obsługiwał finanse, magazyn oraz produkcję seryjną, ale nie został zaprojektowany do zarządzania dynamicznym portfelem projektów NPI. Uzyskanie odpowiedzi na proste pytania – ile projektów jest obecnie aktywnych, gdzie dokładnie się znajdują, które są zagrożone i kiedy realnie zostaną zakończone – wymagało zebrania informacji z wielu miejsc. Nie był to więc problem braku danych. Problem polegał na braku jednego aktualnego obrazu sytuacji. Przy kilkudziesięciu projektach taki model można obsługiwać dzięki doświadczeniu menedżerów i bezpośredniej komunikacji. Przy kilkuset równoległych wdrożeniach potrzebny jest już zupełnie inny system zarządzania.

Pierwsza diagnoza szybko pokazała, że opóźnienia projektów nie miały jednej przyczyny. Nie chodziło też o to, że ludzie pracowali za wolno. Problem był systemowy – organizacja urosła szybciej niż sposób planowania, priorytetyzacji i zarządzania przepływem między działami.

Najważniejszym zjawiskiem była duża liczba równolegle realizowanych projektów. Każdy nowy projekt angażował kolejne obszary – konstrukcję, technologię, narzędziownię, CNC, komponenty, montaż czy jakość – ale nie wszystkie dysponowały taką samą przepustowością (throughput). Uruchamianie kolejnych projektów nie zawsze przekładało się więc na większą liczbę zakończonych wdrożeń. Rosła jednak kolejka pracy przed zasobami, które stanowiły ograniczenie całego systemu.

Drugim problemem była priorytetyzacja. Przy dużej presji klientów przyspieszanie projektów najpilniejszych było naturalną reakcją. Jeżeli jednak priorytety zmieniają się często, zasób przerywa rozpoczętą pracę, przechodzi do kolejnego zadania, a następnie wraca do poprzedniego. Konstruktor przerywa projekt A, aby zająć się pilniejszym projektem B, a po dwóch dniach wraca do projektu A – i musi od nowa odtworzyć okoliczności, przypomnieć sobie założenia i sprawdzić, co tymczasem się zmieniło. Oba projekty właśnie się wydłużyły, mimo że nikt nie pracował wolniej. Z perspektywy pojedynczego projektu takie działanie może być uzasadnione. Z perspektywy całego portfela zwiększa to produkcję w toku (work in progress, WIP), wydłuża czas przejścia projektu przez proces (lead time) i zmniejsza przewidywalność.

Kolejnym elementem były różne sposoby planowania w poszczególnych działach. Część pracy była widoczna w systemie ERP, część w lokalnych arkuszach Excel, a część funkcjonowała przede wszystkim jako wiedza operacyjna zespołów. Brakowało mechanizmu, który łączyłby wszystkie informacje w spójny harmonogram projektu i pozwalał zobaczyć natychmiastowy wpływ opóźnienia pojedynczego zadania na termin dostarczenia próbki.

Istotnym problemem okazała się również jakość informacji o postępie. Sam status „w realizacji” niewiele mówi o tym, kiedy zadanie rzeczywiście zostanie zakończone. Dlatego jednym z kluczowych elementów nowego standardu stało się konsekwentne zarządzanie przewidywanym terminem zakończenia (estimated time to completion, ETTC) oraz jego regularna aktualizacja przez osoby odpowiedzialne za wykonanie pracy.

Diagnoza ujawniła również pracę nie zawsze w pełni widoczną w harmonogramach. Dobrym przykładem są braki produkcyjne i poprawki (scrap and rework). Jeżeli wykonane oprzyrządowanie lub komponent wymaga poprawy albo ponownego wykonania, powstaje rzeczywista dodatkowa praca, która zużywa dostępne zdolności produkcyjne. Jeżeli nie zostanie zarejestrowana jako nowe zadanie, system nadal pokazuje projekt jako znacznie bardziej zaawansowany, niż jest on w rzeczywistości.

Do tego dochodził klasyczny problem optymalizacji lokalnej. Każdy dział starał się maksymalnie wykorzystać własne zasoby, podczas gdy z perspektywy całego systemu nie zawsze było to potrzebne. W produkcji projektowej kluczowe nie jest maksymalne wykorzystanie każdego stanowiska, lecz maksymalizacja przepływu projektów przez ograniczenia systemu.

Z diagnozy wynikał ważny wniosek: nie da się trwale poprawić terminowości, przyspieszając jeden po drugim pojedyncze projekty. Trzeba zbudować system jednocześnie zarządzający portfelem, priorytetami, przepływem pracy, rzeczywistym obciążeniem zasobów oraz odpowiedzialnością za aktualność danych. To właśnie stało się fundamentem nowego modelu zarządzania NPI.

Pierwszym krokiem było zbudowanie wspólnego standardu realizacji projektu NPI. Powstał referencyjny szablon obejmujący wszystkie zadania: od rozpoczęcia wdrożenia do wysyłki próbki. Dla każdego zadania określiliśmy odpowiedzialność, potrzebne zasoby, zależności, czas trwania oraz pracochłonność. To rozróżnienie okazało się bardzo ważne, ponieważ czas obecności zadania w harmonogramie nie jest tym samym co czas pracy człowieka lub maszyny.

Dobrym przykładem jest malowanie próbki. Cały etap może trwać dwa dni, ponieważ obejmuje przygotowanie i malowanie, następnie schnięcie, a na końcu zabezpieczenie, pakowanie i przekazanie do logistyki. Rzeczywiste zaangażowanie pracownika może jednak wynosić jedną godzinę na wejściu oraz kolejną godzinę na zakończenie procesu. Mamy więc dwa dni czasu trwania, ale tylko dwie godziny pracochłonności. Bez takiego rozróżnienia nie da się wiarygodnie planować ani terminów projektów, ani obciążenia zasobów.

Rys. 2. Czas trwania a pracochłonność na przykładzie malowania próbki: dwa dni wobec dwóch godzin

Na bazie tego standardu rozpoczęliśmy budowę aplikacji integrującej informacje z systemu ERP, lokalnych tablic Kanbanoraz arkuszy Excel. Jej zadaniem było automatyczne odtworzenie harmonogramów wszystkich projektów w toku: pokazanie ich rzeczywistego stanu, pracy pozostałej do wykonania oraz przewidywanego terminu zakończenia całego procesu – aż do wysyłki próbki do klienta.

Rys. 3. Od rozproszonych danych (ERP, Excel, Kanban, wiedza ludzi) do jednego harmonogramu portfela

Samo stworzenie oprogramowania było jednym z najtrudniejszych elementów transformacji i zajęło trzy miesiące. Nie wystarczyło połączenie kilku źródeł danych. Najpierw musieliśmy zrozumieć logikę każdego z nich, a następnie zbudować system reguł i wyjątków. Trzeba było rozstrzygnąć, która informacja jest nadrzędna, jeżeli system ERP, tablica Kanban i lokalny Excel pokazują różne statusy tego samego zadania. Konieczne było także ustalenie, jak interpretować brak danych, jak identyfikować zadania rozpoczęte poza systemem oraz jak przeliczać wpływ jednej zmiany na wszystkie kolejne etapy projektu.

Dopiero wtedy mogliśmy uruchomić i przeliczyć harmonogramy wszystkich 280 projektów NPI. Po raz pierwszy organizacja zobaczyła nie tylko, które projekty są opóźnione, lecz również dlaczego i w którym miejscu powstaje opóźnienie. Obraz był jednoznaczny: w niektórych działach zaplanowana praca przekraczała 200 proc. dostępnych zdolności realizacyjnych. Nawet przy pełnej mobilizacji zespołów nie było fizycznej możliwości wykonania wszystkich zadań w oczekiwanych terminach.

Sama widoczność nie rozwiązała jednak problemu. Pokazała jego rzeczywistą skalę i pozwoliła przejść do stabilizacji operacyjnej – swoistego OIOM-u dla portfela projektów. Jak na oddziale ratunkowym, najpierw trzeba było przeprowadzić triaż: rozstrzygnąć, co wymaga natychmiastowej interwencji, co może poczekać, a czego przy dostępnych siłach nie da się teraz uratować.

Powołaliśmy interdyscyplinarny Zespół Odbudowy (Recovery Team), któremu postawiliśmy jednoznaczne zadanie: odzyskać kontrolę nad portfelem i skoncentrować ograniczone zasoby na projektach najważniejszych dla firmy oraz jej klientów. Wszystkie projekty otrzymały priorytet od 1 do 4. Do grupy z priorytetem 4 trafiły te projekty, których przy istniejących ograniczeniach organizacja i tak nie była w stanie zrealizować w zakładanym czasie. Była to trudna, ale konieczna decyzja. Zamroziliśmy 47 proc. projektów. Zamiast nadal deklarować jednoczesną realizację wszystkiego, skupiliśmy ludzi i dostępne zdolności na najważniejszej części portfela. Po raz pierwszy było wyraźnie widać, gdzie znajduje się każdy aktywny projekt, co blokuje jego dalszy przepływ i które zadanie wymaga interwencji.

Rys. 4. Stabilizacja portfela: przeciążenie ponad 200 proc., triaż priorytetów i zamrożenie 47 proc. projektów

W tym momencie rozpoczął się drugi etap wdrożenia – najciekawszy, lecz również najtrudniejszy. Technologia pokazała prawdę o portfelu. Teraz trzeba było zmienić sposób zarządzania: zmierzyć się z błędnym przekonaniem, że wszystko jest równie ważne, rozwinąć wiedzę i umiejętności menedżerskie kadry technicznej, stworzyć nową strukturę zarządczą oraz opisać proces prowadzenia portfela poprzez jednoznaczne wskazanie, kto, co, kiedy, dlaczego i w jaki sposób robi każdego dnia.

Uruchomiliśmy także codzienną, w około 80 proc. zautomatyzowaną aktualizację wszystkich aktywnych projektów. Dzięki temu widoczność przestała być jednorazowym zdjęciem sytuacji, a stała się codziennym mechanizmem zarządzania.

O tym, jak przebiegała walka o trwałą zmianę nawyków, jak został zbudowany nowy system zarządzania oraz w jaki sposób fabryka przeszła od stabilizacji do zwiększania przepustowości, opowiemy w kolejnym wydaniu „Production Managera”.