Migracja Zeiss do SAP Cloud zmienia kurs po tym, jak koszty osiągnęły 200 mln euro

Zeiss przebudował swoją migrację do chmury SAP po tym, jak koszty miały przekroczyć 200 mln euro, rezygnując z kompleksowej przebudowy na rzecz bardziej zachowawczej konwersji.

Niemiecka grupa optyczna zachowa większą część istniejącego oprogramowania, danych i procesów biznesowych, przenosząc swoje systemy planowania zasobów przedsiębiorstwa do chmury. Decyzja zastępuje strategię greenfield, którą Zeiss przedstawiał jako rzadką okazję do przeprojektowania fundamentów technologicznych.

Ta zmiana ma znaczenie wykraczające poza jeden kosztowny projekt korporacyjnego IT. Zeiss dostarcza kluczową optykę do najbardziej zaawansowanych urządzeń ASML do produkcji półprzewodników. Jego systemy wewnętrzne obsługują fabryki, zapasy, zamówienia, kontrole finansowe oraz rozproszoną globalnie sieć produkcyjną.

Migracja Zeiss do SAP Cloud ilustruje obecnie trudny wybór, przed którym stoją inni duzi klienci SAP. Mogą przebudować systemy wokół ustandaryzowanych procesów albo zachować więcej starszej architektury, aby ograniczyć koszty i ryzyko realizacji.

Podejście brownfield oferuje szybszą i potencjalnie tańszą drogę. Zachowuje jednak także część złożoności, którą pierwotny program miał wyeliminować.

Co zmieniło się w migracji Zeiss do SAP Cloud

Zeiss nie porzucił SAP ani celu migracji do chmury, lecz zasadniczo zmienił sposób, w jaki zamierza go osiągnąć.

Według migracji Zeiss firma zaczęła planować przejście do chmury około sześciu lat temu. Zewnętrzne firmy konsultingowe prowadziły program, według osób zaznajomionych z projektem.

Pierwotna strategia opierała się na modelu greenfield. Takie podejście tworzy nowy system z przeprojektowanymi procesami, konfiguracjami i strukturami danych zamiast bezpośrednio konwertować istniejące środowisko.

Programy greenfield obiecują czystszą architekturę, ponieważ zespoły mogą usunąć stare dostosowania i niespójne przepływy pracy. Mogą również zmusić jednostki biznesowe do przyjęcia jednego wspólnego modelu operacyjnego.

Ta obietnica wiąże się z wymagającym warunkiem. Firma musi uzgodnić, jak będzie działać jej przyszły biznes, zanim nowa platforma stanie się operacyjna.

Zeiss publicznie opisywał te ambicje kilka lat przed zgłaszaną zmianą kierunku. Jego program FIT4 miał zastąpić środowisko SAP R/3, które rozwijało się nierównomiernie w całej grupie.

Anglojęzyczny plan FIT4 opisywał cztery główne instalacje SAP i 78 wariantów zamówień. Z istniejącego środowiska ERP korzystało około 14 000 pracowników, którzy przetwarzali miesięcznie około 53 mln transakcji SAP.

Program obejmował około 160 jednostek Zeiss. Kolejne 80 jednostek działało poza istniejącym krajobrazem ERP, co zwiększało trudność stworzenia jednolitego globalnego szablonu.

Zeiss porównywał projekt do budowy kompleksu mieszkaniowego ze wspólnym planem pięter. Poszczególne jednostki biznesowe mogły zgłaszać zmiany, lecz rozwój niestandardowy miał pozostać wyjątkiem.

Model ten wymagał od zespołów technologicznych, konsultantów i specjalistów biznesowych zdefiniowania wspólnych procesów przed wdrożeniem. Zeiss informował, że jego zespoły pracowały nad produkcją, logistyką, finansami i innymi funkcjami operacyjnymi.

Firma twierdzi obecnie, że przeorganizowała program, aby szybciej osiągać postępy. Rzecznik potwierdził, że nowe podejście brownfield zachowa wiele istniejących systemów danych.

Konwersja brownfield wprowadza ugruntowane środowisko SAP do S/4HANA, zachowując dużą część jego danych, konfiguracji i historii procesów. Prace nadal wymagają dostosowania kodu, testów, zmian integracyjnych i migracji infrastruktury.

Nieprecyzyjne byłoby zatem przedstawianie tego ruchu jako zwykłego przeniesienia starego oprogramowania do nowego środowiska hostingowego. Zeiss nadal musi pogodzić systemy, które rozwijały się odmiennie w różnych jednostkach biznesowych i regionach.

Różnica dotyczy początkowego założenia projektu. Greenfield wymaga, by zespoły najpierw zaprojektowały pożądaną przyszłość. Brownfield zaczyna od tego, co już działa, i zmienia wyłącznie to, czego wymaga środowisko docelowe.

Zeiss nie potwierdził publicznie całkowitej inwestycji ani nie ujawnił zmienionej daty ukończenia. SAP również odmówił komentarza na temat projektu klienta.

Te pominięcia pozostawiają bez odpowiedzi kilka ważnych pytań. Firma nie wskazała, które systemy zostaną skonwertowane, które procesy pozostaną niezmienione ani ile wcześniejszych prac można wykorzystać ponownie.

Kluczowa zmiana jest jednak jasna. Plan Zeiss dotyczący SAP w modelu greenfield ustąpił miejsca zachowaniu istniejących rozwiązań, stopniowej modernizacji i ściślejszej kontroli kosztów.

Dlaczego Zeiss wybrał brownfield po latach prac nad greenfield

Zmiana sugeruje, że przeprojektowanie procesów stało się trudniejsze do zarządzania, niż zakładał pierwotny plan architektoniczny.

Zeiss miał mocny powód, by preferować rozwój greenfield. Jego istniejące systemy ERP zawierały warianty nagromadzone przez lata wzrostu, lokalnych decyzji, przejęć i wyspecjalizowanych wymagań produkcyjnych.

Nowe wdrożenie dawało możliwość usunięcia tych różnic. Ustandaryzowane procesy mogły wspierać spójne raportowanie, zintegrowane planowanie i szybszą koordynację między fabrykami oraz jednostkami biznesowymi.

Każdy proponowany standard staje się jednak przedmiotem negocjacji. Zespół produkcyjny może potrzebować wyspecjalizowanego przepływu pracy, podczas gdy dział finansowy może wymagać jednolitych mechanizmów kontroli. Operacje regionalne mogą podlegać odmiennym wymogom regulacyjnym, podatkowym lub oczekiwaniom klientów.

Te spory stają się kosztowne, gdy konsultanci, wewnętrzni eksperci i zespoły programistyczne muszą wielokrotnie zmieniać globalny szablon. Każda zmiana wpływa na konfigurację, interfejsy, konwersję danych, dokumentację i testy.

Zeiss przyznał wcześniej skalę tej koordynacji, przed obecną przebudową. Profil kariery firmy wskazywał, że jej zespół wdrożeniowy liczył ponad 100 pracowników oraz zewnętrznych konsultantów.

Uczestnicy byli rozproszeni po krajach, w tym po Stanach Zjednoczonych, Indiach i Węgrzech. Firma opisywała projekt zarówno jako konsolidację architektury, jak i wysiłek na rzecz harmonizacji procesów.

Realizacja greenfield wymaga także od organizacji odróżnienia rzeczywistych potrzeb operacyjnych od historycznych przyzwyczajeń. To rozróżnienie staje się trudne, gdy system ERP kontroluje działania, które nie mogą tolerować zakłóceń.

W przypadku Zeiss działania te obejmują zamówienia, dostawy, zapasy, zdolności produkcyjne i faktury. Błąd projektowy może więc szybko przejść z zaległości IT do problemu w produkcji lub obsłudze klienta.

Zgłaszane wydatki wskazują, że projekt pochłonął znaczne zasoby, zanim kierownictwo zmieniło kierunek. Nie dowodzą jednak, że wszystkie wcześniejsze prace zostały zmarnowane.

Mapy procesów, oczyszczone dane, inwentaryzacje integracji i przypadki testowe mogą pozostać użyteczne podczas konwersji brownfield. Części globalnego szablonu mogą również wspierać późniejszą optymalizację.

Ekonomiczne uzasadnienie zmienia się jednak, gdy kierownictwo wybiera zachowanie zamiast zastąpienia. Korzyści oparte na szerokim uproszczeniu trudniej uzasadnić, jeśli stare struktury przetrwają w nowym środowisku.

Migracja Zeiss w modelu brownfield daje firmie bardziej kontrolowany zakres działań. Zespoły mogą priorytetowo traktować konwersję techniczną, niezbędne poprawki kodu oraz interfejsy wymagane dla zachowania ciągłości.

Dokumentacja SAP potwierdza, że jego produkt chmury prywatnej obsługuje konwersję z SAP ERP. Zawiera również wytyczne dotyczące dostosowywania niestandardowego kodu i przenoszenia danych do środowiska S/4HANA.

Ta ścieżka ogranicza liczbę równoczesnych zmian organizacyjnych. Nie eliminuje potrzeby testowania procesów biznesowych ani rozwiązywania niezgodnych dostosowań.

Konsultant branżowy Byron Ford powiedział Bloombergowi, że programy greenfield zazwyczaj kosztują co najmniej o 20 procent więcej niż projekty brownfield. W zależności od zakresu różnica może sięgnąć dwukrotności kosztów.

Ta ocena nie jest prognozą dla Zeiss. Globalny zasięg, liczba systemów, jakość danych, obsada wewnętrzna i wymogi regulacyjne mogą prowadzić do bardzo różnych rezultatów.

Wyjaśnia jednak, dlaczego konwersja brownfield staje się atrakcyjna, gdy wydatki rosną. Kierownictwo może zawęzić transformację bez całkowitego powrotu do starszej platformy.

Zwrot odzwierciedla również powszechny wzorzec w dużych programach technologicznych. Wczesne plany optymalizują pożądany stan końcowy, podczas gdy późniejsze decyzje optymalizują możliwą do zrealizowania transformację.

Ten kompromis staje się wyraźniejszy, gdy zapotrzebowanie biznesowe nadal rośnie. Zeiss zwiększa moce związane z półprzewodnikami, a jednocześnie od jego zespołów wewnętrznych oczekuje się przeprojektowania kluczowych systemów operacyjnych.

Rozwijający się producent nie może zamrozić swojej organizacji na kilka lat. Podczas wdrożenia do systemu nadal trafiają nowe zakłady, produkty, podmioty prawne i relacje w łańcuchu dostaw.

Każda zmiana może sprawić, że plan greenfield stanie się przestarzały, zanim wdrożenie zostanie ukończone. Konwersja brownfield akceptuje ten ruchomy cel i zachowuje więcej wiedzy operacyjnej już zapisanej w oprogramowaniu.

Obietnica chmurowa SAP zderza się z rzeczywistością dostosowań w przedsiębiorstwach

Główny konflikt nie dotyczy już starego oprogramowania kontra nowe oprogramowanie. Dotyczy ambicji transformacyjnych kontra rzeczywistość operacyjną.

SAP od lat zachęca klientów do zastępowania lokalnie obsługiwanych aplikacji korporacyjnych subskrypcjami chmurowymi. Jego strategia zależy od przeniesienia dużej zainstalowanej bazy klientów w kierunku S/4HANA i powiązanych usług chmurowych.

Dla klientów atrakcyjność obejmuje zarządzaną infrastrukturę, bardziej regularne aktualizacje, zintegrowaną analitykę oraz dostęp do nowszych funkcji automatyzacji i sztucznej inteligencji.

Te zalety pojawiają się dopiero wtedy, gdy podstawowe procesy biznesowe, dane, integracje i niestandardowy kod działają niezawodnie w systemie docelowym.

Wymóg ten jest szczególnie wymagający dla firm przemysłowych. Ich środowiska ERP łączą oprogramowanie planistyczne z systemami produkcyjnymi, magazynami, dostawcami, kontrolą jakości i raportowaniem finansowym.

Zeiss działa również na kilku odrębnych rynkach. Jego działalność obejmuje technologię półprzewodnikową, systemy medyczne, pomiary przemysłowe i optykę konsumencką.

Proces, który działa w działalności związanej z okularami, może nie spełniać potrzeb dostawcy sprzętu półprzewodnikowego. Standaryzacja greenfield musi albo pogodzić te różnice, albo obsługiwać starannie zarządzane wyjątki.

Pierwotny plan Zeiss dotyczący SAP w modelu greenfield traktował migrację jako okazję do wyeliminowania niespójnych procesów. Jego autorzy chcieli, aby jednostki biznesowe weszły do wspólnej architektury, zamiast odtwarzać każdy wybór ze starszych systemów.

Zgłaszana zmiana kierunku pokazuje ograniczenia tej metafory budowlanej. Globalny system ERP nie jest pustym budynkiem oczekującym na lokatorów. Zawiera decyzje operacyjne podejmowane przez dziesięciolecia.

Niektóre decyzje stanowią złożoność, której można uniknąć. Inne kodują wiedzę o produkcji, zgodności, klientach lub ograniczeniach dostaw, której ogólny szablon nie może bezpiecznie odrzucić.

To rozróżnienie tworzy problem zarządzania. Konsultanci mogą rekomendować standardowe procesy, lecz liderzy biznesowi pozostają odpowiedzialni, gdy procesy te zawodzą podczas produkcji.

Partnerzy zewnętrzni działają również w ramach struktur komercyjnych, które mogą premiować kontynuowanie prac. Wielu dostawców, niejasne uprawnienia decyzyjne i słabe kryteria akceptacji mogą komplikować odpowiedzialność.

Badanie migracji w branży wykazało, że tylko 15 procent badanych programów SAP zakończyło się zgodnie z harmonogramem i budżetem. Analiza powiązała słabe wyniki z niedociągnięciami w zakresie ładu zarządczego, konkurującymi dostawcami oraz niejasnym podziałem odpowiedzialności.

Badanie wykazało również, że wiele organizacji priorytetowo traktuje ograniczanie zakłóceń zamiast szeroko zakrojonej transformacji. Taki wybór może obniżyć bezpośrednie ryzyko, jednocześnie odkładając standaryzację i porządkowanie danych.

Zeiss zbliżył się teraz do tej strategii ograniczania ryzyka. Firma może zachować działające procesy, zakończyć konwersję platformy i wrócić do uproszczeń po poprawie stabilności operacyjnej.

To odwrócenie kolejności, niekoniecznie zmiana celu. Zeiss może nadal standaryzować swoje środowisko, ale nie wydaje się już skłonny traktować kompleksowego przeprojektowania jako warunku postępu w chmurze.

Sam SAP w coraz większym stopniu umożliwia stopniowe przejścia. Komunikacja firmy dotycząca chmury podkreśla ochronę istniejących inwestycji, kontrolę harmonogramu i modernizację etapami.

Takie pozycjonowanie uwzględnia nieunikniony fakt. Najwięksi klienci SAP często mają więcej, a nie mniej złożoności odziedziczonej po starszych systemach, ponieważ ich systemy obsługują wiele krajów i wyspecjalizowane operacje.

Migracja Zeiss do chmury SAP sprawdza więc jednocześnie dwie obietnice. SAP musi pokazać, że jego model chmurowy potrafi obsłużyć złożonych klientów, a Zeiss musi udowodnić, że zachowanie istniejących rozwiązań przyniesie wymierny postęp.

Najbardziej prawdopodobnym rezultatem będzie mniejsza czystość architektoniczna. Może to również stworzyć system, który szybciej trafi do produkcji i przyniesie mniej niespodzianek operacyjnych.

Kontrole brownfield zwiększają koszty, ale zachowują dług techniczny

Zeiss ograniczył jedną kategorię ryzyka, akceptując inną: szybsza konwersja może zachować złożoność, która wcześniej uzasadniała przebudowę.

Dług techniczny odnosi się do decyzji projektowych, które zwiększają przyszłe koszty utrzymania lub zmian. W systemach ERP często przejawia się jako niestandardowy kod, zdublowane procesy, niespójne dane i podatne na awarie integracje.

Konwersja brownfield przenosi znaczną część tej historii do przodu. Zespoły muszą ustalić, które dostosowania pozostają zgodne z S/4HANA, a które wymagają modyfikacji lub wycofania.

Podejście nadal może obejmować porządkowanie. Zeiss może usuwać nieużywany kod, konsolidować wybrane interfejsy, archiwizować przestarzałe dane i standaryzować procesy tam, gdzie istnieje już porozumienie.

Program nie zaczyna się jednak od pustej konfiguracji. Każdy zachowany komponent musi zostać oceniony w nowym środowisku.

Powstaje przez to trudny problem pomiarowy. Udana konwersja techniczna może dotrzymać harmonogramu, a jednocześnie przynieść mniej usprawnień operacyjnych, niż obiecywał biznesowy uzasadnienie wariantu greenfield.

Firma nie ujawniła, które korzyści przetrwały przeprojektowanie. Nie podała też, czy zgłaszane koszty obejmują licencje, konsultantów, pracę wewnętrzną, infrastrukturę czy równoległą eksploatację systemów.

Bez takiego rozbicia obserwatorzy nie mogą określić, dlaczego wydatki przekroczyły oczekiwania. Dostępne informacje wskazują na większą od oczekiwanej złożoność wdrożenia, ale nie na pojedynczą, wyizolowaną awarię techniczną.

Zaangażowanie zewnętrznych firm konsultingowych zasługuje na analizę, bez przedwczesnego przypisywania winy. Bloomberg nie wskazał firm prowadzących transformację Zeiss.

Duże programy często dzielą obowiązki między dostawcę oprogramowania, integratorów systemów, dostawców chmury i zespoły wewnętrzne. Problemy mogą pojawiać się na granicach między ich umowami.

Jeden dostawca może konfigurować podstawową platformę, podczas gdy inny zarządza danymi lub integracjami. Jednostki biznesowe Zeiss muszą następnie potwierdzić, czy połączony system wspiera rzeczywistą pracę operacyjną.

Słabo zdefiniowana odpowiedzialność może prowadzić do powtarzanych przeprojektowań i testów. Może również sprawiać, że raporty zarządcze wyglądają pozytywnie, dopóki wzajemnie powiązane procesy nie zostaną ocenione łącznie.

Dane stanowią kolejne ryzyko. Zachowanie istniejących systemów chroni ciągłość operacyjną, ale niespójne rekordy mogą osłabić analitykę i automatyzację po migracji.

Nowsze usługi SAP zależą od wiarygodnego kontekstu biznesowego. Sztuczna inteligencja nie może zrekompensować sprzecznych kodów materiałowych, zduplikowanych dostawców ani niejasnej odpowiedzialności za procesy.

Ten problem jest już widoczny w całej bazie klientów. W 2025 roku benchmark migracyjny wykazał, że 62 procent respondentów wskazało wysokie koszty projektów jako główną barierę transformacji.

Te same badania wykazały, że 55 procent uznało czas trwania projektu za problem, w porównaniu z 37 procentami w poprzednim roku.

Wyniki te nie dowodzą, że brownfield jest zawsze lepszy. Pokazują, dlaczego zespoły zarządzające stają się mniej tolerancyjne wobec otwartego przeprojektowywania w miarę zbliżania się terminów.

Brownfield nie gwarantuje też niższego kosztu w całym cyklu życia. Organizacje mogą zapłacić za konwersję teraz, a następnie finansować lata późniejszego porządkowania.

Transformacja może wymagać równoległej eksploatacji, podczas gdy zespoły weryfikują nowe środowisko. Jeśli starsze systemy pozostają aktywne dłużej niż planowano, koszty infrastruktury i wsparcia mogą utrzymywać się obok subskrypcji chmurowych.

Badania branżowe wiążą te nakładające się środowiska z wyższymi kosztami po migracji. Ryzyko rośnie, gdy stara platforma nigdy nie zostaje całkowicie wyłączona.

Zeiss musi zatem zapobiec temu, by jego pragmatyczny zwrot stał się nieokreślonym stanem pośrednim. Udana konwersja wymaga konkretnych dat wycofania, zasad odpowiedzialności i mierzalnych celów uproszczenia.

Istnieje też ryzyko strategiczne dla SAP. Każde znaczące odejście od transformacji greenfield może osłabić zaufanie do dużych, prowadzonych przez konsultantów programów modernizacyjnych.

Dostawca oprogramowania może argumentować, że brownfield pozostaje wspieraną ścieżką do jego portfolio chmurowego. To prawda, ale zmienia to narrację dotyczącą wartości dla klienta.

Propozycją wartości staje się ciągłość i zarządzana modernizacja, a nie kompleksowe przeobrażenie. Dla wielu klientów ta węższa obietnica może być bardziej wiarygodna.

Harmonogram wywiera presję na Zeiss, SAP i jego konsultantów

Czas sprzyja teraz kontrolowanej konwersji, ponieważ harmonogram wsparcia SAP i przemysłowa ekspansja Zeiss pozostawiają niewiele miejsca na kolejny reset.

SAP zapewnia standardowe wsparcie dla podstawowych aplikacji Business Suite 7 do końca 2027 roku. Opcjonalne rozszerzone wsparcie będzie obowiązywać do 2030 roku.

Ten harmonogram wsparcia tworzy twarde ograniczenie planistyczne. Klienci mogą wydłużyć transformację, ale opóźnianie nie eliminuje podstawowej decyzji o migracji.

Zeiss rozpoczął planowanie na lata przed tym terminem. Obecna przebudowa sugeruje, że wczesny start nie ochronił programu przed presją zakresu i kosztów.

Strategia brownfield musi teraz przełożyć historię planowania na postęp we wdrożeniu. W przeciwnym razie firma ryzykuje większe wydatki przy jednoczesnym utrzymywaniu starych i nowych środowisk.

Presja wykracza daleko poza dział IT. Zespoły finansowe potrzebują wiarygodnego raportowania, zespoły produkcyjne — dokładnego planowania, a operacje w łańcuchu dostaw — stabilnych danych o zapasach.

Pozycja Zeiss w produkcji półprzewodników zwiększa stawkę. Według Bloomberga firma jest wyłącznym dostawcą optyki do najbardziej zaawansowanych maszyn litograficznych ASML.

Te systemy optyczne pomagają producentom chipów wytwarzać czołowe procesory, w tym komponenty używane w infrastrukturze AI. Zakłócenia operacyjne w Zeiss mogłyby zatem wpłynąć na strategicznie istotny łańcuch dostaw.

Nie ma dowodów, że program SAP zakłócił produkcję Zeiss lub dostawy ASML. Znaczenie sprawy wynika z potencjalnego wpływu, gdyby źle kontrolowana migracja dotarła do krytycznych operacji.

Zeiss musi równoważyć modernizację z wymogiem ciągłości. Konwersja brownfield jest łatwiejsza do obrony, gdy popyt produkcyjny rośnie, a systemy nie mogą tolerować niestabilnego wdrożenia.

SAP mierzy się z inną formą presji. Jego strategia wzrostu w chmurze wymaga, aby duzi klienci kończyli migracje, a nie jedynie podpisywali umowy lub pozostawali w wieloletnich programach wdrożeniowych.

Klient, który przechodzi z greenfield na brownfield, nadal może generować przychody chmurowe. Jednak ta zmiana ujawnia, że złożoność wdrożenia może ograniczać tempo, w jakim SAP rozszerza swoją zainstalowaną bazę.

Kolejnym ograniczeniem stają się budżety klientów. Badanie z 2026 roku wykazało, że 61 procent uczestniczących klientów SAP uznało presję budżetową za swoje główne wyzwanie.

Dyrektor ds. badań ASUG przypisał znaczną część tej presji projektom S/4HANA. Ustalenie, opisane w analizie budżetów klientów, sugeruje, że wydatki na migrację konkurują bezpośrednio z innymi priorytetami technologicznymi.

Ta konkurencja obejmuje teraz produkty SAP z zakresu sztucznej inteligencji. Klienci muszą ustanowić nowoczesne, zarządzane systemy danych, zanim wiele obietnic zaawansowanej automatyzacji stanie się praktycznych.

Firmy konsultingowe również stają przed testem wiarygodności. Prowadzą znaczną część prac projektowych, konwersyjnych, dotyczących danych i zarządzania zmianą w dużych programach ERP.

Przypadek Zeiss nie dowodzi niewłaściwego postępowania konsultantów. Rodzi jednak pytania o szacowanie, kontrolę zakresu i o to, czy zachęty wspierały wdrożenie możliwe do zrealizowania.

Kolejna faza pokaże, jak zmieniły się zakresy odpowiedzialności. Wiarygodny reset powinien wskazywać odpowiedzialnych właścicieli, węższe kamienie milowe i wyniki biznesowe, które użytkownicy mogą zweryfikować.

Wymuszona reakcja jest zatem wspólna. Zeiss musi narzucić ściślejszy ład zarządczy, SAP musi wspierać mniej wyidealizowaną migrację, a partnerzy zewnętrzni muszą realizować zmieniony zakres.

Trzy sygnały pokażą, czy reset brownfield działa

Zmieniony plan należy oceniać na podstawie kamieni milowych produkcyjnych, wycofywania starszych systemów i stabilnych kosztów operacyjnych, a nie kolejnego ogłoszenia transformacji.

Pierwszym sygnałem będzie potwierdzony kamień milowy wdrożenia. Zeiss nie podał zmienionego harmonogramu projektu, dlatego kolejne ujawnione wdrożenie będzie ważniejsze niż ogólny cel ukończenia.

Udane uruchomienie produkcyjne w jednostce biznesowej lub regionie pokazałoby, że firma przełożyła decyzję o brownfield na wykonalny zakres.

Kolejne opóźnienie osłabiłoby argument, że zmiana podejścia przyspieszyła postęp. Sugerowałoby, że ład zarządczy, integracje lub dane pozostają większymi barierami niż projekt systemu.

Drugim sygnałem będą dowody, że Zeiss wycofuje starsze instalacje. Konwersja brownfield zapewnia ograniczoną wartość ekonomiczną, jeśli stare środowiska nadal działają obok platformy chmurowej.

Obserwatorzy powinni szukać mniejszej liczby aktywnych instancji ERP, ograniczenia równoległej eksploatacji oraz jasnego zakresu migracji w około 160 jednostkach wskazanych przez FIT4.

Takie dowody wzmocniłyby tezę, że Zeiss zachował niezbędne procesy bez zachowywania każdego nadmiarowego systemu. Utrzymująca się fragmentacja pokazałaby, że reset jedynie odroczył konsolidację.

Trzecim sygnałem będzie stabilna perspektywa kosztowa po wejściu zmienionego programu w fazę realizacji. Zeiss nie musi ujawniać każdej umowy, ale kierownictwo powinno wyjaśnić, czy wydatki przestały rosnąć.

Stabilny budżet połączony z ukończonymi wdrożeniami wspierałby tezę brownfield. Kolejny istotny wzrost wskazywałby, że prace nad starszym kodem i integracjami zniwelowały oczekiwane oszczędności.

Czytelnicy nie powinni traktować tego ruchu jako dowodu, że migracje greenfield zawsze zawodzą. Niektóre organizacje odnoszą korzyści z przebudowy, gdy starsze procesy blokują strategiczną zmianę, a kierownictwo może wyegzekwować standaryzację.

Wybór Zeiss nie dowodzi też, że konwersja brownfield jest bezpieczna. Zachowana złożoność może ponownie ujawnić się podczas testów, aktualizacji, projektów analitycznych lub późniejszych zmian procesowych.

Bardziej użyteczna lekcja dotyczy kolejności działań. Przedsiębiorstwa mogą oddzielić konwersję platformy od kompleksowego przeprojektowania działalności, zamiast próbować realizować oba te procesy jednocześnie we wszystkich jednostkach.

Taka kolejność ogranicza skalę równoczesnych zmian, ale po uruchomieniu systemu wymaga dyscypliny. Odroczone porządki muszą mieć wyznaczonych właścicieli, finansowanie i terminy, w przeciwnym razie staną się trwałym długiem technicznym.

Liderzy technologiczni oceniający własne migracje powinni zapytać, co chroni każde dostosowanie. Powinni również wskazać, które deklarowane korzyści zależą od usunięcia tego dostosowania przed konwersją.

Przeglądy projektów powinny łączyć decyzje architektoniczne z konkretnymi wynikami biznesowymi. Odsetek czystego rdzenia niewiele znaczy, jeśli fabryki, zespoły finansowe lub działy operacyjne łańcucha dostaw nie mogą niezawodnie wykonywać swojej pracy.

Zespoły potrzebują też niezależnego rejestru decyzji, zależności i kryteriów akceptacji. Przeszukiwalna baza wiedzy inżynieryjnej może pomóc zachować ten kontekst między zespołami wewnętrznymi a partnerami konsultingowymi.

Migracja Zeiss do chmury SAP ma teraz węższy i bardziej praktyczny sprawdzian. Musi przenieść systemy krytyczne bez zakłócania działalności producenta osadzonego w globalnym łańcuchu dostaw półprzewodników.

Warto obserwować kolejne wdrożenie produkcyjne, wycofywanie starych instancji SAP oraz zmienioną trajektorię kosztów. Łącznie sygnały te pokażą, czy Zeiss znalazł realną drogę naprzód, czy jedynie odroczył najtrudniejsze decyzje.