Lidl w 2018 roku zrezygnował z wdrożenia systemu SAP ("eLWIS") po siedmiu latach prac i stracił około 500 mln euro, wracając do starego systemu: pierwotny budżet 201 mln euro spuchł do połowy miliarda, głównie przez nadmierną customizację (Lidl chciał liczyć zapasy po cenach zakupu, SAP był zaprojektowany pod ceny detaliczne) zamiast dostosowania procesów firmy do standardu systemu. To ekstremalny przykład mechanizmu, który w mniejszej skali dotyka większości dużych wdrożeń IT: im dłużej trwa projekt bez weryfikacji z rzeczywistością, tym więcej kosztuje naprawienie złego kierunku.
Skala problemu w liczbach, nie tylko w jednym głośnym przypadku
McKinsey wspólnie z University of Oxford (Bloch, Blumberg, Laartz, 2012) przeanalizowali ponad 5 400 dużych projektów IT o budżecie startowym powyżej 15 mln USD: średnio 45% przekroczenia budżetu, 7% przekroczenia czasu i 56% mniejszą wartość biznesową niż zakładano na starcie. 17% projektów było na tyle złych, że zagrażały istnieniu całej firmy: badacze nazwali je "czarnymi łabędziami", z przekroczeniami rzędu 200-400%. Każdy dodatkowy rok trwania projektu podnosił przeciętne przekroczenie budżetu o kolejne 15%.
Standish Group w CHAOS Report 2020 podaje bardziej umiarkowany, ale wciąż niepokojący obraz: 31% projektów kończy się sukcesem, 50% jest "zagrożonych" (przekracza budżet, czas lub zakres), 19% to całkowita porażka. Sukces silnie zależy od wielkości projektu: 61% dla małych wdrożeń wobec zaledwie 6% dla największych ("grand"). Metodyka Agile kończy się sukcesem około trzykrotnie częściej niż Waterfall, a Waterfall dwukrotnie częściej kończy się porażką (dane CHAOS z 2015 roku: Agile 39% sukces/11% porażka, Waterfall 11% sukces/29% porażka). Warto dodać zastrzeżenie: metodologia CHAOS bywa krytykowana (Eveleens & Verhoef, 2010, IEEE Software) za definicje mogące zawyżać wskaźnik porażek. Badanie McKinsey/Oxford jest metodologicznie mocniejsze, ale kierunek obu badań jest zgodny.
Dlaczego zarządy firm przemysłowych i budowlanych boją się wdrożeń IT
Branża budowlana jest jednym z najmniej scyfryzowanych sektorów gospodarki: przedostatnia w USA, ostatnia w Europie na indeksie cyfryzacji McKinsey Global Institute (2017). To nie przypadek, że zarządy w tej branży podchodzą do wdrożeń systemowych z nieufnością: doświadczenia z dużymi, kaskadowymi projektami ERP czy CRM (Lidl to nie jedyny przypadek, podobne, choć mniej spektakularne katastrofy dotknęły Hershey, Revlon czy Waste Management przy wdrożeniach SAP) uczą, że wielki projekt typu big-bang to wysoka ekspozycja na scenariusz, w którym firma dowiaduje się o błędnym kierunku dopiero po wydaniu większości budżetu.
Jak wygląda wdrożenie AI w przedsiębiorstwie bez ryzyka finansowego
Model, który stosujemy, odwraca kolejność decyzji: podstawowy klikalny prototyp pokazujemy już na pierwszym spotkaniu, a wersję dopasowaną do konkretnej firmy, w 48 godzin od rozmowy, w której ustalimy, czego dokładnie potrzeba w systemie (zwykle pierwsze lub drugie spotkanie). Decyzja o zakresie i budżecie zapada dopiero po zobaczeniu działającego interfejsu, nie na podstawie samej specyfikacji - pisaliśmy o tym szerzej przy okazji tego, dlaczego warto zobaczyć prototyp przed podpisaniem umowy. Kierownik projektu w jednej z firm realizujących instalacje przemysłowe dla energetyki i przemysłu chemicznego, oceniając taki prototyp, wskazał od razu, która funkcja niesie największą wartość: jedną skrzynkę mailową przypisaną do projektu. "Najlepsza funkcjonalność to zdecydowanie ta jedna skrzynka pod projekt. To naprawdę ułatwi pracę" - ocenił przy tym, że rola e-maila jako głównego narzędzia pracy mogłaby dzięki temu spaść nawet o 80%.
Wdrożenie sztucznej inteligencji w firmie krok po kroku - przewodnik po modelu MVP
W praktyce kolejność wygląda tak: pierwsze spotkanie kończy się podstawowym prototypem od razu, a w 48 godzin od ustalenia zakresu powstaje wersja dopasowana do konkretnej firmy. Dopiero po jej akceptacji zapada decyzja o budżecie i harmonogramie - pierwsza działająca wersja systemu (MVP) powstaje w 1-2 miesiące, a kolejne funkcje dochodzą etapami, z odbiorem konkretnego, działającego zakresu po każdym etapie. To bezpośrednia odpowiedź na mechanizm opisany przez Boehm cost of change curve: koszt wprowadzenia zmiany rośnie wykładniczo w późnej fazie projektu, więc krótkie iteracje (korekta kierunku co dwa tygodnie zamiast raz na kilka miesięcy) ograniczają ekspozycję na scenariusz w stylu Lidla, zanim skala błędu urośnie do rozmiaru zagrażającego całej firmie. Ryzyko finansowe nie znika, ale jest rozłożone na małe, odwracalne kroki zamiast jednej decyzji o całym budżecie na starcie.
Jeśli obawiasz się, że wdrożenie nowego systemu w Twojej firmie skończy się jak niejeden duży projekt ERP - zobacz, jak wygląda alternatywa. Opisz swoją sytuację w formularzu kontaktowym albo od razu umów rozmowę wstępną, a proces krok po kroku znajdziesz na podstronie "Jak to działa".