Ten ostatni punkt jest niezwykle istotny i znane są przykłady firm, które w trakcie projektów migracyjnych, z powodu problemów z wystawianiem rachunków, utraciły płynność finansową i znalazły się wręcz na krawędzi bankructwa. W trakcie migracji należy jednak koncentrować się na minimalnym zbiorze wyznaczonych celów, zdecydowanie odrzucać wszelkie działania projektowe, które mają charakter opcjonalny bądź optymalizacyjny. Na "miejsca po przecinku" przychodzi czas po uruchomieniu całości systemu (cudzysłów nie dotyczy rachunkowości, gdzie arytmetyczna precyzja jest rzeczą oczywistą).

Dochodzimy tu do wniosku, który wynika z analizy przebiegu wielu nieudanych przedsięwzięć: istotną przyczyną niepowodzeń projektów IT są czynniki pozatechniczne. Brzmi to paradoksalnie, bo informatyka jak najbardziej wywołuje skojarzenia z dziedzinami technicznymi. Wydaje się zatem, że jeśli zakupimy supersprzęt, najnowocześniejszy software i do tego dodamy zdolnych programistów, to uzyskamy gwarancję sukcesu. Tymczasem, są to jedynie warunki konieczne pomyślności zamierzenia. Dodatkowo, musimy uwzględnić tzw. "czynnik ludzki". Również "miękkie" cechy i umiejętności pracowników (softskills), np. komunikatywność czy zdolność do pracy w zespole, współdecydują o sukcesie migracji.

Tymczasem, otwarcie dużego projektu informatycznego w firmie prowokuje jego uczestników z różnych działów do prób załatwienia przy okazji wszelkich problemów, które mają cokolwiek wspólnego z komputerami, mimo że można było to zrobić wcześniej. Można to także zrobić później - ale niekoniecznie w trakcie migracji, zwiększając w ten sposób związane z nią ryzyka. Przypomina to trochę nierozsądnego klienta w restauracji, który tylko dlatego, że woli jeden większy rachunek zamiast kilku mniejszych o podobnej sumie łącznej, zamawia nadmierną liczbę potraw. Szereg dań pozostaje nieskonsumowanych i muszą być innego dnia zamówione (i zapłacone!) jeszcze raz.

Dla przykładu, dział kontroli jakości ma swoją bazę danych surowców i dostawców, zasilaną interfejsami ERP. Pielęgnuje przy tym dłuższe, 60-znakowe nazwy wyrobów, bo materiałowy moduł starego ERP ma tylko 30 znaków w stosownym polu. Na wieść o migracji do nowego ERP, gdzie pole jest 40-znakowe, dla uniknięcia podwójnej pielęgnacji danych w dziale powstaje pomysł kompromisowego rozwiązania kwestii nazw przez sprowadzenie ich do tej właśnie długości. Jednocześnie, warto by inaczej je poklasyfikować, o czym też dyskutuje się od lat. Podobnie wiecznym i ciągle przesuwanym tematem jest kwestia ich synchronizacji (te same surowce kupowane od różnych dostawców). Inne działy również się uaktywniają, wykazując podobnie twórczą inwencję projektową. Zamiast sprawnie przeprowadzonej migracji ERP, grozi nam tu, skazany na niepowodzenie, moloch projektowy gwałtownej zmiany całego krajobrazu IT firmy. Wyjściem z sytuacji jest jasne zdefiniowanie celu migracyjnego: gwarancja tylko już posiadanej funkcjonalności aplikacyjnej. Dopiero w drugiej fazie wskazane jest stopniowe dochodzenie do pełnej efektywności nowego pakietu ERP.

Metody, modele, narzędzia

Już tylko fragment migracji ERP dotyczący bazy danych materiałowych stanowi poważne wyzwanie dla zespołu projektowego, zwłaszcza jeśli łączy się z fuzją przedsiębiorstw (projekt migracyjno-integracyjny). Pytamy zatem o mapę drogową (road map) migracji, dotyczącej sposobów przejścia do nowych rozwiązań w wymiarze informatycznym, gdzie mamy szereg alternatyw pokazanych w tab. 1.