Migracje komputerów mainframe kończą się niepowodzeniem z przewidywalnego powodu. Nie dlatego, że docelowa architektura chmury jest niewłaściwa. Nie dlatego, że narzędzia do konwersji z COBOL-a do Javy są niewystarczające. Nie dlatego, że zespołowi brakuje intencji lub budżetu. Ponoszą porażkę, ponieważ zespół zaczyna przenosić rzeczy, zanim wie, co się dzieje, zanim będzie w stanie odpowiedzieć dowodami, a nie założeniami, co robi każdy program, które programy zależą od których, jak dane przepływają przez system i co ulegnie awarii po wprowadzeniu zmian. Tryb awarii jest prawie zawsze ten sam: zależność odkryta w trakcie migracji, o której istnieniu nikt nie wiedział, reguła biznesowa ukryta w kopii dołączonej do 400 programów, zadanie wsadowe, które przesyła dane do dwunastu systemów niższego rzędu za pośrednictwem pliku, którego nikt nie pomyślał o udokumentowaniu.
Proces migracji komputerów mainframe wymaga starannego planowania i realizacji, aby zminimalizować ryzyko i zapewnić ciągłość działania. To stwierdzenie jest prawdziwe, ale niekompletne. Staranne planowanie nie polega na wyborze planu działania, dostawcy ani harmonogramu. Liczy się analiza strukturalna, przeprowadzana przed podjęciem jakiejkolwiek decyzji – analiza, która pokazuje, co system faktycznie zawiera i jak działa, w przeciwieństwie do tego, co podaje dokumentacja i jak został pierwotnie zaprojektowany. Te dwa opisy różnią się w każdym dużym środowisku mainframe, często o margines, który decyduje o powodzeniu lub wstrzymaniu migracji.
Zmapuj cały swój komputer mainframe
SMART TS XL analizuje każdy program COBOL, zadanie JCL, copybook i schemat SQL w środowisku komputera mainframe.
Ucz się więcejDlaczego migracje komputerów mainframe kończą się niepowodzeniem: luka w analizie
Migracje komputerów mainframe kończą się niepowodzeniem nie dlatego, że kod jest stary, ale dlatego, że nikt tak naprawdę nie wie, co kod robi, dopóki nie jest za późno. Ukryta logika. Nieudokumentowane przypadki skrajne. Zapomniane przepływy. To nie są teoretyczne zagrożenia, to praktyczne blokady, które wstrzymują projekty, wywołują problemy produkcyjne i po cichu podważają zaufanie do planu migracji.
Luka analityczna ma specyficzną strukturę. Organizacje, które od dwudziestu lub trzydziestu lat korzystają z systemów mainframe, nagromadziły zmiany, które nigdy nie znalazły odzwierciedlenia w dokumentacji, zależności, które ukształtowały się organicznie, gdy programy były sprzężone za pomocą współdzielonych plików, a nie jawnych interfejsów, oraz logikę biznesową, która istnieje jedynie w umysłach programistów, którzy od tego czasu przeszli na emeryturę. Zespoły traktujące dane mainframe jak standardowe pliki napotykają bolesne niespodzianki podczas migracji, gdy uświadamiają sobie, że „dane” obejmują dekady logiki biznesowej rozproszonej w instrukcjach warunkowych i 88-poziomowych nazwach warunków.
Istnieją cztery konkretne luki w wiedzy, które utrudniają migrację. Każda z nich ma technikę analizy, która pozwala ją wyeliminować. Żadnej z nich nie da się wyeliminować wyłącznie poprzez przegląd dokumentacji lub wywiady z programistami.
Luka 1: Nieznany inwentarz programów. Organizacje rutynowo odkrywają, że ich rzeczywista liczba programów jest znacznie wyższa niż udokumentowana. Programy napisane na potrzeby konkretnych potrzeb biznesowych, programy testowe, które stały się programami produkcyjnymi, programy narzędziowe, których nikt nie pamięta, że utworzyli – wszystkie one znajdują się w bibliotece obciążeń i mogą być wywoływane przez zadania JCL pojawiające się w harmonogramach produkcyjnych.
Luka 2: Nieudokumentowane zależności. Komputery mainframe obsługują dziesiątki systemów za pośrednictwem złożonych sieci oprogramowania pośredniczącego, takich jak WebSphere, CICS Transaction Gateway, Enterprise Service Bus, a także współdzielonych narzędzi, harmonogramów i procesów biznesowych. Błąd polega na zbyt długim oczekiwaniu na mapowanie wszystkich tych połączeń, zwłaszcza strumieni danych i wzorców konsumpcji.
Luka 3: Wbudowana logika biznesowa. Programy COBOL gromadzą reguły biznesowe przez dekady. Obliczenie, które było proste w 1985 roku, zostało od tego czasu zmodyfikowane przez dwunastu programistów, z których każdy dodał logikę warunkową odzwierciedlającą zmianę reguły biznesowej, która nigdy wcześniej nie została udokumentowana. Przeniesienie programu bez zrozumienia logiki powoduje powstanie zmigrowanego systemu, który oblicza inne wyniki niż oryginał – poprawnie z punktu widzenia kodu, ale niepoprawnie z punktu widzenia biznesu.
Luka 4: Sprzęganie formatu danych i schematu. Programy, które współdzielą dane za pośrednictwem plików, a nie interfejsów API, są sprzężone za pomocą kontraktów formatu danych, które nie istnieją nigdzie poza instrukcjami FD i COPY. Zmiana układu rekordów współdzielonego pliku powoduje awarię każdego programu, który go odczytuje, co może obejmować programy w zakresie migracji oraz programy, które pozostaną na komputerze mainframe, powodując cichy błąd integracji.
Osiem analiz, które muszą zostać przeprowadzone przed migracją
Poniższe analizy powinny zostać przeprowadzone przed podjęciem jakiejkolwiek decyzji o migracji i przed wprowadzeniem jakichkolwiek zmian w kodzie. Nie są to wstępne kroki, które należy wykonać szybko, lecz fundament, na którym opiera się każda kolejna decyzja.
1. Uzupełnij inwentaryzację programu
Pierwsza analiza to spis: jakie programy, strumienie zadań, kopie zapasowe, procedury i definicje danych faktycznie istnieją w środowisku. Nie jest to przegląd dokumentacji. To analiza rzeczywistych bibliotek obciążeń, bibliotek źródłowych i bibliotek procedur w celu utworzenia wiarygodnego spisu.
Inwentaryzacja powinna obejmować: każdy program źródłowy wraz z jego językiem i przybliżonym rozmiarem; każdy copybook i programy, które go zawierają; każdą skatalogowaną procedurę i zadania, które ją wywołują; każdy zestaw danych, który pojawia się w poleceniach DD, i programy, które go generują lub wykorzystują; każdą tabelę, widok i procedurę składowaną DB2, do których odwołuje się osadzony kod SQL.
W większości dużych środowisk mainframe, inwentaryzacja ta ujawnia programy, które były nieznane zespołowi planującemu migrację, czasami stanowiące margines 20-30% całkowitej liczby. Plany migracji oparte na niekompletnych inwentaryzacjach powodują przekroczenia kosztów, gdy brakujące programy zostają odkryte w trakcie projektu.
2. Mapowanie zależności we wszystkich językach
Po utworzeniu inwentarza, mapowanie zależności śledzi, jak każdy komponent łączy się z pozostałymi. Mapa zależności jest najważniejszą analizą przed migracją, ponieważ definiuje zakres każdej kolejnej zmiany.
Pełna mapa zależności obejmuje:
- Połączenia program-program: WYWOŁANIE, PERFORM, LINK, ATTACH i dynamiczne WYWOŁANIA rozwiązywane w czasie wykonywania
- Wywołania JCL do programu: każde polecenie EXEC PGM= w każdym strumieniu zadań JCL, w tym wywołania PROC z rozwiązanym symbolicznym podstawieniem parametrów
- Łańcuchy inkluzji podręczników:które programy obejmują które zeszyty, w tym zagnieżdżone zeszyty zawarte w innych zeszytach
- Relacje producent-konsument zbioru danych:które programy zapisują do których zestawów danych, które programy odczytują z tych zestawów danych i jakie zależności w sekwencyjnym łańcuchu zadań to tworzy
- Odwołania do schematu DB2: które programy odczytują z których tabel lub do których zapisują, które tabele współdzielą schemat z którymi innymi tabelami
Wynikiem jest graf skierowany. Każdą proponowaną zmianę dowolnego węzła w tym grafie można przeanalizować pod kątem wpływu, przechodząc przez krawędzie w celu wyliczenia wszystkich pozostałych węzłów, które od niej zależą. Bez tego grafu analiza wpływu jest jedynie zgadywaniem.
Zanim rozpocznie się jakakolwiek ingerencja w kod, kluczowa jest dogłębna przejrzystość. Poleganie na przestarzałej dokumentacji to poważny błąd; zautomatyzowane narzędzia muszą mapować aktualny stan, automatycznie skanując JCL, COBOL i PL/I, mapując wszystkie aplikacje, przepływy danych, zależności i ukryte zadania.
3. Ekstrakcja i dokumentacja logiki biznesowej
Programy COBOL zawierają logikę biznesową, której nie ma nigdzie indziej w organizacji. Jest to najczęściej pomijana analiza w planowaniu migracji i ta, która powoduje najkosztowniejsze awarie po migracji.
Ekstrakcja logiki biznesowej tworzy dokumentację obejmującą: reguły decyzyjne zakodowane w strukturach IF/THEN/ELSE i EVALUATE; wzory obliczeniowe w poleceniach COMPUTE; reguły sprawdzania poprawności danych w akapitach PROCEDURE DIVISION; ścieżki obsługi błędów i ich znaczenie biznesowe; oraz logikę zależną od sekwencji, w której kolejność operacji ma wpływ na poprawność wyników.
Ta analiza nie wymaga ręcznego czytania każdej linii każdego programu. Narzędzia do analizy statycznej, które rozumieją COBOL, potrafią identyfikować struktury decyzyjne, wyodrębniać logikę warunkową i generować ustrukturyzowaną dokumentację kodowanych reguł. Dane wyjściowe służą dwóm celom: dostarczają zespołowi ds. migracji specyfikacji niezbędnej do weryfikacji poprawności wyników migrowanego systemu oraz dają firmie pierwszą systematyczną dokumentację reguł biznesowych, które mogły istnieć jedynie w kodzie od dziesięcioleci.
4. Identyfikacja martwego kodu
Nie wszystko w komputerze mainframe wymaga migracji. Programy, które nigdy nie są wywoływane przez żaden strumień zadań, akapity, które nigdy nie są wykonywane przez żadną ścieżkę wywołania, elementy copybooka, do których nigdy się nie odwołujemy – wszystkie te elementy stanowią wysiłek migracyjny, który nie generuje żadnej wartości biznesowej.
Identyfikacja martwego kodu analizuje graf zależności w celu znalezienia komponentów bez odwołań przychodzących z żadnego strumienia zadań produkcyjnych. Komponenty te można wykluczyć z zakresu migracji, co obniża koszty bez ograniczania funkcjonalności. W dużych, starszych środowiskach, martwy kod stanowi zazwyczaj 10–25% całkowitej liczby zasobów, co oznacza znaczną redukcję zakresu, gdy jest identyfikowany systematycznie, a nie przypadkowo.
Analiza musi rozróżniać między kodem całkowicie martwym (nieosiągalnym z żadnej ścieżki wykonania produkcyjnego) a kodem rzadko wykonywanym (osiągalnym, ale rzadko uruchamianym). Kod rzadko wykonywany, taki jak procedury przetwarzania na koniec roku, programy raportowania regulacyjnego czy procedury odzyskiwania po awarii, może mieć krytyczne znaczenie pomimo rzadkiego wykonywania. Wyłączenie go z migracji pozwala uzyskać system, który działa poprawnie w 99% przypadków i ulega awarii dokładnie wtedy, gdy jest najbardziej potrzebny.
5. Złożoność i klasyfikacja ryzyka
Po utworzeniu inwentarza programów i mapy zależności, każdy program można sklasyfikować według złożoności i ryzyka migracji. Klasyfikacja ta wyznacza kolejność: programy o niskiej złożoności i niskiej zależności są migrowane jako pierwsze; programy o wysokiej złożoności i wysokiej zależności są migrowane na końcu, z najdokładniejszym pokryciem testowym.
Metryki złożoności dla ryzyka migracji COBOL:
| Współczynnik złożoności | Co mierzyć | Próg wysokiego ryzyka |
|---|---|---|
| Złożoność cyklomatyczna | Liczba gałęzi decyzyjnych na program | Powyżej 50 na program |
| Liczba zależności kopii | Liczba dołączonych zeszytów | Powyżej 20 zeszytów |
| Liczba wywołań | Liczba programów wywołujących ten program | Powyżej 15 osób dzwoniących |
| Odniesienia do zbiorów danych | Liczba odczytanych lub zapisanych zestawów danych | Powyżej 30 zestawów danych |
| Wbudowany SQL | Liczba instrukcji SQL | Powyżej 100 oświadczeń |
| Rozmowy telefoniczne EXEC CICS | Sprzęganie serwera transakcyjnego | Jakakolwiek zależność CICS |
| Dynamiczne wywołania | Połączenia rozwiązywane w czasie wykonywania | Jakiekolwiek dynamiczne połączenie |
| Wywołania asemblera | Wbudowana logika inna niż COBOL | Dowolne wywołanie Assemblera |
Programy uzyskujące wysokie wyniki w wielu czynnikach reprezentują komponenty migracji o najwyższym ryzyku. Wymagają one najdokładniejszej analizy, najbardziej doświadczonych inżynierów ds. migracji i najbardziej kompleksowego zakresu testów.
6. Analiza zależności okna wsadowego i harmonogramowania
Zadania wsadowe na komputerach mainframe są uruchamiane w zaplanowanych oknach z złożonymi łańcuchami zależności: Zadanie B nie może zostać uruchomione, dopóki Zadanie A nie zakończy się pomyślnie; Zadanie C jest uruchamiane tylko w ostatni dzień roboczy miesiąca; Zadanie D ma ograniczenie maksymalnego czasu wykonania, które wpływa na czas rozpoczęcia Zadania E. Te zależności harmonogramu są częścią operacyjnego zachowania systemu i muszą zostać powielone w środowisku docelowym.
Analiza okna wsadowego dokumentuje: pełny łańcuch wykonania dla każdej partii produkcyjnej; ograniczenia czasowe dla każdego kroku; logikę wykonania warunkowego (co się dzieje, gdy krok się nie powiedzie lub wygeneruje kod powrotu różny od zera); zestawy danych przepływające między krokami; a także zewnętrzne wyzwalacze i powiadomienia generowane przez system wsadowy.
W przypadku środowisk chmurowych oznacza to: odpowiednią konfigurację potoku CI/CD lub koordynacji przepływu pracy; konfigurację obsługi błędów i alertów; konfigurację monitorowania i SLA; oraz integrację z systemami podrzędnymi, które odbierają dane wyjściowe wsadowe.
7. Ocena jakości i formatu danych
Starsze systemy często zawierają tysiące linii kodu napisanych w COBOL-u, PL/I lub assemblerze, z których wiele może być słabo udokumentowanych lub ściśle powiązanych. Użyj narzędzi do analizy statycznej, aby wykryć dług techniczny, zbędny kod oraz moduły, które można zmodularyzować lub wycofać.
Ocena jakości danych polega na porównaniu rzeczywistych danych w zbiorach danych produkcyjnych z definicjami formatu w COBOL FD i definicjami copybook. Rozbieżności są powszechne: pola dziesiętne zawierające nieprawidłowe wzorce bitowe dla niektórych typów rekordów, pola o zmiennej długości, w których wskaźnik długości jest poza zakresem dla podzbioru rekordów, pola znakowe EBCDIC zawierające wartości niemożliwe do wyświetlenia w określonych pozycjach.
Te rozbieżności muszą zostać zidentyfikowane i rozwiązane przed migracją, a nie odkryte podczas testów migracji. Migracja danych, która obejmuje przeniesienie 500 milionów rekordów, a następnie odkrywa, że 0.1% z nich ma nieprawidłowe formaty, ma defekt wpływający na produkcję, który był obecny w danych źródłowych i nieznany aż do etapu walidacji.
8. Integracja i mapowanie systemów zewnętrznych
Twoje źródło danych musi obejmować każdy system pobierający dane z komputera mainframe, od narzędzi do raportowania po integracje z partnerami, ponieważ projekty modernizacyjne nie mogą zostać uruchomione, jeśli zespoły na późnym etapie rozwoju odkryją, że zachowanie tych źródeł danych było konieczne, ale nieplanowane.
Mapowanie integracji identyfikuje każdy system poza komputerem mainframe, który otrzymuje z niego dane lub wysyła do niego dane: aplikacje downstream, które wykorzystują dane wsadowe za pośrednictwem transferu plików; interfejsy czasu rzeczywistego za pośrednictwem MQ, CICS lub wywołań API; integracje partnerskie, które opierają się na określonych formatach plików i harmonogramach transmisji; systemy raportowania, które bezpośrednio wysyłają zapytania do tabel DB2; oraz kanały magazynu danych, które pobierają przetworzone dane z komputera mainframe.
Każdy punkt integracji stanowi potencjalne ryzyko przełączenia: zmigrowany system, który generuje dane w formacie nieoczekiwanym przez system podrzędny, spowoduje cichą awarię, która może nie zostać wykryta, dopóki odbiorca podrzędny nie zgłosi anomalii. Mapowanie integracji to analiza, która sprawia, że planowanie przełączenia jest kompleksowe, a nie optymistyczne.
Wybór strategii migracji na podstawie wyników analizy
Analiza przed migracją nie tylko minimalizuje ryzyko związane z migracją, ale także określa, która strategia migracji jest odpowiednia dla każdego komponentu. Zespoły migrują obciążenia komputerów mainframe na różne sposoby, w zależności od tego, jak dużą liczbę zmian są w stanie obsłużyć. Wyniki analizy bezpośrednio wpływają na tę decyzję.
| Analiza Znalezienia | Zalecana strategia | racjonalne uzasadnienie |
|---|---|---|
| Niska złożoność, niewiele zależności, brak dynamicznych wywołań | Przenoszenie (lift-and-shift) | Najniższe ryzyko; równoważność behawioralna możliwa do osiągnięcia szybko |
| Umiarkowana złożoność, dobrze udokumentowana logika biznesowa | Replatformowanie | Pewne modyfikacje są dopuszczalne, logika jest zrozumiała |
| Wysoka złożoność, gęsty graf zależności | Fazowany dusiciel-fig | Ekstrakcja przyrostowa; zachowanie komputera głównego jako rdzenia podczas modernizacji wokół niego |
| Wspólny program krytyczny, ponad 100 osób dzwoniących | Opakowanie API | Udostępniaj jako usługę; migruj konsumentów bez dotykania programu |
| Programy z nieprawidłowymi danymi lub problemami z formatem | Najpierw naprawa danych | Migracja nie może się powieść, dopóki dane nie będą czyste |
| Analiza potwierdziła martwy kod | Przejść na emeryturę | Migracja nie jest wymagana; usuń z zakresu |
| Nieudokumentowana logika biznesowa, brak dostępnego SME | Wymagana głęboka analiza | Nie można bezpiecznie migrować, dopóki logika nie zostanie wyodrębniona i udokumentowana |
Budowanie sekwencji migracji z grafu zależności
Graf zależności, po ukończeniu, bezpośrednio definiuje kolejność migracji. Komponenty niezależności od innych komponentów mainframe można migrować niezależnie i wcześniej. Komponenty, od których zależy wiele innych komponentów, muszą zostać zmigrowane na końcu, po przygotowaniu wszystkich ich komponentów zależnych.
Praktyczne podejście sekwencyjne:
Faza 1: Programy narzędziowe i samodzielne zadania wsadowe. Programy bez programów wywołujących i bez współdzielonych zestawów danych. Można je migrować w izolacji, bez konieczności koordynacji.
Faza 2: Programy liściowe w drzewie zależności. Programy, które wywołują inne, ale nie są wywoływane przez wiele programów. Migracja tych programów usuwa je z zakresu zależności pozostałych programów.
Faza 3: Programy sprzężone z danymi. Grupy programów, które współdzielą zestawy danych, mogą być migrowane razem jako całość, co pozwala na rozwiązanie kontraktu formatu danych w ramach migrowanej grupy.
Faza 4: Programy usług współdzielonych. Programy z wieloma wywołującymi, czyli węzły o dużej liczbie połączeń w grafie zależności, migrowały dopiero po sprawdzeniu wszystkich wywołujących pod kątem migrowanej implementacji.
Faza 5: Podstawowe programy transakcyjne. Komponenty o najwyższym ryzyku, migrowane na końcu, z najbardziej kompleksowym pokryciem testowym i najbardziej kontrolowanym procesem przejścia na nową wersję.
Ta sekwencja nie jest ogólną heurystyką, lecz wynika ze szczegółowego grafu zależności konkretnego migrowanego systemu. Dwa środowiska mainframe z tą samą liczbą programów będą miały zupełnie inne optymalne sekwencje migracji, ponieważ ich struktury zależności się różnią.
W jaki sposób SMART TS XL Tworzy analizę przed migracją
SMART TS XL Automatycznie wykonuje wszystkie osiem analiz opisanych w tym artykule, analizując rzeczywisty kod źródłowy każdego komponentu w środowisku. Nie opiera się na dokumentacji, wywiadach z programistami ani istniejących diagramach, lecz czerpie model strukturalny z samego kodu, dzięki czemu model jest dokładny nawet w przypadku programów, które nigdy nie zostały udokumentowane, oraz zależności, które powstały bez czyjegokolwiek zamiaru.
Analiza modernizacji starszych wersji rozpoczyna się od wygenerowania kompletnego inwentarza: każdy program COBOL, strumień zadań JCL, copybook, PROC i schemat SQL jest katalogowany wraz z lokalizacją źródłową, rozmiarem, wersją językową i wstępnym wskaźnikiem złożoności. Mapowanie zależności aplikacji tworzy kompletny graf zależności, rozwiązując parametry symboliczne JCL za pomocą funkcji rozszerzania JCL , aby pokazać faktycznie wywołane programy, a nie nierozwiązane odwołania do szablonów.
Funkcja analizy wpływu umożliwia tworzenie zapytań do grafu zależności: przed migracją dowolnego komponentu zespół może sprawdzić, na co wpłynie usunięcie go z komputera mainframe, i otrzymać enumerowaną, ustrukturyzowaną listę wszystkich komponentów zależnych wymagających walidacji lub koordynacji. Funkcja wyszukiwania korporacyjnego umożliwia jednoczesne przeszukiwanie całego inwentarza we wszystkich językach, umożliwiając znalezienie każdego programu odczytującego określony zestaw danych, każdego copybooka definiującego określone pole, każdego polecenia SQL odwołującego się do określonej kolumny – wszystko to w ciągu kilku sekund w bazie kodu liczącej miliony wierszy.
Wynikiem analizy przedmigracyjnej nie jest plan projektu. To dowody strukturalne: graf zależności, klasyfikacja złożoności, inwentaryzacja martwego kodu, dokumentacja logiki biznesowej i mapa integracji, które razem wskazują zespołowi ds. migracji, z czym dokładnie pracuje. To właśnie te dowody decydują o różnicy między migracją, która ujawnia niespodzianki w środowisku produkcyjnym, a migracją, która ujawnia je w analizie, gdzie koszt ich znalezienia i rozwiązania wynosi tygodnie, a nie miesiące.
Analiza nie jest obciążeniem, jest migracją
Najczęstszym zarzutem wobec kompleksowej analizy przed migracją jest harmonogram: organizacja ustaliła datę rozpoczęcia migracji, presja ze strony kierownictwa jest duża, a poświęcenie sześciu do ośmiu tygodni na analizę przed wprowadzeniem jakichkolwiek zmian w kodzie wydaje się opóźnieniem. To rozumowanie odwraca rachunek ryzyka. Gdy reguły są widoczne, a przepływy zmapowane, projekt przechodzi od spekulacji do inżynierii. Narzędzia automatyzacji uwidaczniają to, co niewidoczne, a to jest najważniejsze.
Migracja rozpoczynająca się bez pełnej analizy nie rozpoczyna się szybciej, lecz z nieznanym zakresem. Nieznany zakres powoduje niespodzianki w harmonogramie, przekroczenia budżetu i incydenty produkcyjne, gdy nieodkryte zależności się ujawniają. Faza analizy nie opóźnia migracji; ona jest migracją. Każda zależność odkryta podczas analizy, a nie podczas przełączenia, jest incydentem produkcyjnym, który nie wystąpił. Każdy program zidentyfikowany jako martwy kod przed migracją to niewykorzystany wysiłek. Każda reguła biznesowa udokumentowana przed konwersją jest kryterium walidacji, które można przetestować, a nie zgadywać.
Organizacje, które odnoszą sukces, to te, które proaktywnie radzą sobie ze złożonością, wcześnie mapują zależności, demokratyzują wiedzę, koncentrują się na wartości biznesowej i od pierwszego dnia ustalają jasne cele. To nie tylko najlepsze praktyki, ale i różnica między projektami transformacyjnymi, które przynoszą mierzalny zwrot z inwestycji (ROI), a tymi, które stają się przestrogą.
