Supplier Development – jak planować działania rozwojowe dla słabych dostawców bez mnożenia audytów i pozornej kontroli

W Supplier Development pytanie zarządcze nie brzmi, jak pomóc słabemu dostawcy, lecz czy jego rozwój jest uzasadnioną decyzją biznesową. Jeżeli organizacja miesiącami utrzymuje dostawy dzięki sortowaniu, dodatkowej kontroli wejściowej, buforom, ręcznym uzgodnieniom i stałym eskalacjom, problem nie dotyczy już pojedynczych niezgodności. Dotyczy sposobu, w jaki firma finansuje cudzą niestabilność operacyjną. Dlatego działania rozwojowe wobec dostawcy mają sens tylko wtedy, gdy prowadzą do ograniczenia ryzyka dla jakości wejścia, terminowości i ciągłości dostaw, a nie do przedłużania współpracy bez realnej poprawy. W praktyce oznacza to prostą sekwencję decyzji: najpierw ocena wpływu dostawcy i jego zdolności do poprawy, potem kwalifikacja problemu, następnie plan działań z właścicielem i kryteriami wyjścia, a na końcu rozstrzygnięcie, czy dostawcę rozwijać dalej, utrzymać warunkowo, ograniczyć czy zastąpić.

Nie każdy słaby dostawca nadaje się do rozwoju

Punktem wyjścia nie jest pytanie, jak poprawić relację z dostawcą, lecz czy organizacja może dalej opierać się na źródle dostaw, które generuje niestabilność. To rozróżnienie ma znaczenie operacyjne. Rozwój dostawcy nie jest działaniem wizerunkowym ani próbą „naprawy współpracy”, tylko narzędziem ograniczania ryzyka dla jakości wejścia, terminowości i ciągłości dostaw. Koszt słabego dostawcy pojawia się znacznie wcześniej niż reklamacja: w sortowaniu, dodatkowych kontrolach, blokadach materiału, przyspieszeniach zakupowych, opóźnieniach produkcji, nadgodzinach i stałym angażowaniu jakości do działań ratunkowych. Jeżeli firma nie odróżnia kosztu niezgodności od kosztu utrzymywania niestabilnego źródła dostaw, program rozwojowy staje się jedynie odroczeniem trudnej decyzji zakupowej.

Dlatego przed uruchomieniem działań rozwojowych trzeba odpowiedzieć na dwa pytania: jaki jest wpływ dostawcy na biznes oraz czy po jego stronie istnieje realna zdolność do poprawy. Sam wysoki poziom niezgodności nie przesądza jeszcze o kierunku działania. Inaczej ocenia się dostawcę krytycznego technologicznie, dla którego liczba alternatyw jest ograniczona, a inaczej podmiot łatwo zastępowalny, który od miesięcy nie zamyka działań korygujących i nie utrzymuje podstawowej dyscypliny wykonawczej. Supplier Development ma sens tylko wtedy, gdy dostawca jest istotny biznesowo, wykazuje zdolność do zmiany i istnieje przestrzeń do wpływu po stronie klienta, na przykład przez doprecyzowanie wymagań, stabilizację planowania, audyt procesu lub wspólny plan działań z miernikami.

Najwięcej błędów pojawia się wtedy, gdy problem jakościowy mylony jest z trwałą niewydolnością zarządczą po stronie dostawcy. Jeżeli źródłem trudności są pojedyncze luki procesowe, słaby nadzór nad zmianą, niewystarczające planowanie jakości lub brak spójnych danych, poprawa bywa możliwa. Jeżeli jednak dostawca stale nie zapewnia zasobów, nie utrzymuje terminów, nie reaguje na odchylenia, nie zamyka działań korygujących albo przerzuca odpowiedzialność na klienta, program rozwojowy nie zastąpi decyzji o ograniczeniu współpracy, czasowej blokadzie nowych zamówień albo przygotowaniu alternatywnego źródła.

Ocena nie powinna opierać się na deklaracjach, lecz na danych z własnego systemu nadzoru nad dostawcami: liczbie reklamacji, poziomie PPM, terminowości dostaw, liczbie odstępstw, czasie zamknięcia działań korygujących oraz skali kosztów ukrytych po stronie klienta. Dopiero taki obraz pozwala odróżnić dostawcę trudnego, ale rokującego, od dostawcy, który destabilizuje operacje. W tym sensie Supplier Development jest elementem zarządzania ryzykiem w łańcuchu dostaw i powinien być osadzony w tych samych zasadach decyzyjnych, co segmentacja dostawców i ocena ciągłości dostaw. Bez tego nawet dobrze opisane wskaźniki pozostaną tylko raportem; szerzej ten problem porządkuje pytanie: Jak zbudować procesowe KPI dla zarządu, żeby system jakości nie kończył się na tabelkach.

Największy koszt rośnie tam, gdzie firma kompensuje słabość dostawcy własnym wysiłkiem

Najdroższy problem ze słabym dostawcą rzadko sprowadza się do jednej wadliwej partii albo pojedynczej spóźnionej dostawy. Rzeczywisty koszt narasta wtedy, gdy organizacja przez długi czas obchodzi źródło problemu własnym wysiłkiem operacyjnym. Dodatkowa kontrola wejściowa, ręczne uzgodnienia terminów, wyjątki w planowaniu, awaryjne decyzje zakupowe, doraźne przesunięcia produkcji i wiedza ukryta w głowach kilku doświadczonych osób tworzą równoległy, nieformalny system podtrzymywania dostaw. Z zewnątrz wygląda to jak zachowana ciągłość pracy. W praktyce jest to kosztowna kompensacja niestabilności, która obciąża organizację bardziej niż sama niezgodność.

To dlatego decyzja o rozwijaniu dostawcy nie może opierać się wyłącznie na liczbie reklamacji. Jeżeli firma nie mierzy kosztu kompensacji, łatwo myli utrzymanie dostaw z rzeczywistą stabilnością procesu. Wskaźnik terminowości może wyglądać poprawnie tylko dlatego, że zwiększono zapas bezpieczeństwa. Jakość wejścia może być akceptowalna wyłącznie dzięki selekcji lub nadzorowi 100%. Produkcja może nie zgłaszać przestojów, ponieważ planista stale przebudowuje harmonogram pod słabego dostawcę. W takiej sytuacji dane zarządcze tracą wiarygodność, bo pokazują wynik po stronie klienta, a nie faktyczną zdolność dostawcy do spełniania wymagań.

Dlatego warto zestawiać podstawowe wskaźniki dostawcy z danymi z własnego systemu, zwłaszcza z:

• liczbą dostaw warunkowo dopuszczonych,
• liczbą sortowań,
• czasem przestoju,
• liczbą otwartych 8D lub działań korygujących,
• czasem ich zamykania.

Dopiero taki obraz pokazuje pełny koszt jakości i rzeczywisty wpływ na ciągłość działania.

W praktyce słaby dostawca obciąża nie tylko dział jakości i zakupy. Koszt przenosi się na logistykę, która utrzymuje bufory i pilnuje dostaw awaryjnych, na produkcję, która pracuje na wyjątkach, na obsługę klienta końcowego, która musi tłumaczyć odchylenia, a także na zarząd, który podejmuje decyzje na podstawie wskaźników zniekształconych przez działania ratunkowe. Z tego powodu warto reagować wcześniej niż po formalnej eskalacji. Powtarzalność przyczyn, opóźnione działania korygujące, niestabilność procesu po stronie dostawcy i słaba komunikacja są sygnałami ostrzegawczymi równie ważnymi jak reklamacja. Jeżeli organizacja czeka z Supplier Development do momentu serii incydentów, zwykle uruchamia działania zbyt późno i już pod presją zabezpieczenia bieżącej produkcji. W podobny sposób należy patrzeć na inne obszary odporności operacyjnej, także wtedy, gdy pojawia się temat NIS2 dla firm produkcyjnych: kogo obejmuje, jakie obowiązki wprowadza i jak przygotować organizację bez sprowadzania tematu wyłącznie do IT.

Typowy obraz jest prosty: dostawca formalnie dostarcza, ale klient utrzymuje ciągłość wyłącznie dzięki własnym buforom, selekcji i pełnemu nadzorowi wejścia. Na papierze materiał jest dostępny, a linia pracuje. W rzeczywistości każda partia wymaga dodatkowej decyzji, każda zmiana planu uruchamia kolejne uzgodnienia, a każda niezgodność angażuje te same osoby po stronie jakości, zakupów i produkcji. Taki układ nie oznacza stabilnej współpracy, lecz przeniesienie odpowiedzialności za zdolność procesu z dostawcy na klienta. Z punktu widzenia systemu zarządzania sama kontrola wejściowa lub zwiększenie zapasu bezpieczeństwa nie rozwiązują problemu, lecz jedynie kupują czas. Jeżeli ten czas nie zostanie wykorzystany na uporządkowany plan działań albo decyzję o ograniczeniu ryzyka, organizacja będzie nadal finansować cudzą niewydolność operacyjną.

Najpierw kwalifikacja problemu, potem plan rozwojowy

Supplier Development ma sens dopiero wtedy, gdy organizacja potrafi precyzyjnie nazwać problem, który chce u dostawcy usunąć. Nie wystarczy stwierdzenie, że dostawca jest słaby albo niestabilny, bo taki opis nie prowadzi do właściwej interwencji. Najpierw trzeba rozstrzygnąć, czy źródłem odchyleń jest zdolność procesu, nadzór nad zmianą, kompetencja personelu, planowanie produkcji, zakupy u poddostawców, utrzymanie wyposażenia czy szerzej rozumiana słabość systemu zarządzania. Bez tej kwalifikacji firmy uruchamiają działania pozorne: zlecają audyt, żądają 8D, organizują szkolenie albo zwiększają liczbę spotkań, choć żadne z tych działań samo w sobie nie usuwa przyczyny. W efekcie rośnie aktywność, ale nie rośnie przewidywalność dostaw.

Na wejściu do programu rozwojowego warto przyjąć minimalny zestaw pytań diagnostycznych. Co dokładnie nie działa: jakość wyrobu, terminowość, kompletność dostaw, stabilność partii czy skuteczność reakcji na niezgodność? Od kiedy problem występuje i czy ma charakter incydentalny, czy powtarzalny? W jakiej skali wpływa na klienta: przez reklamację, sortowanie, dodatkową kontrolę wejściową, przestój, dostawy awaryjne? Jakie są dowody skuteczności wcześniejszych działań korygujących i czy poprzednie 8D zamykały przyczynę, czy tylko objaw? Kto po stronie dostawcy ma realną sprawczość: kierownik produkcji, technolog, specjalista jakości, właściciel procesu, a może nikt nie ma mandatu do zmiany? Dopiero na takim materiale można odróżnić problem procesu od problemu systemowego.

Dane wejściowe do tej oceny są zwykle dostępne: reklamacje, wyniki kontroli wejściowej, terminowość, powtarzalność odchyleń między partiami, wyniki audytów, skuteczność poprzednich działań oraz sygnały organizacyjne, takie jak duża rotacja personelu. Ważne jest przy tym rozdzielenie dwóch porządków działań, które w praktyce często są mieszane. Działania ochronne po stronie klienta służą zabezpieczeniu bieżącej produkcji i ograniczeniu skutku ryzyka: dodatkowa kontrola, warunkowe dopuszczenie, separacja partii, bufor, zmiana częstotliwości odbioru. Działania rozwojowe u dostawcy mają usunąć przyczynę i odbudować zdolność do spełniania wymagań. Jeżeli te dwa strumienie wrzuci się do jednego planu bez rozróżnienia celu, organizacja traci przejrzystość decyzji: nie wiadomo, co chroni klienta dziś, a co ma poprawić proces za miesiąc lub kwartał.

To samo dotyczy zakresu wizyty u dostawcy. Jeżeli problem dotyczy ustawień procesu, trzeba włączyć technologię lub inżynierię procesu po stronie klienta. Jeżeli zawodzi nadzór nad zmianą albo zamykanie działań korygujących, większy sens ma przegląd odpowiedzialności, wskaźników i sposobu zarządzania odchyleniami. W tym kontekście pomocne bywa także uporządkowanie własnego obiegu informacji, zwłaszcza gdy organizacja równolegle pracuje nad tematem Jak zbudować standard raportowania problemów jakościowych dla produkcji wielozmianowej.

Praktyczny przykład jest prosty. Jeżeli dostawca raz po raz wysyła partie o zmiennej charakterystyce, a każda niezgodność kończy się deklaracją „przeszkolono operatorów”, to najczęściej nie mamy do czynienia z problemem samej kompetencji personelu, lecz z brakiem stabilnego procesu, nieskutecznym planem kontroli albo słabym nadzorem nad zmianą. W takiej sytuacji właściwą formą interwencji będzie audyt procesowy, przegląd PFMEA i planu kontroli, weryfikacja punktów ustawczych, kryteriów zwolnienia partii oraz sposobu potwierdzania skuteczności działań. Jeżeli natomiast dostawca produkuje poprawnie, ale regularnie nie dowozi terminu z powodu braków materiałowych u poddostawców, ciężar diagnozy przesuwa się na planowanie, zakupy i zarządzanie ryzykiem w łańcuchu dostaw. Dopiero po takiej kwalifikacji plan rozwojowy przestaje być listą oczekiwań klienta, a staje się narzędziem operacyjnym z przypisaną odpowiedzialnością, miernikami i dowodem skuteczności.

Plan rozwojowy musi mieć właściciela, kamienie milowe i warunki wyjścia

Plan działań rozwojowych ma sens tylko wtedy, gdy prowadzi zmianę, a nie porządkuje korespondencję z dostawcą. Dlatego od początku powinien definiować problem w kategoriach operacyjnych, stan docelowy, działania ochronne po stronie klienta i działania rozwojowe po stronie dostawcy, a także odpowiedzialnych po obu stronach, terminy, dowody wykonania i kryteria skuteczności. Najczęstsza przyczyna nieskuteczności nie leży jednak w samym formularzu, lecz w braku właściciela po stronie klienta. Jeżeli program jest formalnie wspólny, ale nikt nie odpowiada za jego prowadzenie, egzekwowanie terminów i ocenę dowodów, kończy się na wymianie prezentacji, deklaracjach o postępie i opóźnionych aktualizacjach. W praktyce właścicielem powinien być konkretny menedżer procesu lub jakości z mandatem do eskalacji, a nie zbiorowa odpowiedzialność kilku funkcji.

Dobrze zaprojektowany plan nie może opierać się na odległych terminach i ogólnych obietnicach. Kamienie milowe muszą być krótkie, weryfikowalne i powiązane z decyzją zarządczą: wdrożenie zabezpieczenia, potwierdzenie jego skuteczności, stabilizacja wyników w kolejnych dostawach, redukcja nadzoru tymczasowego i zamknięcie działań. Równie ważne są warunki eskalacji i warunki wyjścia zapisane już na starcie. Trzeba z góry ustalić, kiedy zwiększana jest kontrola wejścia, kiedy utrzymuje się status dostawcy warunkowego, kiedy ogranicza się zakres powierzanych indeksów lub blokuje nowe projekty, a kiedy poprawę uznaje się za trwałą. Bez takich progów plan rozwojowy staje się dokumentem otwartym bez końca, a decyzje są podejmowane reaktywnie, pod presją bieżących braków materiałowych albo terminów produkcji.

W tym miejscu warto uporządkować także wskaźniki istotne dla zarządu. Nie chodzi o liczbę spotkań czy wysłanych przypomnień, lecz o terminowość, poziom niezgodności, liczbę incydentów powtarzalnych, czas reakcji, czas zamknięcia działań i liczbę odstępstw warunkowych. To jest ten sam porządek myślenia, który pojawia się przy pytaniu, jak zbudować procesowe KPI dla zarządu.

Różnica między planem naprawczym a rzeczywistym rozwojem dostawcy najlepiej wychodzi na prostym przykładzie. Jeżeli po serii reklamacji dostawca dosyła raport 8D, deklaruje przeszkolenie operatorów i aktualizację instrukcji, nie musi to jeszcze oznaczać wzrostu jego zdolności organizacyjnej. Jeżeli nadal nie ma stabilnych parametrów procesu, skutecznego nadzoru nad zmianą, potwierdzenia zdolności pomiarowej albo dyscypliny zamykania działań korygujących, poprawiono opis problemu, ale nie system jego kontroli. Rzeczywisty rozwój zaczyna się wtedy, gdy dostawca potrafi wykazać zmianę sposobu zarządzania procesem: kto zatwierdza nastawy, jak monitorowane są odchylenia, w jakim czasie reaguje technologia, jak potwierdzana jest skuteczność po wdrożeniu i kiedy można bezpiecznie wycofać dodatkowy nadzór po stronie klienta.

W wielu organizacjach właśnie na tym etapie ujawnia się znaczenie odpowiedzialności właściciela procesu oraz przygotowania ludzi. Nawet dobry plan nie zadziała, jeśli po stronie klienta brakuje kompetencji do jego prowadzenia; podobny problem wraca później przy temacie Jak przygotować proces onboardingowy dla nowego inżyniera jakości lub pełnomocnika ISO. Z perspektywy systemu zarządzania takie podejście nie jest dodatkiem do audytu dostawcy, lecz praktycznym wykonaniem nadzoru nad procesami zewnętrznymi, działań korygujących i myślenia o ryzyku. O jakości planu rozwojowego decyduje jednak przede wszystkim to, czy po każdym kamieniu milowym pozwala on podjąć jasną decyzję: utrzymać współpracę, zaostrzyć nadzór, ograniczyć ekspozycję albo zamknąć działania i dopuścić dostawcę do normalnego trybu.

Rozwój dostawcy nie może być odklejony od wymagań branży i ryzyka zgodności

Supplier Development nie może być prowadzony w oderwaniu od kontekstu wyrobu, klienta i sektora. Nie każdy łańcuch dostaw dopuszcza ten sam margines uczenia się dostawcy. Jeżeli dostawca wpływa na bezpieczeństwo wyrobu, identyfikowalność partii, powtarzalność procesu albo skuteczność nadzoru nad zmianą, tolerancja dla improwizacji gwałtownie maleje. W praktyce oznacza to, że ten sam poziom słabości organizacyjnej może być jeszcze akceptowalny przy zakupie materiału pomocniczego, ale nie przy procesie specjalnym, komponencie krytycznym albo usłudze mającej wpływ na zgodność wyrobu końcowego. Dlatego decyzja o rozwijaniu dostawcy musi zaczynać się nie od relacji handlowej, lecz od dopuszczalnego poziomu ryzyka operacyjnego i zgodności.

Z tego wynika druga konsekwencja. W branżach o podwyższonych wymaganiach program rozwojowy nie może ograniczać się do parametrów jakości wyrobu. Musi obejmować dojrzałość zarządczą dostawcy, bo to ona decyduje o przewidywalności wyników. Jeżeli organizacja nie prowadzi wiarygodnych zapisów, nie ma jasnych kompetencji i zastępstw, nie kwalifikuje procesów, nie panuje nad dokumentacją i nie tworzy warunków do zgłaszania problemów bez ich ukrywania, to nawet chwilowa poprawa jakości będzie nietrwała. W takich przypadkach zakres audytu drugiej strony i plan działań powinny być różnicowane zależnie od krytyczności dostawcy, a nie ujednolicane dla całej bazy zakupowej.

Najlepiej widać to na prostym przykładzie. Dostawca utrzymuje zgodność wymiarową detalu przez kilka kolejnych dostaw, ale nie potrafi wykazać, kto zatwierdził zmianę narzędzia, jak odtworzyć historię partii, według jakiej wersji instrukcji pracowała zmiana nocna i w jaki sposób eskalowano odchylenie procesu. W branży o niskiej krytyczności może to skutkować czasowym zwiększeniem kontroli wejścia. W środowisku o wysokim ryzyku taki sam stan oznacza, że dostawca nie daje podstaw do zaufania, nawet jeśli bieżący wyrób wychodzi dobrze. W polskich realiach częstym błędem jest uznawanie certyfikatu za wystarczający dowód zdolności dostawcy. Tymczasem program rozwojowy powinien sprawdzać praktykę działania: jakość zapisów, dyscyplinę zmian, skuteczność reakcji, rzetelność danych i zachowania ludzi pod presją problemu, a nie wyłącznie formalną zgodność.

Dopiero na tym tle widać sens wymagań systemowych. Nie są one dodatkiem do Supplier Development, lecz warunkiem przewidywalności dostawcy. Wymagania branż regulowanych, w tym obszary takie jak identyfikowalność, kwalifikowanie procesów czy nadzór nad dokumentacją, porządkują to, co klient musi móc zweryfikować przed dopuszczeniem dostawcy do stabilnej współpracy. Ta sama logika dotyczy także ciągłości działania i bezpieczeństwa informacji, jeżeli dostawca uczestniczy w procesach krytycznych, utrzymuje systemy wspierające produkcję albo przetwarza dane istotne dla działania organizacji. W takich przypadkach rozwój dostawcy powinien obejmować nie tylko jakość i terminowość, ale również zdolność do utrzymania działania w zakłóceniu oraz poziom ochrony informacji. Właśnie dlatego hasło Jakość bez kompromisów: wymagania dla dostawców branży nuclear nie opisuje wyjątku, lecz skrajny przykład tej samej zasady: im wyższa krytyczność, tym mniej miejsca na domysły, deklaracje i zaufanie oparte wyłącznie na certyfikacie.

Supplier Development kończy się decyzją, nie samym raportem

Program rozwojowy wobec słabego dostawcy ma sens tylko wtedy, gdy kończy się rozstrzygnięciem operacyjnym. Po okresie działań organizacja powinna podjąć jedną z kilku decyzji: utrzymać współpracę na standardowych zasadach, utrzymać ją warunkowo, ograniczyć zakres, przenieść część lub całość wolumenu albo zakończyć współpracę. Raport z audytu, plan działań i statusy zadań nie są celem samym w sobie. Największym błędem nie bywa brak narzędzi, lecz brak gotowości do zamknięcia programu, który nie przynosi trwałej zmiany. W praktyce oznacza to miesiące funkcjonowania z dostawcą, który formalnie pracuje nad poprawą, podczas gdy koszt niestabilności pozostaje po stronie klienta: w kontroli wejścia, reklamacjach, przyspieszeniach produkcji i obciążeniu zespołów operacyjnych.

Dlatego Supplier Development trzeba projektować od końca, czyli od kryteriów decyzji. Nie wystarczy potwierdzić, że dostawca wykonał działania korygujące. Trzeba ocenić, czy wyniki ustabilizowały się w czasie, czy źródła problemów rzeczywiście usunięto, czy komunikacja stała się rzetelna i terminowa, czy dostawca potrafi samodzielnie utrzymać standard bez stałego nadzoru klienta oraz czy jego reakcje na odchylenia są przewidywalne. Poprawa częściowa może uzasadniać utrzymanie warunkowe, ale nie powinna być mylona z odzyskaniem zaufania operacyjnego. Jeżeli dostawca pozostaje krytyczny biznesowo, a poprawa nie daje bezpieczeństwa, równolegle trzeba uruchomić kwalifikację nowego źródła i przejrzeć portfel dostawców, zamiast przedłużać stan zawieszenia.

W praktyce dobrze widać to na dostawcy, który ograniczył liczbę niezgodności, ale nadal wymaga ciągłych ponagleń, nie domyka analiz przyczyn, a każda zmiana procesu wywołuje nową falę problemów. Taki przypadek nie powinien kończyć się ogólnym stwierdzeniem, że widać postęp. Jeżeli poprawa jest zależna od presji klienta, dodatkowych kontroli i codziennej eskalacji, organizacja nie kupuje stabilności, tylko finansuje cudzą niedojrzałość. Wtedy właściwą decyzją bywa ograniczenie zakresu powierzanych wyrobów, przeniesienie wolumenu na dostawcę rezerwowego albo przebudowanie odpowiedzialności wewnętrznej za nadzór nad dostawcami. Gdy firma porządkuje ten obszar, często wraca też pytanie o przygotowanie nowej osoby do roli nadzorczej, podobnie jak w procesie onboardingu inżyniera jakości lub pełnomocnika systemu.

Żeby te decyzje nie były uznaniowe, dane o dostawcy muszą trafiać do stałego rytmu zarządczego. Przegląd zarządzania, a przynajmniej regularne forum decyzyjne z udziałem jakości, zakupów i operacji, powinno przekładać status działań, trendy jakościowe, wpływ na klienta i obciążenie operacyjne na konkretne decyzje zakupowe. To właśnie w takim miejscu ocena dostawcy przestaje być zbiorem obserwacji, a staje się zarządzaniem ryzykiem. W branżach o wyższej krytyczności ta dyscyplina jest jeszcze ważniejsza, co dobrze pokazuje także logika wymagań takich jak ISO 19443 dla dostawców energetyki jądrowej: od uporządkowanego systemu jakości do wejścia do łańcucha dostaw. Ostatecznie Supplier Development nie ma poprawiać relacji dla samej relacji. Ma chronić biznes przed kosztownym przyzwyczajeniem do słabości dostawcy i wymuszać świadomą decyzję: rozwijać dalej, ograniczać ryzyko albo zmienić źródło dostaw.