Jeśli historia uczy czegokolwiek, to tylko tego, że ludzie nigdy niczego się nie nauczyli z historii.

Aleksander Krawczuk, Poczet cesarzy rzymskich

Szaleństwem jest robić wciąż to samo i oczekiwać różnych rezultatów

Albert Einstein

Wprowadzenie

Duże projekty technologiczne najczęściej kończą się niepowodzeniem. Czy istnieje sposób na zmniejszenie prawdopodobieństwa niepowodzenia? Tak: należy przyjrzeć się problemom związanym z definicją, zakresem i zarządzaniem, ale nie należy zbyt uważnie przyglądać się problemom związanym z talentami, wsparciem kadry kierowniczej i kulturą korporacyjną. Są one prawie niemożliwe do rozwiązania.

https://www.forbes.com/sites/steveandriole/2021/03/25/3-main-reasons-why-big-technology-projects-fail—why-many-companies-should-just-never-do-them/

Przyczyny porażek wdrożeń systemów ERP są stale te same od lat: łamanie zasad. Jakie to zasady? Generalnie:

1. dostawca ERP nie powinien zarządzać całym projektem ani zakresem projektu (konflikt interesu),
2. nie należy ingerować w strukturę kodu monolitycznego systemu (kastomizacja),
3. nie należy udostępniać bazy danych innym aplikacjom, integracje należy realizowac wyłącznie poprzez API,
4. należy chronić swoje know-how zapewniając sobie prawa majątkowego do każdej dedykowanej części systemu/kodu.

I niestety za każdym razem wniosek jest ten sam: nie brakuje dostępu do wiedzy jak tego nie robić, a mimo to nabywcy systemów ERP (ich prawnicy także) popełniają wszystkie kluczowe błędy .

Pierwszy punkt jest kluczowy, dlatego na czas projektu należy zaangażować eksperta po swojej stronie. Często można usłyszeć: zatrudnijcie “konsultanta ERP”, jednak pojawia sie pytanie kto to taki? Pod pojęciem “konsultant ERP” bardzo często spotyka się osoby specjalizujące się we wdrażaniu jednego konkretnego systemu. Taka osoba raczej sprzedaje konkretny system, bo nie pomaga w wyborze najwłaściwszego spośród wielu dostępnych na rynku. Jeżeli “konsultanta ERP” zapewnia od razu składający ofertę dostawca określonego systemu ERP, jest to po prostu wdrożeniowiec.

Wybór odpowiedniego systemu ERP i jego dostawcy jest krytycznym krokiem w każdym projekcie transformacji cyfrowej. Powinien to jednak być drugi krok. Pierwszym jest analiza biznesowa i przygotowanie wymagań.

Najczęstszą przyczyną kłopotów jest uznanie, że dostawca oprogramowania sam wykona analizę przedwdrożeniową, opracuje wymagania i potem wdroży system.

W efekcie projekt taki skupia się od początku na dopasowywaniu przedwcześnie wybranego systemu, zamiast najpierw opracować wymagania i przygotować się wewnętrznie do wdrożenia. Kilka spostrzeżeń na ten temat w artykule: Kto winien porażki projektu?

Jeżeli wdrożenie jest w toku…

…kolejny raz przekroczono termin i budżet, to masz problem. Nadal coś nie działa tak jak powinno, to masz problem.

Niestety problematyczne wdrożenia systemów ERP, nie są rzadkością. Wiele moich zleceń od klientów to wyprowadzanie ich z impasu sporu z dostawcą a potem kontynuacja wdrożenia lub zmiana systemu bo czasami najlepszym wyjściem okazuje się wyjście z posiadanego/wdrażanego systemu ERP z minimalnymi stratami.

Pierwsza ważna rzecz to uporządkowanie struktury ról w projekcie, jest to ich separacja:

• dostawca platformy i jej administracja (chmura jest akceptowalną opcją),
• projektant logiki biznesowej realizującej wymagania funkcjonalne (to są wymagania),
• dostawca standardowego oprogramowania,
• deweloper implementacji zaprojektowanej dedykowanej funkcjonalności na dostarczonej platformie.

Cele takiego podziału:

• separacja odpowiedzialności ról z konfliktem interesu (np. deweloper nie forsuje swojej platformy, administrator nie ma dostępu do danych, projektant na narzuca technologii),
• przenoszalność projektu na dowolną inną platformę (czyli możliwość implementacji tego samego projektu jeszcze raz z zachowaniem dostępu do 100% zgromadzonych danych)
• prawa majątkowe do pracy projektanta w 100% należą do inwestora, dedykowany kod napisany przez dewelopera (a nie kastomizacja standardowego oprogramowania) będzie z zasady własnością inwestora a nie dewelopera (oprogramowanie standardowe jest odseparowane i z zasady licencjonowane, nigdy kastomizowane).

Rozpoczynają współpracę proponuję:

1. Zrewidowanie dotychczasowego podejścia do wdrożenia i zarządzania zmianą (jeden monolityczny ERP to myślenie życzeniowe, uznanie, że jeden system nadaje sie do wszystkiego w firmie, w obecnych czasach jest utopią).
2. Opracowanie brakujących dokumentów: projekt integracji, logika biznesowa, plan komunikacji itp.

Na pytanie Co Pan proponuje na początek, zawsze odpowiadam:

Najogólniej trzeba by oprzeć sie na dokumentach operacyjnych, na to nałożyć ich treść (dane) i zmapować na posiadane aplikacje (i ich dostawców, to są ich obowiązki). Być może wystarczy tylko uporządkować aktualny stan wdrożenia i integracji.

Masz ochotę jeszcze czytać? Skąd te problemy…

Z mojej perspektywy (analizuję firmy i przyczyny ich porażek) największym problemem wielu firm, jest to, że nie rozumieją jak działają i dlaczego jeszcze nie zbankrutowały. W efekcie czasami wystarczy jedna “decyzja” by położyć firmę. Dlaczego? Bo w firmach istnieje wiele procedur i instrukcji, umów i zarządzeń, ale nie istnieje żaden jeden dokument łączący to w jedną całość, który pokazuje “z lotu ptaka” jak działa całość. A to znaczy, że nie istnieje w firmie narzędzie do analizy wpływu podejmowanych decyzji na całość organizacji. W efekcie te decyzje są dla firmy jak loteria.

W firmach zalegają kupione, i zainstalowane zgodnie z umową, stosy technologiczne, systemy ERP których wiele modułów nigdy nie zostało wdrożonych, mega hurtownie danych i ostatnio “supernowoczesne sztuczne inteligencje”. Są to ogromne pieniądze wydane na niespełnione obietnice dostawców tych produktów i usług. Ale wszystkie te dostawy miały pięknie napisane i wynegocjowane umowy.

Co poszło nie tak? Otóż najbardziej skomplikowaną operacją w biznesie jest dodawanie liczb i porównanie ciągów znaków. Problemem firm nigdy nie była technologia. Mamy bardzo wiele dostarczonych i nieprzydatnych stosów technologicznych. Czas przejazdu samochodem przez miasto w najmniejszym stopniu zależy od tego jakim samochodem jedziemy, a mimo to zawsze znajdzie się mieszkaniec miasta, który uwierzy sprzedawcy, że jak kupi Ferrari to przestanie sie spoźniać do pracy.

Problemem firm jest zrozumienie systemu zarzadzania informacją z perspektywy ludzi i zaprojektowanie systemu zarządzania a danymi z perspektywy systemu informatycznego. Bo system informatyczny przetwarza dane o świecie a nie świat: firma ma pracowników, oprogramowanie HR zarządza danymi o pracownika a nie pracownikami.

Kolejny problem to architektura oprogramowania i jej projektowanie. Jest to dokonywanie fundamentalnych wyborów strukturalnych, których zmiana po wdrożeniu jest kosztowna.

Typowy system ERP to miliony linii kodu programu i setki skojarzonych wzajemnie tabel baz danych. Takie systemy powstają latami, testowanie ich u producenta trwa miesiącami. Każda ingerencja w strukturę tego kodu i tabel baz danych to ryzyko zaburzenia stabilności systemu i ogromna pracochłonność usuwania skutków tych ingerencji.

Najbardziej znane na rynku systemy ERP maja architekturę z czasów gdy powstawały (lata 80-te):

Są to systemy budowane w oparciu o centralną bazę danych, bardzo skomplikowane, z silnie powiązanymi ze sobą komponentami. Typowe problemy w toku wdrożeń takich systemów:

• każda modyfikacja kosztuje kilka-kilkanaście tysięcy zł,
• każda modyfikacja to ryzyko naruszenia integralności całości,
• każda lokalna modyfikacja przenosi sie na resztę systemu (wspólna baza danych),
• nie da się oddzielić od siebie modułów,
• monopol jednego dostawcy, który zacznie Ci dyktować ceny,
• wspólna baza danych (model danych) jest kompromisem, dlatego bardzo często pewnych funkcjonalności jest po prostu niemożliwe.

Już od końca lat 90-tych mówi się o odejściu od tej architektury, gdyż jakakolwiek ingerencja w taki system to ogromne ryzyko jego destabilizacji. Na rynku od lat powstają dziedzinowe specjalizowane systemy z wbudowanymi opcjami integracji (interfejsy API: RPC, REST, SOAP itp.). Dlatego popularną i skuteczną formą wdrażania “starych” ERP jest wykorzystywanie ich tylko w wąskim zakresie (centralne operacje administracyjne). Podobnie wygląda “ratowanie” tych wdrożeń: rezygnujemy z modułów wymagających kastomizacji na rzecz wolnostojących integrowanych specjalizowanych, dziedzinowych aplikacji dobranych do naszych potrzeb .

Najnowocześniejszym podejściem jest to, co dziś nazywamy federacyjnym wdrożeniem dziedzinowych komponentów: zestaw zintegrowanych aplikacji dobranych do potrzeb konkretnej firmy. Na rynku jest obecnie ogromny wybór specjalizowanych aplikacji bardzo łatwych do integracji.

Skuteczne wdrożenie to ERP jako centralny system FK, zintegrowany z dziedzinowymi systemami różnych dostawców :

Taki system można bezpiecznie wdrażać etapami. Decyzje o wyborze kolejnych modułów podejmowane są “na ostatni moment”, czyli wtedy gdy mamy największą wiedzę. Bardzo często okazuje się też, że posiadany i wdrożony system FK nie wymaga wymiany (jeden z moich klientów ma potężny system produkcyjny MES-APS zintegrowany z poczciwą Comarch OPTIMA).

Zawieranie umów

Kilka porad, które uratowały pieniądze i wdrożenia u wielu moich klientów:

1. należy ściśle przestrzegać separacji treści umowy od opisu przedmiotu umowy, który powinien być w 100% odrębną treścią w postaci załącznika do tej umowy,
2. opis przedmiotu umowy to opracowanie inżynierskie a nie prawne.

Umowy na wdrażanie oprogramowania są szczególnie trudne z dwóch kluczowych powodów:

• produkt jest uważany za niematerialny (a to nie jest prawda),
• z produktem prawie zawsze wiąże się specjalistyczna usługa.

Nigdy nie podpisuj umowy na “dostawę oprogramowania” czy “wdrożenie oprogramowania”. Powodem jest to, że tak na prawdę celem jest komputer wraz z tym do czego nam służy: ludzie używają komputera, a nie “oprogramowania” (ono się wykonuje w komputerze bo jest jego częścią).

W konsekwencji żaden kod źródłowy nie jest Twoim celem, a posiadanie tego kodu np. na CD, NICZEGO Ci nie daje, bo oprogramowanie się wykonuje w określonym środowisku, to że masz “swój kod” nie oznacza, że “masz czego używać”, bo używać możesz komputera (sprzęt, specyficzne środowisko wykonawcze itp.) a nie kodu.

Pisałem o tym 12 lat temu z innego powodu w tekście Sprzedam Ci prawa do kodu czyli wielka ściema.

Praktycznie każdy zakup systemu (ERP, CRM itp..) to także usługi i warunki ich świadczenia zwane SLA (Service-Level Agreement). Ale to także jest Przedmiot Umowy a nie Umowa.

Powyższe dotyczy oczywiście także umów na wykonanie dedykowanego oprogramowania.

Proszę pamiętać, że rolą prawnika w projekcie jest bycie prawnikiem, a nie projektantem systemów i powiązanych z nimi specjalistycznych usług. To co widuję w treści umów: definicje systemów, usterek (moje ulubione to uszkodzenia niekrytyczne i obejścia) bywa dramatem i przyczyną kłopotów. Umowa powinna określać Warunki płatności, terminy dostaw, kary umowne itp. ale NIGDY tego co jest jej przedmiotem (nie licząc oczywiście paragrafu mówiącego, że przedmiot umowy został opisany w załączniku).

Nie pozwól by w Twojej umowie znalazły się takie “klauzule w umowach IT“.

Oferta

Polecam opis: Jak wyjść z długu technologicznego jakim jest centralny monolityczny system. Moja oferta to sprawdzone podejście:

Umowa ze mną obejmuje:

1. audyt: opracowanie modeli procesów biznesowych firmy i wskazanie na nich wymagań biznesowych i zakresu wdrożenia,
2. analiza fit-gap: ocenić różnicę pomiędzy planowanym stanem, “idealnym” a aktualnym faktycznym, opracowanie projektu rozwiązania,
3. jeżeli umowa jest w toku:
   • ustalenie z dostawcą formy zamknięcia aktualnego stanu: aneksu lub nowej umowy na dalsze prace (załącznikiem jest co do zasady produkt pierwszego i drugiego etapu powyżej: model procesów biznesowych i projekt rozwiązania jako wymaganie),
   • przejęcie zarządzania zakresem projektu (wymagania i projektowanie ich realizacji): (mój) nadzór autorski na bazie opracowanej mapy procesów i wymagań, dostawca realizuje wyłącznie implementację i wdrożenie pod dyktando Zamawiającego (czyli także moje).
4. jeżeli wdrożenie jest dopiero planowane:
   • wykonanie pkt. 1. i 2. i wybór dostawcy
5. może to być umowa z dowolną ze stron lub wyżej opisana umowa trójstronna.

Poniżej prosty formularz, który pomoże sformułować Wasze oczekiwania i pytanie do mnie.

Zapytanie

Źródła