Badanie Google Cloud AI wykazało, że modernizację blokuje istniejące oprogramowanie
Google Cloud opublikował 9 listopada wyniki wskazujące, że 49% ankietowanych decydentów powiązało oprogramowanie działające lokalnie z opóźnionymi lub ograniczonymi inicjatywami technologicznymi. Inicjatywy te obejmowały AI, choć wynik nie wyodrębnia projektów AI. Badanie Google Cloud AI nadaje konkretną wartość liczbową znanemu konfliktowi w przedsiębiorstwach: utrzymanie bieżącej działalności konkuruje z budowaniem nowych możliwości.
Badanie, przeprowadzone wspólnie z Hypothesis Group, objęło 1 250 decydentów IT i biznesowych z przedsiębiorstw w Stanach Zjednoczonych. Google wykorzystuje wyniki, by argumentować za większą swobodą architektoniczną i mniejszą zależnością od ugruntowanych dostawców. Jego główna obawa jest zrozumiała: agenci AI, czyli oprogramowanie zdolne realizować zadania poprzez kolejne działania, dziedziczą ograniczenia systemów, do których uzyskują dostęp.
Microsoft oferuje przydatne porównanie. Jego badania podkreślają gotowość organizacyjną obok wdrażania rozwiązań przez pracowników, zamiast traktować wymianę infrastruktury jako główną odpowiedź. Napięcie obecne w obu ujęciach dotyczy rozszerzania dostępu do AI i przygotowania na nią procesów biznesowych. Dla liderów technologicznych przesuwa to dyskusję w stronę integracji, odpowiedzialności operacyjnej oraz tego, czy nowe wydatki rzeczywiście uwalniają ograniczone zasoby inżynierskie.
Co faktycznie mierzy badanie Google Cloud AI
Badanie mierzy zgłaszane przez decydentów ograniczenia, zamiast wykazywać, że konkretna strategia modernizacji je usuwa.
Jeanette Manfra, szefowa działu ryzyka i zgodności w Google Cloud, przedstawiła wyniki w komunikacie dotyczącym badania starszego oprogramowania. Towarzyszący raport datowany jest na październik 2026 roku, a metodologia wskazuje, że badanie terenowe przeprowadzono w sierpniu. Publikacja przedstawia więc niedawny opis doświadczeń zebranych wcześniej, a nie bieżący pomiar wdrożeń z listopada.
Istotna definicja wpływa na interpretację. Badanie klasyfikuje lokalnie hostowane lub działające on-premises oprogramowanie dla przedsiębiorstw jako starsze, przeciwstawiając je oprogramowaniu hostowanemu i zarządzanemu w chmurze. Definicja ta dotyczy sposobu wdrożenia i zarządzania. Czytelnicy nie powinni zakładać, że każdy objęty nią system jest przestarzały, niewspierany lub technicznie nieodpowiedni dla AI.
Rozróżnienie jest ważne, ponieważ lokalizacja i stan systemu odpowiadają na różne pytania. Aplikacja obsługiwana lokalnie może mieć przejrzyste interfejsy i być starannie utrzymywana. Aplikacja chmurowa nadal może zawierać niejasne rekordy, niespójne uprawnienia lub ściśle powiązane reguły biznesowe. Żadna z tych obserwacji nie podważa doświadczeń respondentów, lecz obie ograniczają wnioski, jakie powinni wyciągać nabywcy.
Wskazane 49% łączy też kilka wyników: opóźnienia, ograniczenie zakresu, wstrzymanie i anulowanie. Oznaczają one różne poziomy zakłóceń. Tymczasowa zmiana harmonogramu nie pociąga za sobą takich samych skutków biznesowych jak porzucenie projektu. Podobnie uwzględnienie innych inicjatyw technologicznych oznacza, że wynik nie może być traktowany jako wskaźnik anulowania projektów AI.
To zastrzeżenie nie przekreśla istotnego ustalenia. Respondenci wiążą swoje istniejące rozwiązania programowe z barierami dla planowanych zmian. Dla nabywców korporacyjnych jest to dowód, że otaczające środowisko zasługuje na uwagę równolegle z ocenianym produktem AI.
Odpowiedź w ankiecie nie może jednak ustalić pełnego łańcucha odpowiedzialności. Zatrzymana inicjatywa może obejmować ograniczenia aplikacji, restrykcje zakupowe, brak kompetencji, konkurujące priorytety lub niejasne uzasadnienie biznesowe. W ramach tego samego projektu może współistnieć kilka przyczyn.
Badanie Google Cloud AI jest zatem najbardziej przydatne jako diagnoza postrzeganego tarcia organizacyjnego. Daje liderom powód, by zbadać własne zależności. Nie mówi im, którą aplikację zastąpić, którego dostawcę wybrać ani czy migracja powinna poprzedzać konkretne wdrożenie.
Ta różnica oddziela użyteczny sygnał badawczy od zbyt szerokiego wniosku zakupowego. Następne pytanie dotyczy tego, kto musi usunąć tarcie i jaką pracę wykonywałby w przeciwnym razie.
Presja związana z utrzymaniem spada na zespoły, od których oczekuje się dostarczania AI
Bezpośrednia presja spada na zespoły odpowiedzialne zarówno za ciągłość operacyjną, jak i nowe wdrożenia AI.
Organizacja inżynierska nie może traktować istniejącego obciążenia pracą jako opcjonalnego tylko dlatego, że kierownictwo wyznacza termin dla AI. Poprawki bezpieczeństwa, zmiany dostępu, reagowanie na incydenty i wsparcie aplikacji nadal są konieczne. Przydzielenie dodatkowego celu nie tworzy automatycznie zdolności potrzebnej do jego osiągnięcia.
Tworzy to problem budżetowy, który same dane o zatrudnieniu mogą ukrywać. Zespół może sprawiać wrażenie odpowiednio obsadzonego, podczas gdy specjaliści pozostają zajęci systemami wymagającymi ich konkretnej wiedzy. Istotnym ograniczeniem jest często dostępna wiedza ekspercka w okresie realizacji, a nie łączna liczba pracowników.
Rozważmy przykładowego wewnętrznego agenta usługowego, który pomaga pracownikom rozwiązywać problemy z kontami. Wygenerowanie wiarygodnej odpowiedzi jest tylko częścią zadania. Otaczający proces musi zidentyfikować pracownika, ustalić dozwolony dostęp, pobrać aktualne informacje i przekierować wyjątki do osoby odpowiedzialnej.
Jeżeli agent może zmienić konto, organizacja potrzebuje także zasad zatwierdzania i zapisu podjętego działania. Skuteczna demonstracja może ominąć znaczną część tej pracy operacyjnej. Usługa produkcyjna nie może zależeć od ręcznego naprawiania każdego nietypowego przypadku po fakcie.
Te wymagania wyjaśniają, dlaczego programiści i zespoły bezpieczeństwa odczuwają presję z różnych stron. Liderzy biznesowi chcą widocznych postępów. Zespoły operacyjne muszą zachować dostępność. Osoby oceniające bezpieczeństwo potrzebują wystarczających dowodów, by zatwierdzić dostęp. Bez jasno określonych priorytetów praca integracyjna może stać się nieprzypisaną zależnością między tymi grupami.
Utrzymanie wpływa także na kolejność działań. Zastąpienie aplikacji może z czasem zmniejszyć nakłady na wsparcie, lecz wymagać znacznej pracy, zanim korzyść się pojawi. W okresie przejściowym zespoły mogą potrzebować wspierać istniejące procesy, jednocześnie ucząc się rozwiązania zastępczego. Propozycja modernizacji wymaga więc opisu tymczasowego obciążenia pracą.
Właśnie tutaj szerokie obietnice uwolnienia inżynierów zasługują na analizę. Istotne pytanie brzmi: które powtarzalne zadania znikają, kto obecnie je wykonuje i kiedy te osoby staną się dostępne. Przeniesienie odpowiedzialności na dostawcę może pomóc, lecz zachowana praca związana z integracją i nadzorem nadal potrzebuje właściciela.
Zespoły zakupowe stoją przed podobnym wyzwaniem. Muszą odróżnić wygodę nabycia produktu od wysiłku potrzebnego do jego obsługi. Znajoma umowa może uprościć zakup bez rozwiązania problemu dostępu do danych. Nieznany dostawca może oferować atrakcyjne możliwości, jednocześnie dodając kolejny zestaw obowiązków operacyjnych.
Dla pracowników wiedzy konsekwencje widoczne są jako nierówna dostępność. Asystent może skutecznie podsumowywać dokumenty, a jednocześnie nie mieć dostępu do rekordów potrzebnych do podjęcia istotnej decyzji. Widoczny interfejs AI rozwija się wtedy szybciej niż proces roboczy stojący za nim.
Presja ma zatem charakter organizacyjny w równym stopniu co techniczny. Kierownictwo musi zdecydować, które zależności zasługują na inwestycję, a które proponowane projekty powinny poczekać. W przeciwnym razie każdy nowy pilotaż konkuruje o te same osoby, nie zmieniając warunków, które spowolniły jego poprzedników.
Dodanie agenta nie usuwa pracy leżącej u jego podstaw
Automatyzacja zwiększa znaczenie niezawodnych interfejsów biznesowych, ponieważ działania wymagają wyraźniejszych granic niż sugestie.
Argument Google staje się bardziej przekonujący, gdy odniesie się go do konkretnego przepływu pracy, niż gdy dotyczy wyłącznie lokalizacji oprogramowania. System tworzący porady może pozostawić wykonanie człowiekowi. System upoważniony do działania musi napotkać reguły, które organizacja jasno określiła.
Weźmy przykładowe zapotrzebowanie zakupowe. Pracownik może poprosić agenta o przygotowanie zamówienia u zatwierdzonego dostawcy. Zadanie językowe jest łatwe do opisania. Zadanie biznesowe obejmuje sprawdzenie upoważnienia, wybór właściwego konta, zastosowanie polityki zakupowej i obsługę niedostępnych pozycji.
Każdy etap wprowadza pytanie, którego płynny tekst nie może samodzielnie rozstrzygnąć. Który rekord jest autorytatywny? Czy osoba składająca wniosek ma uprawnienia? Czy proponowany zakup jest zgodny z polityką? Co dzieje się, jeśli zamówienie powiedzie się, ale potwierdzenie zawiedzie?
Pytania te ujawniają różnicę między wygenerowaniem odpowiedzi a sfinalizowaniem transakcji. Organizacja musi wiedzieć, co wydarzyło się w jej systemach, w tym w przypadku częściowego ukończenia. Pewna siebie odpowiedź konwersacyjna nie może zastąpić tych dowodów.
Istniejące aplikacje czasem kodują reguły, które pracownicy rozumieją dzięki doświadczeniu, a nie dokumentacji. Wdrożenie agenta może ujawnić tę ukrytą wiedzę. To, co wygląda na problem integracyjny, może w rzeczywistości obejmować nierozstrzygnięte decyzje dotyczące polityki, wyjątków lub odpowiedzialności.
Zastąpienie aplikacji niekoniecznie rozwiąże te decyzje. Może stworzyć lepsze miejsce do ich wyrażenia, ale ktoś nadal musi określić zamierzone zachowanie. Dlatego propozycje modernizacji powinny wskazywać granicę biznesową, którą poprawiają, zamiast opierać się na wieku bazowego oprogramowania.
Własny opis wdrożenia obsługi klienta Google dostarcza konkretnego przykładu. W kwietniu 2025 roku firma opisała, jak Wendy’s FreshAI obsługuje zamówienia drive-through i rozszerza działalność na 24 stany. Są to deklaracje dotyczące wdrożenia przedstawione przez firmę, a nie niezależny dowód ogólnej niezawodności agentów.
Przykład mimo to ilustruje wartość jasno określonego zadania. Zamawianie jedzenia ma rozpoznawalne dane wejściowe, ograniczenia menu i transakcję, która musi dotrzeć do operacji restauracji. Jego użyteczność zależy od połączeń z rzeczywistym procesem obsługi, a nie wyłącznie od jakości rozmowy.
Wewnętrzny przepływ pracy w przedsiębiorstwie potrzebuje porównywalnej jasności, nawet gdy jego granice są mniej widoczne. Prośba o zbadanie umowy, przygotowanie odnowienia lub rozwiązanie problemu z dostępem wymaga uzgodnionego celu końcowego. W przeciwnym razie zespół może ogłosić sukces, gdy agent tworzy tekst, podczas gdy pracownicy w dalszych etapach nadal wykonują zasadniczą pracę.
To sprawia, że integracja staje się kwestią odpowiedzialności. Ktoś musi być właścicielem przejścia od rekomendacji do zatwierdzonego działania oraz od działania do zweryfikowanego rezultatu. Bez takiej odpowiedzialności automatyzacja może redystrybuować wysiłek, pozostawiając proces biznesowy w dużej mierze niezmieniony.
Najmocniejszy argument za modernizacją identyfikuje te przejścia i pokazuje, że ulegają poprawie. Dowody powinny wskazywać mniej nierozwiązanych przekazań, niezawodne zakończenie oraz możliwe do opanowania odzyskiwanie sprawności, gdy coś pójdzie nie tak.
Google i Microsoft podkreślają różne drogi do gotowości
Dostawcy różnią się akcentami, ale oba ujęcia czynią przygotowanie organizacyjne kluczowym elementem użytecznego wdrożenia AI.
Stanowisko Google wyraźnie eksponuje swobodę architektoniczną. Badania Microsoft dotyczące organizacyjnej gotowości na AI większy nacisk kładą na zarządzanie, projektowanie pracy i ocenę. Raport z maja 2026 roku opiera się na ankiecie obejmującej 20 000 pracowników korzystających z AI na 10 rynkach.
Microsoft twierdzi, że warunki organizacyjne są silnie powiązane z wartością, jaką respondenci deklarują jako uzyskaną dzięki AI. Metodologia firmy wyraźnie rozróżnia związek statystyczny od przyczynowości. Ta ostrożność ma znaczenie przy porównywaniu ustaleń z relacją Google: żadne z badań nie ustanawia uniwersalnej recepty na udane wdrożenie.
Porównanie odzwierciedla również odmienne pozycje komercyjne. Google ma motywację, by zachęcać kupujących do ponownego rozważenia utrwalonych relacji biznesowych. Microsoft ma motywację, by uczynić istniejące środowiska pracy produktywnymi miejscami dla AI. Te motywacje pomagają wyjaśnić akcenty, nie unieważniając automatycznie ustaleń żadnej z firm.
Dla kupujących wybór wiąże się z praktycznymi kompromisami. Rozszerzenie istniejącego środowiska może zachować znane sposoby administracji i ograniczyć część pracy związanej z przejściem. Wprowadzenie alternatywy może zwiększyć możliwości negocjacyjne lub spełnić wymagania konkretnego przepływu pracy. Każda z tych dróg może rozczarować, jeśli organizacja pominie ocenę integracji.
Badanie Google Cloud AI powinno więc skłaniać do analizy zależności, a nie do automatycznego odrzucenia obecnego dostawcy. Zależność staje się istotna, gdy zmiana komponentu wymaga niedopuszczalnych zakłóceń, prowadzi do utraty niezbędnych informacji albo pozbawia firmę możliwości samodzielnego działania.
Ta obawa dotyczy nowego dostawcy równie mocno jak istniejącego. Przedsiębiorstwo może zastąpić znane ograniczenie mniej znanym ograniczeniem. Inna umowa sama w sobie nie oznacza większej swobody.
Rzeczywisty wybór wymaga dowodów operacyjnych. Kupujący musi rozumieć, czy rekordy pozostają użyteczne poza produktem, czy uprawnienia można odtworzyć oraz czy ukończoną pracę nadal można skontrolować. Te pytania są bardziej wymowne niż liczba nazw modeli dostępnych w menu.
Istnieje również różnica między wyborem modelu AI a zastąpieniem platformy obsługującej przepływ pracy. Model generuje lub interpretuje informacje. Platforma może przechowywać instrukcje, połączenia, rekordy i historię zatwierdzeń. Zmiana pierwszego elementu może być stosunkowo ograniczona, podczas gdy zmiana drugiego wpływa na cały proces.
To sprawia, że dyskusja zakupowa staje się bardziej wymagająca. Kupujący powinni oceniać pełny układ operacyjny, w tym utrzymujące się zobowiązania i warunki wyjścia. Wygodna demonstracja daje ograniczony wgląd w to, co dzieje się, gdy krytyczne połączenie przestaje działać lub jednostka biznesowa zmienia swój proces.
Zarządzanie wiedzą stanowi mniejszą analogię. Baza wiedzy z możliwością wyszukiwania jest użyteczna, gdy ludzie mogą odzyskiwać istotne materiały w odpowiednim kontekście. Automatyzacja przedsiębiorstwa nakłada dodatkowe wymagania, ponieważ odzyskane informacje mogą wpływać na działania o konsekwencjach organizacyjnych.
Najistotniejsze porównanie Google i Microsoft dotyczy zatem tego, jak każde proponowane środowisko wspiera rzeczywistą pracę. Preferencja wobec marki jest słabym substytutem analizy tego samego procesu, uprawnień i kryteriów akceptacji w konkurencyjnych podejściach.
Badanie pozostawia otwarte ważne pytania dotyczące przyczynowości i bezpieczeństwa
Zgłaszane trudności z utrzymaniem uzasadniają analizę, lecz nie dowodzą, że migracja do chmury przynosi lepsze wyniki dla każdego obciążenia.
Towarzyszący raport o gotowości przedsiębiorstw opisuje 20-minutową ankietę internetową, uzupełnioną wywiadami jakościowymi. Amerykańska próba decydentów przedstawia określoną perspektywę. Czytelnicy powinni zachować tę świadomość, omawiając przedsiębiorstwa w innych miejscach lub pracowników spoza działów zakupów i kierownictwa technologicznego.
Raport podaje również, że 78% respondentów uważa, iż utrzymanie technologii odciąga zasoby od AI, podczas gdy 48% uznaje swój stos technologiczny za gotowy do wdrożenia na skalę. Są to oceny zdolności i gotowości. Nie są to bezpośrednie pomiary godzin pracy inżynierów odzyskanych po migracji.
Respondenci mogą trafnie opisywać frustrację, nie wskazując jednak najlepszego rozwiązania. Zespół zmagający się z wymaganiami wsparcia może skorzystać na wymianie, lepszej konfiguracji, dodatkowej wiedzy specjalistycznej lub węższym zakresie AI. Wybór między tymi reakcjami wymaga dowodów ze środowiska, którego dotyczą.
Sponsoring komercyjny zasługuje na uwagę z tego samego powodu. Google sprzedaje usługi zgodne z proponowanym przez siebie kierunkiem. Właściwą odpowiedzią jest analiza definicji i porównanie alternatyw, przy jednoczesnym zachowaniu ustaleń, które pozostają użyteczne po weryfikacji.
Szczególnie istotna jest oparta na wdrożeniu definicja zawarta w badaniu. Uznanie lokalnie zarządzanego oprogramowania za rozwiązanie starszej generacji od początku czyni porównanie z chmurą centralnym elementem. Kupujący nadal potrzebują odrębnej oceny łatwości utrzymania, bezpieczeństwa, jakości integracji i przydatności biznesowej.
Bezpieczeństwo wprowadza kolejne ograniczenie dla prostej narracji o migracji. Usługa zarządzana może zmienić to, kto zajmuje się utrzymaniem infrastruktury. Nie eliminuje potrzeby decydowania, do jakich informacji agent może uzyskać dostęp ani które działania wymagają przeglądu.
Ramy zarządzania agentami Gartnera odnoszą się do tego rozróżnienia. Analityk Shiva Varma twierdzi, że jednolite mechanizmy kontroli mogą nadmiernie ograniczać proste agenty, a jednocześnie zbyt słabo ograniczać bardziej autonomiczne. Ramy rozróżniają obserwację, doradztwo i działania wymagające zatwierdzenia.
Ta perspektywa komplikuje założenie, że zwiększanie autonomii zawsze oznacza postęp. Agent ograniczony do przygotowania rekomendacji może być odpowiedni dla procesu o istotnych konsekwencjach. Wymaganie zatwierdzenia jest decyzją projektową, której wartość zależy od działania i jego potencjalnych skutków.
Ostrożny kupujący korporacyjny powinien w konsekwencji odróżniać usprawnienie infrastruktury od usprawnienia autoryzacji. Lepszy hosting może wspierać dostępność i utrzymanie. Lepsza autoryzacja określa, co system może robić. Oba aspekty zasługują na uwagę i żaden nie powinien zastępować drugiego.
Badanie Google Cloud AI nie rozstrzyga równowagi między tymi inwestycjami. Wskazuje postrzegane ograniczenia, które liderzy mogą zbadać. Błędem analitycznym byłoby przekształcenie tego sygnału w dowód, że jedna architektura, dostawca lub poziom autonomii jest z natury lepszy.
Po wdrożeniu pojawia się dalszy problem pomiarowy. Pracownicy mogą spędzać mniej czasu na inicjowaniu pracy, lecz więcej na sprawdzaniu niepewnych wyników. Twierdzenie o produktywności musi uwzględniać ten wysiłek weryfikacyjny, obok wsparcia i odzyskiwania sprawności. W przeciwnym razie pozorna automatyzacja może ukrywać pracę przeniesioną na inny zespół.
Obserwuj ukończone przepływy pracy, dowody przełączania i odzyskiwanie sprawności
Kolejne użyteczne dowody połączą decyzje modernizacyjne z wynikami operacyjnymi, które kupujący mogą zweryfikować.
W nadchodzących miesiącach pierwszym sygnałem wartym obserwacji będą raporty klientów dotyczące ukończonych przepływów pracy. Użyteczne ujawnienia będą odróżniać demonstrację od powtarzalnego użycia i wyjaśniać, co jest uznawane za pomyślne ukończenie. Powinny również wskazywać, gdzie nadal konieczna jest interwencja człowieka.
Te dowody wzmocniłyby argument Google, gdyby modernizacja usuwała rozpoznawalne ograniczenia i przynosiła powtarzalne usprawnienia operacyjne. Osłabiłyby szerokie twierdzenie o migracji, gdyby projekty nadal wymagały rozległych ręcznych napraw mimo wymiany środowiska bazowego.
Samo ukończenie nie wystarcza, gdy proces generuje niedopuszczalne błędy. Kupujący potrzebują dowodów dotyczących poprawności oraz wysiłku potrzebnego do rozwiązania wyjątków. Przepływ pracy, który kończy się szybko, ale tworzy późniejsze spory, przeniósł problem, zamiast go rozwiązać.
Drugim sygnałem jest wykazane przełączanie. Zapowiedzi produktów dotyczące konektorów lub wyboru modelu zasługują na dokładniejszą analizę, gdy klienci pokazują, że działający proces przetrwa zmianę komponentu. Zachowanie uprawnień, kryteriów oceny i użytecznych rekordów stanowiłoby istotny dowód elastyczności.
Przełączenie wymagające rozległej rekonstrukcji opowiada inną historię. Sugeruje, że nominalny wybór współistnieje ze znaczną zależnością operacyjną. To rozróżnienie będzie istotne, gdy kupujący porównają ugruntowane platformy pracy z alternatywnymi środowiskami agentowymi.
Trzecim sygnałem jest odzyskiwanie sprawności podczas kontrolowanej awarii. Relacje klientów i oceny techniczne powinny wyjaśniać, co dzieje się, gdy dostęp wygasa, podłączona aplikacja staje się niedostępna lub działanie zostaje ukończone tylko częściowo. Dowody odzyskiwania sprawności pokazują, jak system zachowuje się poza korzystną demonstracją.
Jasne przypisanie odpowiedzialności wzmocniłoby zaufanie. Zespół powinien móc zidentyfikować ostatni zweryfikowany stan, ustalić, które działania miały miejsce, i zdecydować, jak wznowić pracę. Jeśli odpowiedzi te wymagają za każdym razem nieformalnego dochodzenia, obciążenie operacyjne pozostaje nierozwiązane.
Te sygnały pomagają również oddzielić ograniczenia infrastrukturalne od ograniczeń procesowych. Nieudane połączenie może wskazywać na zależność techniczną. Nierozstrzygnięty spór dotyczący zatwierdzenia wskazuje na zarządzanie. Oba mogą blokować realizację, ale wymagają innych reakcji.
Badanie Google Cloud AI daje liderom przedsiębiorstw powód, by przeanalizować, na co przeznaczana jest zdolność inżynieryjna. Jego ustalenia są najcenniejsze, gdy przekłada się je na pytania o konkretną usługę, jej zależności i osoby odpowiedzialne za utrzymanie jej użyteczności.
Dla czytelników planujących inwestycję w AI: śledźcie pracę poza odpowiedzią asystenta. Zapytajcie, jaki wynik biznesowy musi zostać osiągnięty, które rekordy potwierdzają ukończenie i kto obsługuje wyjątki. Porównujcie propozycje względem tego samego wyniku, uwzględniając wysiłek migracyjny i ciągłą weryfikację. Zachowajcie spójne kryteria akceptacji przy ocenie obecnej platformy lub alternatywy. Domagajcie się, by twierdzenia o ograniczeniu utrzymania wskazywały usunięte zadania i zachowane obowiązki. Następnie szukajcie dowodów od klientów, że te zmiany utrzymują się podczas zwykłej działalności i kontrolowanych awarii. Która zależność obecnie uniemożliwia Twojemu zespołowi wykonanie wartościowej pracy i jakie dowody pokazałyby, że proponowana inwestycja rzeczywiście ją usuwa?
