Cisco

Problemy CISCO z łańcuchem dostaw

Między wszystkimi upokorzeniami firmy to było chyba jednym z najgorszych. W maju 2001 r. Cisco Systems (CSCO) przedstawiło największy inwentarz w historii: 2,2 bln USD wymazane z zestawienia bilansowego za składniki, które zamówiono, ale których nie wykorzystano. Gafa była tym bardziej upokarzająca, że poprzedzona była rozgłosem na temat genialnej integracji olbrzymiego systemu informacji przez Cisco. Sieć była tak wrażliwa, że firma mogła zamknąć księgi w 24 godziny, każdego dnia roku. Jednakże system był na tyle niewrażliwy, żeby zaprzestać budowania wartości miliardów dolarów w towarach, których nikt nie chciał.

Cisco twierdziło, że fiasko spowodowane było przez "zanurzenie się" technologii. Jak to określił John Chambers, była to nieprzewidziana "100-letnia powódź". Według Cisco, jeżeli tylko prognozy firmy mogłyby przewidzieć to, co miało się stać, łańcuch dostaw zadziałałby idealnie. Ale sprawa z "Business 2.0" nauczyła, że w zasadzie błędy w systemie przyczyniają się do jego załamania. Cisco rozpoznało wiele z tych problemów jeszcze przed zeszłorocznym nadmiarem zapasów. Od tamtej pory elitarna grupa inżynierów i członków zarządu pracowała nad tajnym programem ulepszenia, nazwanym eHub. Widzimy pierwszy raz, w jaki sposób ten ambitny, wielomilionowy projekt mógł pomóc w uniknięciu powtórki z klęski poprzedniego roku... jeśli zadziałałby, jak planowano.

"Bańka mydlana"

W końcu lat 90. Cisco stało się znane z tego, że była to firma tworząca sprzęt komputerowy, która jednocześnie go nie tworzyła. Zamiast tego Cisco dzierżawiło większość routerów i wyłączników zakontraktowanym producentom elektroniki. Ten układ miał wiele zalet. Najważniejszą z nich był fakt, że umożliwiło to Cisco skoncentrowanie się na marketingu i innowacji produktów. Układ ten uwolnił również Cisco od bałaganu i kosztów związanych z magazynowaniem zapasów, gdyż system informacji Cisco umożliwiał wysyłkę bezpośrednio do klienta gotowych (w pełni złożonych) maszyn, zaspokajając popyt.

Niestety, Great Inventory Wreck z 2001 r. podkreślił niektóre defekty w systemie. Struktura łańcucha dostaw w Cisco miała kształt piramidy, gdzie Cisco było na samej jej górze. W drugim rzędzie zasiadali zakontraktowani producenci - włączając Celestica, Flextronics i Solectron - odpowiedzialni za końcowy montaż. Ci producenci mają również swoich dostawców części typu procesory (Intel i Xilinx) i optycznych przekładni (JDS Uniphase i Corning). Te firmy z kolei pobierają części od dostawców porozrzucanych po całym świecie.

Problemy z komunikacją między tymi rzędami piramidy w końcu doprowadziły Cisco do kłopotów. Aby zablokować dostawy części w czasie ożywienia gospodarczego, Cisco zamówiło olbrzymie ilości z dużym wyprzedzeniem, bazując na projekcjach popytu opartych na danych sprzedaży firmy. O jednym jednak zapomniano - wiele z projekcji było sztucznie "nadmuchanych". Wielu klientów Cisco zamawiało podobny sprzęt od konkurencji, mając od początku na uwadze, że ostatecznie dokonają tylko jednego zakupu - od tego, kto szybciej go dostarczy. Rezultatem było podwójne i potrójne zamawianie tych samych urządzeń, co "nadmuchiwało" prognozy. Zabrakło ogniwa w zarządzaniu łańcuchem dostaw w firmie Cisco, co jeszcze powiększyło problem. Wyobraźmy sobie, ze Cisco przedstawiało sprzedaż w wysokości 10 tys. jednostek danego routera. Każdy z zakontraktowanych producentów firmy konkurowałby, aby spełnić całkowite zamówienie szybciej, a żeby temu sprostać, często próbowali oni zablokować dostawy komponentów, których był niedobór. Dostawcy byliby zasypani zamówieniami, ale Cisco nie było w stanie pokazać, że ten wzrost w popycie reprezentował nakładające się na siebie zamówienia. Gdyby trzej producenci konkurowali ze sobą, aby zbudować owe 10 tys. routerów, dla producentów chipów wyglądałoby to jak nagły popyt na 30 tys. maszyn. Cisco zostało wplątane w błędne koło "nadmuchanych" prognoz popytu na główne komponenty, wyższe koszty i na złą komunikację wewnątrz łańcucha dostaw. W końcu bąbel pękł.

Lepsze życie poprzez automatyzację

Problemy z komunikacją zastopowały tylko częściowo dolną warstwę piramidy. I to w tym miejscu zaprojektowano eHub.

Jak to zwykle bywa, praca nad eHub rozpoczęła się w 2000 r., kiedy nikomu nawet przez myśl nie przeszedł gwałtowny spadek popytu. Wręcz odwrotnie, projekt ten miał pomóc wyeliminować "bitwy między zakontraktowanymi producentami". "To było stworzone dla skalowania w górę - mówi Carl Redfield, szef logistyki w Cisco. - Naszym celem było zapewnienie, że materiał będzie zawsze osiągalny."

Do lata 2000 r. Cisco produkowało skoroszyty o grubości 3 cali, które były podstawą eHub. Centralny system nerwowy miał być obsługiwany w Irvine Calif, firmie integracyjnej supply-chain Viacore, która miała wykorzystać, już tak bardzo zaawansowany, system zarządzający łańcuchem dostaw firmy Cisco.

W przeszłości firmy takie jak Dell i GM stworzyły elektroniczne huby, które podawały dane z łańcucha dostaw do zewnętrznych producentów i dostawców i vice versa. Te wymiany były zwykle dostarczane przez interfejsy internetowe, gdzie dostawcy manualnie wpisywali swoje prognozy, zamówienia kupna, plany dostaw.

eHub praktycznie eliminował potrzebę ludzkiej interwencji. Zamiast tego automatyzował przepływ informacji między Cisco, zakontraktowanymi producentami i ich dostawcami komponentów. Głównym składnikiem była tu technologia XML, tak zwana Partner Interface Process (PIP). PIP wskazywał, kiedy dokument wymagał reakcji - i jeśli tak, to jak szybko. Na przykład zamówienie PIP może żądać potwierdzenia od adresata w ciągu dwóch godzin po otrzymaniu i akceptacji tegoż zamówienia w ciągu 24 godzin. Jeżeli system adresata nie sprosta danym oczekiwaniom, zamówienie jest uważane za puste lub nieważne.

W eHub cykl produkcji Cisco rozpoczyna się, gdy prognoza popytu PIP jest wysłana, pokazując skumulowane zamówienia. Ta prognoza jest wysłana nie tylko do kontrahentów, ale także do producentów chipów, takich jak Philips Semiconductors i Altera Corp. "Przedtem, jeżeli Celestica, Flextronics i Solectron przyszły do Philipsa w tym samym czasie i każde z nich chciało 10 tys. jednostek danego chipa, mieliśmy zamówienia w sumie na 30 tys. chipów" - mówi starszy inżynier, który pracował nad projektem eHub. - Teraz Philips może powiedzieć: «Poczekajcie. Jestem na eHub. Wiem, że łączny popyt jest równy tylko 10 tys. jednostek»." Poprzez wymaganie od wszystkich systemów w sieci dostaw utrzymywania wspólnej komunikacji można uniknąć takich wpadek.

Ponieważ projekt był bardzo skomplikowany i kosztowny, wprowadzenie eHub było nieco przesunięte w czasie. Cisco planowało podłączyć się siecią z 250 kontrahentami i dostawcami przed końcem 2001 r. Zamiast tego udało im się podłączyć z mniej więcej 60, włączając w to Agilent Technologies, Hitachi, IBM, Intel, LSI Logic, Motorola i Xilinx. W tym roku ta liczba wzrosła do 150 i Cisco postawiło sobie za cel zintegrowanie 650 uczestników łańcucha dostaw.

eHub jest pierwszym krokiem w planach integracyjnych Cisco. Ostatecznie firma ma nadzieję na zautomatyzowanie całego systemu: klient zamawia produkt on-line, to zamówienie przepływa jednocześnie zarówno do finansowej bazy danych, jak i systemu łańcucha dostaw. Jednakże na razie eHub będzie dręczony ograniczeniami oprogramowania - jest tak dobry, jak dane, które otrzymuje.

"Jeżeli wprowadzane dane są złe, nawet najlepszy łańcuch dostaw nie uratuje sprawy" - mówi Steve Kammen, analityk zajmujący się Cisco dla CIBC World Markets. Jednakże kiedy kolejna zwyżka się pojawi, Cisco planuje dostarczyć części, które będą potrzebne.

Pytania

  1. Jakie słabe strony analizy zamówień doprowadziły Cisco na skraj bankructwa? W jaki sposób można wykorzystać techniki jakościowe i ilościowe, by rozwiązać problemy prognozowania na podobnych rynkach?
  2. Model magazynowania niezależnego od zapotrzebowania jest oparty na różnych analizach kosztów związanych z ich zarządzaniem. Na czym polegał problem Cisco związany z tymi kosztami (przed i po spadku popytu)? Biorąc pod uwagę opisane rozwiązanie, w którym miejscu procesu postrzega się generację kosztów?
  3. Co spowodowało kłopoty z zarządzaniem logistyką?
  4. W Cisco pojawił się problem z podwójnymi zamówieniami na produkty o długim czasie dostawy. Zniecierpliwieni klienci zaczęli zamawiać części bezpośrednio od dostawców Cisco. Kiedy jedno z zamówień zostało zrealizowane, z drugiego rezygnowano. Wytłumacz jak takie zachowanie klientów mogło wpłynąć na system logistyczny firmy Cisco? W jaki to miało wpływ na końcowy nadmiar zapasów Cisco?

Źródła

Zarządzanie operacyjne

Donald Waters

Zarządzanie produkcją jest przedmiotem trudnym, wykładanym we wszystkich szkołach zarządzania. Jest też, obok zarządzania finansami, przedmiotem szczególnego zainteresowania kadr kierowniczych firm. Niniejsza książka powinna spełnić oczekiwania obydwu grup osób. Stanowi bowiem nowoczesny podręcznik, oparty przede wszystkim na doświadczeniach przemysłu brytyjskiego, w którym, podobnie jak w Polsce, dużą rolę w zarządzaniu odgrywa kadra techniczna.

więcej »

Copyright © 1997-2024 Wydawnictwo Naukowe PWN SA
infolinia: 0 801 33 33 88